Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
RFC 6282
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2016-09-29
|
15 | (System) | Received changes through RFC Editor sync (added Errata tag) |
|
2015-10-14
|
15 | (System) | Notify list changed from 6lowpan-chairs@ietf.org, draft-ietf-6lowpan-hc@ietf.org to (None) |
|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2011-09-07
|
15 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-09-07
|
15 | (System) | RFC published |
|
2011-04-11
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-04-11
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2011-04-11
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-04-11
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-04-06
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-03-30
|
15 | (System) | IANA Action state changed to In Progress |
|
2011-03-29
|
15 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-03-29
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-03-29
|
15 | Amy Vezza | IESG has approved the document |
|
2011-03-29
|
15 | Amy Vezza | Closed "Approve" ballot |
|
2011-03-29
|
15 | Amy Vezza | Approval announcement text regenerated |
|
2011-03-29
|
15 | Amy Vezza | Ballot writeup text changed |
|
2011-03-29
|
15 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2011-03-26
|
15 | Ralph Droms | Ballot writeup text changed |
|
2011-03-26
|
15 | Russ Housley | [Ballot discuss] The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion about the use of checksums with UDP. This discussion does … [Ballot discuss] The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion about the use of checksums with UDP. This discussion does not seem to be over. The last thing that I saw was: I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point. This discussion needs to reach a resolution before this document is approved. |
|
2011-03-26
|
15 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
|
2011-03-26
|
15 | Ralph Droms | Ballot writeup text changed |
|
2011-03-26
|
15 | Ralph Droms | Ballot writeup text changed |
|
2011-03-26
|
15 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
|
2011-03-03
|
15 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
|
2011-02-24
|
15 | (System) | New version available: draft-ietf-6lowpan-hc-15.txt |
|
2011-02-14
|
15 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-02-14
|
14 | (System) | New version available: draft-ietf-6lowpan-hc-14.txt |
|
2011-01-21
|
15 | (System) | Removed from agenda for telechat - 2011-01-20 |
|
2011-01-20
|
15 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
|
2011-01-20
|
15 | Tim Polk | [Ballot comment] I support Russ's discuss regarding the checksum. |
|
2011-01-20
|
15 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-20
|
15 | Sean Turner | [Ballot comment] I support Russ's discuss. |
|
2011-01-20
|
15 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-19
|
15 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-19
|
15 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-19
|
15 | Jari Arkko | [Ballot comment] Ari Keränen reviewed this draft. His comments: Abstract Missing "updates RFC4944" text. Section 1 Abbreviations ND & MAC should be expanded. Section … [Ballot comment] Ari Keränen reviewed this draft. His comments: Abstract Missing "updates RFC4944" text. Section 1 Abbreviations ND & MAC should be expanded. Section 3.1.1. First time "ECN" and "DSCP" are used. Could move the expanded versions and references from Section 3.2.1 to here. 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 corrseponding bits carried in-line. Any remaining bits are zero. If the context defines some of the same bits as the in-line data, are context bits always used (and in-line bits ignored)? That could be said more explicitly too. Also: s/corrseponding/corresponding/ Section 3.2.4 Expand RIID. DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression Should that be "DAM = 00"? Section 4.3.1 This specification introduces a range of well-known ports (0xF0Bx) This is a bit strange way to express a port range, and the term "well-known ports" is already reserved for ports < 1024. You could say something like: This specification introduces a range of ports, 61616 - 61631 (0xF0B0 - 0xF0BF), that can be compressed more efficiently, using only 4 bits. Transport Layer Security (TLS) Message Integrity Check (MIC) that validates that the content is expected and checked for integrity. "validates" and "is expected and checked" sound a bit strange here. Could use something like "makes sure" and "is what is expected and is checked" Section 4.3.2 Expand PDU. |
|
2011-01-19
|
15 | Ron Bonica | [Ballot comment] I also support the GENART DISCUSS on the checksum |
|
2011-01-19
|
15 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-19
|
15 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-19
|
15 | Stewart Bryant | [Ballot comment] I support Russ' Discuss on the checksum. The mandatory use of checksum in IPv6 is controversial amongst some IETF communities (particularly the community … [Ballot comment] I support Russ' Discuss on the checksum. The mandatory use of checksum in IPv6 is controversial amongst some IETF communities (particularly the community using UDP as a tunnel type). Either this controversy needs to be resolved, or draft-ietf-6lowpan-hc needs to deal correctly with the c/s /no c/s case. It could of course do this by always carrying the c/s, but it seems perverse to have to carry 16 bits of c/s to say that there is no c/s. |
|
2011-01-19
|
15 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-18
|
15 | Russ Housley | [Ballot discuss] The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion about the use of checksums with UDP. This discussion does … [Ballot discuss] The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion about the use of checksums with UDP. This discussion does not seem to be over. The last thing that I saw was: I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point. This discussion needs to reach a resolution before this document is approved. |
|
2011-01-18
|
15 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-01-18
|
15 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-17
|
15 | Lars Eggert | [Ballot discuss] [Edited to include David Black's gen-art review, since I'm already holding a discuss on part of the issues he has raised.] Section 4.3.2., … [Ballot discuss] [Edited to include David Black's gen-art review, since I'm already holding a discuss on part of the issues he has raised.] Section 4.3.2., paragraph 1: > The UDP checksum operation is mandatory with IPv6 [RFC2460] for all > packets. For that reason [RFC4944] disallows the compression of the > UDP checksum. > With this specification, a compressor in the source transport > endpoint MAY elide the UDP checksum if it is authorized by the Upper > Layer. The compressor SHOULD NOT set the C bit unless it has > received such authorization. The Upper Layer SHOULD only provide the > authorization in the following cases: DISCUSS: First, I think you want to use "MUST NOT" and "MAY only" here. Second, there are additional issues here (see draft-ietf-6man-udpzero). For example, even if there is an upper layer integrity check present for a given app, if the port number field gets corrupted and a message gets mis-delivered to an incorrect application (port), *that* application may not have an upper layer integrity check implemented to protect it. And so on. Have you run this part of the spec by 6MAN? Also, from David Black: > A forwarding node MAY imply authorization from an incoming packet if > the C bit is set. A forwarding node that cannot unambiguously derive > such authorization SHOULD NOT elide the UDP checksum when performing > 6LoWPAN compression. This needs to be a MUST NOT. |
|
2011-01-17
|
15 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-01-17
|
15 | Lars Eggert | [Ballot discuss] Section 4.3.2., paragraph 1: > The UDP checksum operation is mandatory with IPv6 [RFC2460] for all > packets. For … [Ballot discuss] Section 4.3.2., paragraph 1: > The UDP checksum operation is mandatory with IPv6 [RFC2460] for all > packets. For that reason [RFC4944] disallows the compression of the > UDP checksum. > With this specification, a compressor in the source transport > endpoint MAY elide the UDP checksum if it is authorized by the Upper > Layer. The compressor SHOULD NOT set the C bit unless it has > received such authorization. The Upper Layer SHOULD only provide the > authorization in the following cases: DISCUSS: First, I think you want to use "MUST NOT" and "MAY only" here. Second, there are additional issues here (see draft-ietf-6man-udpzero). For example, even if there is an upper layer integrity check present for a given app, if the port number field gets corrupted and a message gets mis-delivered to an incorrect application (port), *that* application may not have an upper layer integrity check implemented to protect it. And so on. Have you run this part of the spec by 6MAN? |
|
2011-01-17
|
15 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-01-16
|
15 | Adrian Farrel | [Ballot comment] I found a few small points of house-keeping: --- I would like to see "6LowPAN" expanded in the title, Abstract, and Introduction. I … [Ballot comment] I found a few small points of house-keeping: --- I would like to see "6LowPAN" expanded in the title, Abstract, and Introduction. I think that you will find "6LowPAN network" includes tautology. --- Section 2 New implementations MAY implement compression according to Section 10 of [RFC4944], but SHOULD NOT send packets compressed according to Section 10 of [RFC4944]. s/compression/decompression/ ? --- Figure 2 You might replace OLD 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 NEW 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 END --- The text in section 3.2.1 is correct and can be understood, but it took me several readings to be sure that the text actually matched the figures. If the authors looked at this piece again and polished it, it would help the document. --- Section 3.2.2 When the encapsulating header carries IPv6 addresses, bits for the source and destination addresses are copied verbatim from the source and destination addresses of the encapsulating IPv6 header. "verbatim" is incorrect in this context. And, anyway, it is redundant - "copied" is adequate. --- Section 3.2.2 I think this section could usefully include a reference to [IEEE 802.15.4] --- A number of figures are not numbered, which is mildly inconsistent. --- Section 4.2 For the most part, the IPv6 Extension Header is carried verbatim in the bytes immediately following the LOWPAN_NHC octet, with two important exceptions: Length Field and Next Header Field. "verbatim" again :-) I think in this case you should use "unmodified" --- Seciotn 4.2 1: The Next Header field is elided and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4. s/4/4.1/ --- Section 4.3.2 A forwarding node MAY imply authorization from an incoming packet if the C bit is set. I think you mean "infer" not "imply". |
|
2011-01-16
|
15 | Adrian Farrel | [Ballot discuss] Thanks for this document which I have reviewed in detail. I will ballot "no objection" when one small point has been resolved. Section … [Ballot discuss] Thanks for this document which I have reviewed in detail. I will ballot "no objection" when one small point has been resolved. Section 4.3.1 This specification introduces a range of well-known ports (0xF0Bx) that can be compressed to 4 bits. I don't believe that these are "Well Known Ports". They would be in the range 0-1023. They appear to be "Dynamic and/or Private Ports" I guess you are trying to say that these ports are known by 6lowpan hc implementers. Maybe a complete rewriting of this sentence? This specification defines the use of range of ports from the Dynamic and/or Private Ports range. Using only ports of the type 0xF0Bx means that the port number can be compressed to 4 bits. But I am unclear that you are really using this range of port numbers! Are you not actually using 4 bits to encode up to 16 port number aliases and, as your text says, you require some mapping to be installed to expand those aliases back to real port numbers. If I am wrong (and you are really using ports in the range you state) you need to add text to indicate how this is safe and will not clash with other usage of these port numbers that might happen randomly as an application picks (dynamically or privately) some port number to use. |
|
2011-01-16
|
15 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-01-14
|
15 | David Harrington | Closed request for Last Call review by TSVDIR with state 'No Response' |
|
2011-01-14
|
15 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-01-11
|
15 | Amanda Baber | IANA understands that, upon approval of this document, there are two IANA Actions which much be completed. First, in the Dispatch Type Field subregistry of … IANA understands that, upon approval of this document, there are two IANA Actions which much be completed. First, in the Dispatch Type Field subregistry of the IPv6 Low Power Personal Area Network Parameters registry located at: http://www.iana.org/assignments/6lowpan-parameters/6lowpan-parameters.xhtml the following changes will be made: The following entry will be removed: Bit Pattern: 01 111111 Header type: ESC - Additional Dispatch byte follows The following entry will be added: Bit pattern: 01 1xxxxx Header type: LOWPAN_IPHC The following entry will be added: Bit pattern: 01 000000 Header type: ESC - Additional Dispatch byte follows Second, a new subregistry of the IPv6 Low Power Personal Area Network Parameters registry will be created. This registry will be named: "LOWPAN_NHC header type" The initial values for this new registry are: 00000000 to 11011111: (unassigned) 1110000N: IPv6 Hop-by-Hop Options Header [RFC-to-be] 1110001N: IPv6 Routing Header [RFC-to-be] 1110010N: IPv6 Fragment Header [RFC-to-be] 1110011N: IPv6 Destination Options Header [RFC-to-be] 1110100N: IPv6 Mobility Header [RFC-to-be] 1110101N: (Reserved for future extension headers) 1110110N: (Reserved for future extension headers) 1110111N: IPv6 Header [RFC-to-be] 11110CPP: UDP Header [RFC-to-be] 11111000 to 11111110: (unassigned) 11111111: (unassigned, reserved for extensions) The new registry will note that: "Capital letters in the bit positions above represent class-specific bit assignments. N indicates whether or not additional LOWPAN_NHC encodings follow." New registrations will be made through IETF review. IANA understands that these are the only actions that need to be completed upon approval of this document. |
|
2011-01-10
|
15 | Peter Saint-Andre | [Ballot comment] This is a fine document. I have only a few comments. 1. According to Section 2, this document appears to update RFC 4944 … |
|
2011-01-10
|
15 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-08
|
15 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-04
|
15 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Larry Zhu |
|
2011-01-04
|
15 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Larry Zhu |
|
2010-12-20
|
15 | David Harrington | Request for Last Call review by TSVDIR is assigned to Mark Handley |
|
2010-12-20
|
15 | David Harrington | Request for Last Call review by TSVDIR is assigned to Mark Handley |
|
2010-12-17
|
15 | Cindy Morgan | Last call sent |
|
2010-12-17
|
15 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <6lowpan@lists.ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-6lowpan-hc-13.txt> (Compression Format for IPv6 Datagrams in 6LoWPAN Networks) to Proposed Standard The IESG has received a request from the IPv6 over Low power WPAN WG (6lowpan) to consider the following document: - 'Compression Format for IPv6 Datagrams in 6LoWPAN Networks' <draft-ietf-6lowpan-hc-13.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-hc/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-hc/ |
|
2010-12-17
|
15 | Ralph Droms | Placed on agenda for telechat - 2011-01-20 |
|
2010-12-17
|
15 | Ralph Droms | [Note]: changed to 'The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann<br>(cabo@tzi.org).' |
|
2010-12-17
|
15 | Ralph Droms | Status Date has been changed to 2010-12-17 from None |
|
2010-12-17
|
15 | Ralph Droms | Last Call was requested |
|
2010-12-17
|
15 | Ralph Droms | State changed to Last Call Requested from AD Evaluation. |
|
2010-12-17
|
15 | Ralph Droms | Last Call text changed |
|
2010-12-17
|
15 | Ralph Droms | Last Call text changed |
|
2010-12-17
|
15 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
|
2010-12-17
|
15 | Ralph Droms | Ballot has been issued |
|
2010-12-17
|
15 | Ralph Droms | Created "Approve" ballot |
|
2010-12-17
|
15 | (System) | Ballot writeup text was added |
|
2010-12-17
|
15 | (System) | Last call text was added |
|
2010-12-17
|
15 | (System) | Ballot approval text was added |
|
2010-11-15
|
15 | Ralph Droms | State changed to AD Evaluation from Publication Requested. |
|
2010-11-08
|
15 | Amy Vezza | [Note]: 'The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann (cabo@tzi.org).' added by Amy Vezza |
|
2010-11-08
|
15 | Amy Vezza | Request for publication of draft-ietf-6lowpan-hc-13.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed … Request for publication of draft-ietf-6lowpan-hc-13.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann (cabo@tzi.org). He has personally reviewed the document and believes that it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document is one of the core output documents of the 6LoWPAN WG. It has received wide review as well as extensive interop testing in ZigBee IP and IPSO events. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No -- there are no concerns that the documents require additional broader review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. One inexorable problem with header compression is that specifications are required to adapt to changes both in the specifications and in the usage of the protocols being compressed. 6LoWPAN-HC has an extensibility point (NHC) that can and will be used for future extensions. However, the present base 6LoWPAN-HC document has been stable for some time and should move forward now even as these extensions are being discussed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong working group consensus behind this document. It is the result of several years of work that has been validated by extensive implementation effort. A significant number of WG members have commented on the technical substance and language of the specification. For something as arcane as a header compression specification, it is extremely widely understood in the WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) The shepherd is not aware of any discontent related to the specification. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The shepherd has verified to the best of his ability that there are no ID nits in this draft. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The Document Shepherd believes all references are appropriately split. There are no down-references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations are quite important to this document and appear to be correct. (One consideration, which has been extensively discussed in the WG, is that an existing somewhat unfortunate, so far unused, allocation by RFC 4944 is preempted and assigned a new codepoint.) (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks that replaces the header compression format specified in RFC 4944. 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; among others, this information can be distributed throughout the 6LoWPAN using the 6LoWPAN-ND protocol.) This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. Working Group Summary This document represents the consensus of the 6LoWPAN community to deprecate the header compression content of RFC 4944 and replace it with a new specification. There has been strong consensus that the compression of arbitrary prefixes is sufficiently important to justify this significant change. Document Quality The document is a product of the 6LoWPAN working group and has been reviewed in detail by a significant number of 6LoWPAN working group members. The principal content of the document has been technically stable for about a year, during which certain fringe cases were identified by implementers and addressed in minor updates to the specification. The specification has been picked up widely in the 6LoWPAN community and has been subject to extensive interoperability testing in vendor organizations such as ZigBee and IPSO. |
|
2010-11-08
|
15 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
|
2010-09-27
|
13 | (System) | New version available: draft-ietf-6lowpan-hc-13.txt |
|
2010-09-21
|
12 | (System) | New version available: draft-ietf-6lowpan-hc-12.txt |
|
2010-09-01
|
11 | (System) | New version available: draft-ietf-6lowpan-hc-11.txt |
|
2010-08-31
|
10 | (System) | New version available: draft-ietf-6lowpan-hc-10.txt |
|
2010-08-23
|
09 | (System) | New version available: draft-ietf-6lowpan-hc-09.txt |
|
2010-07-26
|
08 | (System) | New version available: draft-ietf-6lowpan-hc-08.txt |
|
2010-04-08
|
07 | (System) | New version available: draft-ietf-6lowpan-hc-07.txt |
|
2009-10-05
|
06 | (System) | New version available: draft-ietf-6lowpan-hc-06.txt |
|
2009-06-30
|
05 | (System) | New version available: draft-ietf-6lowpan-hc-05.txt |
|
2009-06-11
|
15 | (System) | Document has expired |
|
2008-12-08
|
04 | (System) | New version available: draft-ietf-6lowpan-hc-04.txt |
|
2008-11-17
|
03 | (System) | New version available: draft-ietf-6lowpan-hc-03.txt |
|
2008-11-01
|
02 | (System) | New version available: draft-ietf-6lowpan-hc-02.txt |
|
2008-10-09
|
01 | (System) | New version available: draft-ietf-6lowpan-hc-01.txt |
|
2008-10-08
|
00 | (System) | New version available: draft-ietf-6lowpan-hc-00.txt |