Subject: [6lowpan] 6lowpan 16-bit PAN-ID Field

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 4 Mar 2010 22:59:22 -0000

Hello,

RFC4944 has the quote:

First, the left-most 32 bits are formed by concatenating 16 zero bits to the
16-bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
used).  This produces a 32-bit field as follows:

How does a receiving node know if zero's have been used there to recreate
the IP addresses? Unless I'm missing something, this seems to be a ambiguous
case. It seems unlikely a node will know it's short address but not PAN-ID.

Regards,

  -Colin

---

From: "Rene Struik" <[email-masked]>
Date: Fri, 5 Mar 2010 09:38:48 -0500

Hi Colin:

According to the 802.15.4-2003 specification (which 6lowpan uses), the
association response command includes the PAN Id and short address for
the associating device in question, which info is stored with the
associating device upon successful receipt (7.3.1.4.3). The PAN
Identifier is present in almost every frame or assumed implied in case
of frames originating from or directed towards a PAN coordinator
(7.2.2.1.6, 7.2.2.1.7, 7.2.1.3, 7.2.1.5). So, indeed, not sure how one
can even communicate with 802.15.4-2003 without a device participating
in the network having knowledge of its own PAN Id.

Best regards, 

Rene

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Colin O'Flynn
Sent: Thursday, March 04, 2010 5:59 PM
To: [email-masked]
Subject: [6lowpan] 6lowpan 16-bit PAN-ID Field

Hello,

RFC4944 has the quote:

First, the left-most 32 bits are formed by concatenating 16 zero bits to
the 16-bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits
may be used).  This produces a 32-bit field as follows:

How does a receiving node know if zero's have been used there to
recreate the IP addresses? Unless I'm missing something, this seems to
be a ambiguous case. It seems unlikely a node will know it's short
address but not PAN-ID.

Regards,

  -Colin

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 05 Mar 2010 09:39:04 -0500

> From: "Colin O'Flynn" <[email-masked]>
> Date: Thu, 4 Mar 2010 22:59:22 -0000
> 
> RFC4944 has the quote:
> 

I am not sure what to make of this either.  The PAN ID
may change if a PAN ID conflict is detected, in which
case it would be a nuisance if all of the interface IDs
had to change.  To me, the only time where it might make
sense to to use the PAN ID in the interface ID would be
if a lowpan was spread across multiple PANs that did not
coordinate 16-bit address assignment.  Even in that case,
it would be better to use a 'symbolic' PAN ID in the
interface IDs, to avoid the need to change later.

In a lowpan With only a single PAN ID it makes much more
sense to use zeros and avoid problems if the PAN ID has to
change.
                          -Richard Kelsey

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 5 Mar 2010 15:39:32 -0000

Hello,

Hmm, makes sense to me. Would it be possible to get a recommendation in
hc-06 before WGLC, or where else would it make sense?

As it's difficult to use hc06 with 16-bit addresses unless you decide on
which way this will work. 

Regards,

  -Colin

-----Original Message-----
From: Richard Kelsey [mailto:[email-masked]] 
Sent: March 5, 2010 2:39 PM
To: Colin O'Flynn
Cc: [email-masked]
Subject: Re: [6lowpan] 6lowpan 16-bit PAN-ID Field

> First, the left-most 32 bits are formed by concatenating 16 zero bits to
the

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 5 Mar 2010 15:42:36 -0000

Hello,

One other question/comment:

Using the PAN-ID has the advantage of allowing the use of short-address
zero. As RFC4944 is written now, it looks to me like if you didn't have the
PAN-ID you would have an all zero 48-bit IID (which 4944 disallows).

But I really don't have strong feelings about if it should be based on
PAN-ID or not, I would like to see one way made "standard" though!

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Colin O'Flynn
Sent: March 5, 2010 3:40 PM
To: 'Richard Kelsey'
Cc: [email-masked]
Subject: Re: [6lowpan] 6lowpan 16-bit PAN-ID Field

Hello,

Regards,

  -Colin

-----Original Message-----
From: Richard Kelsey [mailto:[email-masked]] 
Sent: March 5, 2010 2:39 PM
To: Colin O'Flynn
Cc: [email-masked]
Subject: Re: [6lowpan] 6lowpan 16-bit PAN-ID Field

the

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

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 5 Mar 2010 07:44:44 -0800

For many of the same reasons, early versions of the improved hc draft  
(before it became a WG doc) did not make use of the PAN ID to create  
an Interface ID and left it to all zeros.  If you really wanted  
something other than all zeros (e.g. the 'symbolic' PAN ID), then use  
context information with a longer prefix to indicate what those non- 
zero bits are.

Including this within the next rev of 6lowpan-hc is worth discussion.   
It certainly is related, but not limited to HC.

--
Jonathan Hui

