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

Tue Nov 2 21:20:49 UTC 2010

On Wed, 03 Nov 2010 00:25:34 +1100
Karl Auer <kauer at biplane.com.au> wrote:

> On Tue, 2010-11-02 at 23:23 +1030, Mark Smith wrote:
> > Prefix lifetimes don't work that way - there is no such thing as a
> > "flash" renumbering.
> 
> The lifetimes are reset with every RA the nodes see. If I reconfigure my
> router to start sending out RAs every N seconds, it will take a a
> maximum of N seconds for a new preferred lifetime to be established on
> all active nodes on the link. If the new preferred lifetime is zero, any
> addresses in the prefix will be deprecated immediately, causing other
> prefixes on the link to be preferred.
> 
> The new valid lifetime will be the remaining valid lifetime (if less
> than two hours), the newly advertised valid lifetime (if using SEND), or
> two hours in all other cases.
> 
> That seems pretty close to "flash renumbering"... 

I consider "flash renumbering" to mean that addressing can be changed
without disrupting established and ongoing communications sessions e.g.
doesn't break TCP connection or UDP streams.

I know that renumbering without disrupting transport protocols is
fundamentally impossible to achieve regardless of what the IPv6
preferred and valid lifetimes are because transport protocols are using
locators as identifiers. However, the goal should be to make transient
network faults, such as a broadband service link flap, have as minimal
impact as possible. Changing addresses every time that type of fault
occurs makes the consequences higher for transient faults than they
need to be.

I've had a recent experience of this. Some IPv6 CPE I was
testing had a fault where it dropped out and recovered every 2 minutes
- a transient network fault. I was watching a youtube video over IPv6.
Because of the amount of video buffering that took place, and because
the same IPv6 prefixes were assigned to the connection once it
recovered, the youtube video kept playing. That was a great end-user
experience and it was somewhat addictive to watch the PPP light
go off and come back on while the video kept playing faultlessly.

Some people argue that applications should be built to deal with this
type of situation. I think that is again asking application developers
to expend effort overcoming what are networking layer faults, as it has
been with NAT. I think problems are best solved where they're caused,
not necessarily where their effects are worst felt. I think it's better
to hide transient network faults from applications than have to make
each and every application include code to deal with them. The time
spent writing that code could be better spent on bug fixing, improving
the application functions themselves, or writing a different one.

Regards,
Mark.

>at least for SLAAC.
> DHCPv6 needs more planning.
> 
> Regards, K.
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)
> 
> GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
> Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF