Re: [DNA] how much effort to deal with "unplanned renumbering"

[Erik Nordmark <erik.nordmark@sun.com>]

Thomas Narten wrote:

> I think we need to think hard about how much we are going to
> complicate DNA to deal with "broken renumbering attempts", which are
> not supposed to happen in the first place. The IPv6 protocols do not
> really support taking away a prefix prematurely, and when this
> happens, things aren't guarnteed to work. Thus, this is not advisable
> in general.
> 
> So we should explicitely discuss to what degree DNA needs to support
> such events, especially if they are not expected to be common.

Do read what dna-protocol3 proposes.

But this is actually a case where DNA potentially could make things a 
lot worse if we didn't do anything, because DNAv6 relies on prefixes 
comparisons, which means it uses the prefix lifetimes *even though it is 
not connected to the link*. (And DNAv4 doesn't rely on prefix 
comparisons - it just reverifies things with the DHCP server - so it 
doesn't have this issue AFAIK.)

Without DNA one can do reasonable flash renumbering.
Assume the prefix is advertised with the default 7/30 day 
preferred/valid lifetimes.

Somebody decides that the prefix needs to be forcibly removed from the 
link. Starts advertising the prefix with 0/o preferred/valid lifetimes 
in every RA. All the hosts will notice this - and if the prefix 
continues to be advertised with zero lifetimes for 30 days then even 
hosts that were dormant will never be confused.

Such an event will be disruptive, because some connections will die, if 
not immediately then after the 2 hour limit in RFC 2462.

Thus there might be emergency cases when this will be done.
It might also be possible that somebody decides to immediately reassign 
that prefix to another link, and we should recommend that this is bad 
operational practice. But it might happen with any additional harm.

Enter DNA.

It is possible (but very unlikely) that a host would move from link A 
(which has prefix P1, P2) to link B (with prefix P3) at the same time as
  - P1 is forcibly removed from link A, and P1 is reassigned to link B

If we didn't do anything, then the host would be confused for 30 days, 
because it would think
  - it didn't move to a different link because it hears P1 after reattaching
  - the prefixes assigned to the link are P1, P2, and P3

Thus the host will continue to use it's address in the P2 prefix, which 
will not work.

The above description is longer than the fix; dna-protocol3 says to not 
use information that is older than 1.5 hours.

    Erik