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

[Fernando Gont <[e-mail]>]

On 23/3/19 11:31, Philip Homburg wrote:
> In your letter dated Sat, 23 Mar 2019 09:25:59 -0300 you wrote:
>>> I find the following issues in draft-gont-6man-slaac-renum-01:
>>> - In the notes it says "The aforementioned processing assumes that while
>>>   network configuration information might be split into multiple RAs, PIOs
>>>   will be spread among *at most* two RAs."
>>>
>> Note:
>> The same concept can be implemented as follows:
>> keep a counter of consecutive RAs with PIOs that have not advertised the
>> existing prefix. And trigger actions after some locally-defined value "n".
> 
> 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.



>>> - The draft proposes many changes to router behavior in particular 
>>>   increasing the frequency of RA multicasts.
>>
>> It's not really a change in the behaviour. It is playing with the knobs
>> that the protocol has, within the acceptable boundaries.
> 
> I think 'playing' with knobs should be left to operators. If we change 
> default values of timers, then effectively we are changing the protocol.

If one were to change the defaults, one would be changing the spec, but
not the protocol.

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



>>> - Increased multicast rates may have a negative effect on battery lifetime.
>>
>> Point taken. However, it would seem to me that if you care about battery
>> life, rather than banning what a protocol does, the strategy
>> would/should be different. You have lots of protocols,
>> HTTP-based applications, etc., etc. You cannot police all at the
>> protocol level to save battery life.
> 
> I think we should design protocols such that the use of periodic multicasts is
> minimized. A node receives these multicasts even if it is otherwise idle.

But, ironically, these multicast messages are easier to policy (e.g. at
an AP) than the unicast messages.




> Making these multicasts more frequent is a step in the wrong direction.
> 
>>> - The algorithm has a tight coupling between modifying the preferred and
>>>   valid lifetimes of addresses. In most cases, accidentially marking an
>>>   address as deprecated has little effect on connectivity. Deleting an
>>>   addresses by setting the valid time to zero immediately disrupts all
>>>   communication that uses the address.
>>
>> But if you don't, you cannot communicate with the new "owners" of your
>> stale prefixes.
> 
> 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.


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


>>> For each PIO with A bit set and preferred lifetime non-zero, collect
>>> the label values (based on the policy table in RFC 6724 "Default Address
>>> Selection") in a set.
>>
>> What do you mean by "label"?
> 
> See Section 2.1 in RFC 6724 (the 'Policy Table')
> 
>> Counting RAs or using timers is essentially the same...
> 
> It is not clear how to me could get the same effect using counters. Maybe
> you can give an example algorithm.

Yep:

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.




>>> (I guess that for battery lifetime it is best to send all multicasts
>>> together). If a router would spread RAs out over a longer period, 
>>> hosts will follow the RAs causing load to be distributed over multiple
>>> prefixes in a predictable fashion.
>>
>> >From the pov of the folk doing troubleshooting, this is not of much help.
> 
> You are right. I have an idea how to deal with this issue.

I'm listening ;-)


Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492