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

Philip Homburg <> Tue, 24 November 2020 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C20503A0B68 for <>; Tue, 24 Nov 2020 06:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.401
X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qQZCsv9AF5ld for <>; Tue, 24 Nov 2020 06:31:35 -0800 (PST)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F4DB3A0B62 for <>; Tue, 24 Nov 2020 06:31:34 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1khZLr-0000IXC; Tue, 24 Nov 2020 15:31:27 +0100
Message-Id: <>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Tue, 24 Nov 2020 14:37:16 +0100 ." <>
Date: Tue, 24 Nov 2020 15:31:26 +0100
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 14:31:37 -0000

>Neither do any implementation I'm aware do that.
>To be clear. If a link-type has no L2 address / is point to point, then 
>no implementation I've touched does ND address resolution.
>It would be happy to respond to a NUD message.

ND answers two questions, what is the L2 address of an address and is the
remote node alive.

So from my point of view it is obvious to just send an NS, mark the neighbor
cache as incomplete until you get an NA back. Then you know that neighbor
is alive.

Now, I wouldn't mind if other implementations would not send the NS and
just assume that their neighbors are alive.

However I found that most sutff just doesn't reply with an NA at all.

> The current behaviour of 64share does that (and gets the hack label
> for that reason).  What I'm saying is that 64share (and what I
> propose in p2p ethernet) is a lot closer to PD than it is to address
> assignment.  As soon as you stop thinking that a p2p link has a
> shared subnet, that's where you end up.

>From a 'bits on the wire' point of view, there is nothing magic to PD.
It is just a message that says: here is prefix, you can do with it as you
see fit.

The devil is in the details. What if the down stream router then hands out
the prefix using DHCPv6 PD. Do we need to do anything special for homenet?
(I guess doing PD using RA would actually be the 3rd version of PD, because 
homenet also does prefix delegation).

If we want this to work on ethernet, we may have to say something specific,
like 'a route will be installed that points to the (link local) source
address of the RS'. Which I guess implies that an RA with a PDIO can only
be sent in response to an RS (on ethernet). Then, what do we do on p2p links.