Hi Jonathan, What you propose below is fine.
Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 23/09/2010 10:30 PM, Jonathan Hui wrote:
Hi Robert, Good catch. To be more flexible, how about saying that any bits not covered by the context and IID derivation are zero (it allows a context to carry a prefix less than 64 bits). The full text I'm proposing is as follows: 00: The UNSPECIFIED address, :: 01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Any bits of the IID not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero. 10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Any bits of the IID not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- line. Any remaining bits are zero. 11: 0 bits. The address is fully elided. The prefix is derived using context information. Any bits of the IID not covered by the context information are computed from the encapsulating header (e.g. 802.15.4 or IPv6 source address) as specified in Section 3.2.2. Any remaining bits are zero. The text will be mirrored for the destination address as well. Please provide feedback soon so I can post a new version and *hopefully* we can submit to IESG right after. -- Jonathan Hui On Sep 21, 2010, at 3:24 PM, Robert Cragie wrote:It's a minor nit but the text as it's written now assumes the context will be at least 64 bits. I don't see that written down anywhere - should it be? Robert Robert Cragie (Pacific Gas& Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 21/09/2010 4:28 PM, Jonathan Hui wrote:Added text to specify that the 16-bit to IID mapping is used to derive IID bits when SAC/DAC=1 and the context does not cover those bits. -- Jonathan Hui Begin forwarded message:From: IETF I-D Submission Tool<[email protected]> Date: September 21, 2010 8:27:11 AM PDT To: [email protected] Cc: [email protected] Subject: New Version Notification for draft-ietf-6lowpan-hc-12 A new version of I-D, draft-ietf-6lowpan-hc-12.txt has been successfully submitted by Jonathan Hui and posted to the IETF repository. Filename: draft-ietf-6lowpan-hc Revision: 12 Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks Creation_date: 2010-09-21 WG ID: 6lowpan Number_of_pages: 23 Abstract: This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. The IETF Secretariat._______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
