Re: SLAAC protocol improvements for flash renumbering (Fwd: New Version Notification for draft-gont-6man-slaac-renum-02.txt)

Fernando

The focus of this draft is primarily for the RFC 4941 privacy extension
temporary address current VL 7 PL 1 and future bis version VL 2 PL 1
employed for outgoing connections.

As for the network side RA sent my the router SLAAC PIO address given that
the VL is 30 days and PL 7 days since the last RA is periodic by default
the stable address never ages or gets renumbered as long as the host
endpoints NIC remains on the same subnet.  So for those apps using stable
address for “server like” are not impacted by renumbering event.  The
address can be considered permanent even as opposed to stable if the device
is not mobile or stationary always on and UP device.

When the flash renumbering occurs for outgoing client-like connections at
the VL expire time - at that time long lived connections still using the
now invalid address would be reset and so it’s those long lived connections
that are reset.

So the main goal of this draft is to address that renumbering event.

Maybe we should clarify that in the introduction and abstract.

Kind regards

Gyan

On Wed, Feb 19, 2020 at 11:46 PM Fernando Gont <fgont@si6networks.com>
wrote:

> Folks,
>
> We have posted a revision of our document with a proposal for SLAAC
> protocol tweaks to improve its robustness to renumbering events.
>
> The revised I-D is available at:
> https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-02.txt
>
> This version should be way easier to read.
>
> Besides, part of the contents in earlier versions of the draft have
> moved out into other (stand alone) documents:
>
> * draft-gont-v6ops-slaac-renum: Problem statement & operational mitigations
>
> * draft-gont-v6ops-cpe-slaac-renum: Recommendations for Customer Edge
> Routers
>
> Your feedback will be highly appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-gont-6man-slaac-renum-02.txt
> Date: Sun, 16 Feb 2020 19:45:36 -0800
> 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-02.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:           draft-gont-6man-slaac-renum
> Revision:       02
> Title:          Improving the Robustness of Stateless Address
> Autoconfiguration
> (SLAAC) to Flash Renumbering Events
> Document date:  2020-02-16
> Group:          Individual Submission
> Pages:          18
> URL:
> https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
> Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-02
>
> 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
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com