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

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

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Homburg
> Sent: Thursday, November 26, 2020 3:43 AM
> To: [e-mail]
> Cc: Templin (US), Fred L <[e-mail]>
> 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.
> 
> 
> > > Indeed. Where does it go wrong? Any real world deployment reports where this
> > > is an issue?
> >
> > 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.
> 
> > > 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 stat
> > e
> > > 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.
> 
> 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.
> 
> > > security reasons, if a link uses SEND then all addresses have to be SEND
> > > anyhow.
> >
> > 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.
> 
> > > 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 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.
> 
> > > 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'
> >
> > 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.
> 
> > > 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.
> >
> > 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.
> 
> > > 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.
> >
> > 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.