Rémi Després wrote:
> Keith Moore wrote :
>> 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 don't understand this point. "Traditional NATs" (NAT44, I would
> say) do provide real service. Thanks to them, private address
> spaces in private sites became realistic, and the IPv4 address
> shortage has been pushed far enough in the future.
I'm not going to reiterate the cost vs. benefit of Traditional NAT in
this thread, but I assume you are aware of at least some of the numerous
problems that they cause.
>> ... 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.
The notion of a "session acceptor" is a strange one. It should not be
assumed that sessions are accepted in any particular direction, either
v4->v6 or v6->v4. To make for an effective transition there is a need
to provide both the ability of hosts on v6-only networks (or networks
lacking public v4 Internet access) to have access to the public v4
Internet and to allow hosts on v4-only networks (or networks lacking
public v6 Internet access) to have access to the public v6 Internet. In
either of those cases it is necessary to allow both "incoming" and
"outgoing" sessions. The traditional NAPT model which can only permit
outgoing sessions is not sufficient for an effective transition from v4
to v6.
> 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?
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf