Rémi Després wrote:
Keith Moore a écrit :
"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.
If using them on the wire is useful, without any "identified" problem,
why not ?
it just isn't particularly helpful to do so for the kind of translator
that I envision.
But if you already know of such problem, I am of course interested.
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.
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?
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).
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.
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)
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf