Subject: Re: Reducing the battery impact of ND

From: Carsten Bormann <[email-masked]>
Date: Sat, 1 Feb 2014 11:04:37 +0100

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 1 Feb 2014 11:02:33 +0000

+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" <[email-masked]> a écrit :
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 2 Feb 2014 14:44:25 +0000

Folks,

We have ended up comparing IPv6 ND and ARP.   A few more issues.  Note ND NUD is getting closer to ARP behavior with rfc7048.   Also, ARP was great in one regard by using a different ethertype than the IPv4 ethertype.  IPv6 ND should borrow the same concept and use a different ethertype for IPv6 ND control since IPv6 ND NUD uses unicast messages which are difficult to sniff.   High end routers that are forwarding packets at several hundred Gbps would filter ND control easily,  subscriber edge routers that support DAD Proxy, or machines that support an ND Proxy would benefit from a new ethertype for IPv6 ND.   

If the community is interested in supporting a new ethertype for IPv6 ND, please let me know.  I would expedite an I-D from Cisco who has IPR related to the new ethertype.  See

http://www.google.com/patents/US8102854

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Saturday, February 01, 2014 2:49 AM
To: Warren Kumari; Ole Troan
Cc: 6man Chairs; Erik Nordmark; Andrew Yourtchenko; 6man WG
Subject: Re: Reducing the battery impact of ND

Warren,

Are you asking about the specifics of this topic (how to save on battery and multicast), or a general question on the original motivation for ND?

On the more general question:

ARP didn't have any of
  - NUD (called dead gateway detection back in the days),
  - prefix discovery,
  - router discovery,
  - address allocation (bootp -> dhcp was brand new and unproven at the
time)
(I might be missing something.)
ARP only had the address resolution functionality.

There was a perceived need to be able to handle multiple prefixes and addresses per interface, and a way to renumber those addresses. The nascent DHCPv4 wasn't architected to support multiple addresses.

We had RFC 1256 (ICMP router discovery) as a protocol with very limited deployment for one of the above pieces.

We wanted a more extensible packet format than ARP and reusing IP/ICMP seemed like a good idea since it could enable reusing IP security mechanisms. (Much later when SeND was designed it turned out reusing IPsec was hard - but the more extensible packet format was key.)

For the more general question of battery and multicast/broadcast, folks seem to agree that current ND (with address resolution spread across a large number of multicast addresses) is more scalable than ARP's broadcast. (But on WiFI where broad/multicast is lower bandwidth and less reliable they have the same issue.)

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jan 2014 13:48:13 -0800

On 1/21/14 2:35 PM, Ole Troan wrote:
> Lorenzo,
>
>>      One of your "yes please" below is a change to ND - Andrew's b) about
>>      restarting RS would require a (small) standards update.
>>
>>
>> We should try to get that into draft-6man-resilient-rs.
>>
>> It seems to be out of scope for the problem resilent-rs set out to solve which was loss issues for the initial RS. It might not be wise to expand that drafts scope to also cover (part of) efficient-nd.
>
> the abstract has the following text:
>     "Furthermore, on some links, unsolicited multicast
>     Router Advertisements are never sent and the mechanism in this
>     document is intended to work even in such scenarios."

I think that text can be read in different ways.

One way is within the scope of the  initial configuration (which is what 
the RSs are for) is robust even if there are no unsolicited multicast RAs.

Another way is that the document intended to get rid of the need for 
unsolicited multicast RAs.

Based on the title, name, and content of the document, my conclusion is 
that the first reading is much more accurate.

>> To my mind, sending an RS when the RA lifetime is about to expire is a robustness fix, not an efficiency fix. In a world where IPv6 is optional and IPv4 is the main protocol, just having your IPv6 address expire is not necessarily a problem. But in a world where IPv6 is the main protocol, then hosts will probably want to try harder to keep their IPv6 address around.
>
> I believe you have found a bug in the resilient-rs draft.
> could you reply to the WGLC thread for that document and notify the authors?

It makes sense having the document be clear on its scope, so some 
clarification is in order.

Regards,
    Erik

---

From: Doug Barton <[email-masked]>
Date: Tue, 04 Feb 2014 20:37:34 -0800

On 01/22/2014 01:57 PM, Ole Troan wrote:
| example: a host successfully does router discovery. RA lifetime is
relatively short, e.g. 3 * router advertisement interval.
| host doesn't receive any of the multicast RAs (network drops them or
whatever).
|
| what would be the best behaviour for the end-user?
| a) host sits quietly and waits for a periodic RA
| b) host restarts the initial router discovery

Clearly it's b, or was this a rhetorical question?

Doug

---

From: ek <[email-masked]>
Date: Mon, 17 Feb 2014 19:05:05 +0900

> http://www.google.com/patents/US8102854 
 
I haven't read this, but, IMHO, the potential existence of IPR about using a new ethertype for NUD messages is a wonderful reason to *never ever* do this.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Feb 2014 13:41:19 +0000

Cisco IPR should not block this work.   There are several drafts in the IETF that are underway with IPR from Cisco and other companies. 

Hemant 

-----Original Message-----
From: ek [mailto:[email-masked]] 
Sent: Monday, February 17, 2014 5:05 AM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; Warren Kumari; Ole Troan; 6man Chairs; 6man WG; Andrew Yourtchenko
Subject: RE: Reducing the battery impact of ND

 > If the community is interested in supporting a new ethertype for IPv6 ND, please let me know.  I would expedite an I-D from Cisco who has IPR related to the new ethertype.  See  >  > http://www.google.com/patents/US8102854

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 08:00:15 -0800

> Cisco IPR should not block this work.   There are several drafts in the IETF that are underway with IPR from Cisco and other companies. 

The participants address the question of IPR on per-draft basis.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Feb 2014 11:22:39 -0500

> Cisco IPR should not block this work.   There are several drafts in the IETF that are underway with IPR from Cisco and other companies.

Block? No. Make people concerned / less likely to implement? Yes.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Feb 2014 17:17:30 +0000

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, February 17, 2014 11:23 AM
To: Hemant Singh (shemant)
Cc: ek; Erik Nordmark; Ole Troan; 6man Chairs; 6man WG; Andrew Yourtchenko
Subject: Re: Reducing the battery impact of ND

>Block? No. Make people concerned / less likely to implement? Yes.

Do not disagree with you.  I did outline uses cases for a new ethertype for ND for routers that are forwarding several hundred Gig pps that would benefit filtering ND packets for various needs some of which are filtering ND packets of a scan attack, especially when the attacker is smart to change the source of each subsequent packet the scan sends.  Switches too benefit for the same scan attack.   Other uses are for a machine that implements ND Proxy to sniff all ND mcast and unicast packets.   Granted ND Proxy is an Experimental RFC.

Hemant

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Feb 2014 01:28:47 -0300

> I haven't read this, but, IMHO, the potential existence of IPR about using a new ethertype for NUD messages is a wonderful reason to *never ever* do this.

Can *that* have an IPR???

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492