Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 24 November 2020 15:57 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 06E093A1205; Tue, 24 Nov 2020 07:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.155
X-Spam-Level: ***
X-Spam-Status: No, score=3.155 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, 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 iL8p7gDW4FXy; Tue, 24 Nov 2020 07:57:46 -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 33CCA3A11CD; Tue, 24 Nov 2020 07:57:45 -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 0AOFveIV002469; Tue, 24 Nov 2020 16:57:40 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 47212209416; Tue, 24 Nov 2020 16:57:40 +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 2D07920944B; Tue, 24 Nov 2020 16:57:40 +0100 (CET)
Received: from [10.11.244.24] ([10.11.244.24]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOFvd2T013360; Tue, 24 Nov 2020 16:57:39 +0100
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
To: Erik Kline <ek.ietf@gmail.com>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Cameron Byrne <cb.list6@gmail.com>, 6MAN <6man@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>, IPv6 Operations <v6ops@ietf.org>
References: <CABNhwV2-dH81CY4wSisV8BU-7H9m5a1xYMqTMecRxhNqZe=ApQ@mail.gmail.com> <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com> <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <675c8025-93ff-d0bc-e9be-e900f41f19df@gmail.com>
Date: Tue, 24 Nov 2020 16:57:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.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/AiwA53unGysr9SV3wBsG0YzEYaI>
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, 24 Nov 2020 15:57:55 -0000


Le 24/11/2020 à 07:32, Erik Kline a écrit :
> <no hats>
> 
> There have been, I think, 2-4 (more?) ND-based PD or PD-like 
> proposals.  The main argument against ND-PD, as I recall from PIO-X 
> days, has been "we have DHCPv6 PD, ND PD will have to replicate most 
> of the same semantics, why do we need two ways to do this?"
> 
> If, on the other hand, we are to understand that 3GPP operators are 
> just not deploying DHCPv6 PD (for whatever reason), then I think a 
> reasonable argument can be made that "we wouldn't have two, because
> we currently have zero."
> 
> If the above is true, I, for one, would be interested to evaluate a 
> simple, clean draft that did things like:
> 
> [1] define a PDIO, and its use in RAs and RSes (for requesting a 
> prefix length or refreshing/requesting a previously delegated
> prefix),
> 
> [2] define the scope of applicability (i.e. in contexts where it can
> be guaranteed that only one client will receive the RA),

[2.1] - the option should be implemented on as many as possible
platforms, before proceeding.  Android is a perfect candidate, but there
are more platforms different than Android that use same networks as
Android does - e.g. 'IoT routers' - who also need such option.

> [3] did not make unnecessary reference to link technologies, mobility
> architectures, or the like (just define the generic deployment
> requirements, however they may be met),
> 
> [4] did not try to make other unrelated changes (like redoing the /64
> SLAAC boundary; residential PD has been working fine for a while) 
> and
> 
> [5] define the relationship to any PIOs present (i.e. a PDIO that 
> covers or equals a PIO with L=0 can inform the client that it's in
> an RFC 8273-style environment whereas L=1 indicates an RFC 6603 
> situation).

[5.1] - define whether or not this option is used to form an address on
the receiving interface.  Define whether or not this option must
be accompanied by a regular PIO.  Consider the consideration of the
reduction of numbers of bytes on wireless links.  Consider whether or 
not the use of this option implies that more other messages must be sent 
on the link.

[5.2] - define the additional security implications of using the new option.

> I think it's possible to over-complicate the work, but if the 
> deployment requirements are well-scoped I think it could be fairly 
> clean and simple.

It is a good goal.

Alex

.
> 
> On Mon, Nov 23, 2020 at 5:27 PM Lorenzo Colitti 
> <lorenzo=40google.com@dmarc.ietf.org> wrote:
>> 
>> I don't think anyone ever said Android will not support DHCPv6 PD.
>> That said, implementing DHCPv6 PD on cellular is difficult for
>> technical reasons, including:
>> 
>> There is no DHCPv6 PD implementation in Android, so one would need
>> to be written. The natural place for such an implementation is in
>> the IpClient code, which does not (yet?) run on cellular networks.
>> 
>> Something like the new RA option proposed in the 64share v2 thread
>> (+Cameron Byrne) - assuming it gains consensus - would be much
>> easier to implement.
>> 
>> As an alternative: it's possible to extend the Android telephony
>> HAL to allow the baseband to return a delegated prefix as well as
>> the directly-connected route. That way, if a modem vendor (e.g.,
>> Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent
>> code (which is not part of the Android OS), it can simply pass up
>> the prefix through the HAL and the OS can use it.
>> 
>> As we know, DHCPv6 PD has been mentioned in 3GPP standards for
>> several releases. Are there any 3GPP specs on how prefix delegation
>> should be used? Are there any requirements that might simplify the
>> implementation? For example, a requirement that the delegated
>> prefix may not change for the lifetime of the session, and that its
>> lifetime is infinite, would be consistent with the 3GPP
>> requirements around RAs, and would substantially simplify
>> implementation.
>> 
>> On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra <hayabusagsm@gmail.com>
>> wrote:
>>> 
>>> 
>>> How do we propose to solve this problem if operators don’t
>>> support PD even though the  3GPP standard has supported PD for
>>> over 10 years.
>>> 
>>> Another twist to this puzzle is Android has 90% of the mobile
>>> handset marketplace worldwide and adamantly states they will NOT
>>> support DHCPv6 or PD.
>>> 
>>> I researched Apple which has 10% of the market and they also do
>>> not support PD.
>>> 
>>> Whats the solution now? --
>>> 
>>> 
>>> Gyan Mishra
>>> 
>>> Network Solutions Architect
>>> 
>>> M 301 502-1347 13101 Columbia Pike Silver Spring, MD
>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> --------------------------------------------------------------------
>>
>> 
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------