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

[Mark Andrews <marka () isc org>]

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.

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.

> > 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.

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.

> > 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org