Thus spake "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
Rémi Després wrote:
Keith Moore wrote :
... it shouldn't be assumed that there's any direct relationship
between the interior and exterior addresses across a v6<>v4
translator.
I don't see why, as far as the session acceptor is concerned.
Using an IPv4 mapped addresses as destination address when
an IPv6-onlyhost transmits to an Ipv4-only host does make sense.
"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.
Agreed. That was my first thought when I had independently developed the
NAT-PT concept, but I quickly realized that a v4-mapped source address was
unworkable because it wouldn't ensure that the return path came back to the
same NAT-PT box (which is, unfortunately, necessary).
The traditional NAPT model which can only permit outgoing
sessions is not sufficient for an effective transition from v4 to v6.
Here we differ. I find that to be good enough for the vast majority of
cases, and in those cases where it doesn't work one can deploy native access
so that the NAT-PT box is avoided entirely.
Given that the vast majority of users are behind NAPT boxes today, either
provided by their ISP or purchased at a store, I have a problem with anyone
saying that providing the equivalent (poor) level of functionality via
NAT-PT is insufficient. If we give v6-only users NAT-PT to access v4-only
hosts and native (non-NAT) v6 access, that is better than they have today.
The only other option is multi-layered v4 NAT, which is arguably worse from
an e2e standpoint and certainly from an administrative one.
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?
I find the distinction mostly useless since any NAT-PT box will necessarily
need to translate a given flow in both directions because of the state
involved.
However, there is a potentially-useful distinction between deployment types.
For instance, a NAT-PT box at an eyeball site that allows local IPv6-only
hosts to access remote IPv4-only hosts will look somewhat different than a
NAT-PT box at a content site that allows remote IPv6-only hosts to access
local IPv4-only hosts. (And ditto for reversing the versions for each
case...) We may need to distinguish between roles, because the expectations
and configurations will differ, but the core technology and
protocol-mangling is the same for all of them.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf