Hi Luis, On Sat, Jan 15, 2011 at 4:40 AM, Luis Carlos Maqueda Ara <[email protected]> wrote: > 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
Section 1.3 Assumptions talk about uniform prefixes across the lowpan. Also sections 10.2 and 10.2.1 ( Host Bootstrapping Example messages) show example of host bootstrapping and an error case. There are other examples as well for clarification in the draft already. -Samita > 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]] 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]. 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 > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
