[GTER] Fwd: SLAAC renum/problems I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt)

[Fernando Gont]

FYI:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt


-------- Forwarded Message --------
Subject: SLAAC renum/problems I-D (Fwd: New Version Notification for
draft-gont-v6ops-slaac-renum-00.txt)
Date: Sat, 6 Jul 2019 17:03:08 +0100
From: Fernando Gont <fgont at si6networks.com>
To: IPv6 Operations <v6ops at ietf.org>
CC: Jan Zorz <jan at go6.si>, Richard Patterson <richard.patterson at sky.uk>

Folks,

To make the story short: Based on the discussion we had on
draft-gont-6man-slaac-renum, we have posted this new I-D which focuses
on discussing the problem, and describing operational mitigations.

The document is available at:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt

Comments are welcome.

And whenever the chairs deem appropriate, we'd like to know if v6ops
would like to work/adopt this document.

Thanks!

Cheers,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt
Date: Sat, 06 Jul 2019 08:59:12 -0700
From: internet-drafts at ietf.org
To: Fernando Gont <fgont at si6networks.com>, Jan Zorz <jan at go6.si>,
Richard Patterson <richard.patterson at sky.uk>


A new version of I-D, draft-gont-v6ops-slaac-renum-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-v6ops-slaac-renum
Revision:	00
Title:		Reaction of Stateless Address Autoconfiguration (SLAAC) to
Renumbering Events
Document date:	2019-07-06
Group:		Individual Submission
Pages:		14
URL:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/
Htmlized:       https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum


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 discusses operational
   workarounds to improve network robustness.




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


.