Hi Erik, Comments below bracketed by <RCC></RCC>
Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 31/08/2010 2:04 AM, Erik Nordmark wrote:
<RCC>NS and NA behave very differently for 6lowpan ND than RFC 4861 ND with regard to address registration. I never really understood the necessity to use NS for address registration; personally I preferred the earlier NR/NC approach. NS/NA doesn't align with what's in RFC 4861 anyway. Whilst there isn't an equivalent of address registration, DAD seems to be the closest function and this uses unspecified address as the source address.</RCC>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.<RCC>Quite the contrary. The way it is written now the SLLAO makes a statement about the registration address (which is also the unproven and possibly duplicate source address) in the NS. In the proposal, the SLLAO would always be consistent with the source address and not refer the ARO registered address at all (if I understand the proposal correctly).</RCC>
<RCC>There is confusion currently amongst multiple vendors trying to do interoperability testing with real products. I thought the IETF way was to a) put out a specification, b) try it and c) change it if it doesn't work. The process for (c) doesn't seem to be happening well for some reason.</RCC>I think this will lead to confusion, and result in corner cases that are hard to handle.
<RCC>I disagree. Strictly speaking you should not be using that 16-bit MAC address at all as a source or destination until you are convinced that it is unique within the PAN. MAC association in 802.15.4 is built around that principle. Perhaps we should be using that mechanism for registration, although that would complicate matters by introducing another management entity function when there seems to be a perfectly acceptable alternative. On the other hand, if it were done using MAC association, in 6lowpan (or indeed any network where the IP address is autoconfigured from its IID (hence MAC address), the need for independent address registration of IP addresses would probably go away.</RCC>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.
<RCC>I am assuming one isn't needed just as one isn't strictly needed for RS/RA, which uses LL64. The LBR should not strictly have to maintain state for the joining node for address registration purposes. The NCE would be created when the successful NA comes back from the authoritative 6LBR.</RCC>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 if1a. 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.<RCC>There shouldn't be one. This would actually be end up being more consistent as it means that NCEs only exist for the registered IPv6/MAC address pair.</RCC>
<RCC>CGAs do not occur in 6lowpan (this is *6lowpan* ND we are talking about here). If you really needed a CGA, you can add the option in for the registered address.</RCC>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.
<RCC>In my opinion, it causes less complexity in that NCEs only exist for addresses which will be used. The LL64 can be considered ephemeral up to the point the registered address is acknowledged to be unique. As for the other uses of NS in 6lowpan from RFC 4861, I think we need to carefully go through them as it is not clear from the current draft exactly when they would be used as 6lowpan ND is written as a kind of 'addendum' to RFC 4861.</RCC>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 simplifyprocessing 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 bytesI 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.
<RCC>Multihop NS/NA will by necessity use IP addresses which have a global/UL prefix. This distiguishes them.</RCC>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 codeThe 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 completeFirst 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.)
<RCC>Another kludge and why it is wrong to overload NS/NA in this way. There are two solutions here:
1) Set ttl properly. This limits the attacker space to the same radius as the 6LBR which in practice means inside the 6lowpan. 2) Create state for the NS/NA. This doesn't have to be a NCE, simply a record of the corresponding NS. This would be a 'belt and braces' approach on top of (1)
</RCC>
<RCC>Maybe it isn't but if complementary functions like this appear, it usually means the approach is the right one. The corollary being that if it becomes awkward to add complementary functions using existing specified mechanisms, the existing mechanisms are probably wrong.</RCC>-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.
<RCC>Similar to my point above - if something is implemented correctly, the desire to do hacks goes away to some extent as the hacks no longer appear efficient.</RCC>-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.
<RCC>Like it or not, 6lowpan, 802.15.4 and the 'schizophrenic' MAC address add complexity. The aim is surely to deal with these in L2/L3 management cleanly and not to violate the rules. L3 management has to consider the properties of L2 addressing (if it is used); the use of LLAOs throughout indicate the need to propagate L2 addresses into L3 managament. Quite simply, the use of a 16-bit MAC address before it has been proven to the best of the network's ability to be unique should be avoided, so deliberately specifying it like is done in nd-12 clearly violates the requirement.</RCC>-Does not need SLLAO in initial NSI 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
