North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Access to the IPv4 net for IPv6-only systems

  • From: John Curran
  • Date: Mon Oct 01 10:36:32 2007

At 9:20 AM -0400 10/1/07, Alain Durand wrote:
>On 9/29/07 11:10 PM, "John Curran" <[email protected]> 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).