Subject: terminology proposal: NAT+PT

From: RJ Atkinson <[email-masked]>
Date: Wed, 14 Nov 2007 07:46:49 -0500

NAT, NAPT, and NAT-PT have been used for some while now to refer
to various sorts of address/port translation within an IPv4-only
network.

Recently, there has been some discussion of network address with
IPv6::IPv4 protocol translation.  Some have referred to that as
NAT-PT also, which can be confusing to some.

I'd like to suggest that when talking about the concept of
translating protocol versions (IPv6 <-> IPv4) in addition
to, or instead of, altering port number or IP address, we
use the short-hand notation "NAT+PT".

Cheers,

Ran

(PS:  Perhaps I've been burning too many DVDs lately. :-)

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

 "operations traffic"
are still prohibited from deploying IPv6 -- for myriad reasons,
including unresolved security concerns with IPv6.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Nov 2007 17:41:20 +0100

> use the short-hand notation "NAT+PT".
Full agreement on the importance of the choice of a non confusing acronym.

Alain Durand proposed in 2002  :
 -  NAT64 for IPv6 -> IPv4
 -  NAT46 for IPv4 -> IPv6

This has IMO the following advantages :
 - different acronyms for IPv6 -> IPv4 and IPv4 -> IPv6 (They are really 
different in operation and in purpose. IMO NAT64 is necessary, while 
NAT46 is not and has problems of its own)
 - NAT64 is  more intuitive and self explanatory than NAT+PT.

Would you agree on that kind of proposal ?

Regards

Rémi

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Nov 2007 19:18:24 +0100

> use the short-hand notation "NAT+PT".

Why not just keep the name "NAT-PT" for "NAT-Protocol Translation"?

I've never seen a v4-v4 NAT designated with an acronym with a dash in it.

                  Harald

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 14 Nov 2007 13:45:49 -0600

Thus spake "RJ Atkinson" <[email-masked]>
> to various sorts of address/port translation within an IPv4-only

I have never seen NAT-PT used to refer to that; the common terms are NAT and 
NAPT, though at least one vendor I'm aware of prefers PAT for the latter.

> NAT-PT also, which can be confusing to some.

That is what RFC 2766 defines NAT-PT to be, so if there's any confusion, the 
people using that acronym incorrectly need to be informed of that so they 
can stop.

> use the short-hand notation "NAT+PT".

Why invent a new notation when we already have a correct one?  It's not like 
we have two currently competing proposals that are vying for the same name, 
as with the CD and DVD wars; the naming issue for this scenario was settled 
nearly eight years ago.  If one doesn't like the name that was picked, 
perhaps because it's confusingly similar to names of other things, the time 
to correct that is long past.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Nov 2007 15:31:18 -0500

As far as I'm concerned, NAT-PT is defined in RFC 2766, and describes a
particular way of translating between IPv4 and IPv6.  If people are
using NAT-PT in a different way, that's unfortunate.   But I don't
consider it a major problem because NAT-PT really isn't usable anyway,
for two sets of reasons: (1) for any kind of NAT approach to be
generally applicable, applications need to be explicitly aware of NAT;
have explicit awareness of, and control over, bindings in the NAT; and
be able to distinguish one addressing realm from another and know which
addresses are in which realms.   NAT-PT doesn't do the first two, and
it's arguable that it doesn't do the third. (2) lying about DNS results,
which NAT-PT does, is always a Bad Idea and should be strongly discouraged.

If someone wants to define a different mechanism to translate between
IPv4 and IPv6, it needs a different name to avoid confusion with
NAT-PT.  I don't like NAT+PT as a name, because it's too easily confused
with NAT-PT.  (I don't like DVD-RW and DVD+RW either, but I expect that
was a case of deliberately trying to cause confusion in the marketplace.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Nov 2007 15:45:50 -0500

> Alain Durand proposed in 2002  :
Practically speaking, any box that translates between v4 and v6 has to
be able to translate in both directions.  Which side is "to" and which
is "from" then?  You don't want to make the assumption that the apps are
all client-server.

I agree that there are differences in the best way to provide
connectivity to the public IPv4 network from a private IPv4 or isolated
IPv6 network, and the best way to provide connectivity to the public
IPv6 network from an IPv4 network.  But I don't see these as inherently
different problems requiring a different box or a different protocol.  
I think it makes more sense for there to be a common protocol which can
run over either IPv4 or IPv6 and which supports multiple services.

Also I don't think NAT64 or NAT46 are good names because there are
several different ways of providing the connectivity in each direction,
with advantages and disadvantages to each.

IMHO it would be better to talk in terms of specific proposals than to
debate about names.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Nov 2007 13:27:01 -0800

I am in agreement with Keith here, I don't think the names are helpful.
 
What I want is a network protocol transition box, the ANYBOX which:
 
1) Bridges a local network A to the Internet B
2) Can accept either IPv4 or IPv6 on either side of the box
3) Provides seamless Internet connectivity for the principle legacy Internet applications (SMTP, HTTP, FTP, NNTP) regardless of whether IPv4 or IPv6 is running on either side of the box
4) Provides seamless Internet connectivity for all applications written to a set of clear and concise architectural / discovery requirements regardless of whether IPv4 or IPv6 is running on either side of the box.
5) Addresses some major user requirement so as to give users an incentive to buy it (no IPv6 connectivity is not in itself a user requirement, it is a means, not an end)

I know that we are going to have to engage in some form of fixup to gate IPv4 to IPv6, the question is how much and where we put the fixup technology.
 
I want to concentrate that fixup technology at the network gateway.

________________________________

From: Keith Moore [mailto:[email-masked]]
Sent: Wed 14/11/2007 3:45 PM
To: Rémi Després
Cc: RJ Atkinson; [email-masked]
Subject: Re: terminology proposal: NAT+PT (or NAT64 ?)

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Nov 2007 08:36:22 +0100

Keith Moore a écrit :

In my understanding, the address translation process in an intermediate
box is inherently dissymetric.

The session acceptor address, used to route the first and subsequent
packets is left unchanged (in NAT64, its format changes, say from
xx.yy.zz.tt to ::XY:ZT, but not its semantics)

The connection initiator address ineeds being translated.

In NAT44 it has to be changed because it belongs to a private IPv4
space, not routable in the public backbone.

In NAT64 it has to be changed because the session acceptor, which
handles 32 bit addresses only,  is unable to  work with  the session
initiator  address, which is 128 bits long.

In NAT64, the IPv6 session initiator IPv6 address (128 bits) contains
the IPv4 session acceptor IPv4 address (32 bits).

The process is simple, natural, and necessary if an IPv6-only client is
ever establish a session with an IPv4-only server.

Strictly speaking, the NAT46 described by Alain Durand was not a NAT.

Rather than performing the "address translation" of a NAT, it
translated DNS queries, i.e. an application layer action (an 'A' query
becomes an 'A' plus 'AAAA' couple of queries).

Whether such compexity should appear within the network is IMHO
doubtful, or at least highly debatable. (Upgrading the application to
support 128 bit addresses is simpler and more natural, and moves in the
right direction toward the IPv6 future).

If this means a unique design for NAT64 and NAT46, I don't see this as
feasible.

Trying to do it would IMHO create confusion and transform a (rather)
simple and important problem into an overly complex and unnecessary
one.

Diversity of designs for the same function is IMHO not a reason to
avoid having a good name for the function.(Would the everal ways to
perform NAT+PT also preclude using this acronym?).

Both are appropriate.

As a matter of fact, I see your participation in the "names" debate as
a useful opportunity to clarify the substance of the issue.

Regards.

Rémi

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Nov 2007 02:47:54 -0500

