Subject: [6lowpan] ND exchange example

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Jul 2010 17:27:22 +0300

I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.4 device bootstrapping for the first time, generating a 16-bit address, and then registering it in an unmanaged network. ZigBee IP is trying to minimize the number of addresses each node has to configure - the goal is to use just LL64 and GP16. LL64 is avoided where possible though as it has 6 bytes of extra overhead per address. 

Below the suggested example uses GP16 for RS/RA and NS/NA exchanges where possible. LL64 is used more for bootstrapping before the GP16 is confirmed. A couple questions come up here:

1. Can we make an exception for using global addresses for RS/RA and NS/NA between the host and router? RFC4861 requires the use of link-local. Using GP16 would save some complexity and overhead. 

2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (see Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the source of the NS and the destination of the NA. This means those addresses can't be compressed by 6lowpan, but then again we save the Registration Address field from ARO... Is any change needed here or can we live with the proposed solution in Ticket #87?

RS from joining device

MAC src: IEEE
IP src: LL64
SLLAO: IEEE
MAC dst: Broadcast
IP dst: All-routers Multicast

RA from parent router

MAC src: Short
IP src: GP16
SLLAO: Short
MAC dst: IEEE
IP dst: LL64

Initial NS from joining node

MAC src: IEEE
IP src: GP16 (tentative)
SLLAO: IEEE
MAC dst: Short
IP dst: GP16

(Note: parent router stores no L2 state about the tentative address, carried in the SLLAO to the 6LBR and back)

Initial NA from parent router  (success)

MAC src: Short
IP src: GP16
MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR)
IP dst: GP16 (tentative)

