Hi Erik, Samita, I finally read through your draft in detail. First of all, thanks for taking the time to put your thoughts in a well-written draft. Currently I should be updating the 6lowpan-nd draft to -09 before the March 8th cutoff. There are comments from Richard Kelsey and Robert Cragie to take into account. However now with this new draft I will not update 6lowpan-nd yet. I think we need to discuss this on the list and over beer(s) in Anaheim first.
So far I'm not really sure what you (and Geoff?) have in mind with this draft. My first impression is that this is 90% identical to 6lowpan-nd-08, with differences mainly in the approach to explain it and the terminology. OK, this is a good thing as we're not really that far apart. The drafts are the same in these respects: - Use of RFC4861 possible if appropriate (6lowpan-nd has stronger language requiring the optimized approach to ensure interoperability) - Use of the autoconf-addr model - Autoconfiguration is basically the same (optimized model) - The registration model between a node and its default routers is basically the same. - Sequence number used to ensure RA info freshness - Terminology is basically equivalent - The same address resolution optimization is used - neighbor cache = binding table in this practice - Both drafts avoid DAD for EUI-64s or when DHCPv6 is used - Both drafts (optimized version) are incompatible with RFC4861-only IPv6 interfaces (adaptation needed). Now let me summarize where I see the differences between what you are proposing here, and 6lowpan-nd-08: - Your draft suggests the use of either RFC4861 or nd-simple. I see this as a big interop risk. In 6lowpan-nd we made sure on purpose that everyone MUST support the optimized technique. - Your draft tries to do a diff on RFC4861. Which basically means reading all of RFC4861 plus this to figure out how to implement this. We used to do that in 6lowpan-nd but decided to instead make a stand-alone specification at some point for clarity. - nd-simple changes NS/NA messages for the purpose of node-router registration. 6lowpan-nd uses an explicit message NR/NC for the same purpose. - nd-simple requires hosts to perform DHCPv6 themselves, whereas 6lowpan-nd currently suggests that the router does it on their behalf. - nd-simple requires nodes to support redirect messages. 6lowpan-nd optimizes them away. Here are some problems I found in the nd-simple draft: - No Context Information support, needed for HC - Other fine-grained optimizations are needed wrt RFC4861 in addition to these. For example there are buffer memory requirements for all neighbors that need to be removed, too many caches (not all needed) and plenty of variables to be set for 6lowpan use. - nd-simple talks about advertising multiple /64 prefixes into a LoWPAN. This is confusing and (in my opinion) broken. HC will only work when there is a single prefix (CID=0) advertised in the LoWPAN. All other prefixes (Contexts) need to be assigned CID > 0. Furthermore Section 1.3 refers to using multiple prefixes to deal with mobility in the LoWPAN with an autoconf-addr reference. That one really confused me. autoconf-addr does not require this in our case. This also wouldn't work. - Section 7.4 #3 talks about hosts registering to their default routers. All nodes need to do the same, otherwise address resolution, NUD etc. won't work. Or do you assume routers act as hosts when they use a default router? - Redirect messages as described in Section 7.4 won't work in practice with wireless mesh networks. I think it is safer to disable redirect... - Section 7.5 assumes a routing protocol will have global information (some do, but not all). This is basically the equivalent to a whiteboard by the way. Zach On Mar 1, 2010, at 15:16 , Erik Nordmark wrote: > > Samita and I have tried to capture a minimal set of ND optimizations in this > draft. > > Erik > > > -------- Original Message -------- > > A new version of I-D, draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt has > been successfuly submitted by Erik Nordmark and posted to the IETF repository. > > Filename: draft-chakrabarti-6lowpan-ipv6-nd-simple > Revision: 00 > Title: IPv6 LoWPAN Neighbor Discovery and Addressing Choices > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 16 > > Abstract: > IETF 6LoWPAN working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). IEEE 802.15.4 and other low-power wireless > networks have limited or no usage of broadcast or multicast signaling > due to energy conservation. Besides the wireless nodes may not > strictly follow traditional concept of IP subnet and IP-links while > connecting nodes and routers. This document describes simple > optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and > addressing mechanisms that are useful for small scale 6LoWPAN > networks in star and mesh topologies. > > The optimizations include reducing the amount of Neighbor Discovery > multicast traffic and allowing for a single subnet to span multiple > routers in a "route-over" topology. > > > > The IETF Secretariat. > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