RÃ©mi DesprÃ©s wrote:
> Keith Moore a Ã©crit :
> In my understanding, the address translation process in an
> intermediate box is inherently dissymetric.
you're essentially making the assumption that all apps are client-server
- i.e. that the session is always initiated in one direction across the
NAT box.  that's one of the biggest problems with traditional NATs, and
is part of what makes NAT-PT broken.
> the IPv4 session acceptor IPv4 address (32 bits).
actually I think this limits the applicability of this approach.  it
shouldn't be assumed that there's any direct relationship between the
interior and exterior addresses across a v6<>v4 translator.  nor, for
that matter, should it be assumed that such a box can provide
transparent IPv4-to-IPv6 conversion for arbitrary applications on a
large number of hosts without the knowledge of the applications on those
hosts.  
> simple and important problem into an overly complex and unnecessary one.
I think it's feasible because in the process of trying to describe such
a protocol.  Perhaps you would do me the favor of waiting until I
produce such a description before you denounce it as overly complex and
unnecessary?
> perform NAT+PT also preclude using this acronym?).
Well, if someone says "NAT-XY is good" (or bad) and NAT-XY means
different things to different people, that's fairly confusing.  Also, if
there's a need for a host or application to be able to interact
explicitly with a NAT-XY (as their certainly is) then it's helpful if
that protocol is standardized, and if NAT-XY boxes behave consistently
from one implementation to another.

Keith

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 15 Nov 2007 15:51:32 +0800

Within IPv6 research society, we have used the NAT-PT term for years. For my
concerned, there is no confusion at all. However, it may be confusion for
the others outside IPv6 research society. They may use the term in different
way, such as translation between others protocol rather than IPv4/IPv6. In
that kind of consideration, NAT64 or NAT-64PT would be clear enough. By the
way, 64 should means between v6 and v4 bi-directions rather than only v6 ->
v4.

Cheers,

Dr. Sheng JIANG

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.

*-----Original Message-----
*From: Keith Moore [mailto:[email-masked]]
*Sent: Thursday, November 15, 2007 4:31 AM
*To: RJ Atkinson
*Cc: [email-masked]
*Subject: Re: terminology proposal: NAT+PT
*
*As far as I'm concerned, NAT-PT is defined in RFC 2766, and describes a
*particular way of translating between IPv4 and IPv6.  If people are
*using NAT-PT in a different way, that's unfortunate.   But I don't
*consider it a major problem because NAT-PT really isn't usable anyway,
*for two sets of reasons: (1) for any kind of NAT approach to be
*generally applicable, applications need to be explicitly aware of NAT;
*have explicit awareness of, and control over, bindings in the NAT; and
*be able to distinguish one addressing realm from another and know which
*addresses are in which realms.   NAT-PT doesn't do the first two, and
*it's arguable that it doesn't do the third. (2) lying about DNS results,
*which NAT-PT does, is always a Bad Idea and should be strongly discouraged.
*
*If someone wants to define a different mechanism to translate between
*IPv4 and IPv6, it needs a different name to avoid confusion with
*NAT-PT.  I don't like NAT+PT as a name, because it's too easily confused
*with NAT-PT.  (I don't like DVD-RW and DVD+RW either, but I expect that
*was a case of deliberately trying to cause confusion in the marketplace.)
*
*Keith
*> NAT, NAPT, and NAT-PT have been used for some while now to refer
*> to various sorts of address/port translation within an IPv4-only
*> network.
*>
*> Recently, there has been some discussion of network address with
*> IPv6::IPv4 protocol translation.  Some have referred to that as
*> NAT-PT also, which can be confusing to some.
*>
*> I'd like to suggest that when talking about the concept of
*> translating protocol versions (IPv6 <-> IPv4) in addition
*> to, or instead of, altering port number or IP address, we
*> use the short-hand notation "NAT+PT".
*>
*> Cheers,
*>
*> Ran
*>
*> (PS:  Perhaps I've been burning too many DVDs lately. :-)
*>
*> _______________________________________________
*> Ietf mailing list
*> [email-masked]
*> https://www1.ietf.org/mailman/listinfo/ietf
*
*_______________________________________________
*Ietf mailing list
[email-masked]
*https://www1.ietf.org/mailman/listinfo/ietf

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Nov 2007 10:16:32 +0100

Keith Moore wrote :

> you're essentially making the
assumption that all apps are

> client-server - i.e. that the session is always initiated in one

> direction across the NAT box.  that's one of the biggest problems

> with traditional NATs, and is part of what makes NAT-PT broken.

I don't understand this point.`

"Traditional NATs" (NAT44, I would say) do provide real service.

Thanks to them,  private address spaces in private sites became
realistic, and the IPv4 address shortage has been pushed far enough in
the future.

> ...  it shouldn't be assumed that
there's any direct relationship

> between the interior and exterior addresses across a v6<>v4

> translator.

I don't see why, as far as the session acceptor is concerned.

Using an IPv4 mapped addresses as destination address when an
IPv6-onlyhost transmits to an Ipv4-only host does make sense.

>should it be assumed that such a

> box can provide transparent IPv4-to-IPv6 conversion for arbitrary

> applications on a large number of hosts without the knowledge of
the

> applications on those hosts.

In my undersatnding, neither of us assumes it.

>>... a unique design for NAT64
and NAT46, I don't see this

>> as feasible.

> I think it's feasible because in the process of trying to describe

> such a protocol.  Perhaps you would do me the favor of waiting
until

> I produce such a description before you denounce it as overly
complex

> and unnecessary?

I expressed my "current" belief, and made it clear that it was
an "opinion", not a proved assertion.

When you bring new facts, they will be for sure taken into account.

And I look forward to it.

> different things to different people, that's fairly confusing.

On this point, we thoroughly agree.

And this is THE reason why I prefer Alain's terminology.

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.

Cheers.

Rémi

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Nov 2007 09:33:21 -0500

RÃ©mi DesprÃ©s wrote:
> Keith Moore wrote :
>> you're essentially making the assumption that all apps are
> I don't understand this point. "Traditional NATs" (NAT44, I would
> say) do provide real service.  Thanks to them,  private address
> spaces in private sites became realistic, and the IPv4 address
> shortage has been pushed far enough in the future.

