Subject: [Int-area] Testing mapped and compatible addresses

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 26 Jul 2008 18:56:20 +0200

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.

In order to see if such an approach would be workable we want to test  
the behavior of different operating systems when applications are fed  
AAAA records with these addresses in them. We already have some  
testers for common OSes (Linux, Win XP/Vista, MacOS 10.5, Symbian) but  
we can use more measurements for less common OSes. The IETF network is  
conveniently available in dual stack and IPv6-only flavors.

We've set up the following test to determine how operating systems  
handle IPv4 mapped IPv6 addresses (::ffff:0:0/96) and IPv4 compatible  
addresses (::/96) they encounter in AAAA records.

Please go to http://test.ams.runningipv6.net/

(Make sure you're reaching this page over IPv6 as indicated by your  
source address that the server echos back.)

There, you can download an Excel (XLS) file, please fill in your  
details and those of the machine you're testing with, and set up your  
system with the combination of settings an reachability that you want  
to test, as listed in the spreadsheet. Since most people will run in a  
default configuration, please test at least the defaults for IPv4 and  
IPv6 configured on the system / active interface along with dual stack  
and IPv6-only reachability. There are three other configurations that  
you can test and you can add more if you like.

Visit the 8 URLs listen on the page with the selected settings and  
record the results in the appropriate column.

Repeat for other settings you want to test.

If the system uses normal A or AAAA records (which are available in  
different combinations for the test2 - test4 URLs) you'll return to  
the test page, if the system uses a mapped (or compatible) address  
successfully you'll see the IETF or IANA pages. However, the most  
interesting cases are those where there is a timeout on an IPv6  
network, in that case the host may be trying to send IPv6 packets with  
a destination in the /96 prefix in question.

You can do this at any time, but preferably before Monday so we can  
compile and send out the results before NAT64-related discussions  
commence.

Use the nameserver address in the XLS file if you're experiencing DNS  
issues, but this shouldn't be necessary.

We would also like to test with at least a few OSes in such a way that  
we can determine if the OS generates any IPv6 packets with compatible  
or mapped destination addresses. To do this, please find me (in  
addition to email you can reach me on Jabber and other instant  
messaging networks as [email-masked]) and we'll test with a direct  
ethernet cable between the system to be tested and my laptop, which  
will act as an IPv6 router and intercept all packets sent over the  
ethernet port. This is what the second half of the XLS file is for.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Jul 2008 22:22:59 +0100

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-masked]
https://www.ietf.org/mailman/listinfo/int-area