Rémi Després wrote: > 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. 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 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). 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. >> 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. 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? >> 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?). 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 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf