Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-09

[Dario Tedeschi]

HC-09 looks in good shape. However, I have one suggestion and one question. I hate to bring them up at such a late stage, but I only realized them today while reading through HC-09. 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. 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. 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? Regards Dario Carsten Bormann wrote: LoWPANners, the HC-08 WGLC has closed a while ago and brought us very solid consensus that this is the way forward, but also a couple of small issues in the periphery. Jonathan has submitted HC-09 to handle the WGLC comments to HC-08. There are only some small changes, which could be considered clarifications, but they are technical in nature and it is probably worthwhile to get some final WG review for these small changes. Given the amount of implementation experience we now have, I don't expect this will be a repeat event. So, this is now a Working-Group Last-Call for: http://tools.ietf.org/html/draft-ietf-6lowpan-hc-09 The document is intended to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a one-week Working-Group Last-Call, ending on 2010-08-30 (Monday, August 30, 2010) at 2359 UTC. Please review the changes to the document carefully, and send your comments to the 6lowpan list. A convenient view of the changes is at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6lowpan-hc-09.txt Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan