< draft-ietf-6lo-ghc-00.txt		draft-ietf-6lo-ghc-01.txt >
	6Lo Working Group C. Bormann		6Lo Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Standards Track December 18, 2013		Intended status: Standards Track June 19, 2014
	Expires: June 21, 2014		Expires: December 21, 2014
	6LoWPAN Generic Compression of Headers and Header-like Payloads		6LoWPAN Generic Compression of Headers and Header-like Payloads
	draft-ietf-6lo-ghc-00		draft-ietf-6lo-ghc-01
	Abstract		Abstract
	This short I-D provides a simple addition to 6LoWPAN Header		This short specification provides a simple addition to 6LoWPAN Header
	Compression that enables the compression of generic headers and		Compression that enables the compression of generic headers and
	header-like payloads, without a need to define a new header		header-like payloads, without a need to define a new header
	compression scheme for each new such header or header-like payload.		compression scheme for each new such header or header-like payload.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 21, 2014.		This Internet-Draft will expire on December 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. The Header Compression Coupling Problem . . . . . . . . . 2		1.1. The Header Compression Coupling Problem . . . . . . . . . 2
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		1.2. Compression Approach . . . . . . . . . . . . . . . . . . 3
	1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. 6LoWPAN-GHC . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.4. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC . . . . . . . . . . . 5		2. 6LoWPAN-GHC . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Compressing payloads (UDP and ICMPv6) . . . . . . . . . . 5		3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC . . . . . . . . . . . 6
	3.2. Compressing extension headers . . . . . . . . . . . . . . 5		3.1. Compressing payloads (UDP and ICMPv6) . . . . . . . . . . 6
	3.3. Indicating GHC capability . . . . . . . . . . . . . . . . 6		3.2. Compressing extension headers . . . . . . . . . . . . . . 6
	3.4. Using the 6CIO Option . . . . . . . . . . . . . . . . . . 7		3.3. Indicating GHC capability . . . . . . . . . . . . . . . . 7
	4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8		3.4. Using the 6CIO Option . . . . . . . . . . . . . . . . . . 8
	5. Security considerations . . . . . . . . . . . . . . . . . . . 9		4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		5. Security considerations . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	1.1. The Header Compression Coupling Problem		1.1. The Header Compression Coupling Problem
	6LoWPAN-HC [RFC6282] defines a scheme for header compression in		6LoWPAN-HC [RFC6282] defines a scheme for header compression in
	6LoWPAN [RFC4944] packets. As with most header compression schemes,		6LoWPAN [RFC4944] packets. As with most header compression schemes,
	a new specification is needed for every new kind of header that needs		a new specification is needed for every new kind of header that needs
	to be compressed. In addition, [RFC6282] does not define an		to be compressed. In addition, [RFC6282] does not define an
	extensibility scheme like the ROHC profiles defined in ROHC [RFC3095]		extensibility scheme like the ROHC profiles defined in ROHC [RFC3095]
	skipping to change at page 2, line 50 ¶		skipping to change at page 3, line 5 ¶
	The purpose of the present contribution is to plug into [RFC6282] as		The purpose of the present contribution is to plug into [RFC6282] as
	is, using its NHC (next header compression) concept. We add a		is, using its NHC (next header compression) concept. We add a
	slightly less efficient, but vastly more general form of compression		slightly less efficient, but vastly more general form of compression
	for headers of any kind and even for header-like payloads such as		for headers of any kind and even for header-like payloads such as
	those exhibited by routing protocols, DHCP, etc. The objective is an		those exhibited by routing protocols, DHCP, etc. The objective is an
	extremely simple specification that can be defined on a single page		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		and implemented in a small number of lines of code, as opposed to a
	general data compression scheme such as that defined in [RFC1951].		general data compression scheme such as that defined in [RFC1951].
	1.2. Terminology		1.2. Compression Approach
			The basic approach of GHC's compression function is to define a
			bytecode for LZ77-style compression [LZ77]. The bytecode is a series
			of simple instructions for the decompressor to reconstitute the
			uncompressed payload. These instructions include:
			o appending bytes to the reconstituted payload that are literally
			given with the instruction in the compressed data
			o appending a given number of zero bytes to the reconstituted
			payload
			o appending bytes to the reconstituted payload by copying a
			contiguous sequence from the payload being reconstituted
			("backreferencing")
			o an ancillary instruction for setting up parameters for the
			backreferencing instruction in "decompression variables"
			o a stop code (optional, see Section 3.2)
			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".
			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.
			1.3. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	The term "byte" is used in its now customary sense as a synonym for		The term "byte" is used in its now customary sense as a synonym for
	"octet".		"octet".
	1.3. Notation		1.4. Notation
	This specification uses a trivial notation for code bytes and the		This specification uses a trivial notation for code bytes and the
	bitfields in them the meaning of which should be mostly obvious.		bitfields in them the meaning of which should be mostly obvious.
	More formally speaking, the meaning of the notation is:		More formally speaking, the meaning of the notation is:
	Potential values for the code bytes themselves are expressed by		Potential values for the code bytes themselves are expressed by
	templates that represent 8-bit most-significant-bit-first binary		templates that represent 8-bit most-significant-bit-first binary
	numbers (without any special prefix), where 0 stands for 0, 1 for 1,		numbers (without any special prefix), where 0 stands for 0, 1 for 1,
	and variable segments in these code byte templates are indicated by		and variable segments in these code byte templates are indicated by
	sequences of the same letter such as kkkkkkk or ssss, the length of		sequences of the same letter such as kkkkkkk or ssss, the length of
	skipping to change at page 4, line 15 ¶		skipping to change at page 5, line 15 ¶
	2. 6LoWPAN-GHC		2. 6LoWPAN-GHC
	The format of a GHC-compressed header or payload is a simple		The format of a GHC-compressed header or payload is a simple
	bytecode. A compressed header consists of a sequence of pieces, each		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		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		more bytes as its argument. Some code bytes cause bytes to be laid
	out in the destination buffer, some simply modify some decompression		out in the destination buffer, some simply modify some decompression
	variables.		variables.
	At the start of decompressing a header or payload within a L2 packet		At the start of decompressing a header or payload within a L2 packet
	(= fragment), variables "sa" and "na" are initialized as zero.		(= fragment), the decompression variables "sa" and "na" are
			initialized as zero.
	The code bytes are defined as follows (Table 1):		The code bytes are defined as follows (Table 1):
	+------------+------------------------------------------+-----------+		+----------+---------------------------------------------+----------+
	| code byte | Action | Argument |		| code | Action | Argument |
	+------------+------------------------------------------+-----------+		| byte | | |
	| 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in | k bytes |		+----------+---------------------------------------------+----------+
	| | the bytecode argument (k < 96) | of data |		| 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in the | k bytes |
	| | | |		| | bytecode argument (k < 96) | of data |
	| 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | |		| | | |
	| | | |		| 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | |
	| 10010000 | STOP code (end of compressed data, see | |		| | | |
	| | Section 3.2) | |		| 10010000 | STOP code (end of compressed data, see | |
	| | | |		| | Section 3.2) | |
	| 101nssss | Set up extended arguments for a | |		| | | |
	| | backreference: sa += 0b0ssss000, na += | |		| 101nssss | Set up extended arguments for a | |
	| | 0b0000n000 | |		| | backreference: sa += 0b0ssss000, na += | |
	| | | |		| | 0b0000n000 | |
	| 11nnnkkk | Backreference: n = na+0b00000nnn+2; s = | |		| | | |
	| | 0b00000kkk+sa+n; append n bytes from | |		| 11nnnkkk | Backreference: n = na+0b00000nnn+2; s = | |
	| | previously output bytes, starting s | |		| | 0b00000kkk+sa+n; append n bytes from | |
	| | bytes to the left of the current output | |		| | previously output bytes, starting s bytes | |
	| | pointer; set sa = 0, na = 0 | |		| | to the left of the current output pointer; | |
	+------------+------------------------------------------+-----------+		| | set sa = 0, na = 0 | |
			+----------+---------------------------------------------+----------+
	Table 1: Bytecodes for generic header compression		Table 1: Bytecodes for generic header compression
	Note that the following bit combinations are reserved at this time:		Note that the following bit combinations are reserved at this time:
	011xxxxx, and 1001nnnn (where 0b0000nnnn > 0).		011xxxxx, and 1001nnnn (where 0b0000nnnn > 0).
	For the purposes of the backreferences, the expansion buffer is		For the purposes of the backreferences, the expansion buffer is
	initialized with a predefined dictionary, at the end of which the		initialized with a predefined dictionary, at the end of which the
	target buffer begins. This dictionary is composed of the pseudo-		reconstituted payload begins. This dictionary is composed of the
	header for the current packet as defined in [RFC2460], followed by a		source and destination IPv6 addresses of the packet being
	16-byte static dictionary (Figure 1). These dictionary bytes are		reconstituted, followed by a 16-byte static dictionary (Figure 1).
	therefore available for backreferencing, but not copied into the
	final result.		These 48 dictionary bytes are therefore available for
			backreferencing, but not copied into the final reconstituted payload.
	16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	Figure 1: The 16 bytes of static dictionary (in hex)		Figure 1: The 16 bytes of static dictionary (in hex)
	3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC		3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC
	6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC [RFC6282].		6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC [RFC6282].
	3.1. Compressing payloads (UDP and ICMPv6)		3.1. Compressing payloads (UDP and ICMPv6)
	skipping to change at page 5, line 28 ¶		skipping to change at page 6, line 31 ¶
	ICMPv6 based on GHC (see below).		ICMPv6 based on GHC (see below).
	In addition it is useful to include an NHC format for UDP, as many		In addition it is useful to include an NHC format for UDP, as many
	headerlike payloads (e.g., DHCPv6, DTLS) are carried in UDP.		headerlike payloads (e.g., DHCPv6, DTLS) are carried in UDP.
	[RFC6282] already defines an NHC format for UDP (11110CPP). GHC uses		[RFC6282] already defines an NHC format for UDP (11110CPP). GHC uses
	an analogous NHC byte formatted as shown in Figure 2. The difference		an analogous NHC byte formatted as shown in Figure 2. The difference
	to the existing UDP NHC specification is that for 0b11010cpp NHC		to the existing UDP NHC specification is that for 0b11010cpp NHC
	bytes, the UDP payload is not supplied literally but compressed by		bytes, the UDP payload is not supplied literally but compressed by
	6LoWPAN-GHC.		6LoWPAN-GHC.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 1 | 1 | 0 | 1 | 0 | C | P |		| 1 | 1 | 0 | 1 | 0 | C | P |
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	Figure 2: NHC byte for UDP GHC (to be allocated by IANA)		Figure 2: NHC byte for UDP GHC (to be allocated by IANA)
	To stay in the same general numbering space, we use 0b11011111 as the		To stay in the same general numbering space, we use 0b11011111 as the
	NHC byte for ICMPv6 GHC (Figure 3).		NHC byte for ICMPv6 GHC (Figure 3).
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |		| 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	Figure 3: NHC byte for ICMPv6 GHC (to be allocated by IANA)		Figure 3: NHC byte for ICMPv6 GHC (to be allocated by IANA)
	3.2. Compressing extension headers		3.2. Compressing extension headers
	Compression of specific extension headers is added in a similar way		Compression of specific extension headers is added in a similar way
	(Figure 4) (however, probably only EID 0 to 3 need to be assigned).		(Figure 4) (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-		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		encoded header before decoding, this would make detecting the end of
	the extension header somewhat complex. The easiest (and most		the extension header somewhat complex. The easiest (and most
	efficient) approach is to completely elide the length field (in the		efficient) approach is to completely elide the length field (in the
	same way NHC already elides the next header field in certain cases)		same way NHC already elides the next header field in certain cases)
	and reconstruct it only on decompression. To serve as a terminator		and reconstruct it only on decompression. To serve as a terminator
	for the extension header, the reserved bytecode 0b10010000 has been		for the extension header, the reserved bytecode 0b10010000 has been
	assigned as a stop marker. Note that the stop marker is only needed		assigned as a stop marker. Note that the stop marker is only needed
	for extension headers, not for the final payloads discussed in the		for extension headers, not for the final payloads discussed in the
	previous subsection, the decompression of which is automatically		previous subsection, the decompression of which is automatically
	stopped by the end of the packet.		stopped by the end of the packet.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 1 | 0 | 1 | 1 | EID |NH |		| 1 | 0 | 1 | 1 | EID |NH |
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	Figure 4: NHC byte for extension header GHC		Figure 4: NHC byte for extension header GHC
	3.3. Indicating GHC capability		3.3. Indicating GHC capability
	The 6LoWPAN baseline includes just [RFC4944], [RFC6282], [RFC6775]		The 6LoWPAN baseline includes just [RFC4944], [RFC6282], [RFC6775]
	(see [I-D.bormann-6lowpan-roadmap]). To enable the use of GHC		(see [I-D.bormann-6lowpan-roadmap]). To enable the use of GHC
	towards a neighbor, a 6LoWPAN node needs to know that the neighbor		towards a neighbor, a 6LoWPAN node needs to know that the neighbor
	implements it. While this can also simply be administratively		implements it. While this can also simply be administratively
	required, a transition strategy as well as a way to support mixed		required, a transition strategy as well as a way to support mixed
	skipping to change at page 8, line 17 ¶		skipping to change at page 9, line 22 ¶
	there no longer is a need to continue sending it.		there no longer is a need to continue sending it.
	4. IANA considerations		4. IANA considerations
	[This section to be removed/replaced by the RFC Editor.]		[This section to be removed/replaced by the RFC Editor.]
	In the IANA registry for the "LOWPAN_NHC Header Type" (in the "IPv6		In the IANA registry for the "LOWPAN_NHC Header Type" (in the "IPv6
	Low Power Personal Area Network Parameters"), IANA needs to add the		Low Power Personal Area Network Parameters"), IANA needs to add the
	assignments in Figure 6.		assignments in Figure 6.
	10110IIN: Extension header GHC [RFCthis]		10110IIN: Extension header GHC [RFCthis]
	11010CPP: UDP GHC [RFCthis]		11010CPP: UDP GHC [RFCthis]
	11011111: ICMPv6 GHC [RFCthis]		11011111: ICMPv6 GHC [RFCthis]
	Figure 6: IANA assignments for the NHC byte		Figure 6: IANA assignments for the NHC byte
	IANA needs to allocate an ND option number for the 6CIO ND option		IANA needs to allocate an ND option number for the 6CIO ND option
	format in the Registry "IPv6 Neighbor Discovery Option Formats"		format in the Registry "IPv6 Neighbor Discovery Option Formats"
	[RFC4861].		[RFC4861].
	IANA needs to create a registry for "6LoWPAN capability bits" within		IANA needs to create a registry for "6LoWPAN capability bits" within
	the "Internet Control Message Protocol version 6 (ICMPv6)		the "Internet Control Message Protocol version 6 (ICMPv6)
	Parameters". The bits are assigned by giving their numbers as small		Parameters". The bits are assigned by giving their numbers as small
	non-negative integers as defined in section Section 3.4, preferably		non-negative integers as defined in section Section 3.4, preferably
	in the range 0..47. The policy is "RFC Required" [RFC5226]. The		in the range 0..47. The policy is "RFC Required" [RFC5226]. The
	initial content of the registry is as in Figure 7:		initial content of the registry is as in Figure 7:
	0..14: unassigned		0..14: unassigned
	15: GHC capable bit (G bit) [RFCthis]		15: GHC capable bit (G bit) [RFCthis]
	16..47: unassigned		16..47: unassigned
	Figure 7: IANA assignments for the 6LoWPAN capability bits		Figure 7: IANA assignments for the 6LoWPAN capability bits
	5. Security considerations		5. Security considerations
	The security considerations of [RFC4944] and [RFC6282] apply. As		The security considerations of [RFC4944] and [RFC6282] apply. As
	usual in protocols with packet parsing/construction, care must be		usual in protocols with packet parsing/construction, care must be
	taken in implementations to avoid buffer overflows and in particular		taken in implementations to avoid buffer overflows and in particular
	(with respect to the back-referencing) out-of-area references during		(with respect to the back-referencing) out-of-area references during
	decompression.		decompression.
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 47 ¶
	general. Special thanks go to Colin for indicating that he indeed		general. Special thanks go to Colin for indicating that he indeed
	considers his draft superseded by the present one.		considers his draft superseded by the present one.
	The examples given are based on pcap files that Colin O'Flynn, Owen		The examples given are based on pcap files that Colin O'Flynn, Owen
	Kirby, Olaf Bergmann and others provided.		Kirby, Olaf Bergmann and others provided.
	The static dictionary was developed, and the bit allocations		The static dictionary was developed, and the bit allocations
	validated, based on research by Sebastian Dominik.		validated, based on research by Sebastian Dominik.
	Erik Nordmark provided input that helped shaping the 6CIO option.		Erik Nordmark provided input that helped shaping the 6CIO option.
			Thomas Bjorklund proposed simplifying the predefined dictionary.
	Yoshihiro Ohba insisted on clarifying the notation used for the		Yoshihiro Ohba insisted on clarifying the notation used for the
	definition of the bytecodes and their bitfields.		definition of the bytecodes and their bitfields. Ulrich Herberg
			provided some additional review and suggested expanding the
			introductory material.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, September 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	skipping to change at page 10, line 48 ¶		skipping to change at page 11, line 45 ¶
	[I-D.bormann-6lowpan-roadmap]		[I-D.bormann-6lowpan-roadmap]
	Bormann, C., "6LoWPAN Roadmap and Implementation Guide",		Bormann, C., "6LoWPAN Roadmap and Implementation Guide",
	draft-bormann-6lowpan-roadmap-04 (work in progress), April		draft-bormann-6lowpan-roadmap-04 (work in progress), April
	2013.		2013.
	[I-D.oflynn-6lowpan-icmphc]		[I-D.oflynn-6lowpan-icmphc]
	O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks",		O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks",
	draft-oflynn-6lowpan-icmphc-00 (work in progress), July		draft-oflynn-6lowpan-icmphc-00 (work in progress), July
	2010.		2010.
			[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for
			Sequential Data Compression", IEEE Transactions on
			Information Theory, Vol. 23, No. 3, pp. 337-343, May 1977.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
	[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,		[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
	Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,		Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
	K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,		K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
	Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header		Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
	Compression (ROHC): Framework and four profiles: RTP, UDP,		Compression (ROHC): Framework and four profiles: RTP, UDP,
	ESP, and uncompressed", RFC 3095, July 2001.		ESP, and uncompressed", RFC 3095, July 2001.
	skipping to change at page 11, line 33 ¶		skipping to change at page 12, line 36 ¶
	IP header:		IP header:
	60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00		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		02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00
	00 00 00 00 00 00 00 1a		00 00 00 00 00 00 00 1a
	Payload:		Payload:
	9b 00 6b de 00 00 00 00		9b 00 6b de 00 00 00 00
	Dictionary:		Dictionary:
	fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24		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		ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a
	00 00 00 08 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 04 9b 00 6b de		copy: 04 9b 00 6b de
	4 nulls: 82		4 nulls: 82
	Compressed:		Compressed:
	04 9b 00 6b de 82		04 9b 00 6b de 82
	Was 8 bytes; compressed to 6 bytes, compression factor 1.33		Was 8 bytes; compressed to 6 bytes, compression factor 1.33
	Figure 8: A simple RPL example		Figure 8: A simple RPL example
	Figure 9 shows an RPL DODAG Information Object, a longer RPL control		Figure 9 shows an RPL DODAG Information Object, a longer RPL control
	message that is improved a bit more. Note that the compressed output		message that is improved a bit more. Note that the compressed output
	skipping to change at page 12, line 19 ¶		skipping to change at page 13, line 19 ¶
	Payload:		Payload:
	9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8		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		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		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		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		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		ff ff ff ff 20 02 0d b8 00 00 00 00
	Dictionary:		Dictionary:
	fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23		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		ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a
	00 00 00 5c 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 06 9b 01 7a 5f 00 f0		copy: 06 9b 01 7a 5f 00 f0
	ref(9): 01 00 -> ref 11nnnkkk 0 7: c7		ref(9): 01 00 -> ref 11nnnkkk 0 7: c7
	copy: 01 88		copy: 01 88
	3 nulls: 81		3 nulls: 81
	copy: 04 20 02 0d b8		copy: 04 20 02 0d b8
	7 nulls: 85		7 nulls: 85
	ref(68): ff fe 00 -> ref 101nssss 0 8/11nnnkkk 1 1: a8 c9		ref(60): ff fe 00 -> ref 101nssss 0 7/11nnnkkk 1 1: a7 c9
	copy: 08 fa ce 04 0e 00 14 09 ff		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		ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/11nnnkkk 3 2: a4 da
	5 nulls: 83		5 nulls: 83
	copy: 06 08 1e 80 20 ff ff		copy: 06 08 1e 80 20 ff ff
	ref(2): ff ff -> ref 11nnnkkk 0 0: c0		ref(2): ff ff -> ref 11nnnkkk 0 0: c0
	ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0		ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
	4 nulls: 82		4 nulls: 82
	ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce		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		-> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0
	copy: 03 03 0e 40		copy: 03 03 0e 40
	ref(9): 00 ff -> ref 11nnnkkk 0 7: c7		ref(9): 00 ff -> ref 11nnnkkk 0 7: c7
	ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9		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(24): 20 02 0d b8 00 00 00 00
	-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0		-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
	Compressed:		Compressed:
	06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8		06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8
	85 a8 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06		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		08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 c7
	a3 c9 a2 f0		a3 c9 a2 f0
	Was 92 bytes; compressed to 52 bytes, compression factor 1.77		Was 92 bytes; compressed to 52 bytes, compression factor 1.77
	Figure 9: A longer RPL example		Figure 9: A longer RPL example
	Similarly, Figure 10 shows an RPL DAO message. One of the embedded		Similarly, Figure 10 shows an RPL DAO message. One of the embedded
	addresses is copied right out of the pseudo-header, the other one is		addresses is copied right out of the pseudo-header, the other one is
	effectively converted from global to local by providing the prefix		effectively converted from global to local by providing the prefix
	FE80 literally, inserting a number of nulls, and copying (some of)		FE80 literally, inserting a number of nulls, and copying (some of)
	skipping to change at page 13, line 26 ¶		skipping to change at page 14, line 26 ¶
	00 00 00 ff fe 00 33 44 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		00 00 00 ff fe 00 11 22
	Payload:		Payload:
	9b 02 58 7d 01 80 00 f1 05 12 00 80 20 02 0d b8		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		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		f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00
	11 22		11 22
	Dictionary:		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 33 44
	20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22		20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22
	00 00 00 32 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80		copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80
	ref(68): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44		ref(60): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44
	-> ref 101nssss 1 6/11nnnkkk 6 4: b6 f4		-> ref 101nssss 1 5/11nnnkkk 6 4: b5 f4
	copy: 08 06 14 00 80 f1 00 fe 80		copy: 08 06 14 00 80 f1 00 fe 80
	9 nulls: 87		9 nulls: 87
	ref(74): ff fe 00 11 22 -> ref 101nssss 0 8/11nnnkkk 3 5: a8 dd		ref(66): ff fe 00 11 22 -> ref 101nssss 0 7/11nnnkkk 3 5: a7 dd
	Compressed:		Compressed:
	0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b6 f4 08		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 a8 dd		06 14 00 80 f1 00 fe 80 87 a7 dd
	Was 50 bytes; compressed to 27 bytes, compression factor 1.85		Was 50 bytes; compressed to 27 bytes, compression factor 1.85
	Figure 10: An RPL DAO message		Figure 10: An RPL DAO message
	Figure 11 shows the effect of compressing a simple ND neighbor		Figure 11 shows the effect of compressing a simple ND neighbor
	solicitation.		solicitation.
	IP header:		IP header:
	60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00		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		00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00
	02 1c da ff fe 00 30 23		02 1c da ff fe 00 30 23
	Payload:		Payload:
	87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00		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		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		1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24
	Dictionary:		Dictionary:
	20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3		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		fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
	00 00 00 30 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 04 87 00 a7 68		copy: 04 87 00 a7 68
	4 nulls: 82		4 nulls: 82
	ref(48): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23		ref(40): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
	-> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0		-> ref 101nssss 1 3/11nnnkkk 6 0: b3 f0
	copy: 04 01 01 3b d3		copy: 04 01 01 3b d3
	4 nulls: 82		4 nulls: 82
	copy: 02 1f 02		copy: 02 1f 02
	5 nulls: 83		5 nulls: 83
	copy: 02 06 00		copy: 02 06 00
	ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db		ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db
	copy: 02 20 24		copy: 02 20 24
	Compressed:		Compressed:
	04 87 00 a7 68 82 b4 f0 04 01 01 3b d3 82 02 1f		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		02 83 02 06 00 a2 db 02 20 24
	Was 48 bytes; compressed to 26 bytes, compression factor 1.85		Was 48 bytes; compressed to 26 bytes, compression factor 1.85
	Figure 11: An ND neighbor solicitation		Figure 11: An ND neighbor solicitation
	Figure 12 shows the compression of an ND neighbor advertisement.		Figure 12 shows the compression of an ND neighbor advertisement.
	IP header:		IP header:
	60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00		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		02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00
	00 00 00 ff fe 00 3b d3		00 00 00 ff fe 00 3b d3
	Payload:		Payload:
	88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00		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		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		1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24
	Dictionary:		Dictionary:
	fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23		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		20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3
	00 00 00 30 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 05 88 00 26 6c c0		copy: 05 88 00 26 6c c0
	3 nulls: 81		3 nulls: 81
	ref(64): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23		ref(56): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
	-> ref 101nssss 1 6/11nnnkkk 6 0: b6 f0		-> ref 101nssss 1 5/11nnnkkk 6 0: b5 f0
	copy: 04 02 01 fa ce		copy: 04 02 01 fa ce
	4 nulls: 82		4 nulls: 82
	copy: 02 1f 02		copy: 02 1f 02
	5 nulls: 83		5 nulls: 83
	copy: 02 06 00		copy: 02 06 00
	ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db		ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db
	copy: 02 20 24		copy: 02 20 24
	Compressed:		Compressed:
	05 88 00 26 6c c0 81 b6 f0 04 02 01 fa ce 82 02		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		1f 02 83 02 06 00 a2 db 02 20 24
	Was 48 bytes; compressed to 27 bytes, compression factor 1.78		Was 48 bytes; compressed to 27 bytes, compression factor 1.78
	Figure 12: An ND neighbor advertisement		Figure 12: An ND neighbor advertisement
	Figure 13 shows the compression of an ND router solicitation. Note		Figure 13 shows the compression of an ND router solicitation. Note
	that the relatively good compression is not caused by the many zero		that the relatively good compression is not caused by the many zero
	bytes in the link-layer address of this particular capture (which are		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		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/		the pseudo-header (the 8th byte cannot be copied as the universal/
	skipping to change at page 16, line 22 ¶		skipping to change at page 17, line 22 ¶
	IP header:		IP header:
	60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00		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		ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00
	00 00 00 00 00 00 00 02		00 00 00 00 00 00 00 02
	Payload:		Payload:
	85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00		85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00
	00 01 00 00 00 00 00 00		00 01 00 00 00 00 00 00
	Dictionary:		Dictionary:
	fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01		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		ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02
	00 00 00 18 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 04 85 00 90 65		copy: 04 85 00 90 65
	ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de		ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de
	copy: 02 02 ac		copy: 02 02 ac
	ref(58): de 48 00 00 00 00 01		ref(50): de 48 00 00 00 00 01
	-> ref 101nssss 0 6/11nnnkkk 5 3: a6 eb		-> ref 101nssss 0 5/11nnnkkk 5 3: a5 eb
	6 nulls: 84		6 nulls: 84
	Compressed:		Compressed:
	04 85 00 90 65 de 02 02 ac a6 eb 84		04 85 00 90 65 de 02 02 ac a5 eb 84
	Was 24 bytes; compressed to 12 bytes, compression factor 2.00		Was 24 bytes; compressed to 12 bytes, compression factor 2.00
	Figure 13: An ND router solicitation		Figure 13: An ND router solicitation
	Figure 14 shows the compression of an ND router advertisement. The		Figure 14 shows the compression of an ND router advertisement. The
	indefinite lifetime is compressed to four bytes by backreferencing;		indefinite lifetime is compressed to four bytes by backreferencing;
	this could be improved (at the cost of minor additional decompressor		this could be improved (at the cost of minor additional decompressor
	complexity) by including some simple runlength mechanism.		complexity) by including some simple runlength mechanism.
	IP header:		IP header:
	skipping to change at page 17, line 19 ¶		skipping to change at page 18, line 19 ¶
	Payload:		Payload:
	86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0		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		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		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		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 21 03 00 01 00 00 00 00
	20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22		20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22
	Dictionary:		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 10 34 00 ff fe 00 11 22
	fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01		fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01
	00 00 00 60 00 00 00 3a 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17		copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17
	2 nulls: 80		2 nulls: 80
	copy: 06 07 d0 01 01 11 22		copy: 06 07 d0 01 01 11 22
	4 nulls: 82		4 nulls: 82
	copy: 06 03 04 40 40 ff ff		copy: 06 03 04 40 40 ff ff
	ref(2): ff ff -> ref 11nnnkkk 0 0: c0		ref(2): ff ff -> ref 11nnnkkk 0 0: c0
	ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0		ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
	4 nulls: 82		4 nulls: 82
	copy: 04 20 02 0d b8		copy: 04 20 02 0d b8
	12 nulls: 8a		12 nulls: 8a
	copy: 04 20 02 40 10		copy: 04 20 02 40 10
	ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb		ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb
	copy: 01 e8		copy: 01 e8
	ref(24): 20 02 0d b8 00 00 00 00		ref(24): 20 02 0d b8 00 00 00 00
	-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0		-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
	copy: 02 21 03		copy: 02 21 03
	ref(84): 00 01 00 00 00 00		ref(84): 00 01 00 00 00 00
	-> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6		-> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6
	ref(40): 20 02 0d b8 00 00 00 00 00 00 00		ref(40): 20 02 0d b8 00 00 00 00 00 00 00
	-> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd		-> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd
	ref(136): ff fe 00 11 22		ref(128): ff fe 00 11 22
	-> ref 101nssss 0 15/101nssss 0 1/11nnnkkk 3 3: af a1 db		-> ref 101nssss 0 15/11nnnkkk 3 3: af db
	Compressed:		Compressed:
	0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07		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		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		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 a1 db		f0 02 21 03 a9 e6 b3 cd af db
	Was 96 bytes; compressed to 59 bytes, compression factor 1.63		Was 96 bytes; compressed to 58 bytes, compression factor 1.66
	Figure 14: An ND router advertisement		Figure 14: An ND router advertisement
	Figure 15 shows the compression of a DTLS application data packet		Figure 15 shows the compression of a DTLS application data packet
	with a net payload of 13 bytes of cleartext, and 8 bytes of		with a net payload of 13 bytes of cleartext, and 8 bytes of
	authenticator (note that the IP header is not relevant for this		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		example and has been set to 0). This makes good use of the static
	dictionary, and is quite effective crunching out the redundancy in		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		the TLS_PSK_WITH_AES_128_CCM_8 header, leading to a net reduction by
	15 bytes.		15 bytes.
	skipping to change at page 18, line 24 ¶		skipping to change at page 19, line 21 ¶
	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 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:		Payload:
	17 fe fd 00 01 00 00 00 00 00 01 00 1d 00 01 00		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		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		8d 17 61 e2 b5 d4 22 d4 ed 2b
	Dictionary:		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
	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 2a 00 00 00 00 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00		ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00
	-> ref 101nssss 1 0/11nnnkkk 2 1: b0 d1		-> ref 101nssss 1 0/11nnnkkk 2 1: b0 d1
	copy: 01 1d		copy: 01 1d
	ref(10): 00 01 00 00 00 00 00 01 -> ref 11nnnkkk 6 2: f2		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: 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2
	copy: b5 d4 22 d4 ed 2b		copy: b5 d4 22 d4 ed 2b
	Compressed:		Compressed:
	b0 d1 01 1d f2 15 09 b2 0e 82 c1 6e b6 96 c5 1f		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		36 8d 17 61 e2 b5 d4 22 d4 ed 2b
	Was 42 bytes; compressed to 27 bytes, compression factor 1.56		Was 42 bytes; compressed to 27 bytes, compression factor 1.56
	skipping to change at page 19, line 21 ¶		skipping to change at page 20, line 21 ¶
	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 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:		Payload:
	17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00		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		00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4
	cb 35 b9		cb 35 b9
	Dictionary:		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
	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 23 00 00 00 00 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	ref(13): 17 fe fd 00 01 00 00 00 00 00		ref(13): 17 fe fd 00 01 00 00 00 00 00
	-> ref 101nssss 1 0/11nnnkkk 0 3: b0 c3		-> ref 101nssss 1 0/11nnnkkk 0 3: b0 c3
	copy: 03 05 00 16		copy: 03 05 00 16
	ref(10): 00 01 00 00 00 00 00 05 -> ref 11nnnkkk 6 2: f2		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		copy: 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9
	Compressed:		Compressed:
	b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff		b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff
	8a 24 e4 cb 35 b9		8a 24 e4 cb 35 b9
	Was 35 bytes; compressed to 22 bytes, compression factor 1.59		Was 35 bytes; compressed to 22 bytes, compression factor 1.59
	skipping to change at page 20, line 22 ¶		skipping to change at page 21, line 22 ¶
	00 00 00 00 00 00 00 00		00 00 00 00 00 00 00 00
	Payload:		Payload:
	16 fe fd 00 00 00 00 00 00 00 00 00 36 01 00 00		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		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		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		32 26 9a 16 4e 31 7e 9f 20 92 92 00 00 00 02 c0
	a8 01 00		a8 01 00
	Dictionary:		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
	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 43 00 00 00 00 16 fe fd 17 fe fd 00 01		16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
	00 00 00 00 00 01 00 00
	ref(16): 16 fe fd -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd		ref(16): 16 fe fd -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd
	9 nulls: 87		9 nulls: 87
	copy: 01 36		copy: 01 36
	ref(16): 01 00 00 -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd		ref(16): 01 00 00 -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd
	copy: 01 2a		copy: 01 2a
	7 nulls: 85		7 nulls: 85
	copy: 23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9		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: 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e
	copy: 9f 20 92 92		copy: 9f 20 92 92
	3 nulls: 81		3 nulls: 81
End of changes. 43 change blocks.
	113 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/