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

Hi Fernando,

On Tue, Feb 19, 2019 at 10:48 AM Fernando Gont <fgont@si6networks.com> 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?

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

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

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

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

> -------- Forwarded Message --------
> Subject: New Version Notification for draft-gont-6man-slaac-renum-01.txt
> Date: Mon, 18 Feb 2019 15:45:21 -0800
> From: internet-drafts@ietf.org
> To: Fernando Gont <fgont@si6networks.com>, Jan Zorz <jan@go6.si>
>
>
> A new version of I-D, draft-gont-6man-slaac-renum-01.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:           draft-gont-6man-slaac-renum
> Revision:       01
> Title:          Reaction of Stateless Address Autoconfiguration (SLAAC) to
> Renumbering Events
> Document date:  2019-02-18
> Group:          Individual Submission
> Pages:          22
> URL:
> https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
> Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-01
>
> Abstract:
>    In scenarios where network configuration information related to IPv6
>    prefixes becomes invalid without any explicit signaling of that
>    condition (such as when a CPE crashes and reboots without knowledge
>    of the previously-employed prefixes), nodes on the local network will
>    continue using stale prefixes for an unacceptably long period of
>    time, thus resulting in connectivity problems.  This document
>    analyzes these problem scenarios, and proposes workarounds to improve
>    network robustness.  This document updates RFC4861 and RFC4862 to
>    allow for a more robust reaction to network configuration changes.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--
SY, Jen Linkova aka Furry