Subject: [6lowpan] #87: GP16 as source address in initial NS

From: "6lowpan issue tracker" <[email-masked]>
Date: Fri, 09 Jul 2010 07:35:40 -0000

#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  major               |   Milestone:     
Component:  nd                  |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------
 From ZigBee IP interop:

 Still some potential issues using GP16 in source address of
 initial NS from joining node to parent router and NA back to
 joining node from parent router on initial multihop-DAD. If parent
 router has the same GP16 as the one randomly chosen by the joining
 node in its routing tables (i.e a valid node already exists more
 than one hop away), it has to make sure this new colliding GP16 is
 properly addressed in preference to attempting to send it through
 the routing mechanism. The parent router itself could also have the
 same duplicate address as the chosen GP16. This would mean you are
 trying to send back to itself.

 Furthermore, multihoming device could be an issue
 – may send on another interface if it’s done through routing.
 RFC2462 also states that tentative address (i.e. not been through
 DAD) is not assigned to the interface, so strictly it can’t be
 used. To comply with 4861, choices are are LL64 or unspecified.

 The authors have discussed this issue more, and think it can be solved
 with better clarification in the draft:

 Using GP16 as the src IPv6 address is not an issue - as specified in
 section 8.2:

   "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
   Cache entry for the address until it receives a successful ARO option
 from the 6LBRs."

 Thus the router would not be confused by the duplicate address until it is
 known that the address is not a duplicate. Perhaps we also need to make it
 clear that the router must not create any routing state for the address
 until it has received the success?

 Section 8.2 also tries to make it clear how the router responds by saying

 "Note that the 6LR does not create a Neighbor Cache entry until it
 receives a successful ARO back from a 6LBR.  Instead it uses the SLLA
 option of the NA from the 6LBR to reach the host."

 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2
 and elsewhere. Basically, an NS with a SLLAO does not modify an existing
 NCE, nor does it create a NCE, until it is known that the address is not a
 duplicate. The multicast DAD in 4861 works differently.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87>
6lowpan <http://tools.ietf.org/6lowpan/>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Jul 2010 15:53:51 +0300

Reading the ZigBee IP report more carefully, I noticed one mistake there. The MAC src and SLLAO of the registration NS are specified as the 16-bit short address in the ZigBee document. This is wrong, it should use its 64-bit IEEE address as the MAC src and the SLLAO as obviously this is known to be unique. The 16-bit address shouldn't be used at L2 yet until it has been confirmed. 

When the NA response comes back to the host, the MAC dst is the 64-bit IEEE address and the IP dst is the address that the host tried to register (same as in the IP src of the NS).

Thus there is no chance of a MAC duplicate there, which I think was the main concern below. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Mon, 12 Jul 2010 20:28:25 -0000

#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:        
     Type:  enhancement         |       Status:  closed
 Priority:  major               |    Milestone:        
Component:  nd                  |      Version:        
 Severity:  -                   |   Resolution:  fixed 
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 - Added text about not making router state until receiving the success.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87#comment:1>
6lowpan <http://tools.ietf.org/6lowpan/>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 13 Jul 2010 00:13:19 +0300

Actually, what I wrote below was incorrect after checking the details again. The draft (also in nd-11) does specify that the SLLA of the NS must correspond to the address being registered. In that case, the 16-bit short address. The clarification in Ticket #87 should still take care of this. Sorry for the confusion. 

Zach

On Jul 12, 2010, at 3:53 PM, Zach Shelby wrote:

> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 13 Jul 2010 12:49:23 -0700

There's still the problem of sending an NA back to yourself, if you are 
a router and happen to have the same address as the one being 
registered. Also, section 8.2 (as indicated in the ticket) does not fix 
the problem of sending and NA to a duplicate GP16 address: Here's an 
example of the problem:

   1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
   2. 6LR sends NS+ARO+address to 6LBR.
   3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache
      entry.
   4. 6LR sends NA+ARO+success to Host[A]. All good so far.
   5. Sometime passes
   6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to
      the same 6LR. This is a duplicate address registration.
   7. 6LR sends NS+ARO+address to 6LBR.
   8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a
      Neighbor Cache entry for this GP16 address (pointing to Host[A]).
   9. This is where it goes wrong: How does the 6LR send the ARO failure
      to Host[B] when the Cache entry is clearly pointing to Host[A]?
      Sure, one could come up with a hack to make this work, but
      wouldn't it be cleaner and simpler to always include the address
      field in the ARO. That way, an ARO is the same for all NS/NA
      messages (single or multi hop), and the unique LL64 can be used in
      the source address of an NS.

