Fwd: New Version Notification for draft-mishra-6man-variable-slaac-02.txt

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 22 February 2021 14:39 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E67693A0813 for <ipv6@ietfa.amsl.com>; Mon, 22 Feb 2021 06:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.671
X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PcINL0X0II61 for <ipv6@ietfa.amsl.com>; Mon, 22 Feb 2021 06:39:11 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0D03A07FC for <ipv6@ietf.org>; Mon, 22 Feb 2021 06:39:10 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr []) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 11MEd9tR032905 for <ipv6@ietf.org>; Mon, 22 Feb 2021 15:39:09 +0100
Received: from pisaure.intra.cea.fr (localhost []) by localhost (Postfix) with SMTP id 1116A20CEC8 for <ipv6@ietf.org>; Mon, 22 Feb 2021 15:39:09 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr []) by pisaure.intra.cea.fr (Postfix) with ESMTP id 070B420CEB1 for <ipv6@ietf.org>; Mon, 22 Feb 2021 15:39:09 +0100 (CET)
Received: from [] ([]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 11MEd8Ex006733 for <ipv6@ietf.org>; Mon, 22 Feb 2021 15:39:08 +0100
Subject: Fwd: New Version Notification for draft-mishra-6man-variable-slaac-02.txt
References: <161400396002.10207.237254660863849144@ietfa.amsl.com>
To: IPv6 <ipv6@ietf.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Forwarded-Message-Id: <161400396002.10207.237254660863849144@ietfa.amsl.com>
Message-ID: <284e7e79-65a8-0523-b32c-dc2019df73ad@gmail.com>
Date: Mon, 22 Feb 2021 15:39:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <161400396002.10207.237254660863849144@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RQBy_168ba75UjmPWsyeOJF1LJw>
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: Mon, 22 Feb 2021 14:39:14 -0000


With co-authors we updated the implementation, the draft, and re-submitted.

This new version takes into account comments from linux implementers
that were expressed on this email list.

- removed the flag from the RA.
- added a parameter local to the Host (a sysctl in linux) which is off
   by default, thus respecting the 64bit boundary of RFC4291.  When the
   parameter is set the Host is allowed to form addresses out of prefixes
   whose lengths is different than 64.
- stressed that a race to the bottom should be avoided.
- other small text improvements.

Please have a look at the draft.  We are interested to hear


(and yes, I do remember that during last IETF one of the ideas discussed
for moving forward was a potential new lightweight protocol designed to
do prefix delegation with ND messages.  And no, this draft does not
advance on that particular idea; I can explain why separately if necessary.)


-------- Message transféré --------
Sujet : New Version Notification for draft-mishra-6man-variable-slaac-02.txt
Date : Mon, 22 Feb 2021 06:26:00 -0800
De : internet-drafts@ietf.org
Pour : Alexandre Petrescu <Alexandre.Petrescu@cea.fr>fr>, Alexandre
Petrescu <alexandre.petrescu@cea.fr>fr>, Dmytro Shytyi
<dmytro.shytyi@sfr.com>om>, Dusan Mudric <dmudric@ciena.com>om>, Gyan Mishra
<gyan.s.mishra@verizon.com>om>, Naveen Kottapalli <nkottapalli@benu.net>

A new version of I-D, draft-mishra-6man-variable-slaac-02.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-mishra-6man-variable-slaac
Revision:	02
Title:		SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)
Document date:	2021-02-22
Group:		Individual Submission
Pages:		31

    This draft proposes the use of arbitrary length prefixes in PIO for
    SLAAC.  A prefix of length 63 in PIO, for example, would be permitted
    to form an address whose interface identifier length is 65, which
    allows several benefits.  A prefix of length 65 would be allowed too,
    but it SHOULD NOT be used on a large scale, like at a large ISP; this
    is to avoid a race to the bottom.

    The implementation uses a parameter in the Host which is off by
    default.  In that case, the Host respects the 64bit boundary.  When
    the parameter is set to on the Host accepts prefixes of lengths
    different than 64 and forms 128bit addresses.

    In the past, various IPv6 addressing models have been proposed based
    on a subnet hierarchy embedding a 64-bit prefix.  The last remnant of
    IPv6 classful addressing is a inflexible interface identifier
    boundary at /64.  This document proposes flexibility to the fixed
    position of that boundary for interface addressing.

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