Skip to main content

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 …
[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. However, the document header does not include "Updates: RFC 4944".

2. In Section 6, please add an informative reference for Transport Layer Security (TLS).
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