Re: Extending a /64

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 12 November 2020 08:22 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 6537E3A14CE for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 00:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.67
X-Spam-Level:
X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHnd1glofWAo for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 00:22:57 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 9EAE63A145A for <ipv6@ietf.org>; Thu, 12 Nov 2020 00:22:57 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AC8Mt8R018821 for <ipv6@ietf.org>; Thu, 12 Nov 2020 09:22:55 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5B4562048BC for <ipv6@ietf.org>; Thu, 12 Nov 2020 09:22:55 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4F78320489B for <ipv6@ietf.org>; Thu, 12 Nov 2020 09:22:55 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AC8MtlX019092 for <ipv6@ietf.org>; Thu, 12 Nov 2020 09:22:55 +0100
Subject: Re: Extending a /64
To: ipv6@ietf.org
References: <005ECBB3-088B-4363-BB53-8D4AD25CA3D2@employees.org> <b468124f-f85b-7e20-a354-c6b7eaba3447@mccallumwhyman.com> <20593.1604972743@localhost> <CAKr6gn0tedRz4iBu49Lrw5qMCdXWPcg-66UAOfHeJ_ZUeq8U4g@mail.gmail.com> <CABNhwV2c_qaQGY2J62LDh=EZYHo5poYNF_Asf908ofR3wfmW1g@mail.gmail.com> <CABNhwV3wgdOUKqOyqJ4bTvVv4PKq81anYCxASOTCEMg3T84zig@mail.gmail.com> <CAL9jLaaDYrXVTGQeWh4aAc-qUVCoxRNokwANpQhuZ4OGdpySMw@mail.gmail.com> <46a202df-bae8-626b-042a-72adc3d31fcc@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <7f3dab27-0712-c019-3276-25b59081684e@gmail.com>
Date: Thu, 12 Nov 2020 09:22:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2
MIME-Version: 1.0
In-Reply-To: <46a202df-bae8-626b-042a-72adc3d31fcc@gmail.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/Ve88Df79qFlWhgXy9ax4IDBhwto>
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: Thu, 12 Nov 2020 08:22:59 -0000


Le 11/11/2020 à 22:23, Brian E Carpenter a écrit :
> On 12-Nov-20 08:44, Christopher Morrow wrote:
>> it seems that this whole conversation is really:
>>    https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05
>>
>> happening again.
>>
>> right? :) "I'd like to use all the bits in my address as I see fit for my purposes"
> 
> Except that it *explicitly* recommends against changing the /64 for SLAAC.

This is the text in the draft.

It recommends against changing whileat the same time it says there is no 
reason to recommend so.  What should a reasonable reader conclude?

draft-bourbaki-6man-classless-ipv6-05:
> 5.  Recommendations
> 
>    For historical reasons, when a prefix is needed on a link, barring
>    other considerations, a /64 is recommended [RFC7136].
> 
>    The length of the Interface Identifier in Stateless Address
>    Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
>    sufficient for effective randomization for privacy reasons.  For
>    example, 48 bits might be sufficient.  But operationally we
>    recommend, barring strong considerations to the contrary, using
>    64-bits for SLAAC in order not to discover bugs where 64 was hard-
>    coded, and to favor portability of devices and operating systems.
> 
>    Note that OpenBSD ships with SLAAC for lengths longer than /64.
> 
>    Nonetheless, there is no reason in theory why an IPv6 node should not
>    operate with different interface identifier lengths on different
>    physical interfaces.  Thus, a correct implementation of SLAAC must in
>    fact allow for any prefix length, with the value being a parameter
>    per interface.  For instance, the Interface Identifier length in the
>    recommended (see [RFC8064]) algorithm for selecting stable interface
>    identifiers [RFC7217] is a parameter, rather than a hard-coded value.
[end of citation from draft.]

Alex

> 
>     Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>