Dario

6lowpan issue tracker wrote:
>  Reporter:  zach@...              |       Owner:     
>  -- may send on another interface if it's done through routing.
>  DAD) is not assigned to the interface, so strictly it can't be

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 14 Jul 2010 12:43:49 -0700

Hi Dario,

The assumptions in the steps you provided below are incorrect.

In the given scenario, step 7 will not happen. Checkout section 6.5.1 of
nd-11 .

Also section 8.2 says:

8.2.  Duplicate Address Detection

   The ARO can be used, in addition to registering an address in a 6LR,

   to have the 6LR verify that the address isn't used by some other

   host.  

There  are two levels of check for duplicate MAC addresses in case of
multihop DAD:

1)     At 6LR (neighbor Cache) - when the request comes in

2)     If 1) is fine then send the request 6LBR to make sure that no
duplicates exist in another route-over 6lowpan-link

-Samita

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dario Tedeschi
Sent: Tuesday, July 13, 2010 12:49 PM
To: [email-masked]
Subject: Re: [6lowpan] #87: GP16 as source address in initial NS

There's still the problem of sending an NA back to yourself, if you are a
router and happen to have the same address as the one being registered.
Also, section 8.2 (as indicated in the ticket) does not fix the problem of
sending and NA to a duplicate GP16 address: Here's an example of the
problem:

1.	Host[A] sends NS+ARO (with GP16 source address) to a 6LR
2.	6LR sends NS+ARO+address to 6LBR.
3.	6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache
entry.
4.	6LR sends NA+ARO+success to Host[A]. All good so far.
5.	Sometime passes
6.	Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the
same 6LR. This is a duplicate address registration.
7.	6LR sends NS+ARO+address to 6LBR.
8.	6LBR sends NS+ARO+address+failure to 6LR. There is already a
Neighbor Cache entry for this GP16 address (pointing to Host[A]).
9.	This is where it goes wrong: How does the 6LR send the ARO failure
to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one
could come up with a hack to make this work, but wouldn't it be cleaner and
simpler to always include the address field in the ARO. That way, an ARO is
the same for all NS/NA messages (single or multi hop), and the unique LL64
can be used in the source address of an NS. 

Dario

 Reporter:  zach@.              |       Owner:     

 - may send on another interface if it's done through routing.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Jul 2010 17:52:02 -0700

>    7. 6LR sends NS+ARO+address to 6LBR.

Given that the 6LR has a NCE for the same IPv6 address but a different 
EUI-64, I think the 6LR can directly respond to the host with "duplicate".

Thus I don't think the steps below should happen in this case, but in 
any case ...

>       the source address of an NS.

The 6LR should extract the MAC address of the host from the SLLAO in the 
NA received from the 6LBR. I assume all sane protocol stacks have the 
ability to send an IPv6 packet to a specific MAC address, thus there 
should be no need to create any "temporary NCE" to send a NS to that MAC 
address.

    Erik

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 14 Jul 2010 18:36:58 -0700

Hi Samita

Please see comments below.

Samita Chakrabarti wrote:

Hi
Dario,

The
assumptions in the steps you provided below are incorrect.

In
the given scenario, step 7 will not happen. Checkout section 6.5.1 of
nd-11 .

OK, but removing step 7 still does not solve the problem: How does the
6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for
the GP16 address points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this
seems strange to me: In an implementation, one has to break the
layering so that you can send specific ICMP packets to link-layer
addresses instead of just passing all ICMP packets to the IP layer as
is normally done. Besides that, the concept of sending a DAD failure to
the very address that is in conflict seems completely wrong to me. From
an IP layer perspective, it's like sending the DAD failure to the node
that was the original defender of the address - is that not an odd
thing to do?

Also
section 8.2 says:

8.2.
Duplicate Address Detection

The ARO can be used, in addition to registering
an address in a 6LR,

to have the 6LR verify that the address isn't
used by some other

host.

There  are two
levels of
check for duplicate MAC addresses in case of multihop DAD:

1)
At
6LR (neighbor Cache) – when the request comes in

2)
If
1) is fine then send the request 6LBR to make sure that no duplicates
exist in another
route-over 6lowpan-link

I understand that the ARO is used
in DAD; that's not what I'm questioning. My issue is with having the
GP16 address in the NS and then having to send an NA response to the
same GP16 address.

-Samita

