ietf
[Top] [All Lists]

Re: terminology proposal: NAT+PT (or NAT64 ?)

2007-11-15 19:18:51

The traditional NAPT model which can only permit outgoing
sessions is not sufficient for an effective transition from v4 to v6.

Here we differ.  I find that to be good enough for the vast majority
of cases, and in those cases where it doesn't work one can deploy
native access so that the NAT-PT box is avoided entirely.

Given that the vast majority of users are behind NAPT boxes today,
either provided by their ISP or purchased at a store, I have a problem
with anyone saying that providing the equivalent (poor) level of
functionality via NAT-PT is insufficient.
the two cases aren't as similar as they may seem at first, for a couple
of reasons:

1. "users" != "hosts".  in a case where we run out of v4 addresses, it's
not sufficient to just move "users" to IPv6 and let the "services" stay
in IPv4.   and a "solution" that introduces more special cases only
creates pain.  we need a solution that supports an arbitrary mixture of
v4 and v6 peers in an application.

2. "today" != "tomorrow".  the Internet (and the way people use it)
changes significantly every two years.   analysis based on how things
are today is not reliable at predicting what will satisfy tomorrow's needs.
  If we give v6-only users NAT-PT to access v4-only hosts and native
(non-NAT) v6 access, that is better than they have today. The only
other option is multi-layered v4 NAT, which is arguably worse from an
e2e standpoint and certainly from an administrative one.
I see many other options than these.  But I'd rather spend time writing
up my proposal than answering dozens of emails about it.

As a matter of fact, I like your choice of "NAT-XY" to describe the
general mechanism you are working on (if I got it right). This IMHO
shows the expressive power of generalizing Alain's approach,
introducing a dash, as you did, to separate IP versions
identifications from "NAT". What about NAT-XX, NAT-XY, NAT-44,
NAT-64, NAT-46  ? I would be very happy if this debate, introduced
by Ran Atkinson, would end up with such a step against confusion.

To me NAT-64 and NAT-46 are even more confusing, because I
can't tell which end is which.  If sessions can be initiated from either
the v4 or the v6 side (which IMO is a necessary condition for the
translation box to be effective), what's the significance of the first
digit vs. the second?

I find the distinction mostly useless since any NAT-PT box will
necessarily need to translate a given flow in both directions because
of the state involved.

However, there is a potentially-useful distinction between deployment
types. For instance, a NAT-PT box at an eyeball site that allows local
IPv6-only hosts to access remote IPv4-only hosts will look somewhat
different than a NAT-PT box at a content site that allows remote
IPv6-only hosts to access local IPv4-only hosts.  (And ditto for
reversing the versions for each case...)  We may need to distinguish
between roles, because the expectations and configurations will
differ, but the core technology and protocol-mangling is the same for
all of them.
Agreed that the different cases require slightly different solutions.  I
actually think this varies on a per application basis.  But I'd rather
see a comprehensive solution developed that considers the different
cases, than to see piecemeal solutions developed for each separate
case.  I see a big advantage to having a common interface (API and
control protocol) across all of the different solutions.

Keith


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf