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

Mikael Abrahamsson <> Tue, 24 November 2020 13:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAEA13A0CBC; Tue, 24 Nov 2020 05:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.219
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PHS9GRlhpOXn; Tue, 24 Nov 2020 05:18:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4530A3A0CBA; Tue, 24 Nov 2020 05:18:16 -0800 (PST)
Received: by (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;; 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 []) by (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 <>
cc: Erik Kline <>, "" <>, IPv6 Operations <>, 6MAN <>, Lorenzo Colitti <>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
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: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 13:18:20 -0000

On Tue, 24 Nov 2020, 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:

Mikael Abrahamsson    email: