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

Philip Homburg <> Tue, 24 November 2020 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E79D3A1219 for <>; Tue, 24 Nov 2020 09:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.017
X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Db5q7so02uWc for <>; Tue, 24 Nov 2020 09:12:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72B163A125E for <>; Tue, 24 Nov 2020 09:12:28 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1khbrX-0000J8C; Tue, 24 Nov 2020 18:12:19 +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 16:44:11 +0000 ." <>
Date: Tue, 24 Nov 2020 18:12:15 +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 17:12:39 -0000

In your letter dated Tue, 24 Nov 2020 16:44:11 +0000 you wrote:
>Getting what I said earlier onto this thread, I think we should be discussi=
>ng the
>LLA-based PD scheme specified in:

In my opinion it is a quite broken design to put protocol bits in IPv6
addresses when ND already has an option syntax for these types of extensions.

In addtion, there is realistically no risk of collision in link local address
when the IID is either EUI-64 or pseudo random. EUI-64 should not be used in
new links type so there cannot be a risk of collision between EUI and OMNI.
There is no risk of collision of pseudo random and OMNI. 

Of course, there is the case that a pseudo random number generator could
be broken. But that is smething that should be solved by improving the
implementation, not by putting extra bits in addresses

What we see here is how how creative use of bits starts failing. We had
opague IIDs. Nobody really cares if an IID is EUI-64 or pseudo random.
Those IIDs co-exists well.

Then OMNI comes along and puts protocol bits in link-local addresses. Next step
now we need flags in link-local addresses.

So the obvious thing to do is to kill OMNI. Do not put special bits in IIDs,
and put everything you want to encode in extension headers and payloads.