Hi Erik,
I have gone through your responses carefully. My conclusion is that the "errors-to" (or just sending to the EUI-64 in the returning ARO) would work but is not as clean as carrying them in the ARO. I would like to work through the messaging in more detail as I think some of the MAC address/IPv6 address combinations and the special case for errored status need to be worked through.
So, if the general consensus ends up being that sending to the EUI-64 in the case of an error is the right way forward, I will accept that but I would still like due consideration given to the alternative approach being put forward by Colin O'Flynn, Mads, Dario and myself.
Other comments inline, bracketed by <RCC3></RCC3> 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 09/09/2010 3:54 AM, Erik Nordmark wrote:
On 08/31/10 02:10 AM, Robert Cragie wrote: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. Considerthe following:What you are proposing is very different than how RFC 4861 and 6lowpan-nd works for NS and NA.<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>If you'd like we can sit down and go over this in person at the next IETF, or talk on the phone before then.We don't currently have an address registration mechanism in an IETF RFC. The closest there is would be the ISO ES-IS protocol, but that is rather chatty (fixed period multicast packets sent by every host).The DAD messages in 4861 are not a good fit either. Not only are they multicast, and any response is multicast, but also there is no "ack" message resulting in unreliable behavior if the medium has unknown reliability. Thus 4861 DAD is fine for checking conflicting 64 bit IIDs on reasonably reliable media, but when the probability of collisions goes up and/or the packet loss probability goes up, then such an approach isn't appropriate.
<RCC3>I agree with what you say</RCC3>
<RCC3>That's the point I am making - the SLLAO pertains to the (to be) *registered* address by virtue of using 16-bit autoconfigured address.</RCC3>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 AROregistered address at all (if I understand the proposal correctly).</RCC>There is no registered address field in the NS message with an ARO sent by a host, thus in that case the SLLAO is about the IPv6 source address of the NS.
And the special NS messages sent from 6LR to 6LBR as part of multihop DAD has an ARO which includes the registered address field, but no SLLAO (section 8.2.3.).I think this will lead to confusion, and result in corner cases that are hard to handle.<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>My understanding of the IETF process is that your item c) is supposed to read "improve the specification" instead of "change the specification" ;-)
<RCC3>I would hope any change is for the better ;-)</RCC3>
<RCC3>None as such as SLLAO is just payload carrying a number at this point.</RCC3>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 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>I think I asked these question earlier, and saw no response.What part of 802.15.4 breaks if we carry a 16-bit MAC address as an SLLAO option in ND before it has been verified to be unique?
What part of 802.15.4 breaks if we use a 16-bit MAC address as a MAC source address before it has been verified to be unique?
<RCC3>Whilst it is difficult to specify in 802.15.4 (because it stops at the MAC layer), short address use is based on allocation by a coordinator (i.e. parent node). The assumption in this case is that the coordinator is sufficiently able to pick an address which at least is not in use with any other neighbors already associated through it. When it comes to more complex topologies, a higher layer management entity needs to be responsible for ensuring uniqueness. So whilst there is no explicit text regarding uniqueness, it is implied through the association procedure.
In practice in the ND case, it may not be an issue. The EUI-64 can be used to distinguish the originator therefore it is possible to distinguish the origin of the NS using a duplicate MAC and IPv6 address. Sending a response - again, the nodes can distinguish based on the EUI-64. But this ends up as one packet potentially "bicast" to two nodes, which will both respond with a MAC ack., according to 802.15.4 rules. These MAC acks. could collide and interfere for a number of reasons (distance, vendor) as they are not sent using CSMA/CA, thus they may not be seen by the transmitter. In the worst (admittedly unlikely but not impossible) case, the relationship between the two nodes could conspire to never produce a valid MAC ack.
So, whilst it may work, it seems to be the wrong basis for a specification. You could, as you suggest, send an errored NA to the EUI-64 (using 16-bit based IPv6 address still; also I am not sure you need an extra field) but that tends to go against most of the rules that have been written so far wrt. autoconfiguration of IPv6 addresses and MAC addresses as far as I can see.
</RCC3>
<RCC3>Not so - if the IPv6 address is 16-bit based and fully elided, then the MAC header will carry a 16-bit short address as defined in 6lowpan-hc.</RCC3>Note that in 6lowpan-nd-12 we only do the first of the two, and I can't possibly see how the MAC layer can break as a result.
<RCC3>I agree there may be potential issues here re. overriding the hoplimit on the NA. However I don't see it much different to validating an already-created NCE from the original NS which is currently needed. I think this is an orthogonal issue.</RCC3>But having some packets, depending on option content, redefine theIPv6 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?)<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>Creating an NCE at that point in time has security issues, since we don't have a hoplimit=255 check on the multihop DAD messages.
<RCC>If we use 64-bit for NS and only create the NCE on valid NA then I cannot see how you could ever get an NCE with a 64-bit based address in. The processing precludes it. I agree the way it is specified in nd-12 also precludes it in a different way.</RCC2>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>In agree that in normal operation there shouldn't be one, but our goal is presumably to create robust protocols that don't fall over and crash just because something unusual happened.
<RCC>I agree, but there will always be bridges which will have to be crossed at some point. Ironically, the development of 6lowpan ND is a perfect example of how the original specification did not end up catering for a network not anticipated or considered (either is OK in my book - we don't all have crystal balls :-) at the time of writing.</RCC2>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>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>Thirty-odd years of experience with IP protocols has taught us that a protocol is often applied outside of the context of the original design.Thus I think our responsibility of designers is to have a slightly longer time perspective than the products that people want to build this year and next, and ensure that the architecture of the protocols allow for future evolution.
<RCC2>I was thinking more from the point of view of a clear demarcation of address use in certain phases.</RCC2>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.<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>I don't think "complexity" and "memory consumption" is the same concept, but ignoring that for the moment.
<RCC2>See my comments above. I can see how the "errors-to" proposal would work. I would like to see a detailed breakdown of the messages and the fields as I feel we will be sending to 64-bit MAC addresses inlining a 16-bit based IPv6 address and I am not sure what will be in the SLLAO (16-bit presumably) and that a special rule will have to exist for sending to EUI-64 when status indicates an error. I think carrying the data in the ARO is a cleaner solution.</RCC2>Can you explain to me how, in the "errors-to" proposal, there will be NCEs for addresses which will not be used. The LP64 addresses will be used for the RS/RA exchange will the 6LRs in both cases.
<RCC>I thought RS/RA was used to obtain prefix information - these are link local. The only time non-link local IPv6 addresses are used in the IPv6 header for both source and destination are for multihop DAD NS/NA. The initial NS will have link-local destination (and we are debating on the source right now) and the final NA will have link-local source (and we are debating on the destination right now).</RCC2>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.<RCC>Multihop NS/NA will by necessity use IP addresses which have a global/UL prefix. This distiguishes them.</RCC>A host also sends NS to the 6LR for its global/UL prefixes, thus this can't possibly be used to distinguish multihop DAD messages from the normal AROs from the hosts.What am I missing?
<RCC2>I agree that an outside attacker could be clever enough to figure out what to bump its ttl field up to. You could put harder rules around ttl usage for the multihop NS/NA although I admit it's not nice. So, yes, I am not sure this is a solution</RCC2>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.)<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.The security issue is with reception of packets sent by remote attackers. I don't think we can assume that the attackers should set a sufficiently small ttl so that there packets do not reach 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>The amount of state you need to record is the same as the minimum amount of state needed for an NCE.
<RCC2>Agreed</RCC2>
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.<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>See my questions about "use" above. Erik
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
