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

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

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

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.

On Wed, Apr 8, 2020 at 7:59 AM Fernando Gont <fgont@si6networks.com> wrote:

> Folks,
>
> Ping?
>
>
> On 6/4/20 16:45, Fernando Gont wrote:
> > Folks,
> >
> > I've just posted a revision of draft-gont-6man-slaac-renum
> > (<
> https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-06.txt>),
>
> > which incorporates these changes:
> >
> > * It updates the section on the default PIO lifetimes (Section 4.1.1)
> > according to the discussion we had both at the 6man interim meeting and
> > on the mailing-list.
> >
> > * Added an "Implementation status" section
> >
> >
> > At this point, we would like 6man to be polled for adoption of this
> > document as a wg item.
> >
> > The topic and variants of this document have been discussed for over a
> > year now, with the problem statement document becoming a wg item of
> > v6ops (draft-ietf-v6ops-slaac-renum).
> >
> > We believe that both the topic and the document have received a fair
> > share of interest and discussion, and that it is time for the wg to make
> > a decision on the document, for the wg to continue to work on it as a
> > working group document.
> >
> > Thanks!
> >
> > Cheers,
> > Fernando
> >
> >
> >
> >
> > -------- Forwarded Message --------
> > Subject: New Version Notification for draft-gont-6man-slaac-renum-06.txt
> > Date: Mon, 06 Apr 2020 12:37:26 -0700
> > From: internet-drafts@ietf.org
> > To: Fernando Gont <fgont@si6networks.com>, Jan Zorz <jan@go6.si>,
> > Richard Patterson <richard.patterson@sky.uk>
> >
> >
> > A new version of I-D, draft-gont-6man-slaac-renum-06.txt
> > has been successfully submitted by Fernando Gont and posted to the
> > IETF repository.
> >
> > Name:        draft-gont-6man-slaac-renum
> > Revision:    06
> > Title:        Improving the Robustness of Stateless Address
> > Autoconfiguration (SLAAC) to Flash Renumbering Events
> > Document date:    2020-04-06
> > Group:        Individual Submission
> > Pages:        29
> > URL:
> > https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-06.txt
> > Status: https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
> > Htmlized:
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-06
> >
> > Abstract:
> >     In renumbering scenarios where an IPv6 prefix suddenly becomes
> >     invalid, hosts on the local network will continue using stale
> >     prefixes for an unacceptably long period of time, thus resulting in
> >     connectivity problems.  This document improves the reaction of IPv6
> >     Stateless Address Autoconfiguration to such renumbering scenarios.
> >
> >
> >
> >
> > 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
> >
> >
> >
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>