On 26 jul 2008, at 17:56, Iljitsch van Beijnum wrote:
There has been some discussion whether it would be a good idea to
use the IPv4 mapped IPv6 prefix (::ffff:0:0/96) or the IPv4
compatible prefix (::/96) as the prefix used for a NAT-PT/NAT64
translator that lets IPv6 clients talk to IPv4 servers.
We haven't been able to run the full set of tests yet, but here are
preliminary results which may or may not be useful in the discussions
the coming week.
IPv4-compatible IPv6 addresses (::/96) in AAAA records:
It looks like at least several systems (including MacOS and Linux)
will send packets towards these addresses. Linux seems to prefer
normal AAAA records, and we expect Windows to do the same because of
the RFC 3484 rules. However, MacOS seems to round robin between AAAA
records with normal addresses and compatible addresses.
IPv4-mapped IPv6 addresses (::ffff:0:0/96) in AAAA records:
It looks like at least several systems (including MacOS and Linux)
will at some point go from treating IPv4-mapped addresses as IPv6
addresses to treating them as IPv4 addresses. So they generate IPv4
packets on dual stack connected systems. These addresses didn't show
up in any IPv6 packets in our (limited) tests.
Linux seems to favor normal IPv6 addresses (if available) over mapped
addresses. On MacOS (at least) these addresses won't work with IPv4-
only connectivity because the resolver library doesn't perform AAAA
lookups when there is no IPv6 reachability. With dual stack
connectivity, MacOS consistently chooses the AAAA records and most of
the time, but not always, the mapped addresses which generate IPv4
packets.
Conclusions: using the v4-mapped prefix requires changes for at least
some OSes, and probably all or most. Using the v4-compatible prefix
has the advantage that RFC 3484 compatible systems prefer real/normal
IPv6 addresses, but then this would be true for any prefix that is
"far" from the currently used global unicast space (2000::/3), i.e.,
in ::/3 or 4000:/2.
Based on this, I'd say that it doesn't make much sense to use either
of these prefixes for NAT64, but either to use addresses out of
service provider ranges, which has the downside that configuration is
necessary, or define a new well-known, non-globally-routable prefix
for this purpose which should work without configuration or host
changes (and be less preferred than real AAAA records on RFC 3484
compatible systems, which is most of them apart from MacOS) and
additional benefits can be gained by changes in the host OS and/or
applications.
If anyone is interested in further tests (we don't have any data for
Windows Vista yet) or more detailed tests, see my original message
from saturday and/or contact me directly.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
