At 9:20 AM -0400 10/1/07, Alain Durand wrote:
On 9/29/07 11:10 PM, "John Curran" <jcurran@mail.com> wrote: The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet"
===> John,
With all due respect, I will recommend you to read 4966, reasons to move NAT-PT to historical
Alain - No offense taken. The full quote in context is: "One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet" It's actually the first line of section 5 of RFC 4966. While quite a bit of the document covers the difficultly in doing NAT-PT correctly, the only reason given why it's actually undesirable is that statements at the start of section 5. The sentence which follows begins as such: "Therefore, because IPv6 may be expected to remove the need for NATs and similar impediments to transparency, ..." The paper argues heavily that NAT-PT is a mistake because it gets in the way of IPv6 developers building applications which require end-to-end transparency. The conclusion, in particular, is quite telling: "The potential constraints on the development of IPv6 applications described in Section 5 are particularly undesirable. " I have a lot of sympathy for those all those IPv6 application developers who are constrained by the potential NAT-PT gateways in their way, but they're likely to be constrained in any case if the other end is IPv4 and not moving to IPv6 anytime soon... Furthermore, if we don't have a semitransparent way of giving IPv6-only new customers a modicum of connectivity to existing web and email addresses, the IPv6 community may find themselves with a much bigger impediment to transparency: the proliferation of IPv4 NATs and no adoption of IPv6. Hence the confusion over the conclusion that the impact of NAT-PT on the end-to-end model is so undesirable that we need to limit deployment of it (despite the fact that it allows a viable method of connecting new customers via pure IPv6 and an eventual return to a model which is a lot closer to the desired end-state of one protocol end-to-end). /John