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

otroan@employees.org Tue, 24 November 2020 12:17 UTC

Return-Path: <otroan@employees.org>
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 1E76C3A09F1; Tue, 24 Nov 2020 04:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 QpvDvMxM_juS; Tue, 24 Nov 2020 04:17:31 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1983A09F0; Tue, 24 Nov 2020 04:17:30 -0800 (PST)
Received: from astfgl.hanazo.no (77.16.72.77.tmi.telenormobil.no [77.16.72.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id AF39A4E11AD8; Tue, 24 Nov 2020 12:17:28 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 33D4C45DD987; Tue, 24 Nov 2020 13:17:25 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: otroan@employees.org
In-Reply-To: <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com>
Date: Tue, 24 Nov 2020 13:17:24 +0100
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org>
References: <CABNhwV2-dH81CY4wSisV8BU-7H9m5a1xYMqTMecRxhNqZe=ApQ@mail.gmail.com> <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com> <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jKFr9wJyOKSwgaUCs1SiLdnknG0>
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 12:17:32 -0000

Hi Erik, et al,

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

I come to realise something and I want to hear if others agree.

The 3GPP model is in may ways very similar to the model I described in P2P Ethernet.
It's not traditional address assignment happening on that link. The upstream router does not have a connected route and glean adjacency (address resolution required) towards the host.

When a RA with a /64 PIO is sent and the mobile terminal does tethering, it's much more like prefix delegation of that /64.

In a traditional RA+PIO with L=1, the router states:
 This prefix is directly connected between us and requires address resolution.
 If A=1 && plen == 64 you can generate an address from this prefix.

In the P2P Ethernet/3GPP case it says:
 This prefix is not used on the link between us.
 The prefix is dedicated to you, and I promise to install a route like:
  ipv6 route <prefix> p2p-interface | interface, NH pointing at you.
 You can if you like configure an address on the interface on the upstream link,
 as the router will forward traffic to anything in that prefix blindly.
 (you aren't strictly doing SLAAC at that point though.)

In the latter case the prefix-length can be <1-128>.

Now, if someone else could more succinctly express that difference...

Best regards,
Ole