I'm not going to reiterate the cost vs. benefit of Traditional NAT in
this thread, but I assume you are aware of at least some of the numerous
problems that they cause.

>> ...  it shouldn't be assumed that there's any direct relationship
between the interior and exterior addresses across a v6<>v4 translator.
> I don't see why, as far as the session acceptor is concerned. Using an
IPv4 mapped addresses as destination address when an IPv6-onlyhost
> transmits to an Ipv4-only host does make sense.

"IPv4 mapped" addresses (those of the form ::ffff:{ipv4 address}) should
never appear on the wire.  Embedding an IPv4 address within an IPv6
address might make sense in certain cases, but it doesn't work in general. 

The notion of a "session acceptor" is a strange one.  It should not be
assumed that sessions are accepted in any particular direction, either
v4->v6 or v6->v4.  To make for an effective transition there is a need
to provide both the ability of hosts on v6-only networks (or networks
lacking public v4 Internet access) to have access to the public v4
Internet and to allow hosts on v4-only networks (or networks lacking
public v6 Internet access) to have access to the public v6 Internet.  In
either of those cases it is necessary to allow both "incoming" and
"outgoing" sessions.  The traditional NAPT model which can only permit
outgoing sessions is not sufficient for an effective transition from v4
to v6.

> 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?

Keith

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Nov 2007 16:51:00 +0100

Keith Moore a écrit :

If using them on the wire is useful, without any "identified" problem,
why not ?

But if you already know of such problem, I am of course interested.

This is the crux of the matter.

Is the NAT function inherently oriented or not?

In my understanding it definitely is, and has to be so.

Existing NAT-44s provide only ONE substitute address, that of what I
call the "session initiator" host (the "pivate" address of a connection
is changed, and the "public"address isn't).

NAT-64 is the one which is  NECESSARY for IPv6-only clients to access
IPv4-only servers.

(There may be other needs but this one is clearly identified , and IMO
its solution does deserve a non ambiguous name)

In this case, the "session initiator" is again the one whose address is
replaced by a NAT provided one, and that is the IPv6 only host.

Note that it is on purpose that I use "sessions initiator" and not
"connection initiator".

This takes into account that some application protocols ( FTP, SIP... )
are such that address and/or port numbers may be exchanged as data, for
subsequent UDP or TCP connections.

The "session initiator" of a connection is the host which initiated the
NAT address-port reservation for the connection.

Some other names, e.g. NAT-state initiator, or whatever, could also do,
but "session initiator" sounds intuitive enough to me.

Rémi

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Nov 2007 11:09:50 -0500

> If using them on the wire is useful, without any "identified" problem,
it just isn't particularly helpful to do so for the kind of translator
that I envision.
> call the "session initiator" host (the "pivate" address of a
> connection is changed, and the "public"address isn't).
actually, no.  v4 NATs exist which translate a block of addresses to
another block of addresses. 

more generally, a large chunk of the problems associated with NAT are
due to the assumption that NAT can function properly without the
awareness of the hosts and applications that are affected by it.   if
the applications are explicitly aware of the translator, and can control
it explicitly, then it becomes possible to accept incoming connections
via the translator in addition to initiating outgoing connections
through the translator.  this does require additional signaling, of
course, but that's not a problem once the apps are aware of the NAT.
> its solution does deserve a non ambiguous name)
it is also necessary for servers on IPv6 only networks to be able to
have presence on the public IPv4 internet.  how else (for example) can
IPv6-only networks accept incoming email from v4 only networks and/or
serve web pages to v4-only clients?  yes you can do some of this with
proxies, but it's infeasible to set up a proxy for every single
application that needs to be able to communicate between these networks.
> In this case, the "session initiator" is again the one whose address
> is replaced by a NAT provided one, and that is the IPv6 only host.
when translating between v4 and v6, the source address gets changed in
either direction to one assigned by the translator.  as does the
destination address.  this is true even when the v4 source address gets
embedded in the v6 address assigned by a translator.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Thu, 15 Nov 2007 18:28:46 +0200 (EET)

On Thu, 15 Nov 2007, Rémi Després wrote:
> If using them on the wire is useful, without any "identified" problem, why not ?

Incompatibility with source address spoofing prevention mechanisms.

P.S: please consider turning off HTML.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 Nov 2007 18:49:29 +0100

> serve web pages to v4-only clients?

In principle I agree, but in practice all the services are available  
on the IPv4-only internet so the ability for IPv6-only clients to  
connect to IPv4-only servers will give us more than 90% of what users  
need.

NAT-PT doesn't have to address all corner cases. After all, we do have  
those 3.7 billion IPv4 addresses, finding a few that can be given to  
the few percent of all hosts that have unusual needs shouldn't be a  
huge issue unless we _really_ screw up the address allocation  
mechanisms.

Also, all hosts using NAT-PT have IPv6 connectivity which can be used  
for "difficult" protocols, especially those used by relatively small  
groups of users.

> yes you can do some of this with

You don't need per-application proxy implementations: you can simply  
use the HTTP CONNECT method to ask the proxy to set up a TCP session  
towards a destination (by IPv4/IPv6 address or FQDN) and then pipe  
that session through the one you have to the proxy. Should work for  
everything that uses TCP. See

http://tools.ietf.org/id/draft-van-beijnum-v6ops-connect-method-00.txt

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Nov 2007 14:17:44 -0500

> connect to IPv4-only servers will give us more than 90% of what users
in practice _today_ all of the services are available on the IPv4-only
Internet.  but that ceases to be the case once we run out of IPv4
addresses, or substantial services exist that are based on IPv6 (like
access to mobile terminals).

more generally, enterprises can't move their networks to IPv6 until they
can make their services available to those who are still stuck with only
IPv4.
> NAT-PT doesn't have to address all corner cases.
the cases you're thinking of as "corner cases" are more significant than
you presume.
> http://tools.ietf.org/id/draft-van-beijnum-v6ops-connect-method-00.txt
yes, that's a very useful tool.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 15 Nov 2007 18:27:19 -0600

Thus spake "Keith Moore" <[email-masked]>
>> Using an IPv4 mapped addresses as destination address when
>> an IPv6-onlyhost transmits to an Ipv4-only host does make sense.
>
> "IPv4 mapped" addresses (those of the form ::ffff:{ipv4 address})
> should never appear on the wire.  Embedding an IPv4 address
> within an IPv6 address might make sense in certain cases, but it
> doesn't work in general.

Agreed.  That was my first thought when I had independently developed the 
NAT-PT concept, but I quickly realized that a v4-mapped source address was 
unworkable because it wouldn't ensure that the return path came back to the 
same NAT-PT box (which is, unfortunately, necessary).

> 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.  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.

>> 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.

S

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Nov 2007 21:17:49 -0500

> 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.

> 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