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

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 24 November 2020 13:18 UTC

Return-Path: <swmike@swm.pp.se>
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 CAEA13A0CBC; Tue, 24 Nov 2020 05:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.219
X-Spam-Level:
X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 PHS9GRlhpOXn; Tue, 24 Nov 2020 05:18:18 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 4530A3A0CBA; Tue, 24 Nov 2020 05:18:16 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E7920B1; Tue, 24 Nov 2020 14:18:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1606223893; bh=eibu2BeViaZEX/4uLJ6crpMukYhAa2AQv1GXXYnjdC8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QUMnaw5pPTsXgQsUBpKcHu+I41lP+K7VOnz8DmuhaBbWCNVum8zJAgPbaI1vF7OPu myuJIghbCjhA59zfDSgviwmI9NGZ1568NlZbeX+Kt8TIO3DdX6aSyvafMqCrp4kD0h 29uXeF3FOXinNvY44BEuxXBQ1p0xU1bBDHwuzLjQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E2E68B0; Tue, 24 Nov 2020 14:18:13 +0100 (CET)
Date: Tue, 24 Nov 2020 14:18:13 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: otroan@employees.org
cc: Erik Kline <ek.ietf@gmail.com>, "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>, IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
In-Reply-To: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org>
Message-ID: <alpine.DEB.2.20.2011241409250.26384@uplift.swm.pp.se>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9H9NgTbam2lr-jGh_l9wcqzN_0U>
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 13:18:20 -0000

On Tue, 24 Nov 2020, otroan@employees.org wrote:

> The 3GPP model is in may ways very similar to the model I described in P2P Ethernet.

The 3GPP model is almost identical to PPP, HDLC, ATM, IPIP or whatever 
that doesn't have an ethernet header and isn't a broadcast medium.

> 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 don't think it should be inferred by the link type, I think similar to 
PIO-X it should be explicit. For broadcast media we put in some 
constraints, but there it gets more complicated. If we could start 
defining the "hey, I routed the entire PIO to you" somehow for P2P then we 
could continue with that for broadcast medium in a follow-up RFC.

For reference:

https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se