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

Hello, Jen,

On 20/2/19 06:08, Jen Linkova wrote:
> Hi Fernando,
> 
> On Tue, Feb 19, 2019 at 10:48 AM Fernando Gont <[e-mail]> wrote:
>> We have posted a revision of our I-D, which expands a lot on the problem
>> and possible solutions, based on the email discussion we had on this list.
> 
> A few comments:
> - (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").



> - "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!



> - the draft makes an assumption that "while network
>       configuration information might be split into multiple RAs, PIOs
>       will be spread among *at most* two RAs." - I'm not sure where
> this assumption is coming from - is there any requirements for routers
> saying it MUST/SHOULD do this? Adding any references to support such
> assumption would be very helpful.

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.

So the logic here was "Ok, all information is normally transmitted in a
single RA. But for the sake of (rather insane :-) ) flexibility, let's
assume that you send all the info is sent in as many RAs as you want,
with PIOs split among two RAs". I believe it's quite unlikely that PIO
information needs to be split into more than two RAs -- you'd need ~
(2*1280)/16 worth of prefixes)



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


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

Thoughts?

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.

Thanks!

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