RE: Reducing the battery impact of ND

"Hemant Singh (shemant)" <> Sun, 02 February 2014 14:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 847621A00E0 for <>; Sun, 2 Feb 2014 06:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.035
X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5lrocqP95hLH for <>; Sun, 2 Feb 2014 06:44:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D9FC21A00E2 for <>; Sun, 2 Feb 2014 06:44:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2630; q=dns/txt; s=iport; t=1391352267; x=1392561867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WwR+aP/UZ0Vs2tKbviY98ltTYSX2FAMGvhdAo/AJiuo=; b=Al9uxTMdHh2s7pNQPsRmI34/+UYys7kQG11zTZ0RUudXZXQi8Ggo8H1c VD2QiGU18RYL79c2NW2esizP2bgzOUsvIe/+NHyJ9lojRCGrYEltjhH23 SznauvB6oUyrafeh6K2Wfc5lIegGe6sPwxVpYEIVwhCQYFtfkRDEe6sBp 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFAEZZ7lKtJXG+/2dsb2JhbABYgww4V71hgQEWdIIlAQEBBCcTPwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIDIdxDalyog8XjiEQJzEHBoMegRQBA6pLgy2BaEI
X-IronPort-AV: E=Sophos;i="4.95,766,1384300800"; d="scan'208";a="301309663"
Received: from ([]) by with ESMTP; 02 Feb 2014 14:44:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s12EiQQ1016633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Feb 2014 14:44:26 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Sun, 2 Feb 2014 08:44:25 -0600
From: "Hemant Singh (shemant)" <>
To: Erik Nordmark <>, Warren Kumari <>, Ole Troan <>
Subject: RE: Reducing the battery impact of ND
Thread-Topic: Reducing the battery impact of ND
Thread-Index: AQHPF8uCi/rGSSFcckK5k2X6Rw6QUJqdO7yAgABDuoCAAA28gIAC6/EAgAGb2IA=
Date: Sun, 02 Feb 2014 14:44:25 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 6man Chairs <>, 6man WG <>, Andrew Yourtchenko <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Feb 2014 14:44:32 -0000


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


-----Original Message-----
From: ipv6 [] 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


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
(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.)