When I first read the HC drafts, I interpreted "context" to permit external knowledge, such as the fact that context 7 that I used it told me to construct the IPv6 address from a locally stored constant that was not part of any ND message. Whether to pad with zeros or with FF:FE000 smells like this sort of external knowledge.
Will it be required that padding be done this way for a 64-bit context and 16-bit short address, or merely allowed? Is padding-with-zeroes as an equally valid interpretation of the context? Does this freedom to interpret apply to other context lengths where the prefix length plus the address length does not equal 128? Can I say that context 7 in a network I control means ignore any provided prefix and use a hard-coded constant 112-bit prefix, if I have some reason to believe this makes sense in my deployment environment? Peter On Mon, Aug 23, 2010 at 3:06 AM, Daniel Gavelle <[email protected]> wrote: > Colin, > > It was brought up at the last Zigbee IP test event. Within Zigbee, several > vendors are already using a 64 bit context, 16 bit MAC and filling in the > gap with FF:fe00. I think it would be good to document this case explicitly > in the HC-08 specification. It is more efficient than using a 112 bit > context because only 64 bits of context need to be sent in the 6LowPAN-ND > message. > > Daniel. > > Colin O'Flynn wrote: >> >> Hello, >> >> I could have sworn the following was brought up by someone else, but I >> couldn't find it now, so wanted to make sure it was mentioned: >> >> When using stateful compression for 16-bit inline, the description of how >> to >> generate the address is: >> >> The address is derived using context information >> and the 16 bits carried in-line. >> >> If the context is shorter than 112 bits, how do you fill in the remaining? >> It can either be specified as filling with zeros, filling with :ff:fe00:, >> or >> simply out of scope for this document. >> >> I would vote for either filling with :ff:fe00: (unline with stateless >> compression), since it results in the most efficient usage when forwarding >> IPv6 packets, or leaving as out of scope. >> >> Regards, >> >> -Colin >> >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Carsten Bormann >> Sent: August 19, 2010 10:59 AM >> To: 6lowpan 6lowpan >> Subject: Re: [6lowpan] Working-Group Last Call for >> draft-ietf-6lowpan-hc-08 >> >> I have reviewed HC-08. The review comments are attached. (Everything not >> indented by 8 spaces is my comment.) >> >> As the review comments mix a few detailed editorial with very few >> substantive technical comments, let me quickly identify the more important >> latter ones in my message: >> >> -- Elision of Padding in IPv6 option headers needs to be specified in such >> a >> way as to make sure that the immutability required of IPv6 padding options >> is preserved. In essence, this means that only well-formed trailing >> padding >> can be elided, because only that padding can be reconstructed reliably. >> This is not much of a technical change in practice, as well-formed padding >> should be the norm, but it is important to call out. >> >> -- I think the NH=0 for EID=7 should be a MUST. There is no value in >> leaving this open. >> >> -- We need IANA considerations for the NHC byte. >> >> Also, the editorial comments I have made should clarify the issues raised >> in >> Reddy's comments. >> (They are editorial for me, but may be technical if someone had a >> different >> understanding.) >> >> Gruesse, Carsten >> >> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > > Regards, > > Daniel. > > -- > > __________________________________________________ > > Daniel Gavelle, Software Team Leader > Low Power RF Solutions (formerly Jennic Ltd.) > NXP Semiconductors > Furnival Street, Sheffield, S1 4QT, UK > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Comp Reg No: 3191371 - Registered In England > http://www.nxp.com http://www.jennic.com > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
