Le Mardi 9 Mai 2006 17:27, Pekka Savola a écrit : > 1) v6 site-local address selection problems I assume you refer to the deprecated but Linux kernel-supported site-local fec0::/12 address space (not sure if it is /12 - but anyway). > A site has deployed IPv6 site-local addresses (alongside with NATed > v4). They do not have global IPv6 reachability yet, but want to test > IPv6 alongside IPv4 internally. > As a result, RFC 3484 address selection breaks: when trying to > connect to a hostname with a public IPv4 and IPv6 address, the host > will first try v6 fails (incurring about 3 min TCP timeout if ICMP > error is not sent), and after that connects to the v4 address. I am pretty sure it used to work “properly”... when trying to connect() to some public IPv6 address while the host only had link-local and site-local addresses, the stack would immediatly (non-blocking) address unreachable. Then software using the getaddrinfo() paradigm would fallback to IPv4 without the user noticing any delay. But then indeed, it seems to be now broken. > 2) v6 ULA address selection problems > > Deploying ULAs doesn't help here, it just makes the problem worse as > you couldn't even use the 'matching scope' tweak. Yes, I definitely have had these issues. Since ULA have global scope, there is no way to detect the issue there. Another (Linux-specific) issue is that source address selection is completely broken, so if you have both public addresses and ULAs on the host, the stack might be an ULA (non-routable!) address as source when sending packets toward a public address. But that, I guess, it because Linux does not implement source address selection properly. That said I don't think defaulting to IPv4 in libc is wise, and it will actually break in other case. Linux users should probably rather refrain from using ULAs until their OS supports them properly. I'm actually pretty sure some apps rely on getaddrinfo() returning AF_INET6 entries before AF_INET. Inverting the ordering might cause serious troubles there. This is ***definitely*** going to break listening TCP socket applications that relied on IPv6-mapped IPv4 addresses to catch both IP protocol versions with a single socket. This includes noteworthy Apache httpd 2 and OpenSSH, and probably a bunch of other server apps. This could, to a lesser extent also affect the UDP and “outgoing” TCP cases... in fact, whenever one uses IPv6-mapped IPv4 addresses. -- Rémi Denis-Courmont http://www.simphalempin.com/home/
Attachment:
pgpaJ7VmKRObT.pgp
Description: PGP signature