Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 10 November 2020 10:56 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 246513A0100; Tue, 10 Nov 2020 02:56:16 -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 P1L37JaTdhpn; Tue, 10 Nov 2020 02:56:14 -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 313EB3A00E3; Tue, 10 Nov 2020 02:56:14 -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 0AAAu9s3016105; Tue, 10 Nov 2020 11:56:09 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E4E5520459A; Tue, 10 Nov 2020 11:56:08 +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 C9C0820514B; Tue, 10 Nov 2020 11:56:08 +0100 (CET)
Received: from [10.11.242.43] ([10.11.242.43]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AAAu7hV002426; Tue, 10 Nov 2020 11:56:07 +0100
Subject: Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
To: Mark Andrews <marka@isc.org>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IPv6 IPv6 List <ipv6@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>, Dusan Mudric <dusan.mudric@gmail.com>, Dmytro Shytyi <dmytro@shytyi.net>
References: <CABNhwV1D7ng8JHJVUBrMhVmbQEQrhECBN_XUUcS5ZSV0WF=Lnw@mail.gmail.com> <4658abe3-909e-af0a-ddad-85db06e161ff@gmail.com> <CABNhwV1rBhWF6e7Tuk6L-R=gTmWgfXvFkWkCQyvbmEA06W3t0A@mail.gmail.com> <4088150e-1289-5c4f-184d-30df3e66f354@gmail.com> <9764d64ee89f4a3c95cdcabae08646fb@boeing.com> <CABNhwV1Lm-5OU7zQFMhqJNcE7z-LFS4tA7RSU3sRA5iWWWw_Gw@mail.gmail.com> <7d3d8f4c394b43ef98be5fa648250e0a@boeing.com> <5C1373C0-01FD-40C5-805C-94F3339AA63F@isc.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <bb57c288-1a50-00ac-72f4-43aebee3f7ae@gmail.com>
Date: Tue, 10 Nov 2020 11:56:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <5C1373C0-01FD-40C5-805C-94F3339AA63F@isc.org>
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/i_hMFU_BpJNwxPv0N1i15gfsSng>
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, 10 Nov 2020 10:56:16 -0000

There is something strange in calling a person a 'site'.

Alex

Le 10/11/2020 à 00:20, Mark Andrews a écrit :
> Well people where thinking at the time that a person could be a site in terms
> of wearable networks.  They are now a common reality with cell phones providing
> a uplink.  /48 was chosen with that concept in mind.
> 
> Mark
> 
>> On 10 Nov 2020, at 10:10, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>>
>> I think the notion of what constitutes a “site” has advanced significantly since the
>> publication of RFC6177 – to the point that today even my cellphone could be seen
>> as a “site” in terms of the multi-addressing requirements its internal networks and
>> applications may require. Things that once were regarded as uni-addressed end
>> systems are now becoming (massively) multi-addressed IoTs. So an RFC6177-sized
>> IPv6 prefix for my cellphone could potentially be put to good use.
>>   
>> Fred
>>   
>> From: Gyan Mishra [mailto:hayabusagsm@gmail.com]
>> Sent: Monday, November 09, 2020 2:53 PM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; Dmytro Shytyi <dmytro@shytyi.net>; Dusan Mudric <dusan.mudric@gmail.com>; IPv6 IPv6 List <ipv6@ietf.org>; draft-mishra-6man-variable-slaac@ietf.org
>> Subject: Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
>>   
>>   
>> On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>> Brian, brief comment/question below:
>>
>>> -----Original Message-----
>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
>>> Sent: Monday, November 09, 2020 1:58 PM
>>> To: Gyan Mishra <hayabusagsm@gmail.com>
>>> Cc: IPv6 IPv6 List <ipv6@ietf.org>; draft-mishra-6man-variable-slaac@ietf.org; Alexandre Petrescu <alexandre.petrescu@gmail.com>;
>>> Dusan Mudric <dusan.mudric@gmail.com>; Dmytro Shytyi <dmytro@shytyi.net>
>>> Subject: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
>>>
>>> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
>>> know that the content is safe.
>>>
>>>
>>> In line...
>>>
>>> On 10-Nov-20 04:35, Gyan Mishra wrote:
>>>> Brian
>>>>
>>>> In-line
>>>>
>>>> On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
>>>>
>>>>      Gyan,
>>>>
>>>>      I don't think you were around for the original discussions, so there is an aspect that is missing from your logic below.
>>>>
>>>>      The inclusion of a separate interface identifier field in IP addresses was an entirely intentional feature of IPng. If all we had wanted
>>> to do was IPv4 with bigger addresses, that's what we would have done and the address length would have undoubtedly been 64 bits.
>>> In fact there were various proposals to do exactly that, with a variety of associated transition and coexistence mechanisms.
>>>>
>>>>      But the rough consensus was to do more than that, and to allow *extra* space in the address for an interface identifier that was
>>> not part of the subnetting mechanism. Originally it was going to be 48 bits, so the longest subnet prefix would have been 80; on
>>> second thoughts it was set to 64, which gave *exactly* the same extension to the subnettable space as we would have got from IPv4
>>> with bigger addresses.
>>>>
>>>>      That isn't inconsistent with what we now call BCP198, which says that on links where an interface identifier & SLAAC isn't needed,
>>> subnetting can extend out to /127.
>>>>
>>>>      All that was despite the fact that we hadn't even realised the potential privacy benefits of a host-defined interface identifier at the
>>> time; that is much more recent.
>>>>
>>>>      As far "day 1" goes, please remember that DHCPv6 is a retro-fit:
>>>>
>>>>      RFC1971 IPv6 Stateless Address Autoconfiguration. August 1996
>>>>      RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). July 2003.
>>>>
>>>>
>>>>      Gyan> Makes sense then that as DHCPv6 was a retrofit “add on” to the base architecture that this issue came about afterwards.
>>>>
>>>>
>>>>
>>>>      (In fairness, draft-ietf-addrconf-ipv6-auto-00 was dated January 1995 and draft-ietf-dhc-dhcpv6-00 was dated February 1995, but
>>> it advanced very slowly compared to SLAAC.)
>>>>
>>>>
>>>>      Gyan> From a problem statement perspective do you agree with the title of this thread “Day 1 interoperability issue”?
>>>
>>> No. From the dates of the RFCs, it's a "Year 7 interoperability issue".
>>>
>>>> Do you agree that one way to solve is to allow SLAAC to support longer prefix lengths?
>>>
>>> That's one way, but it's the wrong way. The right way is for all operators, including mobile operators, to assign /48 or /56 to all end
>>> users.
>>
>> Isn't that exactly what RFC6177 (BCP157) tells us? Should we be working to
>> reaffirm that that BCP still applies today?
>>   
>>   
>>      
>>     Gyan> RFC 6177 - Bottom of the intro it states that no formal recommendation is given.  It’s up to the operators to give what they feel is best.
>>   
>>     This document does not make a formal recommendation on what the exact
>>     assignment size should be.  The exact choice of how much address
>>     space to assign end sites is an issue for the operational community.
>>     The IETF's role in this case is limited to providing guidance on IPv6
>>     architectural and operational considerations.  This document provides
>>     input into those discussions.  The focus of this document is to
>>     examine the architectural issues and some of the operational
>>     considerations relating to the size of the end site assignment.
>>
>>
>> Thanks - Fred
>>
>>>> Do you agree that this is a major operational issue that needs to be solved?
>>>
>>> Yes, but as Barbara says, that needs some collaboration with the SDOs and operator fora to get rid of /64 assignments.
>>>
>>>     Brian
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> --
>> <image001.jpg>
>>
>> Gyan Mishra
>> Network Solutions Architect
>> M 301 502-1347
>> 13101 Columbia Pike
>> Silver Spring, MD
>>   
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>