Summary of comments from adoption call of draft-chakrabarti-nordmark-6man-efficient-nd-04

Samita Chakrabarti <> Thu, 06 February 2014 10:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 365A91A0200 for <>; Thu, 6 Feb 2014 02:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lc7tUtp5doqr for <>; Thu, 6 Feb 2014 02:05:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6A3F61A00B4 for <>; Thu, 6 Feb 2014 02:05:37 -0800 (PST)
X-AuditID: c618062d-b7f858e0000031c7-7b-52f35e6b53e7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id CD.EB.12743.B6E53F25; Thu, 6 Feb 2014 11:05:32 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 05:05:34 -0500
From: Samita Chakrabarti <>
To: "" <>
Subject: Summary of comments from adoption call of draft-chakrabarti-nordmark-6man-efficient-nd-04
Thread-Topic: Summary of comments from adoption call of draft-chakrabarti-nordmark-6man-efficient-nd-04
Thread-Index: Ac8jIawi+/whl9UMT0+WgG8z+vQ/5g==
Date: Thu, 06 Feb 2014 10:05:34 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01C15D78Feusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXSPt25O3OcggydzRSwWdDaxWqxccZfJ gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mo4/qmDpaDtLmPFkqfHGRsY51xn7GLk5JAQ MJGY0/mIHcIWk7hwbz1bFyMXh5DAEUaJXZcPMYEkhASWMUq8uxMOYrMJWEl09O4BaxARUJZo O3oErIZZwFvixeO/bCC2sECKRPe5RlaImkyJe5/usEHYehJvPxxi7mLk4GARUJH49LQMJMwr 4CvxbPdvsBJGoBu+n1oDNVJc4taT+UwQtwlILNlznhnCFpV4+fgfK4StJDFp6TlWkJHMAvkS P69EQYwUlDg58wnLBEbhWUgmzUKomoWkCiKsKbF+lz5EtaLElO6H7BC2hkTrnLnsyOILGNlX MXKUFqeW5aYbGWxiBEbIMQk23R2Me15aHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANjzAan0243JXS2p28xuRjEYPe1n2vGzzyXD0aLXc0OT/A9pBm9rmLHWks+rhZW caHVz9Q3uitOMDbIXpBl3MZT7cwubrV9xzTJttsy+kG/dpn9jPfbKbF8Q3H/syYVvwVvxK2D OGa/Kc8VMOkQvXxlTpvK98Cs8KAYzV6d2zdVmY4/ee2j+UGJpTgj0VCLuag4EQCN4KLiXgIA AA==
Cc: "6man Chairs (" <>
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: Thu, 06 Feb 2014 10:05:41 -0000

Hello All:

We have  had  lively and interesting discussions on the mailing list on  efficient-nd.

Here is a  summary gathered from various discussion threads:

As of January 15, 2014 on the adoption call, here are some numbers:

1.       Support (10 including co-authors)

2.       No support or no need of such work (3)

3.       Comments and suggestions  for updates (4) [ Eric Vyncke, Andrew Y, Mark ZZZ, Michael Abrahamson]

In general : Better problem statement and simplification/clarification/improvement is needed. There are multiple folks who commented that such work is needed.

Draft-ietf-6man-resilient-rs context:
It in fact has  a different scope that  suggests increasing  the solicited RS in order to configure the hosts reliably. Resilient RS has accomplished its goal within the scope of the problem statement

-          A suggestion was made to increase its scope which really steps into the scope/solution defined in draft-chakrabarti-nordmark-6man-efficient-nd and thus was objected by the co-authors of efficient-nd

-          A suggestion was made that all hosts should send periodic RS as an alternative to periodic RA – that does not work and several concerns were raised on taxing hosts with battery power

ND and battery power issue: [ aka need for such work?]

1)      Spontaneous all-hosts multicasts interfere with these mechanisms, thus the battery drain on the devices is much higher - especially in a typical network where the mobile devices move, and might trigger an RS/RA on each L2 roam between BSSIDs

2)      ARP in IPv4 had similar issues with broadcast, ND tried to solve that with directed multicast that depends on L2 technologies and works on fixed Ethernet. But both ARP broadcasts and ND multicasts are treated equally in many wireless environments where L2-drivers don’t support multicast resulting in huge signaling in the network and wasting battery power of the hosts[ mobile devices, internet of Things, wireless switches etc. ]

3)      Many wireless switches and wifi-controllers and AP mitigate the ND and ARP related flooding [ not all switches, AP implement MLD snooping] by providing proprietary solutions which result in vendor specific non-interoperable IPv6 solutions in the network else it prevents deployment of successful IPv6.

Summary of technical changes requested by the reviewers of efficient-nd:
Clarify problem statement with more justification of the issues with multicast and why registration is needed
 Clarify whether this draft will support draft-gont-6man-deprecate-eui64-based-addresses-00
 Draft refers to EUI-64 based IPv6-addresses and 64bit MAC address – Needs to fix this to state support for 48bit MAC address and non-EUI-64 based IPv6 address
 Clarify bootstrapping and DAD for link-local or not How to inform duplicate address detection during link-local address formation
 Clarify more on co-existence with the legacy model, distribution scheme of the addresses (hierarchical, hash-based, Š), nature of the registrars (Routers? Switches? DHCP servers? Š).
 Consider Mikael’s suggestion on using DHCPv6_IA_NA option to interact with a DHCPv6 server [ EAH interacting with a DHCPv6 server]
 Describe behavior /interaction with VRRP and how do we deal with single point of failure should there be single default router in the link
 Explain whether this draft really is limited to one central point bottleneck or it can handle single point of failure gracefully with multiple default routers
 Remove the use cases