Re: I-D Action: draft-gont-6man-slaac-renum-02.txt

[Philip Homburg <[e-mail]>]

In your letter dated Mon, 9 Mar 2020 14:47:58 -0300 you wrote:
>* Is there a rationale for "10"? Or is it mostly "routers couldn't 
>reasonably send SLAAC config split into that many RAs"?

The 10 is not supposed to be optimal. Just something that works. 

The rational is that if a router splits the prefixes over 2 RAs, then the
chance that you only get 1 of them 10 times in a row is extremely low.

If, for example, you would set the value to 2, then just one packet need to 
be lost for a misclassification to happen.

>* Are these "measurements" something you'd continually perform, or 
>something you'd only do on e.g. a link-up event?

After a link up event be also when a prefix is deprecated.

>* Would a connectivity glitch reset these measurements?

A link attachment event should reset them. Just a temporary loss of 
connection should have no effect.

>* WHile measuring, do you assume "split RA" or "non-split RA"?

Split RA. Split RA is that safe version (just let the prefix expire), 
non-split RA needs to be established.

>> by the current router and are not in the current RA then
>> - if SPLIT_RA is set, deprecate the old prefixes if they were last seen at
>>    least as long as the router lifetime (if the router is not a default
>>    router then do nothing).
>
>When using "deprecate", do you mean:
>1) unprefer, or,
>2( invalidate

Unprefer.

>If #1, what would trigger invalidation? A receipt of a similar RA?

I have no code for immediate invalidation. RFC 4862 is very conservative
in marking an address invalid (the 2 hour minimum).

It is a significant departure from RFC 4862 to invalidate addresses quickly.
If that is the behavior we want, then changing from unprefer to invalidate
would do the right thing.

>Since this bullet implies that RAs are not split, what would be the 
>rationale for "setting the preferred lifetime to a short timeout"?

This is a bit of overly clever trickery that handles the case if a router
switches from sending one RA to multiple RAs and sends them close together.

>And, as before: if this simply unprefers the address, what would 
>actually invalidate it? Receipt of a similar RA?

The current code just lets the address become invalid when the valid lifetime
expires. In my opinion, the important part is to pick a working address for
outgoing connections (i.e. making sure the right address is preferred).
Breaking exiting connections should be left to application protocols.

Though if there is consensus that existing connections should be terminated 
by the IPv6 layer, then the code can be changed to invalid addresses instead
unpreferring them.