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 17:00 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 C78623A1214; Tue, 24 Nov 2020 09:00:50 -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 TXNcnU1JtOWf; Tue, 24 Nov 2020 09:00:49 -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 355B73A120E; Tue, 24 Nov 2020 09:00:49 -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 0AOH0dWq021016; Tue, 24 Nov 2020 18:00:39 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EB2B2209518; Tue, 24 Nov 2020 18:00:38 +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 D3D9F2094FB; Tue, 24 Nov 2020 18:00:38 +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 0AOH0cTc014762; Tue, 24 Nov 2020 18:00:38 +0100
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
To: otroan@employees.org, Erik Kline <ek.ietf@gmail.com>
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>
References: <CABNhwV2-dH81CY4wSisV8BU-7H9m5a1xYMqTMecRxhNqZe=ApQ@mail.gmail.com> <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com> <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com> <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c825a649-42e9-2bb7-fef9-8ab637f9a464@gmail.com>
Date: Tue, 24 Nov 2020 18:00:38 +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: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.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/AGoPG5o14PiSJCQoqaMuFgzqM-A>
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 17:00:51 -0000


Le 24/11/2020 à 13:17, otroan@employees.org a écrit :
[...]
> I come to realise something and I want to hear if others agree.

Since publication I wondered whether P2P Ethernet is an L2TP 'in 
disguise'?  I mean, If I understand correctly, L2TP is used in 
residential networks much how the P2P Ethernet seems to be assumed to 
work on a cellular link: a ptp link whose interfaces are highly like 
Ethernet.

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

I cant express it more succinctly.

The difference between 'assigning a prefix to a link' and 'allocating a
prefix to a Host' depends on the nexthop presence and the kind of iface
in the routing table entry.

In the simplest linuces, three alternate forms of entries in the routing
table are possible:

(1) nexthop '*'        | kind of iface 'Ethernet'
(2) nexthop '*'        | kind of iface 'ptp'
(3) nexthop IP-of-Host | kind of iface 'Ethernet' or 'ptp'
(assume a prefix/plen in each entry)

In the first form, a Gateway 'assigns' that prefix on that link.  The
Host can form an address within that prefix, but packets whose dst is
some address within that prefix might not reach that Host, because other
Host might have it, and because ND would kick in and resolve to that
other Host's IP address; ND is used because there is no nexthop.  This
is the typical Ethernet.  This is called 'connected' route, I think, on
Cisco.

In the second form, a Gateway 'assigns' the prefix to that link, and
also 'delegates' the prefix to the Host.  Packets whose dst is any
address prefixed by that prefix will be transmitted to that Host,
because ND is not used on ptp links, because even if there is no
nexthop, the 'ptp' is exceptional; 'ptp' means no ND because there are
always two neighbors that know each other very well.

In the third form, a Gateway 'delegates' the prefix to the Host but does
not 'assign' it on the link.  The Host cant form an address out of that
prefix on the receiving interface.  That prefix is not assigned to that
link.  But packets addressed to any address prefixed by that prefix are
indeed forwarded to the Host, because ND is not used here because there
is a next-hop.

In summary:
       Assign to link     Delegate to Host
(1)         x
(2)         x                   x
(3)                             x

Alex

> 
> Best regards,
> Ole
>