Subject: RE: Local addresses and security? (was: SL deprecation draft)

From: "Christian Huitema" <[email-masked]>
Date: Mon, 24 Nov 2003 09:00:02 -0800

> ...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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------