Re: Reducing the battery impact of ND

[Carsten Bormann <[e-mail]>]

On 01 Feb 2014, at 08:49, Erik Nordmark <[e-mail]> 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