undefined | Better HN

0 pointsNoZebra120vClip2y ago0 comments

Very ambiguous reply. Which host? The remote or the local? What do you mean "has no v4"? No A record? No v4 address on an interface?

Which hardware and OS are you describing? Clearly the blog post illustrated some examples where switching to v6 was not happening, so it seems to contradict your comment right off the bat. There are many implementations of dual-stack IPv4/v6. In fact, they are more divergent than IPv4 implementations, because the latter often derives from the BSD-RENO codebase, while IPv6 was introduced after Linux became King, so Microsoft, Apple, and Linux (and lots of router/firewall vendors) have ostensibly developed IPv6 stacks separately, some being more open than others. They're not all going to work the same way with fallbacks/failovers.

0 comments

aidenn02y ago

If (a host trying reach a remote service) has (no route to the address indicated by the A record) then it will try a AAAA record if one exists.

> Which hardware and OS are you describing?

This is how it's supposed to work on all OSes; on any recent BSD (excepting perhaps Apple?) or Linux setup, it should work this way.

> Clearly the blog post illustrated some examples where switching to v6 was not happening

In those situations it was for connecting to services that do not advertise a AAAA record.

NoZebra120vClipOP2y ago

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.

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