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
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 changing
anything about RFC4944, just optimizing out a conditional statement
that
always 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
