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

"Templin (US), Fred L" <> Tue, 24 November 2020 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 004053A121A for <>; Tue, 24 Nov 2020 09:33:38 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kiESfGDt_1nP for <>; Tue, 24 Nov 2020 09:33:37 -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 242F23A1218 for <>; Tue, 24 Nov 2020 09:33:37 -0800 (PST)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AOHXXrR022832; Tue, 24 Nov 2020 12:33:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1606239214; bh=PQrWGedi4MFxY5Lia3sbQceyIvj79Q6otCxPHljRbBk=; h=From:To:Subject:Date:References:In-Reply-To:From; b=duU0N0WzM20Ki2W+noJibYPrUmjVsm7qj3vY2073WUqXF1fO81yAjntxrZ4CGOn6C TYgQht3TACzjhmOc4Ef1sqrOhWVjQTK/XsMysofuvmStfylNweyPxlnqI84axE+h3V 0y190J4DvsdryjJgv17DzznVyYLEwi5J7Fb/uTTLdQ0O59COvcZDs61w8QS5kcsMSU 5ylPWjtTZr5r5ZutYtJgm2LG+HXuTTcLet6UTlEcuThIGVw7riTGRsd6DPvTWqWOPD vv9xxLk9WhzkCelP8RORNoaM5AbFVArVwbdycKIGgNBgSeWB1D+ARboeYoPQEPjlYV wjSO1rNyweOoA==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AOHXQIj022664 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 24 Nov 2020 12:33:27 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 24 Nov 2020 09:33:25 -0800
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 24 Nov 2020 09:33:25 -0800
From: "Templin (US), Fred L" <>
To: Philip Homburg <>, "" <>
Subject: RE: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Topic: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Date: Tue, 24 Nov 2020 17:33:25 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 1593460201B6109C39F93B3AE5CCAE5CA91A47FC38AE32453EFADD96B2AC155C2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:33:39 -0000

Philip, obviously I do not agree to your position and ask that you have a further
consideration of the "LLA Type" draft. IPv6 interfaces may assign multiple IPv6
addresses, and even multiple IPv6 link-local address which may be created by
multiple means (e.g., RFC4941(bis), RFC7217, RFC3972, admin config, OMNI etc.).
By placing a "Type" code in bits 56-63 of the LLA the different types can be
differentiated without there being a chance for mutual interference or collisions
that might require DAD. Then, by also including a Prefix Length value in bits
48-55 of the LLA we can have a PD exchange without having to include any
form of PIO* in the RS/RA message, which saves some bits over low-end links.
Finally, when the mobile node gets its prefix delegation its LLA encodes the
prefix so that PD and IPv6 ND are inherently linked instead of having to map
the PD to some other form of LLA through a lookup table.

Please have a run through the draft(s); I think you will begin to see the value.


> -----Original Message-----
> From: [] On Behalf Of Philip Homburg
> Sent: Tuesday, November 24, 2020 9:12 AM
> To:
> Cc: Templin (US), Fred L <>
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 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.