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).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. 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.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. 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?).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. Both are appropriate.IMHO it would be better to talk in terms of specific proposals than to debate about names. 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf