undefined | Better HN

0 pointsNoZebra120vClip2y ago0 comments

No, actually it does not work that way. You have it backwards, first of all: IPv6 AAAA record is queried first, then the connection is attempted, and then a fallback may happen to an A record and an IPv4 connection attempted.

https://www.rfc-editor.org/rfc/rfc5220.txt

I'm not sure why you specified "if a host has no route to the address", because that's a very specific and transient failure. Furthermore, the dual-stack handling necessarily happens in the application, so this is not an OS or kernel-level decision, it will be subject to each individual app's behavior: https://issues.apache.org/jira/browse/SERF-190

As you can see from RFC5220, IPv6 is preferred over IPv4, unless an option is set to swap those around. Of course, certain configurations can confound this preference order, such as ULA IPv6.

"No route to host", as should be obvious, is only one of many errors that could prevent an app from establishing an IPv6 connection. It would seem that they should handle most failures as an occasion to fall back to IPv4, unless configured not to.

0 comments

Dagger22y ago

That is also not accurate. Clients query both the A and AAAA records simultaneously up front, sort the replies according to the RFC3484/6724 rules, and then try each address in turn.

The rules are somewhat involved but they roughly boil down to "sort v6 addresses first if the client has a non-ULA v6 address, otherwise sort v4 first". However, note that the very first rule in 6177 is "avoid unusable destinations" so not having a route to an IP may factor in to the sorting.

A machine with no v6 will(/may) still query AAAA records, but it will attempt to connect to any A records first before trying any AAAA records. (This sometimes exhibits as people seeing software like apt-get report connection failures to v6 addresses and then blaming v6 for it, even though the problem is that they only have v4 and the v4 is broken.)

j / k navigate · click thread line to collapse