Re: Reducing the battery impact of ND

On 1/30/14 3:12 AM, Warren Kumari wrote:
> ... and can someone please remind me what exactly was wrong with ARP? 
> Other than the fact that v4 uses it?!

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

>
> W
>
>
>> does that sound fair?
>>
>> cheers,
>> Ole
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>