Re: [v6ops] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)

[Fernando Gont <[e-mail]>]

On 21/2/19 01:25, Jen Linkova wrote:
> On Wed, Feb 20, 2019 at 8:49 PM Fernando Gont <[e-mail]> wrote:
>>> - (sorry if I missed another thread on it - I'm catching up with
>>> emails slowly): any reason for setting Valid Lifetime to 0 as well? It
>>> looks to me that just deprecating the prefix would be enough..What
>>> would be a benefit of completely removing an address already
>>> deprecated?
>>
>> You mean in the host-side algorithm specified in Section 5.1.3? The
>> benefit would be garbage collection. -- another alternative would be,
>> instead removing the addresses, reduce the current Valid Lifetime -- say
>> to 10 minutes or whatever, so that the stale addresses do not stay
>> around forever. (if SLAAC was using sensible timer values, you wouldn't
>> need these... but you probably don't want stale addresses to stay around
>> for one months, as per the default "Valid Lifetime").
> 
> Do we have any data on how much pain this is causing? 

Not that I know of. Problem is: you still have v4, and if v6 fails, HE
makes it work over v4.


> I  mean those
> addresses are not staying forever,
> just one month  in the worst case scenario. So they will disappear eventually.

Many stacks limit the number of prefixes they will use for address
configuration. Some limit such number to 16. That means that if you
experience crash-and-reboot 16 during the same month, your host may fail
to configure addresses for the fresh prefix.



> On the other hand if I have an tcp session opened - why do we need to
> kill it in 10 mins?

Not sure what you mean....



> I agree that default times should be more reasonable, so I agree that
> defaults should be changed and depend on the
> AdvDefaultLifetime.
> 
> Speaking of exact numbers - how did you come up with values? Just
> curious if the is any background for choosing them...

The only one you really choose is MaxRtrAdvInterval. The rest are set as
a function of it.

For the most part, I picked MaxRtrAdvInterval such that there were more
ferquent RAs, but in the worst-case scenario, never more than 1 every
1.5-2 minutes. (trade-off beween responsiveness and not bothering the
network a lot, unnecessarily)



> 
>>> - "After normal processing of Router Advertisement messages, Router
>>>    Advertisements that contain at least one PIO MUST be processed as
>>>    follows" - I'd suggest you make it explicit that PIOs must of of
>>> the global scope. I did see CPEs including PIOs for fe80::/64 (and
>>> AFAIR such behavior is not explicitly prohibited);
>>
>> Item b) in Section 5.5.3 says:
>>     b)  If the prefix is the link-local prefix, silently ignore the
>>       Prefix Information option.
>>
>> albeit not with normative language. But, anyway, if you've seen CPEs
>> send them, we better make this explicit!
> 
> I must be blind, I can not see that sentence in the draft ;(


Sorry, that section is not in the draft, but in rfc4862.

Same text appears in Section 6.3.4 of RFC4861.



>> I've never seen a scenario where information actually needs to be split
>> among multiple RAs. I have a hard time thinking of filling up a whole RA.
> 
> Let's wait for the new shiny world of mPVD to come...

Same router, PIOs split over more than three RAs?




>>> -  as I've mentioned earlier, it would be nice not to break other
>>> scenarios while fixing DHCP-PD case. So what do you think about
>>> modifying the algorithm so the addresses are deprecated only if *all*
>>> routers the PIO has been received from stopped advertising it? Again,
>>> my point is that while proposed behavior *does* help in a single-homed
>>> residential case, it would be nice to keep in mind other cases and
>>> avoid breaking them;
>>
>> Yes, we should update the algorithm as you suggest.
>>
>> Thinking our loud: best thing would probably be that, in the case the
>> prefix has been advertised by multiple routers, it is dis-associated
>> with the prefix that ceased advertising it. Otherwise, you might end up
>> sending packets sourced from that prefix to the next-hop router that has
>> ceased advertising it.  That is, if multiple routers were advertising a
>> prefix, and one has ceased advertising it, you want packets sourced from
>> that prefix to use a next-hop router that keeps advertising the prefix.
> 
> So...it looks to me that the only change should be:
> - if a host supports prefix <> advertizing router mapping and supports
> the Rule 5.5:
>    --  deassociate prefix - next-hop if the given router stops advertizing it;
>    -- deprecate the prefix if there is no routers advertizing it;

In response to what?

I was thinking this would be an action by algorithm from 5.1.3 once the
prefix has been un-preferred.

If not, what would be the event that would trigger such dis-association?




> Then the default address selection takes care of selecting the right
> source address.
> No need for complex algorithm described in the draft (and potential
> implementation bugs).
> 
> If the host does not support Rule 5.5 + prefix<>next-hop mapping, this
> draft (PIO processing part) would not work for them anyway.
> 
> Combined with reduced default timers it should help significantly (at
> least for hosts and routers implementing this..)

With appropriate timers + modification to SAS you get the problem
solved. However, if you have multiple prefixes, and the source address
will flap among them. -- I'd try, to the extent that is possible, to
avoid that....


> 
>>> - the proposed changes say that PIOs MUST be processed as
>>> follows....and relies on hosts tracking prefix <> nexthop as per
>>> RFC8028...However RFC8028 (and RFC8504) uses  'SHOULD' ...so it seems
>>> to be inconsistency here..If a host does not implement RFC8029, all
>>> those MUST in the draft do not make much sense.
>>
>> That's a good point. I wonder if we should change the "MUST" to
>> "SHOULD", or whether we should stick to "MUST" with a rationale of "a
>> host that implements this standard MUST implement RFC8028 and MUST
>> process PIOs as follows..."
> 
> See above. All we need to do in terms of PIO processing by a host is
> to say 'host SHOULD refresh prefix-next-hop mapping while processing
> RAs' (which would mean 'remove all mappings for that next-hop if they
> are not in that RA you are processing') and 'host SHOULD deprecate
> addresses with no next-hops'.

This enforces a more strict requirement on RAs. i.e., PIOs can only be
sent in one RA. I'm not saying that's necessarily bad, but the reasons
for the algorithm in Section 5.1.3 is to allow PIOs to be split in at
most two RAs.



> Even if you say 'MUST' here (and explicitly state 'MUST implement
> RFC8028') it would only mean 'hosts MUST support a standard which says
> they SHOULD do smth' => effectively that requirement means 'SHOULD'.

Agreed.



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