From:
[email-masked]
[mailto:[email-masked]] On Behalf Of Dario Tedeschi

To: [email-masked]

Subject: Re: [6lowpan] #87: GP16 as source address in initial
NS

There's still the problem of sending an NA back
to yourself,
if you are a router and happen to have the same address as the one
being
registered. Also, section 8.2 (as indicated in the ticket) does not fix
the
problem of sending and NA to a duplicate GP16 address: Here's an
example of the
problem:

Host[A] sends NS+ARO (with GP16
source address) to a 6LR

6LR sends NS+ARO+address to 6LBR.

6LBR sends NS+ARO+address+success to
6LR. 6LR adds Neighbor Cache entry.

6LR sends NA+ARO+success to Host[A].
All good so far.

Sometime passes

Host[B] sends NS+ARO (with source as
Host[A]'s GP16 address) to the same 6LR. This is a duplicate address
registration.

6LR sends NS+ARO+address to 6LBR.

6LBR sends NS+ARO+address+failure to
6LR. There is already a Neighbor Cache entry for this GP16 address
(pointing to Host[A]).

This is where it goes wrong: How
does the 6LR send the ARO failure to Host[B] when the Cache entry is
clearly pointing to Host[A]? Sure, one could come up with a hack to
make this work, but wouldn't it be cleaner and simpler to always
include the address field in the ARO. That way, an ARO is the same for
all NS/NA messages (single or multi hop), and the unique LL64 can be
used in the source address of an NS.

Dario

Component:  nd                  |     Version:

Severity:  -                   |    Keywords:

From ZigBee IP interop:

section 8.2:

from the 6LBRs."

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 15 Jul 2010 19:08:38 -0700

Hi Dario,

OK, but removing step 7 still does not solve the problem: How does the 6LR
send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16
address points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this seems
strange to me: In an implementation, one has to break the layering so that
you can send specific ICMP packets to link-layer addresses instead of just
passing all ICMP packets to the IP layer as is normally done. Besides that,
the concept of sending a DAD failure to the very address that is in conflict
seems completely wrong to me. From an IP layer perspective, it's like
sending the DAD failure to the node that was the original defender of the
address - is that not an odd thing to do?

[SC>]  There are few cases where 6lowpan-nd is highly optimized. This is one
of them.

Section 6.5.1 says that,  upon receiving the NS registration request, 6LR
checks its NC for any duplicate, if it is found, then it would respond NA
back with duplicate address error set directly to the node using the MAC
address found from SLLA. 

This check is only in the control path of the packet, so I don't see a
problem with implementation of 6lowpan-nd..

Thanks,

-Samita

Also section 8.2 says:

   host.  

At 6LR (neighbor Cache) - when the request comes in

If 1) is fine then send the request 6LBR to make sure that no duplicates
exist in another route-over 6lowpan-link

I understand that the ARO is used in DAD; that's not what I'm questioning.
My issue is with having the GP16 address in the NS and then having to send
an NA response to the same GP16 address. 

-Samita

Dario

---

From: Robert Cragie <[email-masked]>
Date: Mon, 19 Jul 2010 15:54:18 +0100

Hi Samita,

