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

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Homburg
> Sent: Wednesday, November 25, 2020 8:22 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?
> 
> > > 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?
> 
> 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.

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

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.

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

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.

> 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

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

> > > 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.
> 
> Who is 'we'. I certainly don't want create a mess of the IPv6 architecure
> 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.).

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

I am working on getting the code approved for public release. There is
value there today, and not horrible in any conceivable 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 don't see any way in which this analogy applies to the discussion we
are having.

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

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

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.

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

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

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

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