Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)

[Owen DeLong <owen () delong com>]

<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