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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf