Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? Tue, 24 November 2020 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 234623A0AD4 for <>; Tue, 24 Nov 2020 04:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CxQcF1cE8YOm for <>; Tue, 24 Nov 2020 04:40:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 587383A0AC7 for <>; Tue, 24 Nov 2020 04:40:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 740C54E11AEC; Tue, 24 Nov 2020 12:40:27 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 97D6245DE79F; Tue, 24 Nov 2020 13:40:22 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
In-Reply-To: <>
Date: Tue, 24 Nov 2020 13:40:21 +0100
Cc: 6man WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Philip Homburg <>
X-Mailer: Apple Mail (2.3654.
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 12:40:33 -0000


>> 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 lin
>> k,
>> as the router will forward traffic to anything in that prefix blindly.
>> (you aren't strictly doing SLAAC at that point though.)
> In my experience, many true point-to-point links (such as ppp, but also
> tunnels) are like this.
> The reason is that in theory you should do neighbor discovery even if a link
> has no L2 addresses. I found that many implementations just don't react
> to an NS or send any themselves.

That is correct for any implementation I have written.

> So all traffic is just sent to the other side of the link. I.e., the route
> could actually point to the link, but you can't really tell the difference.
> In theory you could try to see if the router has an address on the link, but
> I never tried that experiment.

And my point was that this is the desired behaviour in this case.
At least we should explore the consequences of not treating the nodes on each end as having a directly connected shared subnet (apart from fe80::/10) and what that does for address assignment/pd.

Best regards,