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

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

Philip,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Homburg
> Sent: Wednesday, November 25, 2020 4:08 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?
> 
> > 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.
> 
> That doesn't make any sense to me. Outside OMNI, this type of interference
> just doesn't exist.

Oh no? On interfaces that want to do both RFC4941(bis) and RFC7217, and
possibly also RFC3972?

> If it does, then please give numbers. How often does adding the flag prevent
> interference or collisions outside OMNI? Did anyone ever spotted interference
> between different types of addresses on ethernet?

It is not a numbers-proof question; it is an enabling function question. All
IPv6 interfaces may assign multiple IPv6 addresses, and even multiple LLAs
which could be of different types. It will provide good future functionality
to be able to ascertain the type by checking a Type field.

> I can see how it is an issue for OMNI, but that just means that OMNI is
> broken.

Wrong.

> > 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.
> 
> Compression for low-bandwidth links should be done in IPv6-over-foo documents,
> not as general changes to the architecture.
> 
> In particular, we are discussing prefix delegation in mobile networks,
> which as not low-end by any sensible definition of low-end.

We will want this to work well over links with data rates as low as 32Kbps.
We will also want to minimize the number of messages on any link types.
This satisfies both requirements.

> > 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.
> 
> This seems to be a bogus argument to me. The router needs to map the GUA
> prefix to an outgoing interface, so you get the link-local next hop for free.
> 
> A transmission function on a point-to-point interface doesn't a next hop
> unless you run NUD on the link, which as far as I know, mobile doesn't.

What you are missing is that this links IPv6 ND to IPv6 forwarding in a way
that is very convenient for implementations. For example, a router can
determine the IPv6 next hop by examining the neighbor's link-local
address without having to do a forwarding table lookup. This has a
corresponding reduction in the amount of code needed in routers.  It
is also possible to deduce the LLA of a neighbor having only a GUA, i.e.,
IPv6 ND can be keyed on a GUA. I have coded this, and there is a
significant savings of code.

Fred