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

["Templin (US), Fred L" <[e-mail]>]

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.

Fred

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Homburg
> Sent: Tuesday, November 24, 2020 9:12 AM
> To: [e-mail]
> Cc: Templin (US), Fred L <[e-mail]>
> 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:
> >
> >https://datatracker.ietf.org/doc/draft-templin-6man-lla-type/
> 
> 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.