From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Erik Nordmark <nordmark@acm.org>, Warren Kumari <warren@kumari.net>,
 "Ole Troan" <otroan@employees.org>
Subject: RE: Reducing the battery impact of ND
Thread-Topic: Reducing the battery impact of ND
Thread-Index: AQHPF8uCi/rGSSFcckK5k2X6Rw6QUJqdO7yAgABDuoCAAA28gIAC6/EAgAGb2IA=
Date: Sun, 2 Feb 2014 14:44:25 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com>
References: <CAKD1Yr29S=O5L4DfhNoiVieWPkgBJ2veuOu6ig5rwgK4ELz7Xw@mail.gmail.com>
 <52D96663.6060005@sonic.net>
 <CAKD1Yr3pCQ15uFz36MvKG3Q_Vzt27ws0aG1=94377FFaJtWV7g@mail.gmail.com>
 <52DA0ABA.8030903@acm.org>
 <CAKD1Yr1zSfAOv8j9XgB_ph9uaUUNW0yrJhfjJTsSTYHNKYNx9A@mail.gmail.com>
 <52E03BB4.8040309@acm.org>
 <DCA1F00D-0775-4030-A3BF-700F01F98C35@employees.org>
 <52E0423A.5070906@acm.org>
 <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org>
 <52E9EF2D.9050402@acm.org>
 <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org>
 <CAHw9_i+0DKS7pTFmRaajdX0=R9yhY7=6gXs2nV_vEKqEsz=d2Q@mail.gmail.com>
 <52ECA6EE.1080201@acm.org>
In-Reply-To: <52ECA6EE.1080201@acm.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>,
 Andrew Yourtchenko <ayourtch@gmail.com>
Precedence: list

Folks,

We have ended up comparing IPv6 ND and ARP.   A few more issues.  Note ND N=
UD 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 N=
D 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 snif=
f.   High end routers that are forwarding packets at several hundred Gbps w=
ould filter ND control easily,  subscriber edge routers that support DAD Pr=
oxy, or machines that support an ND Proxy would benefit from a new ethertyp=
e for IPv6 ND.  =20

If the community is interested in supporting a new ethertype for IPv6 ND, p=
lease 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:ipv6-bounces@ietf.org] 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 an=
d 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 addre=
sses per interface, and a way to renumber those addresses. The nascent DHCP=
v4 wasn't architected to support multiple addresses.

We had RFC 1256 (ICMP router discovery) as a protocol with very limited dep=
loyment for one of the above pieces.

We wanted a more extensible packet format than ARP and reusing IP/ICMP seem=
ed 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 - bu=
t the more extensible packet format was key.)


For the more general question of battery and multicast/broadcast, folks see=
m to agree that current ND (with address resolution spread across a large n=
umber of multicast addresses) is more scalable than ARP's broadcast. (But o=
n WiFI where broad/multicast is lower bandwidth and less reliable they have=
 the same issue.)

    Erik