(after this point the LL64 isn't really used anymore)

Refresh NS

MAC src: Short
IP src: GP16
SLLAO: Short 
MAC dst: Short
IP dst: GP16

Refresh NA

MAC src: Short
IP src: GP16
MAC dst: Short
IP dst: GP16

-- 
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: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 12 Jul 2010 17:01:55 +0200

Hi Zach,

Thanks for clarifying the example, I was just going through the same
exercise myself and I have a couple of questions:
- In the NS, why not use "SLLAO: short" since the ARO already carries the
IEEE. This would avoid to use an additional refresh NS to establish the
mapping "GP16 / short"
- Also concerning the processing of the RS and the draft says:   
  "A Router Solicitation might be received from a host that has not yet
   registered its address with the router.  Thus the router MUST NOT
   modify its Neighbor Cache with the SLLA option from the Router
   Solicitation.  The SLLA option is only used to form the link-layer
   address to which the router sends the Router Advertisement."
I'm not sure I understand the last sentence. Isn't the IPv6 DST of the RA
the IPv6 SRC of the RS. Then a temporary, "neighbor cache" entry "source RS
/ SSLAO RS" would be needed to establish the mapping with the layer 2
address, no?
- Similarly upon receiving a RA the host should install a neighbor cache
entry for the router. Is there a lifetime or other information associated
with this entry?

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Zach Shelby
Sent: lundi, 12. juillet 2010 16:27
To: 6lowpan 6lowpan
Subject: [6lowpan] ND exchange example

I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.4
device bootstrapping for the first time, generating a 16-bit address, and
then registering it in an unmanaged network. ZigBee IP is trying to minimize
the number of addresses each node has to configure - the goal is to use just
LL64 and GP16. LL64 is avoided where possible though as it has 6 bytes of
extra overhead per address. 

Below the suggested example uses GP16 for RS/RA and NS/NA exchanges where
possible. LL64 is used more for bootstrapping before the GP16 is confirmed.
A couple questions come up here:

1. Can we make an exception for using global addresses for RS/RA and NS/NA
between the host and router? RFC4861 requires the use of link-local. Using
GP16 would save some complexity and overhead. 

2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (see
Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the source of
the NS and the destination of the NA. This means those addresses can't be
compressed by 6lowpan, but then again we save the Registration Address field
from ARO... Is any change needed here or can we live with the proposed
solution in Ticket #87?

RS from joining device

MAC src: IEEE
IP src: LL64
SLLAO: IEEE
MAC dst: Broadcast

RA from parent router

MAC src: Short
IP src: GP16
SLLAO: Short
MAC dst: IEEE
IP dst: LL64

MAC src: IEEE
IP src: GP16 (tentative)
SLLAO: IEEE
MAC dst: Short
IP dst: GP16

(Note: parent router stores no L2 state about the tentative address, carried
in the SLLAO to the 6LBR and back)

MAC src: Short
IP src: GP16

Refresh NS

MAC src: Short
IP src: GP16
SLLAO: Short 
MAC dst: Short
IP dst: GP16

Refresh NA

MAC src: Short
IP src: GP16
MAC dst: Short
IP dst: GP16

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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Jul 2010 22:34:34 +0300

Hi,

> IEEE. This would avoid to use an additional refresh NS to establish the

You could if that short-address would have been e.g DHCPv6 or otherwise assigned. In this example the short address is randomly generated - too dangerous to start using that as your MAC address before knowing if it is a duplicate. 

> / SSLAO RS" would be needed to establish the mapping with the layer 2

You are correct, but we don't call that a temporary neighbor cache entry as it doesn't go into the neighbor cache. In the example I gave the source address is an EUI-64 based  link-local so it would be safe to make an entry - but that might not always be the case. 

> entry for the router. Is there a lifetime or other information associated

Correct. I would assume that this follows normal RFC4861 behavior for default routers?

Zach

---

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

Here is a new version of the exchange example to reflect the situation in nd-11. In the spec one-hop ND traffic uses link-locals (from RFC4861) and the SLLA in the NS should be the short address (6lowpan-nd). This should now be correct. 

RS from joining device

MAC src: IEEE
IP src: LL64
SLLAO: IEEE
MAC dst: Broadcast

RA from parent router

MAC src: Short
IP src: LL16
SLLAO: Short
MAC dst: IEEE
IP dst: LL64
ABRO, PIO, 6CO

MAC src: Short
IP src: GP16 (tentative)
SLLAO: Short
MAC dst: Short
IP dst: LL16
ARO: IEEE

Initial NA from parent router 

MAC src: Short
IP src: LL16
MAC dst: Short (Copied from the SLLAO of the NA from the 6LBR)
IP dst: GP16 (tentative)
ARO: IEEE, Success

Refresh NS

MAC src: Short
IP src: GP16
SLLAO: Short 
MAC dst: Short
IP dst: LL16
ARO: IEEE

Refresh NA

MAC src: Short
IP src: LL16
MAC dst: Short
IP dst: GP16
ARO: IEEE, Success

---

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

On 07/12/10 07:27 AM, Zach Shelby wrote:
> I made an example of a 6lowpan-nd bootstrapping exchange for an
> 802.15.4 device bootstrapping for the first time, generating a 16-bit
> address, and then registering it in an unmanaged network. ZigBee IP
> is trying to minimize the number of addresses each node has to
> configure - the goal is to use just LL64 and GP16. LL64 is avoided
> where possible though as it has 6 bytes of extra overhead per
> address.
>
> Below the suggested example uses GP16 for RS/RA and NS/NA exchanges
> where possible. LL64 is used more for bootstrapping before the GP16
> is confirmed. A couple questions come up here:
>
> 1. Can we make an exception for using global addresses for RS/RA and
> NS/NA between the host and router? RFC4861 requires the use of
> link-local. Using GP16 would save some complexity and overhead.

link-local is used for RS/RA, but not required for NS/NA.

    Erik

---

From: Robert Cragie <[email-masked]>
Date: Mon, 19 Jul 2010 17:58:42 +0100

Hi Zach,

The main issue I have is premature (and strictly illegal) use of the 
tentative MAC short/ IP GP16 address. Additional comments below, 
bracketed bu <RCC></RCC>.

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/>

> IP dst: All-routers Multicast
<RCC>[1] I think it is worth exploring the ability to elide the SLLAO. 
It's not strictly needed as the link-layer (MAC) address can be obtained 
from MAC header. RFC4861 does not mandate it either.</RCC>
> IP src: GP16
<RCC>[2] The joining device does not know the GP at this point, which 
would either mean the parent router doesn't elide the GP16 (special 
case) or preferably uses MAC src: IEEE, IP src: LL64.</RCC>
> SLLAO: Short
<RCC>[3] See above comment [1] re. eliding SLLA option</RCC>
> Initial NS from joining node
<RCC>[4] I don't think this will work. I think src has to be MAC src: 
IEEE, IP src: LL64 and the tentative 16-bit address should be carried in 
the ARO</RCC>
> SLLAO: IEEE
<RCC>[5] See above comment [1] re. eliding SLLA option, unless of course 
you are using it as below to carry state all the way to 6LBR and back.</RCC>

> IP dst: GP16
<RCC>[6] Based on the RA, (comment [2] above) this should also be MAC 
dst: IEEE, IP dst: LL64.</RCC>.
> Initial NA from parent router  (success)
<RCC>[7] This would be OK at this point, albeit a little imbalanced. On 
the other hand, if we used LL64 at this point, we would have the problem 
about how the joining node learns the 16-bit link layer of the parent 
router. LL16 would be one solution but we generally agreed that we'd try 
and avoid using these. Maybe there's a cleaner way?</RCC>
> MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR)
<RCC>[8] Doesn't the parent router has to have some state (tentative 
neighbor cache) for the joining device at this point? It needs to 
maintain timers, for example. If this becomes a real NCE then its IEEE 
address will be needed. So again maybe the SLLAO could be elided?</RCC>
> IP dst: GP16 (tentative)
<RCC>[9] See comment [4] above. Ideally this should be MAC dst: IEEE, IP 
dst: LL64, with the tentative 16-bit address carried in the ARO along 
with the status pertaining to that address.</RCC>
> (after this point the LL64 isn't really used anymore)
<RCC>Agreed. The joining node autoconfigures its GP16 if it's 
successful.</RCC>

---

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

> Robert Cragie (Pacific Gas & Electric)

RFC 4861 doesn't require it because the router can always multicast a RA 
or multicast a NS. We want to avoid that for 6lowpan-nd, thus the router 
must always be able to determine the link-layer address of the host. The 
only generic way we have to do that is to require the SLLAO.
(Anything else would be some form of header compression that can omit a 
SLLAO when the source MAC address is the same as in the MAC header.)

    Erik