<massive snip>
Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do.
However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main = reasons that Google does not publish AAAA records generally today).
However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc.
There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration.
You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs
Sure, or, you can use PI without ULA and not need to develop a tool.
If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64.
Preference the ULA/64 addresses first (link). Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next. Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs outside of 2002::/16] Preference fc00::/7 last.
For ULA/64 destination select a source address from the corresponding ULA/64. For ULA/48 destination select a source address from the corresponding ULA/48. For PA/PI/6to4/64 destination addresses select a source address from the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last.
Now is that really so hard?
It just took you 20+ lines to describe the process in english without producing a single line of code. PI without ULA strikes me as being a lot less complicated.
I'm not sure where the IETF is with revising the default address selection rules but ULA came out after the first set of rules was published so it needs to be taken into account if it hasn't already been.
It doesn't matter where the IETF is. What matters is how many systems are deployed with what address selection rules and how long they would take to change if IETF ever did make up their mind on new standards.
If you are merging two sites you just extend the ULA of one to cover the other as well then slowly deprecate the other or tweak the rules above and distribute them via DHCP.
Or you use PI and don't worry about it at all. You're making a very good case fro why ULA is vastly inferior to PI. Owen