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

[Jen Linkova <[e-mail]>]

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? I  mean those
addresses are not staying forever,
just one month  in the worst case scenario. So they will disappear eventually.
On the other hand if I have an tcp session opened - why do we need to
kill it in 10 mins?
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...

> > - "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 ;(

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

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

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

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

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

> Thinking out loud: I wonder if support for RFC8028 should have actually
> been a MUST in RFC8504 -- reality is that in many multiprefix/multihomed
> scenarios, if you don't do RFC8504 it's quite likely your packets will
> be dropped -- i.e., an interoperability issue that would have warranted
> a "MUST" for 8028.

See above. Then 8028 should have said 'MUST support rule 5.5
-- 
SY, Jen Linkova aka Furry