Hi Erik, Thanks for looking through my proposal & commenting. I think a lot of the problems come from my original e-mail/proposal not being clear enough, or mixing possible implementation-specific optimizations with what the general case I saw was. Let me try to clarify some of those:
>. Currently NS and NA make a statement about the source address when they include > a SLLAO. But with your approach it is sometimes a statement about the source > address, and sometimes a statement about the ARO registered address. Not sure I understand that one. If the SLLAO is included, the LLAO has the address associated with the IPv6 source address is all I assume. The ARO registered address is ALWAYS the address which you wish the 6lowpan-ND action on (register, re-register, etc). >1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the >registered address is a GP16. In that case what should happen if > 1a. There is no NCE for the LL64? (Should one be created?) 6lowpan-nd-12 already has this if I'm reading your e-mail correctly. Section 5.2 Interface Initialization says that: A link-local address is formed based on the EUI-64 assigned to the interface, and then the host sends Router Solicitation messages as described in [RFC4861] Section 6.3.7. Hence the router may have already created a NC entry if it is using standard ND. In my suggestion it's up to implementers HOW the deal with routing the NA response back. They may use a normal NC, they may use a special NC that only stores entries from NS, or they may fake it out by sending to the EUI-64 of the ARO if their specific network design allows such faking. >1b. There is an NCE for the LL64, but the stored mac address is >different than what is in the SLLAO. (Should it be updated?) My understanding is standard ND processing would deal with this. When the NS (or anything else) was sent from the LL64, the SLLAO would always point to the correct mac address to use. Which will for efficiency reasons always be the EUI-64 in 6LoWPAN networks. > 2. Apply ARO to CGA addresses and Secure Neighbor Discovery. Not sure on this one. I've never implemented SeND so don't know about resource requirements, is it something which could be implemented on the type of nodes we are looking to run 6lowpan-ND on? But I don't have a good response to that concern, AFAIK my proposal isn't cleanly compatible with SeND. > . In addition this causes more complexity in the implementation since an > implementation still has to handle NS and NA messages that do not contain an ARO Huh? How is this different from 6lowpan-ND currently? In fact I thought it even easier, as the processing only needs to check the EUI-64, and generally keeps processing of messages more streamlined. These observations are at least based on how I've implemented 6lowpan-ND. Perhaps I'm missing very obvious optimizations in ND-12, but from my perspective of someone who has written a 6lowpan-ND implementation, the proposed changes would be considerably easier. > The ARO length is already overloaded to distinguish between multi-hop >DAD messages My proposal moves to distinguishing based on the src/dest IP addresses. Multi-hop uses global IP addresses, everything else uses link-local. > First of all, wouldn't you need the SRAM once the DAD has completed? It was more that you could get away without a NC at all in the intermediate 6LR. Again this isn't required in the general case, but if using for example RPL on top you could get away without a NC on the 6LRs. > Second of all, I think the notion of a temporary NCE is needed to avoid > security issues Hmm good point. That would require changes to my proposal, either: -Include the temporary NCE again -On receiving a NA, check if the IPv6 address you will send to based on the EUI-64 is already in your NC. It should be in the NC as you received a NS from it. This basically uses the LL64 as the temporary NCE. -Include something like a nonce in the reserved space of the ARO. This is less in line with current 6lowpan-ND so probably not worth the hassle. > How > does it relate to the overall goal of making 6lowpan compact, simple, > and sufficient to handle 6lowpans. It would cleanly allow extensions to 6lowpan-ND that could do the following (if someone later wanted to): * Have the 6LBR tell you a better short address to use instead of the one you picked. If the network is packed, maybe it's better than the guess & check method. * Would let the 6LBR tell a node which is re-registering what his old short address was. I don't mean we will add them to 6lowpan-ND immediately. But these are things I could see being useful, and having the protocol designed such that the EUI-64 and NOT the registered address is used to uniquely identify the NS sender makes sense to me. > Thus for robustness all messages that contain the ARO must be able to > function whether or not the 6LR has an NCE My message probably wasn't clear, as I didn't mean in the general case you can remove the SLLAO. Just that in specific implementations, it would give them the flexibility to remove the SLLAO as they KNOW the same information is carried in e.g. the EUI-64. But I probably shouldn't have mixed implementation-specific optimizations and the general case. > Introducing an "errors-to" field in the ARO (either as a MAC address or >an IP address) solves the problem One of the problems I was looking to solve is with people using "standard" stacks. Such stacks had trouble sending a packet to a destination IPv6 address that was in the neighbor cache, BUT the mac address was something different. Thus it should be an IP address that the "error-to" is. To save space though it would be better if the error-to was just a MAC address & you auto-configure the IPv6 address based on this. Or if the error-to is the LL64. After all the RS should have come from the LL64, so presumably you have an entry in your NC for the LL64 of that node. Regards, -Colin O'Flynn -----Original Message----- From: Erik Nordmark [mailto:[email protected]] Sent: August 31, 2010 2:05 AM To: Colin O'Flynn Cc: 'Westergreen Mads-MWEST2'; [email protected]; 'Dario Tedeschi'; [email protected] Subject: Re: [6lowpan] ND Short Address Collisions On 08/21/10 04:45 AM, Colin O'Flynn wrote: > Hello, > > Would there be support for putting in 6lowpan-ND that you must send from > an address based on the EUI-64 instead of anticipated 16-bit address? I > think it is more consistent with what is already in 6lowpan-ND. Consider > the following: What you are proposing is very different than how RFC 4861 and 6lowpan-nd works for NS and NA. Currently NS and NA make a statement about the source address when they include a SLLAO. But with your approach it is sometimes a statement about the source address, and sometimes a statement about the ARO registered address. I think this will lead to confusion, and result in corner cases that are hard to handle. And in fact you don't need any of that. All you seem to need to handle your concerns is an "errors-to" MAC address, which the host might set to its EUI-64 MAC address. (It could also be an "errors-to" IPv6 address like the LP64.) We can easily add such a field to the ARO. But having some packets, depending on option content, redefine the IPv6 source address field as the "errors-to" field makes no sense to me. Two examples of corner cases to worry about in the short term. 1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the registered address is a GP16. In that case what should happen if 1a. There is no NCE for the LL64? (Should one be created?) 1b. There is an NCE for the LL64, but the stored mac address is different than what is in the SLLAO. (Should it be updated?) Those questions don't arise in 6lowpan-nd-12 because the NS only applies to one address - the one in the IPv6 source field. 2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that case, which addresses should be used for the SeND verification? In 6lowpan-nd-12 the answer is simple since it is always the IPv6 source address. > From the assumptions section of 6lowpan-ND, we have: > > o EUI-64s are globally unique. > > o All nodes in the LLN have an EUI-64 interface identifier in order > > to do address auto-configuration and detect duplicate addresses. > > Thus 6lowpan-ND is already assuming we have a link-local address based > on an EUI-64. Based on those two assumptions you could greatly simplify > processing of NA by performing the following when you receive a NA message: > > [1] Is the EUI-64 my address? If so skip to general processing (not > shown here) > > [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing > more to do. > > [3] Generate an address by performing the address autoconfiguration > > algorithm on the EUI64 in the ARO with the link-local prefix > > [4] Forward the message to the address generated in step 3, > recalculating ICMPv6 checksum > > Such a setup has the following disadvantages: > > -You ALWAYS transmit the registered address in the ARO on first hop, > wasting 16 bytes I listed a few architectural disadvantages above. In addition this causes more complexity in the implementation since an implementation still has to handle NS and NA messages that do not contain an ARO, and the rules for how such messages are processed will be different than when the ARO is in place. > But the following advantages: > > -Cannot have collision of two 802.15.4 ACK's because you are > transmitting to two nodes at once > > -Less FLASH usage, since you have removed temporary NCE, and always use > the same ARO Length which further simplifies code The ARO length is already overloaded to distinguish between multi-hop DAD messages (which are disjoint for all other use of NS and NA) from normal NS/NA. Hence as 6lowpan-nd is currently written hosts can't send ARO with length=4 since those have completely different semantics. That detail could be fixed, but is an example of the confusion in this space. > > -Less SRAM usage, since you never need a neighbor cache entry for > multi-hop DAD to complete First of all, wouldn't you need the SRAM once the DAD has completed? Second of all, I think the notion of a temporary NCE is needed to avoid security issues (preventing an off-link attacker from creating bogus NCEs - there is no ttl check on the multi-hop DAD messages to protect against such attacks.) > -ARO registered address can be changed by ABR. For example if ABR > notices a node is re-registering after that node reboots, the ABR could > change registered address to nodes old address in NA it sends back. Why is this an important problem to solve? How does it relate to the importance of your original issue around short address collisions? How does it relate to the overall goal of making 6lowpan compact, simple, and sufficient to handle 6lowpans. > -Avoids "hacks" when sending last-hop NA. By "hack" I mean that people > may just take registered address out of ARO, and send 802.15.4 message > to lower 16 bits of registered address, since they are only every > registering GP16 addresses in their case. By instead explicitly using > EUI-64 to generate address, you decouple the registered IPv6 address > from the MAC address used during registration. Thus the same code could > in the future be used to register any address, not just GP16 addresses. > It is only the final hop that knows if there should be any correlation > between IPv6 address & 802.15.4 address, not intermediate nodes. I'm sure misguided implementors can still be creative in coming up with things that violate the letter or intent of the specification. > -Does not need SLLAO in initial NS I suspect you are referring to the notion of "first time an address is registered with a particular 6LR" when you say "initial NS". That notion only exists on a the 6LR. In particular, a host can not reliably know whether or not a particular 6LR has a NCE for the host's address. Thus for robustness all messages that contain the ARO must be able to function whether or not the 6LR has an NCE. So while I understand the problem you are trying to solve, the proposed solution looks like it is making things a few orders of magnitude worse than the problem you tried to solve. Introducing an "errors-to" field in the ARO (either as a MAC address or an IP address) solves the problem without adding more confusion, complexity, and ill-defined behaviors. Regards, Erik _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
