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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 19 February 2019 01:18 UTC

Return-Path: <prvs=1953e7be70=jordi.palet@consulintel.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CAB129BBF; Mon, 18 Feb 2019 17:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRtbC3nUWst1; Mon, 18 Feb 2019 17:18:42 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC381200D7; Mon, 18 Feb 2019 17:18:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550539118; x=1551143918; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=HaecmpCxBtk0XfAswpVjlzUknIMF63e2cvn24Qu3yYo=; b=fscTwdgkqk0Un 4euGUya7xGXYCGAniGrUEFbi7M2+ZdcBgqhM6aObtMhsLeTYPQmf4vOz/RBP6uHW jtwO7x00FyihHDSXBziLWQ0734SaF0KPARzzrn+m4AxPyNcd4+T9O/ENtFSgtpLt XErvodN2I0FT4JJbq8rt/TNw4TE5Wc=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 19 Feb 2019 02:18:38 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 19 Feb 2019 02:18:25 +0100
Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006159717.msg; Tue, 19 Feb 2019 02:18:25 +0100
X-MDRemoteIP: 10.8.10.10
X-MDHelo: [10.10.10.160]
X-MDArrival-Date: Tue, 19 Feb 2019 02:18:25 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1953e7be70=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.7.190210
Date: Tue, 19 Feb 2019 10:18:14 +0900
Subject: Re: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
CC: IPv6 Operations <v6ops@ietf.org>
Message-ID: <105E9F49-A9E7-4C77-963D-0B37997FF7AE@consulintel.es>
Thread-Topic: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)
References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> <fe9eecc0-b41a-53c5-5e17-7f8d732cb7cf@si6networks.com>
In-Reply-To: <fe9eecc0-b41a-53c5-5e17-7f8d732cb7cf@si6networks.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fkr1VEsU2A3HiBWtpjBJT2WxJj0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2019 01:18:44 -0000

As just said in another list in Spanish, the reference to GERMAN-DP is wrong, in the sense that is not a law or anything similar. German folks can confirm. At least that has been said a few weeks ago by Germans in another list ...

Regards,
Jordi
 
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Fernando Gont <fgont@si6networks.com>
Fecha: martes, 19 de febrero de 2019, 8:49
Para: "6man@ietf.org" <6man@ietf.org>
CC: IPv6 Operations <v6ops@ietf.org>
Asunto: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)

    Folks,
    
    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.
    
    The revised I-D is available at:
    https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt
    
    Comments will be very welcome.
    
    Thanks!
    Fernando & Jan
    
    
    
    
    -------- 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
    
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.