Re: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt)

[Fernando Gont <[e-mail]>]

Hi, Erik,

On 13/4/20 01:57, Erik Kline wrote:
> <no hats>
> 
> I think I would prefer if we can solve 90+% of the problem with: (a) 
> hosts try to do right thing as told to them by routers and (b) the 
> routers tell hosts the right thing.  I think improved timer guidance 
> (vis. v6ops drafts) could be of value in regard to (b).

FWIW, Section 4.1 of draft-gont-6man-slaac-renum-06 is exactly that:
* Section 4.1.1 changes the defaults for routers
* Section 4.1.2 sanitizes the received lifetimes

Part of the rationale behind this document is that we need to improve 
things with what we have. e.g., there are going to be routers that will 
not be updated until they are phased out.

The v6ops work is indeed useful and tackles one of the most common cases 
where this kind of scenario takes place (CE in a home deployment)... but 
doesn't apply to the general case of routers. And I believe that is 
needed, too. What we have as current default values should be changed.



> That having been said, as noted there are times where the routers might 
> not be able to correctly deprecate a prefix.  (Also the whole "2 hour" 
> PIO lifetime thing always struck me as a a bit of wart.)

Indeed. And as noted in the I-D, with all the other vectors that remain 
open, it doesn't make sense to do this 2-hour thing.



> I feel like what's wanted here is for hosts to be able to do something 
> like BFD for any given non-link-local unicast address -- some host OSes 
> /might/ even want to do something (log/warn, maybe) about manual/DHCPv6 
> configured addresses that might fall within a problematically 
> disappearing prefix.
> 
> Is it just as workable, and less complicated, if hosts that want to 
> check the validity of a previously advertised prefix do a few unicast 
> NSes for the router's link-local address from a source address in the 
> prefix to see if the router thinks the path to prefix is back onto the 
> link?  I just did this at home it worked, but my setup is also about as 
> simple as they come.

The document essentially has to sets of components:

1) A set of modications that help deprecate stale prefixes in a timelier 
manner, including:
    - remove the prohibition to reduce the to < 2-hours
    - more appropriate lifetimes at routers
    - capping PIOs at hosts

2) Then an algorithm (Section 4.5.1 or 4.5.2) to infer stale prefixes.


If I understand correctly your proposal/evaluation of BFD as a possible 
alternative would be an alternative for 2), but not for 1). Is that correct?

I believe that BFD would be exercising something else, as opposed to, 
specifically, if the prefixes have become stale. Additionally, it would 
seem to me that doing something ala BFD would be much more complicated, 
and with a number of corner cases that are hard to predict, and prone to 
failure. -- just me thinking out loud:

* What if the router advertises the prefix, but is not a default router?

* How often would you send probes? If you have multiple prefixes and 
multiple routers, would you do all the possible combinations?

* Would you have different timers for BFD?

* What would be the criteria for deprecating/invalidating addresses? -- 
i.e., how would BFD map into these to ND phases?

Part of the design goal we had in mind when developing the algorithms in 
Section 4.5 was to avoid sending extra packets (the two algorithms are 
essentially passive), and have something which integrates with ND/SLAAC 
as much as possible.

If one were to opt for actively "probing" stuff, then one might simply 
poll routers with RSs, and check if they keep advertising the same 
information.

IMHO, what we need to check for dealing with stale information is 
whether the advertised information is current or not -- with current 
meaning "there's a router actively advertising such information, on a 
regular basis". While in a way you might infer that if you can't BFD the 
information is stale, I think the two are verifying two different 
things. What we are doing is, in a way, garbage collection (passive 
stuff), where BFD requires active action on the host side.

That aside, what would be the advantage of the algorithm you describe vs 
e.g. Section 4.5.2 of drf-gont-6man-slaac-renum?

Thanks!

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