> ...prefer to say it the other way ... if your evidence is actual,
> it shows the other groups are disconnected with this one.
> 
> I agree, but either way there is a disconnect.

Eric,

One simple way to cure the disconnect would be to actually read the
drafts that you are quoting, starting with the H/H local addresses
specification. I am familiar with several of these drafts, and you
appear to be way off base:

- http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt
        Deals with signaling, i.e. how to learn the mappings established
by a
        NAT. Fundamentally a "NAT traversal" technology, made necessary
to 
        remedy the effect of NAT. Certainly not a NAT advocacy paper.

-
http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal
-00.txt
        Tries to define an extension of the STUN technology to traverse
NAT. 
        Again, NAT remedy rather than NAT advocacy.

- http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt
        Describes the state of the art in traversal techniques for IPv4
NAT,
        and recommends ways for these NATs to allow P2P traffic. Never
        mentions IPv6.

- http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-07.txt
        Definition of a MIB for controlling NAT. Also used by MIDCOM to
        specify NAT traversal technologies.

- http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt
        Describes how to allocate global IPv6 addresses so hosts behind 
        An IPv4 NAT could behave as if directly connected to the IPv6 
        Internet.

- http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt
        Negotiation of NAT traversal for IPSEC traffic.

In fact, a common point of all these drafts is to try to bypass the NAT,
to obtain global connectivity despites the NAT, often using side effects
of the NAT implementation. Most of that work is driven by application
developers who are making their best to make NAT go away. None of these
drafts is an advocacy for NAT, quite the contrary in fact.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to