On Mar 5, 2010, at 7:39 AM, Colin O'Flynn wrote:

>> recreate

---

From: Robert Cragie <[email-masked]>
Date: Fri, 05 Mar 2010 15:54:00 +0000

Another issue is PAN ID ambiguity due to the need to set the NMSN 
(next-most-significant nibble) of the EUI-64 to make the U/L bit valid 
for an ID which is local. Another reason why a symbolic PAN ID might 
make more sense.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

Jonathan Hui wrote:
> context information with a longer prefix to indicate what those 
> non-zero bits are.
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 5 Mar 2010 19:53:23 +0200

> sense to use zeros and avoid problems if the PAN ID has to

+1. 

Or it can also be 0xFFFF (broadcast) which then allows a 16-bit MAC address of 0. This is what most people are doing in practice from what I've seen. Wouldn't hurt to have a recommendation like that in HC...

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 5 Mar 2010 10:06:32 -0800

On Mar 5, 2010, at 9:53 AM, Zach Shelby wrote:

> Or it can also be 0xFFFF (broadcast) which then allows a 16-bit MAC  
> address of 0. This is what most people are doing in practice from  
> what I've seen. Wouldn't hurt to have a recommendation like that in  
> HC...

It would have to be stronger than a recommendation, otherwise you  
don't get interoperability.

I don't think anything is technically broken if we leave Section 6 of  
RFC 4944 as is.  The text around "unknown PAN ID" just becomes  
irrelevant because that case never happens.  But I agree, there are a  
number of reasons why it is not desirable.

*IF* we decide to exclude the use of the PAN ID in creating IIDs, then  
the relevant part of 6lowpan-hc that would need to change is when SAC/ 
DAC = 00 and SAM/DAM = 11.  My suggestion would be to create a new  
section that updates Section 6 of RFC 4944 and point the text to that  
section.

--
Jonathan Hui

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 6 Mar 2010 12:14:50 -0000

Hello,

> I don't think anything is technically broken if we leave 
> Section 6 of RFC 4944 as is.  

True, as people almost always know their PAN-ID. We were seeing it as a
question & interoperability problem though - some people used 0x0000 here,
some people used a PAN-ID here. And Zach mentions some people using 0xFFFF.

> My suggestion would be to create a new section that updates 
> Section 6 of RFC 4944 and point the text to that section.

Works for me! I don't have strong feelings about if it should be PAN-ID or
0x0000 or anything else, but again I think it's critical one is picked
(ideally adding to hc-06 before WGLC).

0x0000 has the advantage of being easy, and avoids any possible U/L
problems. If you use PAN-ID, there will always be two PAN-IDs mapping to the
same IP address (as the U/L bit is cleared).

Using the PAN-ID has the advantage that we are not actually changing
anything about RFC4944, just optimizing out a conditional statement that
always evaluates to false. 

Regards,

  -Colin

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: March 5, 2010 5:53 PM
To: Richard Kelsey
Cc: Colin O'Flynn; [email-masked]
Subject: Re: [6lowpan] 6lowpan 16-bit PAN-ID Field

+1. 

Or it can also be 0xFFFF (broadcast) which then allows a 16-bit MAC address
of 0. This is what most people are doing in practice from what I've seen.
Wouldn't hurt to have a recommendation like that in HC...

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.

---

From: Robert Cragie <[email-masked]>
Date: Sat, 06 Mar 2010 13:50:08 +0000

Regarding the PAN ID in the IID - if we are not considering the 
'Extended LoWPAN' idea, then I don't think it matters what goes in 
(respecting the U/L bit) as all nodes will know their PAN ID and as the 
global prefix will be unique to the PAN. If we are still considering the 
Extended LoWPAN idea, then some super-authority potentially needs to 
allocate PAN IDs across the LoWPANs and the PAN ID should be included in 
the IID to provide uniqueness across all the LoWPANs on the same global 
prefix.

On a related topic: There is still the issue of duality in IIDs. It is 
possible for an 802.15.4-based interface to have an IID based on its 
IEEE address and also its assigned short address (and possibly PAN ID 
depending on the outcome of the debate below), if it gets one. Stateless 
autoconfiguration can then be based on either. At the moment, we have 
sort of assumed that link-local address will be autoconfigured using the 
IEEE address and thus use 64-bit addressing in the MAC header and global 
prefix-based addresses will be autoconfigured using the 16-bit address 
and thus use 16-bit addresses in the MAC header. Alternatively, it can 
be possible to use stateful configuration of the IPv6 address but this 
would rely on neighbor cache and address resolution mechanism. I realise 
there are other valid variants here - comments?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

---

From: Richard Kelsey <[email-masked]>
Date: Sat, 06 Mar 2010 11:27:22 -0500

> Date: Sat, 6 Mar 2010 12:14:50 -0000
> 

