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

[Philip Homburg <[e-mail]>]

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

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

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

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.