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

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



Colin O'Flynn wrote:
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 protected]] Sent: March 5, 2010 5:53 PM
To: Richard Kelsey
Cc: Colin O'Flynn; [email protected]
Subject: Re: [6lowpan] 6lowpan 16-bit PAN-ID Field


On Mar 5, 2010, at 16:39 , Richard Kelsey wrote:

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.

+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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to