Hi Carsten,
On Jul 8, 2008, at 3:31 AM, Carsten Bormann wrote:
On Jul 08 2008, at 04:12, Jonathan Hui wrote:
it explicitly separates the context ID space from the address
compression mode. In my mind, the compression prefix and address
compression mode are orthogonal concepts. A single context ID can
be used to support different address compression modes. For
example, a single /64 prefix could be used along with 64-bit, 16-
bit, or 0-bit compressed addresses.
Do you have an example how that would work in practice?
Consider a::b where a is a /64 prefix and b is the 64-bit IID.
1) all 64-bits of b carried in-line in the compressed IPv6 header.
2) lower 16-bits of b carried in-line in the compressed IPv6 header.
Other 48-bits are derived using the PAN ID (if we follow the IID
generation guidelines of RFC 4944).
3) 0-bits of b carried in-line in compressed IPv6 header. b is derived
from either the 6lowpan mesh header or the 802.15.4 link header.
I don't think we should be coupling the context ID with the address
compression mode. Am I missing something? Or is this a plausible
scenario?
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
