Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Lorenzo

For the record, actually no, that is not my position. Protocol changes do belong in 6man. But as Brian says, we may not need protocol changes. A BCP seems like a fine place to say "here's a good reason not to implement this SHOULD in a router".

<Pascal>

  *   Sorry for placing words in your mouth, that was my understanding of your last sentence. I hope v6ops finds tricks with the current methods that help the situation. Jen’s draft is useful and uncovers one of more than a half dozen of issues that are related to the reactive nature of ND.
  *   And I read that the proposed approach to solve that is to populate the ND cache in advance. Which is what in my book is called proactive, regardless of the method used to get there. The question is whether we do it well or just scratch the surface.
  *   I’d like the draft to include other problems that relate to the same cause. This includes:


  *   PUNTing packets to software for resolution, an archaic operation. Kills the benefits of 802.11ai. Makes IPv6 looks even worse than IPv4 because of more addresses.
  *   Scanning attacks to DoS the router, trying to either fill the ND cache, saturate the CPU, or deny access to legitimate hosts when the router protects itself.
  *   Broadcast inefficiencies, in particular in wireless and distributed L2 domains
  *   Silent host
  *   Need for a global broadcast domain and always on devices (for DAD and AR) = A bad match with pretty much all modern networks including overlays, IOT, vehicular or wireless
  *   ND abuse / SeND too complex

We are now finding that we need to reconsider the reactive behavior of ND AR. Tricking the current model can improve things but only so far.

For the record, I don't agree with this. Changing the reactive behaviour has far-reaching implications and a number of difficult trade-offs with regard to scalability, crash recovery, availability of addresses to network nodes, and so on.


<Pascal>


Ø    Ain’t that FUD? We all have been using Wi-Fi ESS for a long time and the pro-active model has been delivering quite satisfactorily AFAIK. It is actually a lot more scalable than transparent bridging, which is the analogous to AR relie at the MAC-level. It was designed to protect the wireless medium. The EARO model is a plain adaptation of the model at Layer-3. It was doable at L2 for a while, it is probably doable at L3 today. Actually we’ve done it. We have deployed MLSNs on thousands of nodes operating that way.


Cheers,

Pascal