RE: IPv6 "bloat" history

["Pascal Thubert \(pthubert\) via NANOG" <nanog () nanog org>]

> Pascal Thubert (pthubert) wrote:
>
> > You're perfectly correct. This is exactly what the registration would
> > be for. I'm concerned about its adoption that I do not see coming on
> > Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot
> > worse*.
>
> You can't expect people still working primarily on v6 have much sense of
> engineering.

That includes me

> > * APs today snoop DHCP; DHCP is observable and stateful, with a
> > lifetime that allows to clean up. So snooping it is mostly good enough
> > there. The hassle is the SL in SLAAC which causes broadcasts and is
> > not deterministically observable; this problem is specific to IPv6. We
> > already have the registration to avoid snooping DHCP and SLAAC; yet we
> > do not observe any adoption in mainline APs and STAs.
>
> As broadcast/multicast packets are first sent to APs as unicast packets with
> ACKs, snooping by APs should be reliable at L2.

Well, up to the N retries. After that the stack is not even aware that the multicast was not delivered. 

Oh but that's just the beginning of the story; yes we mostly can form an initial state and it mostly appears to work 
and people are mostly satisfied. 
And then you realize:

- there's no way to know how long the device will you that address
- there's no way to know how many addresses the device will form
- there's no way to know how many addresses the device has already formed and which (at least MLD can do that)
- there's no clean way to know is an address is still in use (e.g., without reviving it in the host stack)
- there's no way to know which is the most recent location of the address (unless you have a fine time distribution and 
that costs)
- there's no way to know if 2 locations are OK (anycast)
- there's no way to know for sure that the claimer is the owner

Snooping DHCP you expect:
- one address per MAC (that's it's pretty limiting but that protects the network)
- A MAC address or least a unique ID to differentiate duplicates (but not recognize a thief)
- An upper bound for the state lifetime based on the lease

Certainly a bad guy doing impersonation and DOS can play havoc in such network, but at least between good guys we get 
something we can operate.

I'm not saying that snooping DHCP is fully deterministic but it's orders of magnitude better than snooping SLAAC when 
it comes to forming a state like an association than SLAAC. Knowing that you base things like EVPN on such state, using 
SLAAC is building on sand.

Ideally you'd want:
- a negotiated contract for a number of addresses with a lifetime, etc
- a provable ownership so we route to the legitimate owner and can do SAVI
- a sense of mobility so we can route the packets to the latest location
- a sense of anycast vs unicast so we can install routing properly based on that
- the capability to indicate whether the address should be redistributed, a sense of weight in ECMP, etc...

We've done just that, and with that, we're effectively providing a deterministic state that we can redistribute in 
routing or ARP/ND proxy.

In the case of EVPN that gives this:
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling

Then again, retrofitting the ND registration for IPv4 addresses is piece of cake, but IPv4 is DHCP only and the pain 
does not really feel; so people may not be inclined to make the steps for IPv4. To be seen.

> So, by snooping DAD, which is ugly, ARP table can be constructed.

A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, start populating the hot-line before you 
turn the lights on 😊

> A problem, however, is that there is no ACK above L2, that is, there is no
> end to end ACK, which means, if something goes wrong above L2, the result can
> be weird.

Yes, and all the other things above. E.g., a DAD coming from the wire that is sent over the wireless is not 
deterministically delivered and a duplicate is often missed. I do not need to continue the endless list do I?

Keep safe;

Pascal

>                                               Masataka Ohta