One document matched: draft-ietf-6lo-ghc-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC6282 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC4944 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6775 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC4861 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC5226 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC3095 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3095.xml">
<!ENTITY RFC5795 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5795.xml">
<!ENTITY RFC1951 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1951.xml">
<!ENTITY RFC7228 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY I-D.bormann-6lo-6lowpan-roadmap SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.bormann-6lo-6lowpan-roadmap.xml">
<!ENTITY RFC4821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY I-D.oflynn-6lowpan-icmphc SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.oflynn-6lowpan-icmphc.xml">
]>
<rfc ipr="trust200902" docName="draft-ietf-6lo-ghc-05" 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 (GHC)</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="19"/>
<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.:
Generic Header Compression (GHC).
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>Terms from <xref target="RFC7228"/> are used in <xref target="security"/>.</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"/>. (For the fields marked by an underscore in
<xref target="figure-6ci"/>, see <xref target="bitnumbers"/>.)</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:
the 16th bit is flag number 0, the 31st bit (the G bit) is flag number
15, up to the 63rd bit for flag number 47.
(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" 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" 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>
<t>As with any LZ77 scheme, decompression bombs (compressed packets
crafted to expand so much that the decompressor is overloaded) are a
problem. An attacker cannot send a GHC decompressor into a tight loop
for too long, because the MTU will be reached quickly. Some
amplification of an attack from inside the compressed link is
possible, though. Using a constrained node in a constrained network
as a DoS attack source is usually not very useful, though, except
maybe against other nodes in that constrained network.
The worst case for an attack to the outside is a not-so-constrained
device using a (typically not-so-constrained) edge router to attack by
forwarding out of its Ethernet interface. The worst-case
amplification of GHC is 17, so an MTU-size packet can be generated
from a 6LoWPAN packet of 76 bytes. The 6LoWPAN network is still
constrained, so the amplification at the edge router turns an entire
250 kbit/s 802.15.4 network (assuming a theoretical upper bound of 225
kbit/s throughput to a single-hop adjacent node) into a 3.8 Mbit/s
attacker. <!-- The edge router may be a more useful target as it gets the -->
<!-- full bandwidth of the Ethernet interface. --></t>
<t>The amplification may be more important inside the 6LoWPAN, if there
is a way to obtain reflection (otherwise the packet is likely to
simply stay compressed on the way and do little damage), e.g., by
pinging a node using a decompression bomb, somehow keeping that node
from re-compressing the ping response (which would probably require
something more complex than simple runs of zeroes, so the worst-case
amplification is likely closer to 9). Or, if there are nodes that do
not support GHC, those can be attacked via a router that is then
forced to decompress.</t>
<t>All these attacks are mitigated by some form of network access
control.</t>
<t>In a 6LoWPAN stack, sensitive information will normally be protected
by transport or application (or even IP) layer security, which are all
above the adaptation layer, leaving no sensitive information to compress at the GHC level.
However, a 6LoWPAN deployment that entirely depends on MAC layer
security may be vulnerable to attacks that exploit redundancy
information disclosed by compression to recover information about
secret values.
The attacker would need to be in radio range to observe the compressed
packets.
Since compression is stateless, the attacker would need to entice the
party sending the secret value to also send some value controlled (or
at least usefully varying and knowable) by the attacker in (what
becomes the first adaptation layer fragment of) the same packet.
This attack is fully mitigated by not exposing secret values to the
adaptation layer, or by not using GHC in deployments where this is
done.</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>Using these pcap files as a corpus, 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>The IESG reviewers Richard Barnes and Stephen Farrell have contributed
issues to the security considerations section; they and Barry Leiba,
as well as GEN-ART reviewer Vijay K. Gurbani also have provided
editorial improvements.</t>
<t><vspace blankLines='999' /></t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC6282;
&RFC4944;
&RFC2119;
&RFC6775;
&RFC4861;
&RFC5226;
</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>
&RFC3095;
&RFC5795;
&RFC1951;
&RFC7228;
&I-D.bormann-6lo-6lowpan-roadmap;
&RFC4821;
&I-D.oflynn-6lowpan-icmphc;
</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:22:59 |