> From: Jonathan Hui <[email protected]>
> 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.
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.
> 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.
This seems like a very good idea.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
