If you got into such problem, which I ran into today, I’ve got the reason why it behaves so. But let me first describe the problem:
When I connect to IPv6 internet via 6to4, Firefox doesn’t display IPv6 sites (by default), those also have corresponding IPv4 site. To be precise, in spite of presence of an
AAAADNS RR for a domain name, Firefox refers to the
ADNS RR. If no
ADNS RR exists, then only Firefox refers to
AAAA. And this happens only when I’m connected via 6to4 tunnel not on Freenet6 tunnel which offers a non 6to4 address.
When, I told about this to one of my CentOS-tic friend, who told me I should try CentOS as it works fine in IPv4 free environment. So I thought its some bug. But after posting this question on
jakllsch (a nick in
#ipv6) pointed me to RFC 3484. As clear from the title of RFC, Default Address Selection for Internet Protocol version 6 (IPv6) it deals with address selection. So I became confident that due to this RFC, this all is happening. But to became 100% sure, I started reading RFC, and in section Destination Address Selection, I found the solution of my problem. So following is a practical-case (filled with sample data) of my problem:
I’ve 2 addresses a
2002::/16 (a 6to4 address) and a
122.xxx.yyy.zzz (an IPv4 address). I wanted to visit website of www.sixxs.net (
220.127.116.11 ) . So to which destination address should Firefox try. According to the rule no. 5:
Rule 5: Prefer matching label.
If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA))<> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB.
So in my case,
Label(2002::/16) <> Label(2001:838:1:1:210:dcff:fe20:7c7c) ⇒ 2 <> 1 and
Label(122.xxx.yyy.zzz) = Label(18.104.22.168) ⇒ 4 = 4, Thanks to
jakllsch for confirming this. And I later discovered that its not only applicable for Firefox but also for other applications using getaddrinfo() routine of POSIX API. So mystery solved. Anyways, happy IPv6ing… :)