I'm still confused by this. Earlier, Zach said that in fact we should 
not be using GP16 in the src IP address of the NS. I totally agree. 
However, there is now some talk of setting the SLLA option to be the 
16-bit address of the device attempting address registration. This is 
also surely wrong? We should be carrying the tentative 16-bit address in 
the ARO, not in any other field. Then it only becomes a real address 
(MAC or IP) when it is fully confirmed it is not a duplicate.

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 16/07/2010 3:08 AM, Samita Chakrabarti wrote:
> In the given scenario, step 7 will not happen. Checkout section 6.5.1 
> of nd-11 .
>
>
> 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry 
> for the GP16 address points to Host[A]?
>
> is normally done. Besides that, the concept of sending a DAD failure 
> to the very address that is in conflict seems completely wrong to me. 
> From an IP layer perspective, it's like sending the DAD failure to the 
> node that was the original defender of the address - is that not an 
> odd thing to do?
>
>
> */[SC>]  There are few cases where 6lowpan-nd is highly optimized. 
> This is one of them./*
>
> */ /*
>
> */Section 6.5.1 says that,  upon receiving the NS registration 
> request, 6LR checks its NC for any duplicate, if it is found, then it 
> would respond NA back with duplicate address error set directly to the 
> node using the MAC address found from SLLA. /*
>
> */ /*
>
> */This check is only in the control path of the packet, so I don't see 
> a problem with implementation of 6lowpan-nd../*
>
> */ /*
>
> */Thanks,/*
>
> */-Samita/*
>
> Also section 8.2 says:
>
> At 6LR (neighbor Cache) -- when the request comes in
>
> If 1) is fine then send the request 6LBR to make sure that no 
> I understand that the ARO is used in DAD; that's not what I'm 
> questioning. My issue is with having the GP16 address in the NS and 
> then having to send an NA response to the same GP16 address.
>
>
>
> -Samita
>
> *From:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Dario Tedeschi
> *Sent:* Tuesday, July 13, 2010 12:49 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [6lowpan] #87: GP16 as source address in initial NS
>
> There's still the problem of sending an NA back to yourself, if you 
> are a router and happen to have the same address as the one being 
> registered. Also, section 8.2 (as indicated in the ticket) does not 
> fix the problem of sending and NA to a duplicate GP16 address: Here's 
> an example of the problem:
>
>    3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor
>       Cache entry.
>    9. This is where it goes wrong: How does the 6LR send the ARO
>       failure to Host[B] when the Cache entry is clearly pointing to
>       Host[A]? Sure, one could come up with a hack to make this work,
>       but wouldn't it be cleaner and simpler to always include the
>       address field in the ARO. That way, an ARO is the same for all
>       NS/NA messages (single or multi hop), and the unique LL64 can be

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 19 Jul 2010 12:50:08 -0700

Sorry, steps 7 & 8 in my previous example may have been misleading.
Here's a
more accurate example to try explain why using GP16 in the source
address of an NS is problematic:

Host[A] sends NS+ARO (with GP16 source address) to a 6LR

6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache
entry.

6LR sends NA+ARO+success to Host[A]. All good so far.

Sometime passes

Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to
the same 6LR. This is a duplicate address registration.

6LR
detects a duplicate address, because the EUI in the Neighbor Cache
Entry (NCE) for the address is different to the EUI in the ARO. The NCE
is pointing to Host[A].

How does the 6LR send the NA+ARO+duplicate to Host[B] when the
NCE is clearly pointing to Host[A]?

It has been suggested that the NA must be sent directly to the SLLA,
and that most IPv6 layers allow for explicitly directing a packet to a
given MAC address (even when an NCE for a packet's destination address
is pointing elsewhere). However, a couple of well-known stacks I've had
a look at don't seem to support this without a bit of hacking or tricks
in the network-interface driver.

Dario

Dario Tedeschi wrote:

Host[A] sends NS+ARO (with GP16 source address) to a 6LR

6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor
Cache
entry.

6LR sends NA+ARO+success to Host[A]. All good so far.

Sometime passes

Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to
the same 6LR. This is a duplicate address registration.

6LBR sends NS+ARO+address+failure to 6LR. There is already a
Neighbor Cache entry for this GP16 address (pointing to Host[A]).

This is where it goes wrong: How does the 6LR send the ARO
failure to Host[B] when the Cache entry is clearly pointing to Host[A]?
Sure, one could come up with a hack to make this work, but wouldn't it
be cleaner and simpler to always include the address field in the ARO.
That way, an ARO is the same for all NS/NA messages (single or multi
hop), and the unique LL64 can be used in the source address of an NS.

Dario

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 19 Jul 2010 15:36:24 -0700

Hi Robert

First, let me say that I think the source address of an NS should have
nothing to do with the address being registered. The source address
should be a confirmed unique address assigned to a node's interface
(i.e. the LL64, since 6LoWPAN assumes this to be unique). If that were
the case: I think the idea of using a 16bit SLLA with an LL64 source
address is fine, because it just informing the receiver that another
LLA (other than the EUI-64) is available for the source address. An NS
would then provide the following mappings:

EUI-64 ~ 16bit LLA (assuming ARO is included)

LL64 ~ 16bit LLA

GP Address ~ 16bit LLA (assuming ARO would always contain the
address field)

GP Address ~ EUI-64 (assuming ARO would always contain the
address field)

Of course, these mappings are only stored in the Neighbor Cache once a
registration has succeeded. Mapping [2] need not be stored by an
implementation. In the unlikely event that [2] is needed, it can be
derived from mapping [1].

For a given IP address, a Neighbor Cache lookup could potentially
return two MAC addresses (a 16bit LLA and a EUI-64). An implementation
could select one of them for optimal compression. I'd also go so far as
to say that, if (for some reason) a 16bit LLA was not set for a
Neighbor Cache entry then a lookup could return the EUI-64. The EUI-64
might not always be optimal, but at least a packet could still be sent.

Regards

Dario

Robert Cragie wrote:

Hi Samita,

I'm still confused by this. Earlier, Zach said that in fact we should
not be using GP16 in the src IP address of the NS. I totally agree.
However, there is now some talk of setting the SLLA option to be the
16-bit address of the device attempting address registration. This is
also surely wrong? We should be carrying the tentative 16-bit address
in the ARO, not in any other field. Then it only becomes a real address
(MAC or IP) when it is fully confirmed it is not a duplicate.

Robert

Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 1924 910888

+1 415 513 0064

http://www.gridmerge.com

Hi
Dario,

The

In

OK, but removing step 7 still does not solve the problem: How does the
6LR send
the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16
address
points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this
seems
strange to me: In an implementation, one has to break the layering so
that you
can send specific ICMP packets to link-layer addresses instead of just
passing
all ICMP packets to the IP layer as is normally done. Besides that, the
concept
of sending a DAD failure to the very address that is in conflict seems
completely wrong to me. From an IP layer perspective, it's like sending
the DAD
failure to the node that was the original defender of the address - is
that not
an odd thing to do?

[SC>]
There are few cases where 6lowpan-nd is highly
optimized. This is one of them.

Section
6.5.1 says that,  upon receiving the NS
registration request, 6LR checks its NC for any duplicate, if it is
found, then
it would respond NA back with duplicate address error set directly to
the node
using the MAC address found from SLLA.

This
check is only in the control path of the packet, so I
don’t see a problem with implementation of 6lowpan-nd..

Thanks,

-Samita

Also
section 8.2 says:

8.2.

host.

There  are
two
levels of

At 6LR
(neighbor
Cache) – when the request comes in

If 1) is
fine then
send the request 6LBR to make sure that no duplicates exist in another
route-over 6lowpan-link

I understand that the ARO is used in DAD; that's not what I'm
questioning. My
issue is with having the GP16 address in the NS and then having to send
an NA
response to the same GP16 address.

-Samita

From:
[email-masked]
[mailto:[email-masked]]
On
Behalf Of Dario Tedeschi

To: [email-masked]

Subject: Re: [6lowpan] #87: GP16 as source address in
initial
NS

There's still the problem of sending an NA
back
to yourself,
if you are a router and happen to have the same address as the one
being
registered. Also, section 8.2 (as indicated in the ticket) does not fix
the
problem of sending and NA to a duplicate GP16 address: Here's an
example of the
problem:

6LBR sends NS+ARO+address+success
to
6LR. 6LR adds Neighbor Cache entry.

6LR sends NA+ARO+success to
Host[A].
All good so far.

Sometime passes

Host[B] sends NS+ARO (with source
as
Host[A]'s GP16 address) to the same 6LR. This is a duplicate address
registration.

6LBR sends NS+ARO+address+failure
to
6LR. There is already a Neighbor Cache entry for this GP16 address
(pointing to Host[A]).

Dario

Component:  nd                  |     Version:

Severity:  -                   |    Keywords:

From ZigBee IP interop:

section 8.2:

from the 6LBRs."

---

From: Zach Shelby <[email-masked]>
Date: Sun, 25 Jul 2010 22:59:46 +0200

On Jul 19, 2010, at 4:54 PM, Robert Cragie wrote:

> I'm still confused by this. Earlier, Zach said that in fact we should not be using GP16 in the src IP address of the NS. I totally agree.

Sorry, that was a temporary brain-short (which I corrected). In nd-10 the NS src IP address must be the address being registered, and the SLLAO the LLA corresponding to that address. In the case of ZigBee IP, that would be the GP16 and the 16-bit MAC address. 

The main reason for using the address being registered as the NS src IP address is related to security. We would like to preserve compatibility with SeND for more general applicability of this mechanism in the future. 

I am not totally caught up on the 6lowpan and ZigBee IP mailing lists (just came back from vacation yesterday), but to throw a few possible options out here:

a. Do things as in nd-10 and require more specialized code for this, this was the conclusion the authors came when closing ticket #87. Most 6lowpan implementations are specialized stacks anyways - is this really an issue?

b. Move the address being registered to the ARO and add a flag (breaking SeND compatibility). 

c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when the IP src address is a tentative GP16. This doesn't really solve the resolution problem worrying Dario and Robert though.

I will add a bullet point about this to the ND presentation for the WG meeting tomorrow.

Zach

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 25 Jul 2010 14:37:10 -0700

On 07/19/10 12:50 PM, Dario Tedeschi wrote:
> Here's a more accurate example to try explain why using GP16 in the
> source address of an NS is problematic:
>
>    7. 6LR detects a duplicate address, because the EUI in the Neighbor
>       Cache Entry (NCE) for the address is different to the EUI in the
>       ARO. The NCE is pointing to Host[A].
>    8. How does the 6LR send the NA+ARO+duplicate to Host[B] when the NCE
>       is clearly pointing to Host[A]?
>
>
> It has been suggested that the NA must be sent directly to the SLLA, and
> that most IPv6 layers allow for explicitly directing a packet to a given
> MAC address (even when an NCE for a packet's destination address is
> pointing elsewhere). However, a couple of well-known stacks I've had a
> look at don't seem to support this without a bit of hacking or tricks in
> the network-interface driver.

I don't see any other path forward than getting those IPv6 stacks 
improved to allow for sending to a link-layer address.

Do you have a working alternative approach?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 25 Jul 2010 14:34:00 -0700

> (MAC or IP) when it is fully confirmed it is not a duplicate.

The SLLAO needs to be a link-layer address that can be used to send the 
success/failure of the registration, hence using the possibly duplicate 
16 bit MAC address wouldn't work.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 Jul 2010 02:16:43 -0700

> Do you have a working alternative approach?

The above was answered in the WG meeting, which was to include the 
EUI-64-based (link-local? or global?) in the ARO and use that for a 
response.

If we want to use the EUI-64 based link-local then we could potentially 
hack things and just form that based on the EUI-64 in the ARO (by 
prepending fe80:: to the EUI-64). But it might be cleaner to expand the 
ARO to have an address instead of just the EUI-64.

AFAICT if we keep the IPv6 source in the NS as the one for which we 
register we don't need any special handling for SeND. In essence the 
above idea would add a "send ack/nack to this address".

Comments?
    Erik

---

From: Peter Bigot <[email-masked]>
Date: Mon, 26 Jul 2010 11:17:05 -0500

This thread refers to "GP16" from a Zigbee Interop document, and I infer
it's probably a global-scope IPv6 address derived from a 16-bit 802.15.4
short address, but how the derivation is done is not clear.  The term does
not appear in 6lowpan-nd except in a comment in -11 that refers to this
thread; nor is it in RFC4944 or 6lowpan-hc-08.

If it's a Zigbee concept, could somebody translate it into IETF-speak, or at
least suggest where those of us privileged to access the Zigbee Alliance
docs might find the referenced interop report?

Thanks.

Peter

On Sun, Jul 25, 2010 at 3:59 PM, Zach Shelby <[email-masked]> wrote:

> > I'm still confused by this. Earlier, Zach said that in fact we should not
> be using GP16 in the src IP address of the NS. I totally agree.
>
> Sorry, that was a temporary brain-short (which I corrected). In nd-10 the
> NS src IP address must be the address being registered, and the SLLAO the
> LLA corresponding to that address. In the case of ZigBee IP, that would be
> the GP16 and the 16-bit MAC address.
>
> The main reason for using the address being registered as the NS src IP
> address is related to security. We would like to preserve compatibility with
> SeND for more general applicability of this mechanism in the future.
>
> I am not totally caught up on the 6lowpan and ZigBee IP mailing lists (just
> came back from vacation yesterday), but to throw a few possible options out
> here:
>
> a. Do things as in nd-10 and require more specialized code for this, this
> was the conclusion the authors came when closing ticket #87. Most 6lowpan
> implementations are specialized stacks anyways - is this really an issue?
>
> c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when the
> IP src address is a tentative GP16. This doesn't really solve the resolution
> problem worrying Dario and Robert though.
>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 26 Jul 2010 17:44:41 +0100

Hi Peter,

Your guess is correct - GP is the address autoconfigured with the global
prefix (from the RA) based on the 16-bit MAC address. This autoconfiguration
is specified in RFC4944, section 6. Hc-08 changes that slightly though for
the 16-bit address, see section 3.2.2.

Regards,

  -Colin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peter Bigot
Sent: July 26, 2010 5:17 PM
To: Zach Shelby
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] #87: GP16 as source address in initial NS

Thanks.

Peter

Sorry, that was a temporary brain-short (which I corrected). In nd-10 the NS
src IP address must be the address being registered, and the SLLAO the LLA
corresponding to that address. In the case of ZigBee IP, that would be the
GP16 and the 16-bit MAC address.

b. Move the address being registered to the ARO and add a flag (breaking
SeND compatibility).

I will add a bullet point about this to the ND presentation for the WG
meeting tomorrow.

Zach

6lowpan mailing list
[email-masked]

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 27 Jul 2010 10:09:44 -0700

Hi Erik

Thanks for your comments. Please see my comments below.

Erik Nordmark wrote:

On
07/25/10 02:37 PM, Erik Nordmark wrote:

It has been suggested that the NA must be
sent directly to the SLLA, and

that most IPv6 layers allow for explicitly directing a packet to a
given

look at don't seem to support this without a bit of hacking or tricks
in

It sounds like the source address is now being placed in the ARO. Is
this the case or is the new address (an address requiring
registration/DAD) being placed inside the ARO?

I'm not very familiar with SeND, but having had a quick search for
"source address" and "duplicate" in RFC3971, I came across two
paragraphs for CGA

>From Section 3:

o Duplicate Address Detection (DAD) is used for preventing address
collisions [5]: for instance, during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that no other node is using
the same address. As the rules forbid the use of an address until
it has been found unique, no higher layer traffic is possible
until this procedure has been completed. Thus, preventing attacks
against DAD can help ensure the availability of communications for
the node in question.

>From Section 5.1.1:

Neighbor Solicitation

The address MUST be the Target Address for solicitations sent for
Duplicate Address Detection; otherwise it MUST be the source
address of the message.

It seems the source address can't be an address that has not been
confirmed by DAD. In 6LoWPAN ND, DAD is achieved through the
registration process so I would expect that it should follow the same
rules.

Also important is the section on "CGA Generation" (section 4 in
RFC3972). Particularly the text for step 8.

As for an alternative approach, I was thinking that the ARO would
contain the address being registered and the source address would be
one already confirmed and assigned to the interface. Yes, this means
that the source address would probably be the EUI-64 based link-local
address (at least for the first address registration). I'm no
cryptographic expert, but having read a bit on the CGA process, it does
seem possible that this approach would still work in SeND. The
difference being that for 6LoWPAN, the new address would go in the ARO
instead of the target-address field of the NS. From what I understand
from SeND (correct me if I wrong), the CGA option is there to
authenticate the source address not to authenticate an address going
through the DAD process.

Regards

Dario

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 27 Jul 2010 23:20:15 -0700

On 07/27/10 10:09 AM, Dario Tedeschi wrote:
>>>> and

With my suggestion the "address to which you send errors" would be in 
the ARO. The "registered address" would be in IPv6 source address field.

But I think we have a simpler way to handle the whole issue which is to 
reintroduce the tentative Neighbor Cache entries we had in nd-10.

>>
>> If we want to use the EUI-64 based link-local then we could
>> potentially hack things and just form that based on the EUI-64 in the
>> ARO (by prepending fe80:: to the EUI-64). But it might be cleaner to
>> expand the ARO to have an address instead of just the EUI-64.
>>

We are not using the DAD mechanism in 4861/62 hence the text about DAD 
in 3971 doesn't apply either.

>        collisions [5  <http://tools.ietf.org/html/rfc3971#ref-5>]: for instance, during Address Autoconfiguration.  A
> registration process so I would expect that it should follow the same rules.

Why must we follow the rules associated with the 4861/62 DAD when we are 
not using any of that?

   Erik

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 28 Jul 2010 02:08:12 -0700

Hi Robert,

> > in the ARO, not in any other field. Then it only becomes a real
> > address (MAC or IP) when it is fully confirmed it is not a duplicate.
> 

[SC>]  Sorry, I missed this email earlier.
Have we resolved this question now with the new update in the nd-draft with
tentative NCEs? I am actually a bit confused about using MAC-16 bit address.

At what point is ZigBee planning to start using 16bit-MAC address? At the
start of ND operation?

Thanks,
-Samita

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 28 Jul 2010 13:40:07 -0700

Erik Nordmark wrote:
> But I think we have a simpler way to handle the whole issue which is 
> to reintroduce the tentative Neighbor Cache entries we had in nd-10.
>
>>>
>>        collisions [5  <http://tools.ietf.org/html/rfc3971#ref-5>]: 
>> for instance, during Address Autoconfiguration.  A
> Why must we follow the rules associated with the 4861/62 DAD when we 
> are not using any of that?

My point is that since we are doing some kind of DAD (by having address 
registration), sending a "duplicate" response to the appropriate node 
needs similar technical consideration as in classic DAD. Specifically, 
that sending a "duplicate" response to the duplicate address is 
problematic. I'm sure that's why RFC text like the above even exists and 
part of the reason why the "Target Address" field in an NS exists. The 
designers of classic ND must have experienced or thought of this 
technicality.

Using a trick like "a temporary NCE" in an implementation might work, 
but it comes with its own problems. Wouldn't it just be simpler and 
safer if the requesting NS used a valid source address (one that is 
considered unique in the WPAN).

Dario

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 00:54:32 -0700

On 07/28/10 01:40 PM, Dario Tedeschi wrote:
> problematic.

I don't think so. The approach in 4862 was based on concerns around the 
behavior of token ring and fddi where sending a unicast packet to a MAC 
address, when two stations use the same MAC address, could be 
problematic. We also have the same issue with Ethernet bridges learning 
MAC addresses.
But for 6lowpan we don't have those issues since even if the MAC address 
is duplicate both radios will receive the packet.

Note that the above is all about duplicate *MAC* addresses.
In the case of duplicate *IP* addresses with unique MAC addresses there 
is no issue in sending a unicast response.

> I'm sure that's why RFC text like the above even exists and

FWIW I'm not aware that DAD was ever tested (on Ethernet, fddi, etc) 
using duplicate MAC addresses. To my knowledge the duplicate IP address 
case is part of test suites.

> considered unique in the WPAN).

Are you talking about the source IP address or source MAC address? For 
IP we don't have an issue.

The use of a tentative NCE also has the benefit of removing a security 
issue we have in nd-11 where an off-link attacker can cause NCE to be 
created, which is something that isn't possible in base ND.

    Erik

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 29 Jul 2010 14:18:55 -0700

Perhaps there's been a misunderstanding: I have been implying IP
addresses where others may have been thinking of MAC address. Perhaps I
should have been more specific. I've
been talking about duplicate IP addresses not duplicate MAC addresses.
However, since some IP addresses are derived from MAC addresses, I can
see how one might view the 6LoWPAN registration process as MAC address
registration. I view the registration process as IP address
registration, and it's only coincidental (from a DAD perspective) that
the IID in the IP address matches the MAC address.

So, to reiterate my previous point:

""

... since we are doing some kind of DAD (by having IP address

that sending a "duplicate" response to the duplicate IP address is

problematic.

""

I'd like to come back to the two solutions mentioned in previous emails
on this thread:

The ARO in the NS carries the address to which a NA response is
sent.

The use of a temporary NCE.

If the first solution were used, then I would suggest that we just swap
address fields: The return IP address goes into the IP source field of
the NS and the IP address under registration goes into the ARO.

Having thought about the second solution a bit more and how I would
implement it in the stack we are currently using (BSD), I can not see
how it
would work at all without hacks. Lets say that a valid NCE (NCE1)
exists
for an IP address (A1). If a duplicate is then detected for A1, a
temporary NCE (NCE2) is created. Both NCE1 and NCE2 are keyed on A1.
Now comes time for the NA "duplicate" response. 6LoWPAN ND creates the
NA packet and pushes it down to the IP layer. Next, lets say that the
IP layer does IP to MAC address resolution at this point (BSD does this
in the network-interface driver, but it doesn't really matter
for this example). Since the response is to be sent to A1, how exactly
does the stack resolve the appropriate destination MAC address.
Specifically, how does the NCE-lookup function determine which NCE to
return when both NCEs are keyed on the same address. There's no
discriminatory information that can be used at this point. One might
think that the EUI-64 could be used to discriminate, but that would
mean the EUI-64 of the destination would need to be gleaned from the
ARO in the outgoing packet. One other thing to note is that some stacks
store NCEs in their routing tables and don't allow duplicate keys (i.e.
duplicate destination IP addresses).

Perhaps someone can explain this to me, but I can't understand why we
are placing a tentative address in the IP source address field, when no
other Internet protocol (I know of) does that. The idea that "this is
the 6LoWPAN realm and we can do what we want" is no answer in my
opinion. It is risky thinking that when we are trying to remain
compatible with the wider Internet.

Dario

Erik Nordmark wrote:

On
07/28/10 01:40 PM, Dario Tedeschi wrote:

problematic.

But for 6lowpan we don't have those issues since even if the MAC
address is duplicate both radios will receive the packet.

I'm sure that's why RFC text like the above
even exists and

technicality.

Using a trick like "a temporary NCE" in an
implementation might work,

Erik