RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

["Eric Vyncke (evyncke)" <[e-mail]>]

Ole

As you asked for a review... here is belated one... (bear in mind that I still have to read the whole thread... I do need an efficient email processing brain!)

First, centralization and the removal of mcast traffic has already an impact on security, security (and operation probably) people tend to prefer strong centralized architecture vs. decentralized ones because they are easier to control. Of course, the drawback is 'single point of failure'

Sometimes, the ID looks more like a marketing document "optimization will be highly effective" ;-) Also, too many sentences & concepts that are relevant in the past 6lowpan WG. Some acronyms are used (NCE) before being defined (if at all for neighbor cache entry)

Mandatory use of SLAAC and EUI-64. In the contex of privacy (and possible obsolete EUI-64 + stable privacy address), I wonder whether it is still useful to rely on EUI-64. I guess that changing to a stable but private IID would be enough. The text is not really clear whether this EUI-64 is only for LLA or for any global address.

In section 4, I failed to understand the link between ULA & EUI-64.

Section 7.1, it is also unclear for me when talking about a unique address per host, does this include LLA as well? Or ULA (cfr low end CPE) in combination with GUA? Most of the document seems to indicate only EUI-64 while this section seems more open (then I remove previous comments of course). If EUI-64 is 'just' used as a node identifier/unique-ID (and not linked to any IPv6 address) why not simply using DHCP DUID? Or even the layer-2 address (assuming that this one is unique & stable). Then, I strongly suggest removing all reference to EUI-64 and use 'opaque node unique ID'.

There is the mention of 'transaction' but to me it appears as a shoot a packet and hope that it is not lost and that the receiver gets it...

Be sure to mention unauthenticated WiFi DoS against the router table as a node could easily change of MAC address and fill the table. Bringing the whole network down (including intra-link traffic). 

Also, the behavior should be explained when the NEAR receives ARO with different lifetimes, which ones to keep? Suggestion: If the 'index' to the table is no more EUI-64 (which is guessable) but an opaque/random but stable identifier (such as DHCP DUID), then the NEAR could overwrite the existing entries only when NS/ARO has the right identifier/cookie?

11.1 another way to prevent NDP cache exhaustion is simply not doing NS/NA when NEAR receives a packet to an unknown destination.

Who announced mixed mode? Can this be downgraded by sending a fake RA without the E-bit? Hence, being no more efficient? No clue on how to fix it though ;-)

Not clear to me whether CGA is supported... I would guess not, then it should be stated somewhere

15. Again, I am not really a big fan on relying on EUI-64 addresses... see above. Then, DAD is more important. Later in the section, it is talked about 64-bit MAC addresses... which is unusual on legacy W/LAN ;-)

17.2 should really be closer to the section describing mixed-mode operation

19 it makes this I-D really close to 6lowpan and similar use cases while there are benefits of this I-D applicable outside of 6lowpan as explained in appendix A

Final recommendation: remove the use cases and create a problem statement I-D because, again, the problem is wider than NS/NA (too many mcast RS/RA and other protocols such as mDNS).

Hope this helps

-éric




> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Ole Troan
> Sent: mardi 19 novembre 2013 11:46
> To: 6man WG
> Cc: 6man Chairs
> Subject: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-
> nd-04
> 
> All,
> 
> There was moderate support to adopt this draft at the working group
> meeting in Vancouver.
> This is an adoption call to confirm the result of the hum at the meeting.
> 
> Please provide a view with reasons as to whether the WG should adopt this
> or not.
> 
> This message starts a one week 6MAN Working Group call on adopting:
> 
> 	Title           : Wired and Wireless IPv6 Neighbor Discovery
> Optimizations
> 	Author(s)    : S. Chakrabarti, E. Nordmark, P. Thubert, M. Wasserman
> 	Filename    : draft-chakrabarti-nordmark-6man-efficient-nd-04
> 	Pages        : 31
> 	Date          : 2013-10-22
> 
>   http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-
> 04
> 
> The call ends on November 26th, 2013.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan