Thank you for this clarification. Is there any reference to this in I.D.ietf-6lowpan-nd? Otherwise, in my opinion, it may be an interesting thing to include on this draft.
Regards, Luis Maqueda On Jan 15, 2011, at 12:41 PM, Colin O'Flynn wrote: Hello Luis, Registration only occurs for a single address at a time, and the registering node needs to keep that state. IIRC part of the logic of this is that it prevents another node on the network from sending you a “this address is duplicate” message at any time. Regards, -Colin From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Luis Carlos Maqueda Ara Sent: January 15, 2011 10:34 AM To: 6lowpan 6lowpan Subject: [6lowpan] 6lowpan-nd: Returning Address Registration Errors Hi, I have a question related to I.D.ietf-6lowpan-nd, regarding registration errors. Section 6.5.2 says: 6.5.2. Returning Address Registration Errors Address registration errors are not sent back to the source address of the NS due to a possible risk of L2 address collision. Instead the NA is sent to the link-local IPv6 address with the IID part derived from the EUI-64 field of the ARO as per [RFC4944<http://tools.ietf.org/html/rfc4944>]. In particular, this means that the universal/local bit needs to be inverted. The NA is formatted with a copy of the ARO from the NS, but with the Status field set to indicate the appropriate error. This, together with what is said in section 5.5.3, makes me doubt about the following: If a host tries to register a duplicate address with a router, the router will respond a NA containing an ARO option with status = 1. As this NA will be sent to the link-local (EUI-64 based) address, how does the host know which address in particular is a duplicate? As far as I understand, there is not enough information in the NA to determine this. I understand that the host may have some way to store information about registrations that are in progress, but this may be tricky in a scenario like this: There are 2 6LRs (6LR1 and 6LR2) and 1 host (H). H is initializing one of its interfaces and thus behaves as described in I.D.ietf-6lowpan-nd: 1 - H sends a multicast RS to the all-reouters multicast address 2 - 6LR1 and 6LR2 are within the radio range of H and thus respond a RA (RA1 and RA2 respectively), each of them announcing a different prefix (P1 and P2). 3 - H receives first RA1, and configures a global address G1.In order to register this new address G1, H sends a NS with an ARO option to both 6LR1 and 6LR2 (the source address of this NAs is G1). 4 - Just after, H receives RA2 and configures a second global address G2. Unfortunately, G2 is a duplicate but, as H does not know it yet, it tries to register it again with 6LR1 and 6LR2 by sending a NS with an ARO option to each of them (the source address of this NAs is G1). 5 - 6LR2 receives the second NA before than the first one and detects that G2 is a duplicate address. Thus, it responds a NA containing an ARO option with status = 1 (this NA is sent to the link-local address of H). 6 - H receives the NA sent from 6LR2. H knows that one of the addresses it has tried to register with 6LR2 is a duplicate, but it has no information about which address in particular (G1 or G2) is the duplicate one. Best regards, Luis Maqueda
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
