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

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 25 Nov 2020 14:35:53 +0000

Philip,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Wednesday, November 25, 2020 4:08 AM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>
> 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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 25 Nov 2020 17:22:19 +0100

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

Indeed. Where does it go wrong? Any real world deployment reports where this
is an issue?

> 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.

No, because IIDs have no network semantics. Locally a stack knows what the
address type is. And we don't want to go the BSD route of putting local state
in the zero bits of the link-local address.

So why does a stack care how a remote node generated its IIDs? Either a
link is p2p and remote is remote. Of you pass the address to ND. ND also has
to work for GUA. 

So this only goes wrong when ND is assigning a special meaning to bits in the
IID. Of course SEND tried to do this. But SEND didn't go anywhere, and for
security reasons, if a link uses SEND then all addresses have to be SEND
anyhow.

> 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.

Who is 'we'. I certainly don't want create a mess of the IPv6 architecure
because some people only have GPRS.

Beyond that, the point of prefix delegation is to have a network with multiple
subnets. Yes, you can run that over 32 kbps, but if you are that desperate, 
you can afford the RS/RA exchange as well.

> 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.

What is in the short term convenient for implementations tends to be
horrible in the future.

What if IPv6 over ethernet had specified that ND would simply take the
ethernet address out of the EUI-64 IID and use that as detination address?
Then we would have been stuck.

I'm clueless what you are saying about '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'

By definition, the IPv6 next hop of a link-local address is the link-local
address itself. Link-local addresses are not routed. However, there is
basically no traffic with link local addresses on a p2p link.

You also can't derive a link local address from a GUA unless you know the
prefix length of the GUA. So you are creating a completely hacky situation
where a router would have to know the prefix lenghts of all prefixes that
are downstream of a router to be able to compute link local addresses for
those.

Knowing the link-local address doesn't say anything about the outgoing 
interface. So the router has to lookup the GUA in its FIB anyhow.

We are talking about p2p links, so ND is essentially empty. Any packet that
needs to be forwarded just goes to the other end of the link. 

What you are saying make senses on the context of OMNI. But basically you
are arguing that OMNI is not a great idea. Trying to save a few cycles
by putting L2 information in a L3 address is just a bad architecture.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 25 Nov 2020 17:06:12 +0000

> Sent: Wednesday, November 25, 2020 8:22 AM
> To: [email-masked]

Any interface type that configures multiple LLAs based on different specs
(the RFCs mentioned above as well as others and any future RFCs) is
susceptible to autoconfigurtion collisions where an LLA configured
according to spec A collides with an LLA configured according to spec B.

> in the zero bits of the link-local address.

BSD did what they did as a implementation-local hack that leveraged the
coincidence that the LLA bits 10-63 were currently specified as all-0. They
ran the risk that some future spec might define non-0 uses for those bits,
and that is what is being considered here.

> link is p2p and remote is remote. Of you pass the address to ND. ND also has

Some LLA types can be generated without having to do DAD - or at least
while observing optimistic DAD. But, if multiple types of LLAs are assigned
on a link then the DAD-avoidance property goes out the window.  Again,
if there is an LLA Type field, then there is no chance that an LLA formed
from autoconfiguration scheme A could be seen as a duplicated for an
LLA formed from scheme B since the "Type" values would not match.

> IID. Of course SEND tried to do this. But SEND didn't go anywhere, and for

SEND may not have seen an uptake in adoption yet, but with OMNI we see
a case where that may change. The SEND specs have not been moved to
historic category as far as I can tell.

> security reasons, if a link uses SEND then all addresses have to be SEND

Not if there is a Type field to differentiate the LLA types. I can imagine an
interface that wants to assign both SEND/CGAs and RFC4941(bis) LLAs,
for example.

> because some people only have GPRS.

We is anyone with good architectural sense who can see the value in
what is being proposed, and there is value there. And no, this is not
motivated by GPRS; it is motivated by a need to accommodate any link
type that may be low-end in nature. There are many examples of these
in the aviation domain, and I think we will see many in other mobile
internetworking applications (cars, urban air mobility, etc.).

> What is in the short term convenient for implementations tends to be

I am working on getting the code approved for public release. There is
value there today, and not horrible in any conceivable future.

> Then we would have been stuck.

I don't see any way in which this analogy applies to the discussion we
are having.

