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

Erik Kline <ek.ietf@gmail.com> Tue, 24 November 2020 06:33 UTC

Return-Path: <ek.ietf@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 F04413A13AA; Mon, 23 Nov 2020 22:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gWgl_OB3xant; Mon, 23 Nov 2020 22:32:59 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8AC3A1425; Mon, 23 Nov 2020 22:32:43 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id 92so15297139otd.5; Mon, 23 Nov 2020 22:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2yITO8yI6AIOKuy8jabGVQTSrgGHh+8X4z3nfxId7vA=; b=ixlplgZLl1wcYVDGcKd7RTk5+Xfp3M/4yLuam0Ew7ouRtYBtBv0oeBAwYyWDJL+eUj kQz7PFmv5NuTw2LkVS7Ia/k3c1DitLETQQxsHKDVrMzWkQ6MKLA/eOacEXm7HhabsWEF LfzhYl43zrJwqeWiLQW7DOhwSmRwngeFu6WDvmmIULFtoEf+MlJ6xDqHzMPMxWWOLwH5 iQYz3tKDfmoaZ17i4Sa4HvE9nA9ZUmv6aKCHHRaj6IcgwY405jJhQnmQhTx98NcA46xd JKfsxJBCID7dZZzrDczw0jJ7l8Ti7f2ZQE8CgjK6zwIlWbJT1i/LghQvaTDkW8yzRa3g JZ8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2yITO8yI6AIOKuy8jabGVQTSrgGHh+8X4z3nfxId7vA=; b=WWvV/NXasJtyt04fI1NMpI6oBcxOwiVIIkHB2FgJEyFkTqhx4QA6xXEo3omHt0N91h k2Ztp09MlNPCM+4PoSnAC78j+gIoKrepcHHOs5pwT2VPeqnn+iI9Nu0Tbt7NdnAazTMv +sajkUBYNldcoaCwxT9t6+/V7Hc3iw7YPTdqlRs+yGq3YZdGenbQz6OTa2mbnUKZQwoX M6maFtZDyHdxBg+2E12HgdnjKjuFG8ZhHwBjVQWQHjpXWufks9QExgSYjBVhESxIP6Gn DiJeb0Xvs/RST6gENfS9YfQvCk8F0snl1oOA7kQXwNalCgZR6Yl0PcA+EtkBX63smpqp M/mA==
X-Gm-Message-State: AOAM531N6TnWHGe4LTMwPYjcyDtNFXg8iBhG+Sn5QXpF+vIcPCgxIhtz P5397MMrIYKc2qQYCm7YRXgCvctCAXLKTXCRMh8=
X-Google-Smtp-Source: ABdhPJzicmn/Lb54avaF6Bku4JP/bmYJTHo8IownCdnvKIRFGbpdRKdk2GAbs1DfFbBWIEHGUopjuko6IFfzx/5+bSk=
X-Received: by 2002:a05:6830:1e08:: with SMTP id s8mr2395441otr.144.1606199563235; Mon, 23 Nov 2020 22:32:43 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV2-dH81CY4wSisV8BU-7H9m5a1xYMqTMecRxhNqZe=ApQ@mail.gmail.com> <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Mon, 23 Nov 2020 22:32:32 -0800
Message-ID: <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Cameron Byrne <cb.list6@gmail.com>, Alexandre Petrescu <alexandre.petrescu@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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TesUbTHImsDdX8XAKfFlphgQjtw>
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 06:33:01 -0000

<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),

    [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).

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.

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
> --------------------------------------------------------------------