Hi Jonathan, Comments inline, bracketed by <RCC></RCC>
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:
<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>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.
<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>
-- Jonathan Hui On Mar 6, 2010, at 8:27 AM, Richard Kelsey wrote:From: "Colin O'Flynn" <[email protected]> Date: Sat, 6 Mar 2010 12:14:50 -0000 Using the PAN-ID has the advantage that we are not actually changinganything about RFC4944, just optimizing out a conditional statement thatalways evaluates to false.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_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
