On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote:
In message <2CE5A700-EB60-453F-85CF-5E679E94EE4C@delong.com>, Owen DeLong write s:
<massive snip>
=20 Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. =20 However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main =3D reasons that Google does not publish AAAA records generally today). =20 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. =20 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. =20 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 =20 Sure, or, you can use PI without ULA and not need to develop a tool.
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
If you can get PI *and* get it routed then yes PI is the way to go. PA alone is also not the way to go.
OK, so, PI is the way to go, since you can get it routed for free. (If you don't know how, see http://tunnelbroker.net and look for the subject "BGP tunnel")
If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. =20 Preference the ULA/64 addresses first (link).=20 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.=20 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. =20 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. =20 Now is that really so hard? =20 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.
And PA alone doesn't work well.
Where did PA enter into my statement above?
As for lines of code they won't be many as basically it is just inserting/removing rules when addresses are assigned/removed to/from interfaces.
And then distributing those rules to EVERY host (or you have to pre- distribute the script to EVERY host). <snip> Owen