Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Philip Homburg <[e-mail]>]

>> I'm not sure that will work. If you set 'n' high to be safe, then it will
>> take long time before the hosts takes action. If you set 'n' low, then you
>> still have a risk that a particular network exceeds this value.
>
>If you have another (working) address, then that's safe.

I think my very first proposal was effectively n=1:
after receiving an RA, deprecate all addresses from the same router
not covered by PIOs in the RA.

If I remember correctly, you didn't like it.

For higher values of n, it will take longer to deprecate addresses, which
may lead to shorter RA intervals, which has it's own problems.

>That said, even if one wasn't changing the defaults but rather
>suggesting tweaking of the timers, advice is warranted: you cannot
>expect the operator to figure out all the relevant details....

But increasing multicast rates to deal with a rather obscure problem doesn't
strike me as a good trade-off.

>> I don't think that's true for two reasons:
>> - If the ISP re-assigns the prefix within the valid-lifetime of the
>>   IA_PD prefix option, then the ISP is violating the DHCPv6 RFC.
>
>You may be right in "the ISP is violating the dhcpv6 rfc"... but this
>doesn't make  what I describe an inexistent scenario.

I don't think we should introduce risky code on hosts to deal with 
broken DHCPv6 server implementations. 

And even then, the problem seems mostly theoretical.

>> - The source address selection algorithm avoids deprecated addresses.
>>   So the only way this can lead to trouble is if the a new node would
>>   use the exact same address. With SLAAC that basically cannot happen.
>
>That's not correct. Normally, when a PIO has A=1, it normally has L=1.
>Therefore, that prefix will be considered on-link, and any packets meant
>for it will be sent on the local link, as opposed to forwarded to the
>local router...

That's a separate issue. Deleting an address will immediately disrupt
any flows that use that address.

Deleting a prefix from the list of onlink prefixes is more complex.
If the router still knows about the prefix, then there is no issue.
The router is supposed to forward the packet to the destination and
send a redirect.

If the router lost knowledge of the prefix and two hosts are communicating
locally then marking the prefix as offlink may disrupt that communication.

So there is no obvious way to deal with DHCPv6 servers that violate the
specs.

>1) c=0
>2) Whenever you receive a PIO from the same router that does not include
>the currently-configured prefix: c++;
>3) if c >= N1 -> address deprecated
>4) If c >= N2  (where N2>N1) -> address removed.

So for high values of N1, communication will be disrupted for a long time.
For values of N1 less than the number of RAs that a router uses, prefixes
will periodically marked as deprecated.

If the router also exceeds N2, then addresses will periodically be removed.

>> You are right. I have an idea how to deal with this issue.
>
>I'm listening ;-)

My current idea is that is is safe mark an address as deprecated if no
PIO that covers the address was seen for the 'Router Lifetime' field 
in the RA. Unless the field is zero, then do nothing. This should make
sure that eventually, stale addresses are marked deprecated. An obvious
edge case is PIOs advertised only by a router that is not a default router.

However for the case at hand, it is worth looking at deprecating an
address much quicker. So my proposal is to deprecate an address on a much
shorter time scale if the PIO is advertised by only one router and if that
router sends all PIOs in one RA.

Multiple routers advertising a single PIO is easy to detect. Detecting that
a single router puts all PIO in a single RA is harder. My currently
idea is to use a counter that counts how often a single RA covers all PIOs.
For low values of the counter, an PIO that was left out is evidence that the
router puts PIO in multiple RAs. If the counter is high enough (say above 10)
then assume that a missing PIO is stale and deprecate the address.

There are some corner cases, but they should be rare, and the effect 
relatively benign.