Subject: [6lowpan] 6lowpan-nd: Returning Address Registration Errors

From: Luis Carlos Maqueda Ara <[email-masked]>
Date: Sat, 15 Jan 2011 10:34:05 +0000

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

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 15 Jan 2011 11:41:43 -0000

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-masked] [mailto:[email-masked]] 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:

 
   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 [
<http://tools.ietf.org/html/rfc4944> 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:

H is initializing one of its interfaces and thus behaves as described in
I.D.ietf-6lowpan-nd:

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

---

From: Luis Carlos Maqueda Ara <[email-masked]>
Date: Sat, 15 Jan 2011 12:40:00 +0000

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-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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,

Section 6.5.2 says:

Best regards,

Luis Maqueda

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 17 Jan 2011 11:55:18 -0800

Hi Luis,

On Sat, Jan 15, 2011 at 4:40 AM, Luis Carlos Maqueda Ara <[email-masked]> 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

> prevents another node on the network from sending you a “this address is
> duplicate” message at any time.
>
> Regards,
>
>   -Colin
>
>    derived from the EUI-64 field of the ARO as per [RFC4944].  In
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>