On Aug 24, 2010, at 11:24 AM, Dario Tedeschi wrote: > Could the stateless address compression be changed slightly to be more inline > with how IIDs are derived from 16bit MAC addresses. Something like the > following: > SAM: Source Address Mode: > If SAC=0: > 00: 128 bits. The full address is carried in-line. > 01: 64 bits. The first 64-bits of the address are elided. > The value of those bits is the link-local prefix padded with > zeros. The remaining 64 bits are carried in-line. > 10: 16 bits. The first 112 bits of the address are elided. > The value of > the first 64 those > bits is the link-local prefix > padded with zeros. > The following 48 bits are the first 48 bits > of the IID as defined in section 3.2.2. > The remaining 16 bits > are carried in-line. > > > DAM: Destination Address Mode: > If M=0 and DAC=0 This case matches SAC=0 but for the destination > address: > 00: 128 bits. The full address is carried in-line. > 01: 64 bits. The first 64-bits of the address are elided. > The value of those bits is the link-local prefix padded with > zeros. The remaining 64 bits are carried in-line. > 10: 16 bits. The first 112 bits of the address are elided. > The value of > the first 64 those > bits is the link-local prefix > padded with zeros. > The following 48 bits are the first 48 bits > of the IID as defined in section 3.2.2. > The remaining 16 bits > are carried in-line.
Good catch. This text was left over from when we were debating what value to use for those 48-bits. Now that it's 0000:00ff:fe00:xxxx, we should update the text to reflect that. It's a straightforward edit. I defer to the chairs on the best process of making the change. > Without this change, I see it highly unlikely that 112 bit stateless address > compression will ever be used, because the 0000:00FF:FE00:XXXX IID pattern > could only ever be elided in 128 bit stateless compression mode. > > This also raises a question for stateful compression mode: What must an > decoder do when it has a context entry with a prefix length less than what is > provided in the Address Mode field (SAM or DAM). Effectively, an undefined > gap in the decoded IP address exists. For example: > SAC = 1 and SAM = b10 (16 bits inline) > Context Entry = 2001:AAAA:BBBB:CCCC::/64 > Inline portion of source address = 1234 > > So would the decoded IP address become [#1]: > 2001:AAAA:BBBB:CCCC:0000:0000:0000 > :1234 > > or [#2]: > 2001:AAAA:BBBB:CCCC:0000:00FF:FE00 > :1234 > > or [#3] should the decoder discard the packet. Section 3.2.2 states: This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is also used to reconstruct any part of an IID not covered by context information when only 16 bits are carried in-line (SAC/DAC=10). > Similarly, is an encoder allowed to send a packet with the SAM or DAM fields > set in such a way to create a gap between context prefix length and inline > address bits? One view is to make it a context information problem - if the context doesn't say what to do with a gap, then the compressor is not allowed to and the decompressor should treat it as an error. -- Jonathan Hui _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