> having to do a forwarding table lookup'

What I mean is that the LLA can be statelessly derived from the GUA prefix
and vice-versa. So, if an IPv6 packet with GUA 2001:db8:1:2::3 is received on
an interface, and there is a neighbor cache entry on the same interface for
LLA fe80::2001:db8:1:2 then the packet can be forwarded directly to the
neighbor without having to send it to ip6_forward() - so, what I mean is a
fast-path "hairpinning" capability on interface types that support hairpinning.

> are downstream of a router to be able to compute link local addresses for

No, that is not the case. If a downstream router has been delegate the prefix
2001:db8:1::/48, and a packet arrives on the upstream router with address
2001:db8:1:2::1, the upstream router can statelessly derive the LLA
fe80::2001:db8:1:2 and that address would be honored by the downstream
router. In other words, if a /48 is owned by a downstream router, then by
definition all /64s covered by the /48 are also owned by the downstream
router. And, the downstream router would need to accept as its own any
fe80::2001:db8:1:* LLAs that are covered by the /48.

> interface. So the router has to lookup the GUA in its FIB anyhow.

No, not in the case I described above.

> needs to be forwarded just goes to the other end of the link.

Who is "we"? I am talking about all link types, and not just one link type. What
is being proposed is good for all link types.

> by putting L2 information in a L3 address is just a bad architecture.

Beauty is in the eye of the beholder, and I disagree with your assertion.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 Nov 2020 12:42:58 +0100

> Any interface type that configures multiple LLAs based on different
> specs (the RFCs mentioned above as well as others and any future
> RFCs) is susceptible to autoconfigurtion collisions where an LLA
> configured according to spec A collides with an LLA configured
> according to spec B.

You keep saying this but provide no proof. For many years we have been
using EUI-64 IIDs next to pseudo random ones (privacy extensions). This
has caused no problem.

This is a problem that only seems to affect OMNI. No other links have this
issue.

> BSD did what they did as a implementation-local hack that leveraged
> the coincidence that the LLA bits 10-63 were currently specified
> as all-0. They ran the risk that some future spec might define
> non-0 uses for those bits, and that is what is being considered
> here.

I was trying to point out that allocating those bit makes sense only if they
appear on the wire (as opposed to BSD that uses them within their system).

However, those bits only benefit OMNI. No other link type needs to know about
what way an IID was created. It doesn't make sense to make major changes
to the architecture for one obscure link type.

> Some LLA types can be generated without having to do DAD - or at
> least while observing optimistic DAD. But, if multiple types of
> LLAs are assigned on a link then the DAD-avoidance property goes
> out the window.  Again, if there is an LLA Type field, then there
> is no chance that an LLA formed from autoconfiguration scheme A
> could be seen as a duplicated for an LLA formed from scheme B since
> the "Type" values would not match.

Again this only a problem for OMNI. Pseudo random IIDs have essentially no
collisions. EUI-64 can collide within the group (two devices with the same
ethernet MAC), but that cannot be solved by adding flags.

However, a very common cause of a duplicate address is a link in loopback. 
Of course, adding flags doesn't do anything solve this isuee.

In short, you are solving a problem that doesn't currently exist outside OMNI.
No matter how much you want it to exists, it just doesn't.

> SEND may not have seen an uptake in adoption yet, but with OMNI we
> see a case where that may change. The SEND specs have not been
> moved to historic category as far as I can tell.

FTP also has not been moved to historic. That doesn't mean we will see a
lot more FTP servers showing up in the near future.

If OMNI does SEND, then we are still talking about a very obscure link type.
And there is something seriously wrong if you need major architectural 
changes for an obscure link type.

> Not if there is a Type field to differentiate the LLA types. I can
> imagine an interface that wants to assign both SEND/CGAs and
> RFC4941(bis) LLAs, for example.

No, you don't want a mix of secure ND and insecure ND. That's just a
downgrade attack waiting to happen. You would have to add the same flags
to GUA as well. And that for protocols that have hardly any use.

> We is anyone with good architectural sense who can see the value
> in what is being proposed, and there is value there. And no, this
> is not motivated by GPRS; it is motivated by a need to accommodate
> any link type that may be low-end in nature. There are many examples
> of these in the aviation domain, and I think we will see many in
> other mobile internetworking applications (cars, urban air mobility,
> etc.).

