One document matched: draft-ietf-6lo-ghc-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc ipr="trust200902" docName="draft-ietf-6lo-ghc-04" category="std">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="6lowpan-ghc">6LoWPAN Generic Compression of Headers and Header-like Payloads</title>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universitaet Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>D-28359 Bremen</city>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email>
</address>
</author>
<date year="2014" month="September" day="08"/>
<area>General</area>
<workgroup>6Lo Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This short specification provides a simple addition to 6LoWPAN Header
Compression that enables the compression of generic headers and
header-like payloads, without a need to define a new header
compression scheme for each new such header or header-like payload.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<section anchor="the-header-compression-coupling-problem" title="The Header Compression Coupling Problem">
<t>6LoWPAN-HC <xref target="RFC6282"/> defines a scheme for header compression in
6LoWPAN <xref target="RFC4944"/> packets. As with most header compression schemes, a new
specification is needed for every new kind of header that needs to be
compressed. In addition, <xref target="RFC6282"/> does not define an
extensibility scheme like the ROHC profiles defined in ROHC
<xref target="RFC3095"/> <xref target="RFC5795"/>. This leads to the difficult situation that
6LoWPAN-HC tended to be reopened and reexamined each time
a new header receives consideration (or an old header is changed and
reconsidered) in the 6LoWPAN/roll/CoRE cluster of IETF working groups.
While <xref target="RFC6282"/> finally got completed, the underlying problem
remains unsolved.</t>
<t>The purpose of the present contribution is to plug into
<xref target="RFC6282"/> as is, using its NHC (next header compression)
concept. We add a slightly less efficient, but vastly more general
form of compression for headers of any kind and even for header-like
payloads such as those exhibited by routing protocols, DHCP, etc. The
objective is an extremely simple specification that can be defined on a single
page and implemented in a small number of lines of code, as opposed to a
general data compression scheme such as that defined in <xref target="RFC1951"/>.</t>
</section>
<section anchor="compression-approach" title="Compression Approach">
<t>The basic approach of GHC’s compression function is to define a
bytecode for LZ77-style compression <xref target="LZ77"/>. The bytecode is a
series of simple instructions for the decompressor to reconstitute the
uncompressed payload. These instructions include:</t>
<t><list style="symbols">
<t>appending bytes to the reconstituted payload that are literally
given with the instruction in the compressed data</t>
<t>appending a given number of zero bytes to the reconstituted payload</t>
<t>appending bytes to the reconstituted payload by copying a contiguous
sequence from the payload being reconstituted (“backreferencing”)</t>
<t>an ancillary instruction for setting up parameters for the
backreferencing instruction in “decompression variables”</t>
<t>a stop code (optional, see <xref target="exthdr"/>)</t>
</list></t>
<t>The buffer for the reconstituted payload (“destination buffer”) is
prefixed by a predefined dictionary that can be used in the
backreferencing as if it were a prefix of the payload.
This predefined dictionary is built from the IPv6 addresses of the
packet being reconstituted, followed by a static component, the
“static dictionary”.</t>
<t>As usual, this specification defines the decompressor operation in
detail, but leaves the detailed operation of the compressor open to
implementation. The compressor can be implemented as with a classical
LZ77 compressor, or it can be a simple protocol encoder that just
makes use of known compression opportunities.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in RFC
2119 <xref target="RFC2119"/>.</t>
<t>The term “byte” is used in its now customary sense as a synonym for
“octet”.</t>
<t><vspace blankLines='999' /></t>
</section>
<section anchor="notation" title="Notation">
<t>This specification uses a trivial notation for code bytes and the
bitfields in them, the meaning of which should be mostly obvious.
More formally, the meaning of the notation is:</t>
<t>Potential values for the code bytes themselves are expressed by
templates that represent 8-bit most-significant-bit-first binary
numbers (without any special prefix), where 0 stands for 0, 1 for 1,
and variable segments in these code byte templates are indicated by
sequences of the same letter such as kkkkkkk or ssss, the length of
which indicates the length of the variable segment in bits.</t>
<t>In the notation of values derived from the code bytes, 0b is used as a
prefix for expressing binary numbers in most-significant-bit first
notation (akin to the use of 0x for most-significant-digit-first
hexadecimal numbers in the C programming language).
Where the above-mentioned sequences of letters are then referenced in
such a binary number in the text, the intention is that the value from
these bitfields in the actual code byte be inserted.</t>
<t>Example: The code byte template</t>
<t><list style='empty'>
<t>101nssss</t>
</list></t>
<t>stands for a byte that starts (most-significant-bit-first) with the
bits 1, 0, and 1, and continues with five variable bits, the first of which is
referenced as “n” and the next four are referenced as “ssss”.
Based on this code byte template, a reference to</t>
<t><list style='empty'>
<t>0b0ssss000</t>
</list></t>
<t>means a binary number composed from a zero bit, the four bits that are in the
“ssss” field (for 101nssss, the four least significant bits) in the actual
byte encountered, kept in the same order, and three more zero bits.</t>
<t><vspace blankLines='999' /></t>
</section>
</section>
<section anchor="lowpan-ghc" title="6LoWPAN-GHC">
<t>The format of a GHC-compressed header or payload is a simple bytecode.
A compressed header consists of a sequence of pieces, each of which
begins with a code byte, which may be followed by zero or more bytes
as its argument. Some code bytes cause bytes to be laid out in the
destination buffer, some simply modify some decompression variables.</t>
<t>At the start of decompressing a header or payload within a L2 packet
(= fragment), the decompression variables <spanx style="verb">sa</spanx> and <spanx style="verb">na</spanx> are initialized as zero.</t>
<t>The code bytes are defined as follows (<xref target="bytecodes"/>):</t>
<texttable title="Bytecodes for generic header compression" anchor="bytecodes">
<ttcol align='left'>code byte</ttcol>
<ttcol align='left'>Action</ttcol>
<ttcol align='left'>Argument</ttcol>
<c>0kkkkkkk</c>
<c>Append k = 0b0kkkkkkk bytes of data in the bytecode argument (k < 96)</c>
<c>k bytes of data</c>
<c>1000nnnn</c>
<c>Append 0b0000nnnn+2 bytes of zeroes</c>
<c> </c>
<c>10010000</c>
<c>STOP code (end of compressed data, see <xref target="exthdr"/>)</c>
<c> </c>
<c>101nssss</c>
<c>Set up extended arguments for a backreference: sa += 0b0ssss000, na += 0b0000n000</c>
<c> </c>
<c>11nnnkkk</c>
<c>Backreference: n = na+0b00000nnn+2; s = 0b00000kkk+sa+n; append n bytes from previously output bytes, starting s bytes to the left of the current output pointer; set sa = 0, na = 0</c>
<c> </c>
</texttable>
<t>Note that the following bit combinations are reserved at this time:
011xxxxx, and 1001nnnn (where 0b0000nnnn > 0).</t>
<t>For the purposes of the backreferences, the expansion buffer is
initialized with a predefined dictionary, at the end of
which the reconstituted payload begins.
This dictionary is composed of the source and destination IPv6
addresses of the packet being reconstituted, followed by a 16-byte
static dictionary (<xref target="staticdict"/>).
These 48 dictionary bytes are therefore available for backreferencing,
but not copied into the final reconstituted payload.</t>
<figure title="The 16 bytes of static dictionary (in hex)" anchor="staticdict"><artwork><![CDATA[
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
]]></artwork></figure>
</section>
<section anchor="integrating-6lowpan-ghc-into-6lowpan-hc" title="Integrating 6LoWPAN-GHC into 6LoWPAN-HC">
<t>6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC
<xref target="RFC6282"/>.</t>
<section anchor="payload" title="Compressing payloads (UDP and ICMPv6)">
<t>GHC is by definition generic and can be applied to different kinds of
packets. Many of the examples given in <xref target="examples"/> are for ICMPv6 packets; a
single NHC value suffices to define an NHC format for ICMPv6 based on
GHC (see below).</t>
<t>In addition it is useful to include an NHC format for UDP, as many
headerlike payloads (e.g., DHCPv6, DTLS) are carried in UDP.
<xref target="RFC6282"/> already defines an NHC format for UDP (11110CPP).
GHC uses
an analogous NHC byte formatted as shown in <xref target="udpnhc"/>.
The difference to the existing UDP NHC specification is that for 0b11010cpp
NHC bytes, the UDP payload is not supplied literally but compressed by
6LoWPAN-GHC.</t>
<figure title="NHC byte for UDP GHC (to be allocated by IANA)" anchor="udpnhc"><artwork><![CDATA[
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
]]></artwork></figure>
<t>To stay in the same general numbering space, we use
0b11011111
as the NHC byte for ICMPv6 GHC (<xref target="icmpv6nhc"/>).</t>
<figure title="NHC byte for ICMPv6 GHC (to be allocated by IANA)" anchor="icmpv6nhc"><artwork><![CDATA[
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
]]></artwork></figure>
</section>
<section anchor="exthdr" title="Compressing extension headers">
<t>Compression of specific extension headers is added in a similar way (<xref target="extnhc"/>)
(however, probably only EID 0 to 3 need to be assigned).
As there is no easy way to extract the length field from the GHC-encoded
header before decoding, this would make detecting the end of the
extension header somewhat complex.
The easiest (and most efficient) approach is to completely elide the
length field (in the same way NHC already elides the next header field
in certain cases) and reconstruct it only on decompression.
To serve as a terminator for the extension header, the reserved
bytecode 0b10010000 has been assigned as a stop marker.
Note that the stop marker is only needed for extension headers, not
for the final payloads discussed in the previous subsection, the decompression of which is automatically stopped
by the end of the packet.</t>
<figure title="NHC byte for extension header GHC" anchor="extnhc"><artwork><![CDATA[
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 1 | EID |NH |
+---+---+---+---+---+---+---+---+
]]></artwork></figure>
</section>
<section anchor="capability" title="Indicating GHC capability">
<t>The 6LoWPAN baseline includes just <xref target="RFC4944"/>,
<xref target="RFC6282"/>, <xref target="RFC6775"/> (see
<xref target="I-D.bormann-6lo-6lowpan-roadmap"/>).
To enable the use of GHC towards a neighbor, a 6LoWPAN node needs to
know that the neighbor implements it.
While this can also simply be administratively required, a transition
strategy as well as a way to support mixed networks is required.</t>
<t>One way to know a neighbor does implement GHC is receiving a packet
from that neighbor with GHC in it (“implicit capability detection”).
However, there needs to be a way to bootstrap this, as nobody ever
would start sending packets with GHC otherwise.</t>
<t>To minimize the impact on <xref target="RFC6775"/>, we define
an ND option 6LoWPAN Capability Indication (6CIO), as illustrated in
<xref target="figure-6ci"/>.</t>
<figure title="6LoWPAN Capability Indication Option (6CIO)" anchor="figure-6ci"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 |_____________________________|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The G bit indicates whether the node sending the option is GHC
capable.</t>
<t>Once a node receives either an explicit or an implicit indication of
GHC capability from another node, it may send GHC-compressed packets
to that node. Where that capability has not been recently confirmed,
similar to the way PLPMTUD <xref target="RFC4821"/> finds out about changes in the
network, a node SHOULD make use of NUD (neighbor unreachability
detection) failures to switch back to basic 6LoWPAN header compression
<xref target="RFC6282"/>.</t>
</section>
<section anchor="bitnumbers" title="Using the 6CIO Option">
<t>The 6CIO option will typically only be ever sent in 6LoWPAN-ND RS
packets (which cannot itself be GHC compressed unless the host
desires to limit itself to talking to GHC capable routers).
The resulting 6LoWPAN-ND RA can then already make use of GHC and thus
indicate GHC capability implicitly, which in turn allows both nodes to
use GHC in the 6LoWPAN-ND NS/NA exchange.</t>
<t>6CIO can also be used for future options that need to be negotiated
between 6LoWPAN peers; an IANA registry is used to assign the flags.
Bits marked by underscores in <xref target="figure-6ci"/> are unassigned and available for future
assignment. They MUST be sent as zero and MUST be ignored on reception
until assigned by IANA. Length values larger than 1 MUST be accepted by
implementations in order to enable
future extensions; the additional bits in the option are then deemed unassigned
in the same way. For the purposes of the IANA registry, the bits are
numbered in most-significant-bit-first order from the 16th bit of the option onward,
i.e., the G bit is flag number 15.
(Additional bits may also be used by a follow-on version of this
document if some bit combinations that have been left unassigned here
are then used in an upward compatible manner.)</t>
<t>Flag numbers 0 to 7 are reserved for experiments.
They MUST NOT be used for actual deployments.</t>
<t>Where the use of this option by other specifications or by experiments is envisioned,
the following items have to be kept in mind:</t>
<t><list style="symbols">
<t>The option can be used in any ND packet.</t>
<t>Specific bits are set in the option to indicate that a capability is
present in the sender. (There may be other ways to infer this
information, as is the case in this specification.) Bit
combinations may be used as desired. The absence of the capability
<spanx style="emph">indication</spanx> is signaled by setting these bits to zero; this does not
necessarily mean that the capability is absent.</t>
<t>The intention is not to modify the semantics of the specific ND
packet carrying the option, but to provide the general capability
indication described above.</t>
<t>Specifications have to be designed such that receivers that do not
receive or do not process such a capability indication can still
interoperate (presumably without exploiting the indicated capability).</t>
<t>The option is meant to be used sparsely, i.e. once a sender has
reason to believe the capability indication has been received, there
no longer is a need to continue sending it.</t>
</list></t>
</section>
</section>
<section anchor="iana-considerations" title="IANA considerations">
<t>[This section to be removed/replaced by the RFC Editor.]</t>
<t>In the IANA registry for the “LOWPAN_NHC Header Type” (in the “IPv6
Low Power Personal Area Network Parameters”), IANA is requested to add the
assignments in <xref target="ianaassign"/>.</t>
<figure title="IANA assignments for the NHC byte" anchor="ianaassign"><artwork><![CDATA[
10110IIN: Extension header GHC [RFCthis]
11010CPP: UDP GHC [RFCthis]
11011111: ICMPv6 GHC [RFCthis]
]]></artwork></figure>
<t>IANA is requested to allocate an ND option number for the “6LoWPAN
Capability Indication Option (6CIO)” ND option
format in the Registry “IPv6 Neighbor Discovery Option Formats”
<xref target="RFC4861"/>.</t>
<t>IANA is requested to create a subregistry for “6LoWPAN capability bits” within
the “Internet Control Message Protocol version 6 (ICMPv6) Parameters”.
The bits are assigned by giving their numbers as small non-negative
integers as defined in section <xref target="bitnumbers"/>, preferably in
the range 0..47. The policy is “IETF Review” or “IESG Approval” <xref target="RFC5226"/>.
The initial content of the registry is as in <xref target="ianaassign1"/>:</t>
<figure title="IANA assignments for the 6LoWPAN capability bits" anchor="ianaassign1"><artwork><![CDATA[
0..7: reserved for experiments [RFCthis]
8..14: unassigned
15: GHC capable bit (G bit) [RFCthis]
16..47: unassigned
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
</section>
<section anchor="security-considerations" title="Security considerations">
<t>The security considerations of <xref target="RFC4944"/> and <xref target="RFC6282"/>
apply. As usual in protocols with packet parsing/construction, care
must be taken in implementations to avoid buffer overflows and in
particular (with respect to the back-referencing) out-of-area
references during decompression.</t>
<t>One additional consideration is that an attacker may send a forged
packet that makes a second node believe a third victim node is GHC-capable.
If it is not, this may prevent packets sent by the second node from reaching
the third node (at least until robustness features such as those
discussed in <xref target="capability"/> kick in).</t>
<t>No mitigation is proposed (or known) for this attack, except that a
victim node that does implement GHC is not vulnerable. However, with
unsecured ND, a number of attacks with similar outcomes are already
possible, so there is little incentive to make use of this additional
attack. With secured ND, 6CIO is also secured; nodes relying on
secured ND therefore should use 6CIO bidirectionally (and limit the
implicit capability detection to secured ND packets carrying GHC)
instead of basing their neighbor capability assumptions on receiving
any kind of unprotected packet.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Colin O’Flynn has repeatedly insisted that some form of compression
for ICMPv6 and ND packets might be beneficial. He actually wrote his
own draft, <xref target="I-D.oflynn-6lowpan-icmphc"/>, which compresses better, but
addresses basic ICMPv6/ND only and needs a much longer spec (around 17
pages of detailed spec, as compared to the single page of core spec
here). This motivated the author to try something simple, yet
general. Special thanks go to Colin for indicating that he indeed
considers his draft superseded by the present one.</t>
<t>The examples given are based on pcap files that Colin O’Flynn, Owen
Kirby, Olaf Bergmann and others provided.</t>
<t>The static dictionary was developed, and the bit allocations
validated, based on research by Sebastian Dominik.</t>
<t>Erik Nordmark provided input that helped shaping the 6CIO option.
Thomas Bjorklund proposed simplifying the predefined dictionary.</t>
<t>Yoshihiro Ohba insisted on clarifying the notation used for the
definition of the bytecodes and their bitfields.
Ulrich Herberg provided some additional review and suggested expanding
the introductory material, and with Hannes Tschofenig and Brian
Haberman he helped come up with the IANA policy for the “6LoWPAN capability
bits” assignments in the 6CIO option.</t>
<t><vspace blankLines='999' /></t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC6282'>
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). 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. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6282' />
<format type='TXT' octets='52588' target='http://www.rfc-editor.org/rfc/rfc6282.txt' />
</reference>
<reference anchor='RFC4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'>
<organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'>
<organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'>
<organization /></author>
<date year='2007' month='September' />
<abstract>
<t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4944' />
<format type='TXT' octets='67232' target='http://www.rfc-editor.org/rfc/rfc4944.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC6775'>
<front>
<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'>
<organization /></author>
<author initials='S.' surname='Chakrabarti' fullname='S. Chakrabarti'>
<organization /></author>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'>
<organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<date year='2012' month='November' />
<abstract>
<t>The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6775' />
<format type='TXT' octets='130616' target='http://www.rfc-editor.org/rfc/rfc6775.txt' />
</reference>
<reference anchor='RFC4861'>
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'>
<organization /></author>
<author initials='W.' surname='Simpson' fullname='W. Simpson'>
<organization /></author>
<author initials='H.' surname='Soliman' fullname='H. Soliman'>
<organization /></author>
<date year='2007' month='September' />
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4861' />
<format type='TXT' octets='235106' target='http://www.rfc-editor.org/rfc/rfc4861.txt' />
</reference>
<reference anchor='RFC5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="LZ77" >
<front>
<title>A Universal Algorithm for Sequential Data Compression</title>
<author initials="J." surname="Ziv">
<organization></organization>
</author>
<author initials="A." surname="Lempel">
<organization></organization>
</author>
<date year="1977" month="May"/>
</front>
<seriesInfo name="IEEE" value="Transactions on Information Theory, Vol. 23, No. 3, pp. 337-343"/>
</reference>
<reference anchor='RFC3095'>
<front>
<title>RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<author initials='C.' surname='Burmeister' fullname='C. Burmeister'>
<organization /></author>
<author initials='M.' surname='Degermark' fullname='M. Degermark'>
<organization /></author>
<author initials='H.' surname='Fukushima' fullname='H. Fukushima'>
<organization /></author>
<author initials='H.' surname='Hannu' fullname='H. Hannu'>
<organization /></author>
<author initials='L-E.' surname='Jonsson' fullname='L-E. Jonsson'>
<organization /></author>
<author initials='R.' surname='Hakenberg' fullname='R. Hakenberg'>
<organization /></author>
<author initials='T.' surname='Koren' fullname='T. Koren'>
<organization /></author>
<author initials='K.' surname='Le' fullname='K. Le'>
<organization /></author>
<author initials='Z.' surname='Liu' fullname='Z. Liu'>
<organization /></author>
<author initials='A.' surname='Martensson' fullname='A. Martensson'>
<organization /></author>
<author initials='A.' surname='Miyazaki' fullname='A. Miyazaki'>
<organization /></author>
<author initials='K.' surname='Svanbro' fullname='K. Svanbro'>
<organization /></author>
<author initials='T.' surname='Wiebke' fullname='T. Wiebke'>
<organization /></author>
<author initials='T.' surname='Yoshimura' fullname='T. Yoshimura'>
<organization /></author>
<author initials='H.' surname='Zheng' fullname='H. Zheng'>
<organization /></author>
<date year='2001' month='July' />
<abstract>
<t>This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3095' />
<format type='TXT' octets='368746' target='http://www.rfc-editor.org/rfc/rfc3095.txt' />
</reference>
<reference anchor='RFC5795'>
<front>
<title>The RObust Header Compression (ROHC) Framework</title>
<author initials='K.' surname='Sandlund' fullname='K. Sandlund'>
<organization /></author>
<author initials='G.' surname='Pelletier' fullname='G. Pelletier'>
<organization /></author>
<author initials='L-E.' surname='Jonsson' fullname='L-E. Jonsson'>
<organization /></author>
<date year='2010' month='March' />
<abstract>
<t>The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.</t><t> The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.</t><t> This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5795' />
<format type='TXT' octets='89850' target='http://www.rfc-editor.org/rfc/rfc5795.txt' />
</reference>
<reference anchor='RFC1951'>
<front>
<title>DEFLATE Compressed Data Format Specification version 1.3</title>
<author initials='P.' surname='Deutsch' fullname='L. Peter Deutsch'>
<organization>Aladdin Enterprises</organization>
<address>
<postal>
<street>203 Santa Margarita Ave.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country></postal>
<phone>+1 415 322 0103</phone>
<facsimile>+1 415 322 1734</facsimile>
<email>ghost@aladdin.com</email></address></author>
<date year='1996' month='May' />
<abstract>
<t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents.</t></abstract></front>
<seriesInfo name='RFC' value='1951' />
<format type='TXT' octets='36944' target='http://www.rfc-editor.org/rfc/rfc1951.txt' />
<format type='PS' octets='57408' target='http://www.rfc-editor.org/rfc/rfc1951.ps' />
<format type='PDF' octets='56620' target='http://www.rfc-editor.org/rfc/rfc1951.pdf' />
</reference>
<reference anchor='I-D.bormann-6lo-6lowpan-roadmap'>
<front>
<title>6LoWPAN Roadmap and Implementation Guide</title>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='October' day='21' year='2013' />
<abstract><t>6LoWPAN is defined in RFC 4944 in conjunction with a number of specifications that are currently nearing completion. The entirety of these specifications may be hard to understand, pose specific implementation problems, or be simply inconsistent. The present guide aims to provide a roadmap to these documents as well as provide specific advice how to use these specifications in combination. In certain cases, it may provide clarifications or even corrections to the specifications referenced. This guide is intended as a continued work-in-progress, i.e. a long- lived Internet-Draft, to be updated whenever new information becomes available and new consensus on how to handle issues is formed. Similar to the ROHC implementation guide, RFC 4815, it might be published as an RFC at some future time later in the maintenance curve of the specifications. This document does not describe a new protocol or attempt to set a new standard of any kind - it mostly describes good practice in using the existing specifications, but it may also document emerging consensus where a correction needs to be made.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-bormann-6lo-6lowpan-roadmap-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bormann-6lo-6lowpan-roadmap-00.txt' />
</reference>
<reference anchor='RFC4821'>
<front>
<title>Packetization Layer Path MTU Discovery</title>
<author initials='M.' surname='Mathis' fullname='M. Mathis'>
<organization /></author>
<author initials='J.' surname='Heffner' fullname='J. Heffner'>
<organization /></author>
<date year='2007' month='March' />
<abstract>
<t>This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4821' />
<format type='TXT' octets='75665' target='http://www.rfc-editor.org/rfc/rfc4821.txt' />
</reference>
<reference anchor='I-D.oflynn-6lowpan-icmphc'>
<front>
<title>ICMPv6/ND Compression for 6LoWPAN Networks</title>
<author initials='C' surname='O'Flynn' fullname='Colin O'Flynn'>
<organization />
</author>
<date month='July' day='28' year='2010' />
<abstract><t>Compression for ICMPv6 Messages, specifically designed for 6lowpan-nd.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-oflynn-6lowpan-icmphc-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-oflynn-6lowpan-icmphc-00.txt' />
</reference>
</references>
<section anchor="examples" title="Examples">
<t>This section demonstrates some relatively realistic examples derived from
actual PCAP dumps taken at previous interops.
<!-- (TBD: Add a couple DHCP examples.) --></t>
<t><xref target="ex1"/> shows an RPL DODAG Information Solicitation, a quite short RPL
message that obviously cannot be improved much.</t>
<figure title="A simple RPL example" anchor="ex1"><artwork><![CDATA[
IP header:
60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00
02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 1a
Payload:
9b 00 6b de 00 00 00 00
Dictionary:
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 04 9b 00 6b de
4 nulls: 82
Compressed:
04 9b 00 6b de 82
Was 8 bytes; compressed to 6 bytes, compression factor 1.33
]]></artwork></figure>
<t><xref target="ex2"/> shows an RPL DODAG Information Object, a longer RPL control message
that is improved a bit more.
Note that the compressed output exposes an inefficiency in the
simple-minded compressor used to generate it; this does not devalue
the example since constrained nodes are quite likely to make use of
simple-minded compressors.</t>
<t><vspace blankLines='999' /></t>
<figure title="A longer RPL example" anchor="ex2"><artwork><![CDATA[
IP header:
60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 1a
Payload:
9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14
09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20
ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00
ff ff ff ff 20 02 0d b8 00 00 00 00
Dictionary:
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 06 9b 01 7a 5f 00 f0
ref(9): 01 00 -> ref 11nnnkkk 0 7: c7
copy: 01 88
3 nulls: 81
copy: 04 20 02 0d b8
7 nulls: 85
ref(60): ff fe 00 -> ref 101nssss 0 7/11nnnkkk 1 1: a7 c9
copy: 08 fa ce 04 0e 00 14 09 ff
ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/11nnnkkk 3 2: a4 da
5 nulls: 83
copy: 06 08 1e 80 20 ff ff
ref(2): ff ff -> ref 11nnnkkk 0 0: c0
ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
4 nulls: 82
ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce
-> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0
copy: 03 03 0e 40
ref(9): 00 ff -> ref 11nnnkkk 0 7: c7
ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9
ref(24): 20 02 0d b8 00 00 00 00
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
Compressed:
06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8
85 a7 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06
08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 c7
a3 c9 a2 f0
Was 92 bytes; compressed to 52 bytes, compression factor 1.77
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
<t>Similarly, <xref target="ex27a"/> shows an RPL DAO message. One of the embedded
addresses is copied right out of the pseudo-header, the other one is
effectively converted from global to local by providing the prefix FE80
literally, inserting a number of nulls, and copying (some of) the IID
part again out of the pseudo-header. Note that a simple implementation
would probably emit fewer nulls and copy the entire IID; there are
multiple ways to encode this 50-byte payload into 27 bytes.</t>
<figure title="An RPL DAO message" anchor="ex27a"><artwork><![CDATA[
IP header:
60 00 00 00 00 32 3a ff 20 02 0d b8 00 00 00 00
00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00
00 00 00 ff fe 00 11 22
Payload:
9b 02 58 7d 01 80 00 f1 05 12 00 80 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 33 44 06 14 00 80
f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00
11 22
Dictionary:
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80
ref(60): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44
-> ref 101nssss 1 5/11nnnkkk 6 4: b5 f4
copy: 08 06 14 00 80 f1 00 fe 80
9 nulls: 87
ref(66): ff fe 00 11 22 -> ref 101nssss 0 7/11nnnkkk 3 5: a7 dd
Compressed:
0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b5 f4 08
06 14 00 80 f1 00 fe 80 87 a7 dd
Was 50 bytes; compressed to 27 bytes, compression factor 1.85
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
<t><xref target="ex3"/> shows the effect of compressing a simple ND neighbor
solicitation.</t>
<figure title="An ND neighbor solicitation" anchor="ex3"><artwork><![CDATA[
IP header:
60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00
00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23
Payload:
87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00
1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24
Dictionary:
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 04 87 00 a7 68
4 nulls: 82
ref(40): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
-> ref 101nssss 1 3/11nnnkkk 6 0: b3 f0
copy: 04 01 01 3b d3
4 nulls: 82
copy: 02 1f 02
5 nulls: 83
copy: 02 06 00
ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db
copy: 02 20 24
Compressed:
04 87 00 a7 68 82 b3 f0 04 01 01 3b d3 82 02 1f
02 83 02 06 00 a2 db 02 20 24
Was 48 bytes; compressed to 26 bytes, compression factor 1.85
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
<t><xref target="ex4"/> shows the compression of an ND neighbor advertisement.</t>
<figure title="An ND neighbor advertisement" anchor="ex4"><artwork><![CDATA[
IP header:
60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00
00 00 00 ff fe 00 3b d3
Payload:
88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00
1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24
Dictionary:
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 05 88 00 26 6c c0
3 nulls: 81
ref(56): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
-> ref 101nssss 1 5/11nnnkkk 6 0: b5 f0
copy: 04 02 01 fa ce
4 nulls: 82
copy: 02 1f 02
5 nulls: 83
copy: 02 06 00
ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db
copy: 02 20 24
Compressed:
05 88 00 26 6c c0 81 b5 f0 04 02 01 fa ce 82 02
1f 02 83 02 06 00 a2 db 02 20 24
Was 48 bytes; compressed to 27 bytes, compression factor 1.78
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
<t><xref target="ex5"/> shows the compression of an ND router solicitation.
Note that the relatively good compression is not caused by the many zero
bytes in the link-layer address of this particular capture (which are
unlikely to occur in practice):
7 of these 8 bytes are copied from the pseudo-header (the 8th byte
cannot be copied as the universal/local bit needs to be inverted).</t>
<figure title="An ND router solicitation" anchor="ex5"><artwork><![CDATA[
IP header:
60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00
ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 02
Payload:
85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00
00 01 00 00 00 00 00 00
Dictionary:
fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 04 85 00 90 65
ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de
copy: 02 02 ac
ref(50): de 48 00 00 00 00 01
-> ref 101nssss 0 5/11nnnkkk 5 3: a5 eb
6 nulls: 84
Compressed:
04 85 00 90 65 de 02 02 ac a5 eb 84
Was 24 bytes; compressed to 12 bytes, compression factor 2.00
]]></artwork></figure>
<t><xref target="ex6"/> shows the compression of an ND router advertisement.
The indefinite lifetime is compressed to four bytes by
backreferencing; this could be improved (at the cost of minor additional
decompressor complexity) by including some simple runlength mechanism.</t>
<t><vspace blankLines='999' /></t>
<figure title="An ND router advertisement" anchor="ex6"><artwork><![CDATA[
IP header:
60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00
10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00
ae de 48 00 00 00 00 01
Payload:
86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0
01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff
ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00
00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8
20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22
Dictionary:
fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22
fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17
2 nulls: 80
copy: 06 07 d0 01 01 11 22
4 nulls: 82
copy: 06 03 04 40 40 ff ff
ref(2): ff ff -> ref 11nnnkkk 0 0: c0
ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
4 nulls: 82
copy: 04 20 02 0d b8
12 nulls: 8a
copy: 04 20 02 40 10
ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb
copy: 01 e8
ref(24): 20 02 0d b8 00 00 00 00
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
copy: 02 21 03
ref(84): 00 01 00 00 00 00
-> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6
ref(40): 20 02 0d b8 00 00 00 00 00 00 00
-> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd
ref(128): ff fe 00 11 22
-> ref 101nssss 0 15/11nnnkkk 3 3: af db
Compressed:
0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07
d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82
04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2
f0 02 21 03 a9 e6 b3 cd af db
Was 96 bytes; compressed to 58 bytes, compression factor 1.66
]]></artwork></figure>
<t><xref target="ex7"/> shows the compression of a DTLS application data packet with a
net payload of 13 bytes of cleartext, and 8 bytes of authenticator
(note that the IP header is not relevant for this example and has been
set to 0).
This makes good use of the static dictionary, and is quite effective
crunching out the redundancy in the TLS_PSK_WITH_AES_128_CCM_8
header, leading to a net reduction by 15 bytes.</t>
<figure title="A DTLS application data packet" anchor="ex7"><artwork><![CDATA[
IP header:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Payload:
17 fe fd 00 01 00 00 00 00 00 01 00 1d 00 01 00
00 00 00 00 01 09 b2 0e 82 c1 6e b6 96 c5 1f 36
8d 17 61 e2 b5 d4 22 d4 ed 2b
Dictionary:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00
-> ref 101nssss 1 0/11nnnkkk 2 1: b0 d1
copy: 01 1d
ref(10): 00 01 00 00 00 00 00 01 -> ref 11nnnkkk 6 2: f2
copy: 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2
copy: b5 d4 22 d4 ed 2b
Compressed:
b0 d1 01 1d f2 15 09 b2 0e 82 c1 6e b6 96 c5 1f
36 8d 17 61 e2 b5 d4 22 d4 ed 2b
Was 42 bytes; compressed to 27 bytes, compression factor 1.56
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
<t><xref target="ex8"/> shows that the compression is slightly worse in a subsequent
packet (containing 6 bytes of cleartext and 8 bytes of authenticator,
yielding a net compression of 13 bytes). The total overhead does stay
at a quite acceptable 8 bytes.</t>
<figure title="Another DTLS application data packet" anchor="ex8"><artwork><![CDATA[
IP header:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Payload:
17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00
00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4
cb 35 b9
Dictionary:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
ref(13): 17 fe fd 00 01 00 00 00 00 00
-> ref 101nssss 1 0/11nnnkkk 0 3: b0 c3
copy: 03 05 00 16
ref(10): 00 01 00 00 00 00 00 05 -> ref 11nnnkkk 6 2: f2
copy: 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9
Compressed:
b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff
8a 24 e4 cb 35 b9
Was 35 bytes; compressed to 22 bytes, compression factor 1.59
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
<t><xref target="ex9"/> shows the compression of a DTLS handshake message, here a
client hello. There is little that can be compressed about the 32
bytes of randomness. Still, the net reduction is by 14 bytes.</t>
<figure title="A DTLS handshake packet (client hello)" anchor="ex9"><artwork><![CDATA[
IP header:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Payload:
16 fe fd 00 00 00 00 00 00 00 00 00 36 01 00 00
2a 00 00 00 00 00 00 00 2a fe fd 51 52 ed 79 a4
20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe c6 89 2f
32 26 9a 16 4e 31 7e 9f 20 92 92 00 00 00 02 c0
a8 01 00
Dictionary:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
ref(16): 16 fe fd -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd
9 nulls: 87
copy: 01 36
ref(16): 01 00 00 -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd
copy: 01 2a
7 nulls: 85
copy: 23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9
copy: 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e
copy: 9f 20 92 92
3 nulls: 81
copy: 05 02 c0 a8 01 00
Compressed:
a1 cd 87 01 36 a1 cd 01 2a 85 23 2a fe fd 51 52
ed 79 a4 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe
c6 89 2f 32 26 9a 16 4e 31 7e 9f 20 92 92 81 05
02 c0 a8 01 00
Was 67 bytes; compressed to 53 bytes, compression factor 1.26
]]></artwork></figure>
<t><vspace blankLines='999' /></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:21:21 |