Posted on

Tags: IPv6, FOSDEM

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.

        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 netmask 0xffff0000 broadcast
        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.

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.