I think the real point is that it's quite unrealistic at this
stage in the history of NAT to imagine that we can make the mess
(which was inevitable anyway) any better by codifying the
least-bad form of NAT behaviour. The NAT codes are shipped, burnt
into lots of devices, and the IETF can't do much about it.
So I think this would be wasted effort.
Brian
Pekka Savola wrote:
[[ Resending the comment to ietf(_at_)ietf(_dot_)org as
ietf-behave(_at_)list(_dot_)sipfoundry(_dot_)org illegitimately *) automatically
rejects the posts by non-subscribers.
*) http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
]]
On Fri, 17 Sep 2004, The IESG wrote:
A new IETF working group has been proposed in the Transport Area. The IESG has
not made any determination as yet. The following description was submitted,
and is provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg(_at_)ietf(_dot_)org) by September 24.
I do not think it's useful to spend too much energy in trying to
figure how NATs work (or do not work).
Further, even though the draft charter talks about IPv6 and eventual
deployment, it seems to be ignoring the fact that if you use an IPv6
transition mechanism which is specifically designed to traverse NATs
(see e.g., draft-huitema-v6ops-teredo-xx [this should probably be on
the 'reading list']), you don't have these problems.
And if you are able to use a transition mechanism which is not tied to
the IP versions supported by your ISP own, the barrier for IPv6
deployment should be significantly reduced.
Therefore the issue seems to boil down to whether the NAT traversal
mechanism described in draft-huitema-v6ops-teredo-xx is sufficient to
traverse the NATs, and whether the support for something like Teredo
is expected to be sufficiently commonplace to depend on it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf