Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 05 November 2020 18:05 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 5747B3A1943; Thu, 5 Nov 2020 10:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.424
X-Spam-Level:
X-Spam-Status: No, score=0.424 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.247, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIby-pDrPBIV; Thu, 5 Nov 2020 10:05:31 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 938353A193F; Thu, 5 Nov 2020 10:05:30 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A5I5Pdu041024; Thu, 5 Nov 2020 19:05:25 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4782B209A4C; Thu, 5 Nov 2020 19:05:25 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 32802209A38; Thu, 5 Nov 2020 19:05:25 +0100 (CET)
Received: from [10.11.242.214] ([10.11.242.214]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A5I5O80012953; Thu, 5 Nov 2020 19:05:24 +0100
Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, otroan@employees.org, Gyan Mishra <hayabusagsm@gmail.com>
Cc: draft-mishra-6man-variable-slaac@ietf.org, 6man WG <ipv6@ietf.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CABNhwV3L7kz=cWu8s3X=djVf4MCwewzbEgx09TWaKzCULCjYUQ@mail.gmail.com> <9A9CE8E7-3552-4FD8-A50E-1BDCA2CB813F@employees.org> <7551d6af-0cd6-dfc4-652c-5d026f740415@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b8fa6b50-6d61-fe5f-2f10-8693d97fb08b@gmail.com>
Date: Thu, 05 Nov 2020 19:05:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <7551d6af-0cd6-dfc4-652c-5d026f740415@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/W1aZUfuyebezsmZbgWmtr08fp4o>
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, 05 Nov 2020 18:05:32 -0000

Le 03/11/2020 à 21:20, Brian E Carpenter a écrit :
> On 03-Nov-20 22:02, otroan@employees.org wrote:
>>> With 5G network slicing will become a formidable part of the 
>>> paradigm shift from shared resources to network resource 
>>> isolation at the radio and RAN layers.  The use case for being 
>>> able to provide critical segmentation for network slices makes
>>> it an industry imperative to be able support variable IID
>>> lengths with slaac as all 5G deployments worldwide will be IPv6
>>> only from the start.
>> 
>> You'd likely find most people on this group thinking of 5G as just 
>> "more of the same"; access to the Internet. At least I struggled 
>> understanding what there is about 5G that would require a change
>> in IPv6 addressing models.
>> 
>> Are there any of the problems/use-cases that cannot be solved by 
>> assigning a shorter prefix than /64 to the end-user networks?
> 
> Is it really the case that 5G hasn't fixed the notorious 4G bug of 
> only allowing /64s?

I think yes, it is really the case.

A 5G network will see many modifications (from 4G) with the New Radio
access, but is not likely to make many change to GGSN and SGSN, which 
are the entities involved in IP address allocation.  I think.

One operator's goal to migrate to 5G is to make it as easy to migrate
for end users as possible.  Just notice higher bandwidth.  On a
smartphone, there will be just a small acronym '5G', hardly seen without
glasses, in the list of acronyms GPRS, 3G, H+, 4G and 4G+ next to 5
small bars showing signal quality.  And no, 5 in the number of bars is 
just a coincidence: they have always been 5 even in times of 2G.

This is how it happened when it moved from 3G to 4G and still kept that /64.

Where I live the next 5G deployment for the masses arrives at the
earliest in December.  At that point it's easy to try it and answer to
the question you raise: is 5G offering something else than a /64 to
smartphones.

(there is one little issue in trying that very quickly, in that the
operator that claims to do 5G first among all the others also has
something against IPv6, believing in essence IPv6 is not needed
anywhere, including 5G; so the trial might not happen that quickly).

> Or is it a matter of operational choice by 5G operators?

I dont know.

Some operators say they depend on what the router manufacturers do.
Router manufacturers do put this DHCPv6-PD option in, but for
convenience, also keep the 64bit limit in most places.

Alex

> 
> Brian
>