Hi, Some comments below, but then I'm cut off from e-mail until Anaheim. See you there!
On Mar 6, 2010, at 20:05 , Erik Nordmark wrote: >> >> So far I'm not really sure what you (and Geoff?) have in mind with >> this draft. > > I wasn't in Hiroshima but from what I understood there was push back from the > WG about the complexity of the specification. > Hence Samita and I went back and tried to come of with a minimal set of > things that would be needed. Part of the reason for doing that was that some > of the push back seemed to be that RFC 4861 works just fine, which I don't > think is the case for route-over networks where hosts should keep the same IP > address even if the router they use becomes unreachable. Correct, we both agree there. > > 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) > > That might be mostly a choice of language. I think a reasonable intent is > that host support receiving and responding to all what is in RFC 4861. That > includes responding to multicast NS. Such a thing isn't useful when a host is > sleeping 99% of the time (it wouldn't respond while it is asleep) but allows > a host implementation to support both 4861 and 6lowpan behavior without > needing a configuration knob to select between two very different behaviors. It would be a mistake to try to mix RFC4861 and a highly optimized version using a registration model (nd-simple or 6lowpan-nd) on the same link. This is confusing for the implementations and will definitely break. As ND is a link protocol, how about we keep the assumption that all interfaces on the same LoWPAN run the same ND. Now the re-use of code, techniques and tools between RFC4861 and an optimized ND makes sense where possible. But this is a different issue. >> - The registration model between a node and its default routers is basically >> the same. > > I think the registration is quite different in that in one case it is an > acknowledged message and in the other it is not. Got you. This is something that would probably need to be fixed for NS/NA. Not acknowledging this over lossy links could become problematic? What if there is some kind of error regarding the Node-Lifetime Option? In my opinion a registration works better if it is explicitly acknowledged. If doing it with a unicast NS that could be acknowledged with a unicast NA? >> - Sequence number used to ensure RA info freshness > > That isn't the purpose of the sequence number in nd-simple. It is required to > be able to get rid of prefixes as they expire. 6lowpan-nd uses it for that purpose too. >> - The same address resolution optimization is used - neighbor cache = >> binding table in this practice > > I think nd-simple can allow for an L2 address that is not embedded in the > IPv6 address. I don't know if nd-08 can do that. Yes, it can do that too in nd-08. As nodes may have multiple IPv6 addresses (link-local and global at least) the NR is able to hold multiple address options. In order for address-resolution to work the router needs to have entries for all IP addresses of nodes registered. How would this work in nd-simple? The current spec would only allow you to register one address at a time (the IPv6 source address). Do you just keep repeating multiple NSs and NAs? > >> - Both drafts (optimized version) are incompatible with RFC4861-only IPv6 >> interfaces (adaptation needed). > > No, nd-simple isn't incompatible. A host can send a NS with a node lifetime > option to an unmodified RFC 4861 router without any problems. And an > unmodified host will just ignore the authoritative router option in an RA. > Where did you see any incompatibility? Sleeping nodes mixed with non-sleeping nodes will cause plenty of problems for example. At the same time, unmodified routers would not include the authoritative router option, so it wouldn't work for route-over at least. Address resolution will fail for nd-simple hosts for unmodified routers etc. As I suggested above, let's not try to mix multiple flavors of ND in the same LoWPAN. If nothing else it is unnecessarily confusing. > >> 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. > > That statement is opposite to how I see things. In 6lowpan-nd a host must > know up front whether to send a NR or not. > > You can't make all existing IPv6 hosts "MUST support" 6lowpan-nd. You don't need to. You just perform some adaptation in the same place you do 6lowpan-IPv6 adaptation under an unmodified IPv6 stack (usually in the interface driver or wireless interface). Of course that adaptation should be minimized. There is a section about that in 6lowpan-nd. > > Perhaps the different view is based on an implicit assumption that 6lowpan > nodes will always be completely separate from regular IPv6 nodes. > > I suspect we'll see implementations that need to operate in both a 6lowpan > environment and in a regular IPv6 environment. That will definitely be the > case for routers from day one, but I wouldn't be surprised if there are > benefits for host implementations to be able to live in both environments. Sure, and the 6lowpan interface on an IPv6 router can deal with this. It should be totally transparent to the IPv6 stack of the router of course. This is how we do it today. > >> - 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. > > Yes, and I view that as a feature because I don't think 6lowpan is a > different universe. It is merely a different L2. As ND is a link protocol, I don't see a problem with different links running slightly different ND specifications. See above. > >> - nd-simple requires hosts to perform DHCPv6 themselves, whereas 6lowpan-nd >> currently suggests that the router does it on their behalf. > > I had missed that the routers should do DHCPv6 on behalf of the hosts. > > How does that handle the case when a router dies or becomes unreachable, yet > the DHCPv6 lease needs to be renewed? Wouldn't all the routers in the 6lowpan > need to share information about all the leases so that routerM has all the > state needed to be able to carry on with a lease that routerN originally > acquired? Good point, probably the lease info would have to be returned to the host. This is just one option, the host is of course allowed do DHCPv6 itself as well. > >> - nd-simple requires nodes to support redirect messages. 6lowpan-nd >> optimizes them away. > > I wouldn't expect redirects to be used in 6lowpans. The draft outlines the > constraints on sending them (necessary to handle the hidden terminal problem.) Then I would just disable them. >> - 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. > > The IPv6 architecture requires that multiple prefixes can be supported. Even > if we think that all 6lowpans for the next 10 years will be deployed with a > single prefix that must never change, it would be short-sighted to design the > protocol so that multiple prefixes can't possibly be supported. > > And I thought that HC could handle more than one prefix, but perhaps this has > changed since last time I looked. Here we have to be careful. You may have only one valid default prefix in a LoWPAN (CID=0), otherwise you would have no clue what the compressed prefix means. You may have up to 15 more prefixes (even up to /128) in addition to this, but those must be marked with CID > 0 and are used for compressing addresses, not for autoconfiguration. You may have multiple logical LoWPANs (each with its own default prefix) overlapping, so in that way it fulfills the IPv6 architecture requirement. However a LoWPAN router must only advertise the RA information originating from one edge router (you hint at this in nd-simple). Thus the set of edge routers and lowpan routers advertising the same default prefix (and the hosts attached to them) make up a logical LoWPAN. Hosts can participate in more than one LoWPAN at a time (keeping track of that state) but routers can not. > >> - 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? > > The assumption is that the routers run some routing protocol, and that that > routing protocol means that routers keep track (proactively or reactively) > which neighboring routers they can reach. As a result the routers don't need > to register themselves. You are assuming that a routing protocol replaces ND between LoWPAN routers? I wouldn't do that. Routers still need to perform resolve addresses somehow between themselves. A LoWPAN also needs to bootstrap before starting up its routing protocol. In 6lowpan-nd routers still register with their own default routers, but that can optionally be refreshed using routing traffic. > >> - 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. > > I think one section 7.5 should be rephrased. It says: > A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created > from the routing protocol. > > But this goes into different ways folks might want to use a wired backbone. > One way to use a wired backbone is to run the lowpan routing protocol over > that wired backbone. That doesn't add any new requirements in this area. > Another way is to terminate the lowpan routing protocol at the edge of the > wired network and use some other routing protocol across the wire. In the > latter case there is an assumption that the 6LBR can determine all the hosts > IP addresses. Perhaps some lowpan routing protocols can provide that and > others can not. > But this is far from the central issue in how to do ND on 6lowpans. Yep. This is why we agreed to now specify a base ND protocol, and this kind of Extended LoWPAN behavior will be discussed in a different draft. Zach > > Erik -- 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
