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

Keith Moore a écrit :

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

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.
  

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.

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.

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

  
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.
  

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.  

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.
  

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

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

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

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