Re: Reducing the battery impact of ND

+1, Direct from an implementor of the hackery in question in widely distributed switches and wireless controllers.

Our first generation was really about protecting against rogues (SAVI, RA GUARD).

Interestingly, our second generation was focussed on multicast control to protect the wireless medium (ND Suppression including RA throttling and ND proxy) to address customers and product management requests for the wifi market.

Based on that support, I have developped a prototype backbone router that learns southwards from 6LoWPAN ND registration and proxies northwards classical ND.

6TiSCH has planned a plugfest during the IETF and I hope we´ll be able to demo this fonctionality at that time with real ipv6 motes.

Cheers,

Pascal

> Le 1 févr. 2014 à 11:05, "Carsten Bormann" <cabo@tzi.org> a écrit :
> 
> On 01 Feb 2014, at 08:49, Erik Nordmark <nordmark@acm.org> wrote:
> 
>>> ... and can someone please remind me what exactly was wrong with ARP? Other than the fact that v4 uses it?!
> 
> What Erik said, plus maybe this reminder:
> 
> When ARP was invented more than 30 years ago, Ethernet networks were run on the assumption that everyone on them could be trusted, both from a security and from an implementation bugs perspective.
> (Those yellow-cable networks were so fragile... Let’s not digress.)
> 
> To make ARP actually work in less peaceful environments, there is usually significant hackery deployed at layer 2 (in Ethernet switches and WiFi base stations/controllers).  With all that hackery in place, it may *seem* as if ARP works, but it is really the combination of the ARP implementation in the IP nodes and the magic in the switches that makes this so.
> 
> ND inherited most of this situation, except that the hackery wasn’t deployed yet.  That’s why you hear so much about ND being “insecure”, “not deployable” — ND really is much better than ARP, it just had to wait for the hacks to catch up.  The directed multicast of ND (as opposed to ARP’s broadcast) only makes a difference where L2 actually implements that directionality; more hackery.  (The irony is that MLD now becomes an address registration protocol that is needed to make the illusion of "no registration" work at the ND level, but I digress again.)
> 
> So the reality today is that we have this fragile combination of the documented protocols and the switch vendor magic that makes it all work.  Of course, the switch vendors don’t complain; it creates an opportunity for market differentiation.
> 
> Now, for 6LoWPAN, we had to build something that relies much less on multicast.  That became 6LoWPAN-ND, RFC 6775.  Having built this fine hammer, of course other nails sprang to mind.  The above situation looks like a fine nail to me (except that legacy compatibility makes things so much more complex).  That’s maybe the explanation why this discussion didn’t start with documenting the well-known problems, but with looking at one specific solution, and how it could be made to work with legacy.  But I agree documenting the problem would be a worthwhile exercise, if it is not used as an excuse to stop looking for solutions.
> 
> Clearly, efficient-ND will work best if it doesn’t require a new layer of L2 hackery, and if it cooperates reasonable with (or works around) the existing, deployed hackery.  This is more work to make sure given that this hackery is only partially documented.  So that is maybe another reason to work on documenting ARP/ND’s problems and the existing magic.
> 
> Grüße, Carsten
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------