I’m attending FOSDEM again this year. Last time the wireless network here was dual-stacked, this time it’s IPv6 only network, which is super cool.
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether xx:xx:xx:xx:xx:xx inet6 fe80::xxxx:xxxx:xxxx:xxxx%en0 prefixlen 64 secured scopeid 0x5 inet6 2001:67c:1810:f051:1435:4a43:7ce7:fb8d prefixlen 64 autoconf secured inet6 2001:67c:1810:f051:b181:3e25:ed4a:9e3e prefixlen 64 autoconf temporary inet 169.254.178.7 netmask 0xffff0000 broadcast 169.254.255.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active
For IPv4 only destinations, their advertised DNS servers were responding with
AAAA records which have IPv4 address mapped in well-known prefix, e.g.
;; ANSWER SECTION: beta.quicklisp.org. 300 IN CNAME d2uc670daj8sxz.cloudfront.net. d2uc670daj8sxz.cloudfront.net. 60 IN AAAA 64:ff9b::8fcc:2f1c d2uc670daj8sxz.cloudfront.net. 60 IN AAAA 64:ff9b::8fcc:2f41 d2uc670daj8sxz.cloudfront.net. 60 IN AAAA 64:ff9b::8fcc:2f64 d2uc670daj8sxz.cloudfront.net. 60 IN AAAA 64:ff9b::8fcc:2f7b
This all is perfect, except for some applications which don’t use
getaddrinfo() (or similar fancy functions) for hostname resolution, and just die with Network Unreachable error when trying to reach host over IPv4 after being unable to find an IPv4 gateway. What they should do is, fall back on IPv6, if not trying IPv6 in the first place. It’s ironic, esp. when these applications are just plain HTTP clients downloading some files, which doesn’t have anything to do with network protocol in use. Hopefully it will get resolved soon when someone (maybe me 😉) provide some patches, or file bugs.