We are talking about solving the prefix delegation problem for mobile
connections.

This is not the working group to deal with low-bandwidth links. Making
random changes to optimize a packet exchange that is extremely rare is 
great way to end up with a broken architecture.

> I don't see any way in which this analogy applies to the discussion
> we are having.

It is exactly what OMNI is doing. Putting forwarding information in IIDs.
I.e., you cannot both put prefix information in an IID and use SEND at the
same time.

> What I mean is that the LLA can be statelessly derived from the
> GUA prefix and vice-versa. So, if an IPv6 packet with GUA
> 2001:db8:1:2::3 is received on an interface, and there is a neighbor
> cache entry on the same interface for LLA fe80::2001:db8:1:2 then
> the packet can be forwarded directly to the neighbor without having
> to send it to ip6_forward() - so, what I mean is a fast-path
> "hairpinning" capability on interface types that support hairpinning.

So you have a separate link local address for each /64? So a delegated
/48 would potentially require a router to install 64k link local addresses in
the NC?

You continue to ignore my argument that you need to do a FIB lookup anyhow
to find the outgoing interface. So this idea that you have a GUA without the
next hop link-local address just doesn't happen outside OMNI.

> No, not in the case I described above.

In your example, how does the router know the outgoing interface? 

Or do you do a separate table lookup to map the link local address to an
outgoing interface. In that case you just moved the problem.

> Who is "we"? I am talking about all link types, and not just one
> link type. What is being proposed is good for all link types.

"we", in a thread called 'How do you solve 3GPP issue if neither opera
tor nor handset supports PD?' are trying to solve the mobile problem.

Other link types have deployed DHCPv6 PD a long time ago and don't need fixing.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Nov 2020 13:52:13 +0000

Philip,

This is not just about SEND/CGA, it is about the fact that there are multiple and
diverse ways of configuring LLAs that all could be in used on the same interface
at the same time. There are multiple and growing numbers of ways of crafting
LLAs on any interface type, including:

- RFC4291 (EUI-64)
- RFC7217
- RFC4941(bis)
- manual config
- OMNI

Having a Type field that unambiguously differentiates the multiple LLA config
types that could all be used on the same interface avoids collisions. The mere
existence of the multiple methods of configuring LLAs that could all be used
on the same interface at the same time is proof that having a way of
distinguishing types would be valuable.

Fred

> Sent: Thursday, November 26, 2020 3:43 AM
> To: [email-masked]
> Subject: Re: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Nov 2020 15:53:50 +0100

> Having a Type field that unambiguously differentiates the multiple
> LLA config types that could all be used on the same interface avoids
> collisions. 

You keep talking about collisions and confusion, but there is no evidence
that collision among pseudo random IIDs actually happen. Furthermore, pseudo
randoms IID doesn't collide with EUI-64. We have many years of experience with
this.

Similarly, where IIDs are used as identifers, and not as a hack to obtain
a few protocol bits, there is no confusion when it comes to different ways
of generating IIDs. An address is just something to pass to ND to revolve
to an L2 address (for multi-access links). There is no need to know how 
remote host generates it's IIDs.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Nov 2020 15:03:45 +0000

Having the Type field would allow an administrator to manually configure an
administratively-assigned LLA without risk of colliding with another LLA that was
configured via one of the multiple and growing numbers of LLA autoconfiguration
methods. This is true today, and will become even more true as more and more
LLA autoconfiguration methods are standardized.

Fred 

> Sent: Monday, November 30, 2020 6:54 AM
> To: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Nov 2020 17:03:36 +0100

> Having the Type field
> would allow an administrator to manually configure an
> administratively-assigned LLA without risk of colliding with another
> LLA that was configured via one of the multiple and growing numbers
> of LLA autoconfiguration methods. This is true today, and will
> become even more true as more and more LLA autoconfiguration methods
> are standardized.

Obviously, a manually configured LLA doesn't conflict with EUI-64. We can
assume that an administrator is smart enough to not set the middle two bytes
of the IID to FFFE. So that doesn't happen.

The chance that a manually configured IID collides with a pseudo random is 1 in
2^64. Realistically that doesn't happen.

In practice we also see that nodes with manually configured IIDs have all other
IID mechanisms disabled.

Any future IID mechanism that does not try to use IID bits for other purposes
is pseudo random. So there no risk of collisions.