But then what do you do if the PAN ID changes in response
to a conflict?

We seem to have the following issues to contend with:
  - The option of using either the PAN ID or 0x0000 can
    lead to interoperability problems.
  - The PAN ID is not necessarily constant over time.
  - If a subnet has multiple PANs, setting the U/L bit to
    zero may cause distinct PAN IDs to collide.
  - 0x0000 doesn't allow the use of the 0x0000 short address.
  - 0xFFFF has the wrong value for the U/L bit.
  
For subnets that have only a single PAN, the simplest solution
would be to use a fixed value non-zero value, such as 0x0001
or 0xFDFF (assuming I have the U/L bit in the right place).

For subnets with multiple PANs, if we want to support them,
either 16-bit addresses need to be unique across the subnet
or there has to be a way to distribute the "PAN ID" to be
used in forming interface IDs.  The former seems
conceptually simpler, and would allow 0x0001 (or 0xFDFF or
whatever value is chosen) to be used everywhere.

                                   -Richard

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 6 Mar 2010 14:08:28 -0800

It would be good to separate out the issues (and solutions) for link- 
local and global addresses.

For link-local addresses:
- There is no conflict due to the U/L bit since IP addresses are local  
to the link (e.g. PAN).  When compressing/decompressing a IPv6 address  
for a specific interface (i.e. PAN), there should be no ambiguity.
- A change of PAN ID does require invalidating IPv6 addresses with  
IIDs generated using the old PAN ID.  This may cause some confusion  
during a transition, but hopefully most protocols that matter will  
include the psuedo-header in any checksums.

I agree that it would be better to generate IIDs for link-local  
addresses using some well-known, non-zero set of bits for the upper 48  
bits to avoid the second issue above.  I did assume that no one is  
interested in creating a mesh-under network across multiple PANs, but  
is anyone trying to do this?

For global addresses:
- When generated from a 64-bit prefix and 15.4 PAN ID/short addresses,  
we run into the issues of IPv6 address collisions in extended PANs due  
to the U/L bit.
- When generated from a 64-bit prefix and 15.4 PAN ID/short addresses,  
must be invalidated when the PAN ID changes.  Again, hopefully the  
pseudo-header will catch problems during at transition.  But endpoints  
that are not link-local must also be aware of this change.

My suggestion would be to say that generating a global IPv6 addresses  
using a 15.4 short address MUST be coupled with a 112-bit prefix that  
are unique between different PANs.  The compression context would then  
contain a 112-bit prefix.  It would be much nicer to manage the  
uniqueness at the IPv6 layer (through prefixes) rather than the 15.4  
layer (through PAN IDs).  The former at least as well-known ways of  
managing them across different subnets.  Note that it is technically  
possible for logically separate 15.4 networks with the same PAN IDs to  
coexist when using different channels and/or security mechanisms.   
Would be nice to avoid problems when that situation happens as well.

--
Jonathan Hui

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 08 Mar 2010 10:47:25 -0500

> From: Jonathan Hui <[email-masked]>
> Date: Sat, 6 Mar 2010 14:08:28 -0800
> 
> bits to avoid the second issue above.

If the U/L bit is not an issue, I advocate that we
use 0xFFFF when extending 16-bit short addresses into
link-local addresses, in order to avoid any hiccoughs
if the PAN ID changes.

> managing them across different subnets.

This seems like a very good idea.

                                   -Richard Kelsey

---

From: Robert Cragie <[email-masked]>
Date: Mon, 08 Mar 2010 17:51:16 +0000

Hi Jonathan,

Comments inline, bracketed by <RCC></RCC>

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Jonathan Hui wrote:
>
> It would be good to separate out the issues (and solutions) for 
> link-local and global addresses.
>
<RCC>As far as I can see, for link local, there is no need to specify 
how the IID is formed at all as all datagrams are single hop within the 
PAN and the IPv6 address can be fully elided and derived from the actual 
link layer address (i.e. MAC header address). In other words, for 
802.15.4, I am struggling to see where you would use xAC=0, xAM=01, 10. 
Maybe I'm missing something. The only potential confusion is the use of 
64-bit vs. 16-bit addresses (see my earlier post) but even then I don't 
think this is a particular issue for one hop datagrams. Even if we were 
doing mesh under (even over multiple PANs), surely the address would be 
derived from the link layer header (virtual link layer in this case)? 
Perhaps there are PAN transition cases where the originating PAN ID gets 
lost and therefore you would need to inline the addresses somehow.</RCC>
> managing them across different subnets.
<RCC>Agreed - that sounds like a good idea.</RCC>
> Note that it is technically possible for logically separate 15.4 
> networks with the same PAN IDs to coexist when using different 
> channels and/or security mechanisms.  Would be nice to avoid problems 
> when that situation happens as well.
<RCC>Technically possible but not recommended ;-)</RCC>