draft-ietf-6lowpan-hc-05.txt   draft-ietf-6lowpan-hc-06.txt 
Network Working Group J. Hui, Ed. Network Working Group J. Hui, Ed.
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Updates: 4944 (if approved) P. Thubert Updates: 4944 (if approved) P. Thubert
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 1, 2010 June 30, 2009 Expires: April 8, 2010 October 5, 2009
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-05 draft-ietf-6lowpan-hc-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 1, 2010. This Internet-Draft will expire on April 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies an IPv6 header compression format for IPv6 This document specifies an IPv6 header compression format for IPv6
packet delivery in 6LoWPAN networks. The compression format relies packet delivery in 6LoWPAN networks. The compression format relies
on shared context to allow compression of arbitrary prefixes. The on shared context to allow compression of arbitrary prefixes. How
information that is maintained in that shared context is out of the information is maintained in that shared context is out of scope.
scope. This document specifies compression of multicast addresses This document specifies compression of multicast addresses and a
and a framework for compressing next headers. This framework framework for compressing next headers. This framework specifies UDP
specifies UDP compression and is prepared for additional transports. compression.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 2. Specific Updates to RFC 4944 . . . . . . . . . . . . . . . . . 4
2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 3. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 5
2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5
2.1.2. Context Identifier Extension . . . . . . . . . . . . . 8 3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 8
2.2.1. Traffic Class and Flow Label Compression . . . . . . . 8 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9
2.2.2. Stateless Multicast Addresses Compression . . . . . . 10 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 9
2.2.3. Stateful Multicast Addresses Compression . . . . . . . 11 3.2.2. Stateless Multicast Addresses Compression . . . . . . 10
3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 3.2.3. Stateful Multicast Addresses Compression . . . . . . . 11
3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 12
3.2. IPv6 Extension Header Compression . . . . . . . . . . . . 12 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12
3.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 14 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 12
3.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 14 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 14
3.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 14 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 14
3.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 15 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding
about 80 octets of actual MAC payload once security is turned on, on about 80 octets of actual MAC payload with security enabled, on a
a wireless link with a link throughput of 250 kbps or less. The wireless link with a link throughput of 250 kbps or less. The
6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6
datagrams over such constrained links, taking into account limited datagrams over such constrained links, taking into account limited
bandwidth, memory, or energy resources that are expected in bandwidth, memory, or energy resources that are expected in
applications such as wireless Sensor Networks. [RFC4944] defines a applications such as wireless sensor networks. [RFC4944] defines a
Mesh Addressing header to support sub-IP forwarding, a Fragmentation Mesh Addressing header to support sub-IP forwarding, a Fragmentation
header to support the IPv6 minimum MTU requirement [RFC2460], and header to support the IPv6 minimum MTU requirement [RFC2460], and
stateless header compression for IPv6 datagrams (LOWPAN_HC1 and stateless header compression for IPv6 datagrams (LOWPAN_HC1 and
LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down
to (in the best case) several bytes. to (in the best case) several bytes.
LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of
6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local
unicast communication, where IPv6 addresses carry the link-local unicast communication, where IPv6 addresses carry the link-local
prefix and an Interface Identifier (IID) directly derived from IEEE prefix and an Interface Identifier (IID) directly derived from IEEE
802.15.4 addresses. In this case, both addresses may be completely 802.15.4 addresses. In this case, both addresses may be completely
elided. However, though link local addresses are commonly used for elided. However, though link-local addresses are commonly used for
local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6
[RFC3315] or routing protocols, they are usually not used for [RFC3315] or routing protocols, they are usually not used for
application layer data traffic, so the actual value of this application-layer data traffic, so the actual value of this
compression mechanism is limited. compression mechanism is limited.
Routable addresses must be used when communicating with devices Routable addresses must be used when communicating with devices
external to the LoWPAN or in a route-over configuration where IP external to the LoWPAN or in a route-over configuration where IP
forwarding occurs within the LoWPAN. For routable addresses, forwarding occurs within the LoWPAN. For routable addresses,
LOWPAN_HC1 requires both IPv6 source and destination addresses to LOWPAN_HC1 requires both IPv6 source and destination addresses to
carry the prefix in-line. In cases where the Mesh Addressing header carry the prefix in-line. In cases where the Mesh Addressing header
is not used, the IID of a routable address must be carried in-line. is not used, the IID of a routable address must be carried in-line.
However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line
and cannot be shortened even when it is derived from the IEEE and cannot be shortened even when it is derived from the IEEE
802.15.4 16-bit short address. 802.15.4 16-bit short address. When the destination is an IPv6
multicast address, LOWPAN_HC1 requires the full 128-bit address to be
carried in-line.
When the destination is an IPv6 multicast address, LOWPAN_HC1 As a result, this document defines an encoding format, LOWPAN_IPHC,
requires the full 128-bit address to be carried in-line. This for effective compression of Unique Local, Global, and multicast IPv6
specification provides an additional mechanism to compress Unique Addresses based on shared state within contexts. In addition, this
Local, Global and multicast IPv6 Addresses based on shared states document also introduces a number of additional improvements over the
within contexts. It also introduces a number of additional header compression format defined in [RFC4944].
improvements over [RFC4944].
LOWPAN_HC1 cannot elide the IPv6 Hop Limit in the IPv6 header, even LOWPAN_IPHC allows for compression of some commonly-used IPv6 Hop
though a limited set of values are useful in many practical cases. Limit values. If the LoWPAN is a mesh-under stub, a Hop Limit of 1
For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1
for inbound and a default value such as 64 for outbound are usually for inbound and a default value such as 64 for outbound are usually
enough for application layer data traffic. Compressing that field enough for application layer data traffic. Additionally, a hop-limit
enables saving one octet per packet. value of 255 is often used for verify that a communication occurs
over a single-hop. This specification enables to compress the IPv6
Hop Limit field in those common cases, whereas LOWPAN_HC1 does not.
LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support This document also defines LOWPAN_NHC, an encoding format for
compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed arbitrary next headers. LOWPAN_IPHC indicates whether the following
right after the LOWPAN_HC1 octet and before the uncompressed IP header is encoded using LOWPAN_NHC. If so, the bits immediately
fields. This specification moves the transport control octet after following the compressed IPv6 header start the LOWPAN_NHC encoding.
the uncompressed IP fields for a more properly layered structure. In contrast, LOWPAN_HC1 could be extended to support compression of
next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6.
Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet
and uncompressed IPv6 header fields. This specification moves the
next header encoding bits to follow all IPv6-related bits, allowing
for a properly layered structure and direct support for IPv6
extension headers.
[RFC4944] defines a compression mechanism for UDP, but that mechanism Using LOWPAN_NHC, this document defines a compression mechanism for
does not enable checksum compression when rendered possible by UDP. While [RFC4944] defines a compression mechanism for UDP, that
additional upper layer mechanisms such as upper layer Message mechanism does not enable checksum compression when rendered possible
by additional upper layer mechanisms such as upper layer Message
Integrity Check (MIC). This specification adds the capability to Integrity Check (MIC). This specification adds the capability to
compress the UDP checksum over the LoWPAN, which enables to save an elide the UDP checksum over the LoWPAN, which enables to save an
additional pair of octets. additional pair of octets.
Finally, LOWPAN_HC1 lacks the flexibility to support the compression Also using LOWPAN_NHC, this document defines encoding formats for
of additional transport mechanisms that could be introduced in the IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With
future. LOWPAN_HC1 and LOWPAN_HC2, chains of next headers can not be encoded
efficiently.
This document specifies a header compression format for IPv6
datagrams. This format improves on the header compression format
defined in [RFC4944] by generalizing it to support a broader range of
communication paradigms, including both mesh-under and route-over
configurations; communication to nodes internal and external to the
6LoWPAN network; and multicast communication. This document also
defines a flexible framework for compressing arbitrary next headers
and defines UDP header compression within this framework. This
compression format carries forward the design concepts in RFC 4944
[RFC4944], minimizing any state and relying on shared context among
all nodes in a 6LoWPAN network.
1.1. Requirements Language 1.1. Requirements Language
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].
2. IPv6 Header Compression 2. Specific Updates to RFC 4944
This document specifies a header compression format that is intended
to replace that defined in Section 10 of [RFC4944]. Implementation
of Section 10 of [RFC4944] is now NOT RECOMMENDED. New
implementations MAY implement Section 10 decompression, but SHOULD
NOT send section-10-compressed packets.
The header compression format defined in this document preempts the
ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the
value of 01 000000 is is reserved as a replacement value for ESC, to
be finally assigned with the first assignment of extension bytes.
3. IPv6 Header Compression
In this section, we define the LOWPAN_IPHC encoding format for In this section, we define the LOWPAN_IPHC encoding format for
compressing the IPv6 header. To enable effective compression compressing the IPv6 header. To enable effective compression
LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN
network. LOWPAN_IPHC assumes the following will be the common case network. LOWPAN_IPHC assumes the following will be the common case
for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label
are both zero; Payload Length can be inferred from lower layers from are both zero; Payload Length can be inferred from lower layers from
either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header;
Hop Limit will be set to a well-known value by the source; addresses Hop Limit will be set to a well-known value by the source; addresses
assigned to 6LoWPAN interfaces will be formed using the link-local assigned to 6LoWPAN interfaces will be formed using the link-local
skipping to change at page 5, line 16 skipping to change at page 5, line 27
network; addresses assigned to 6LoWPAN interfaces are formed with an network; addresses assigned to 6LoWPAN interfaces are formed with an
IID derived directly from either the 64-bit extended or 16-bit short IID derived directly from either the 64-bit extended or 16-bit short
IEEE 802.15.4 addresses. IEEE 802.15.4 addresses.
+-------------------------------------+------------------------ +-------------------------------------+------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header
+-------------------------------------+------------------------ +-------------------------------------+------------------------
Figure 1: LOWPAN_IPHC Header Figure 1: LOWPAN_IPHC Header
The LOWPAN_IPHC encoding utilizes 11 bits, 3 of which are taken from The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from
the rightmost bit of the dispatch type. The encoding may be extended the rightmost bit of the dispatch type. The encoding may be extended
by another octet to support additional contexts. Uncompressed IPv6 by another octet to support additional contexts. Uncompressed IPv6
header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1.
With the above scenario, the LOWPAN_IPHC can compress the IPv6 header With the above scenario, the LOWPAN_IPHC can compress the IPv6 header
down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) down to two octets (the dispatch octet and the LOWPAN_IPHC encoding)
with link-local communication. When routing over multiple IP hops, with link-local communication.
LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet
dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source
Address, and 2-octet Destination Address).
2.1. LOWPAN_IPHC Encoding Format When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6
header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC,
1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination
Address). The Hop Limit may not be compressed because it needs to
decremented at each hop and may take any value. Stateful address
compression must be applied to the source and destination IPv6
addresses because they do not statelessly match the source and
destination link layer addresses on intermediate hops.
2.1.1. Base Format 3.1. LOWPAN_IPHC Encoding Format
This section specifies the format of the LOWPAN_IPHC encoding that
describes how an IPv6 header is compressed. The encoding can be 2
octets long for the base encoding or 3 octets long when an additional
context encoding is present. The IPv6 header fields that are not
fully elided are placed immediately after the LOWPAN_IPHC, either in
a compressed form if the field is partially elided, or litteraly.
3.1.1. Base Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC Encoding Figure 2: LOWPAN_IPHC base Encoding
TF: Traffic Class, Flow Label: TF: Traffic Class, Flow Label:
00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes) 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided
10: Traffic Class (1 byte) 10: ECN + DSCP (1 byte), Flow Label is elided
11: Version, Traffic Class, and Flow Label are compressed. 11: Traffic Class and Flow Label are elided.
NH: Next Header: NH: Next Header:
0: Full 8 bits for Next Header are carried in-line. 0: Full 8 bits for Next Header are carried in-line.
1: The Next Header field is compressed and the next header is 1: The Next Header field is compressed and the next header is
compressed using LOWPAN_NHC, which is discussed in Section 3. encoded using LOWPAN_NHC, which is discussed in Section 4.
HLIM: Hop Limit: HLIM: Hop Limit:
00: The Hop Limit field is carried in-line. 00: The Hop Limit field is carried in-line.
01: The Hop Limit field is elided and the the hop limit is 1. 01: The Hop Limit field is compressed and the the hop limit is 1.
10: The Hop Limit field is elided and the the hop limit is 64. 10: The Hop Limit field is compressed and the the hop limit is
11: The Hop Limit field is elided and the hop limit is 255. 64.
11: The Hop Limit field is compressed and the hop limit is 255.
CID: Context Identifier Extension: CID: Context Identifier Extension:
0: No additional 8-bit Context Identifier Extension is used. If 0: No additional 8-bit Context Identifier Extension is used. If
context-based compression is specified in either SC or DC, context-based compression is specified in either SAC or DAC,
context 0 is used. context 0 is used.
1: An additional 8-bit Context Identifier Extension field 1: An additional 8-bit Context Identifier Extension field
immediately follows the DAM field. immediately follows the DAM field.
SAC: Source Address Compression SAC: Source Address Compression
0: Source address compression uses stateless compression. 0: Source address compression uses stateless compression.
1: Source address compression uses stateful, context-based 1: Source address compression uses stateful, context-based
compression. compression.
SAM: Source Address Mode: SAM: Source Address Mode:
skipping to change at page 6, line 42 skipping to change at page 7, line 18
The value of those bits is the link-local prefix padded with The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried inline. zeros. The remaining 64 bits are carried inline.
10: 16 bits. The first 112 bits of the address are elided. 10: 16 bits. The first 112 bits of the address are elided.
The value of those bits is the link-local prefix padded with The value of those bits is the link-local prefix padded with
zeros. The remaining 16 bits are carried inline. zeros. The remaining 16 bits are carried inline.
11: 0 bits. The address is fully elided. The first 64 bits 11: 0 bits. The address is fully elided. The first 64 bits
of the address are the link-local prefix padded with zeros. of the address are the link-local prefix padded with zeros.
The remaining 64 bits are computed from the link-layer The remaining 64 bits are computed from the link-layer
address as defined in [RFC4944]. address as defined in [RFC4944].
If SAC=1: If SAC=1:
00: Reserved. 00: The UNSPECIFIED address, ::
01: 64 bits. The address is derived using context information 01: 64 bits. The address is derived using context information
and the 64 bits carried inline. and the 64 bits carried inline.
10: 16 bits. The address is derived using context information 10: 16 bits. The address is derived using context information
and the 16 bits carried inline. and the 16 bits carried inline.
11: 0 bits. The address is derived using context information 11: 0 bits. The address is derived using context information
and possibly link-layer addresses. and possibly the link-layer addresses.
M: Multicast Compression M: Multicast Compression
0: Destination address does not use multicast compression. 0: Destination address is not a multicast address.
1: Destination address uses multicast compression. 1: Destination address is a multicast address.
DAC: Destination Address Compression DAC: Destination Address Compression
0: Destination address compression uses stateless compression. 0: Destination address compression uses stateless compression.
1: Destination address compression uses stateful, context-based 1: Destination address compression uses stateful, context-based
compression. compression.
DAM: Destination Address Mode: DAM: Destination Address Mode:
If M=0: If M=0 and DAC=0 This case matches SAC=0 but for the destination
If DAC=0: address:
00: 128 bits. The full address is carried in-line. 00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided. 01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded The value of those bits is the link-local prefix padded with
with zeros. The remaining 64 bits are carried inline. zeros. The remaining 64 bits are carried inline.
10: 16 bits. The first 112 bits of the address are elided. 10: 16 bits. The first 112 bits of the address are elided.
The value of those bits is the link-local prefix padded The value of those bits is the link-local prefix padded with
with zeros. The remaining 16 bits are carried inline. zeros. The remaining 16 bits are carried inline.
11: 0 bits. The address is fully elided. The first 64 11: 0 bits. The address is fully elided. The first 64 bits
bits of the address are the link-local prefix padded with of the address are the link-local prefix padded with zeros.
zeros. The remaining 64 bits are computed from the link- The remaining 64 bits are computed from the link-layer
layer address as defined in [RFC4944]. address as defined in [RFC4944].
If DAC=1:
00: Reserved. If M=0 and DAC=1:
01: 64 bits. The address is derived using context 00: Reserved.
information and the 64 bits carried inline. 01: 64 bits. The address is derived using context information
10: 16 bits. The address is derived using context and the 64 bits carried inline.
information and the 16 bits carried inline. 10: 16 bits. The address is derived using context information
11: 0 bits. The address is derived using context and the 16 bits carried inline.
information and possibly link-layer addresses. 11: 0 bits. The address is derived using context information
and possibly the link-layer addresses.
If M=1 and DAC=0: If M=1 and DAC=0:
00: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 00: 128 bits. The full address is carried in-line.
01: 32 bits. The address takes the form FFXX::00XX:XXXX. 01: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX.
10: 16 bits. The address takes the form FF0X::0XXX. 10: 32 bits. The address takes the form FFXX::00XX:XXXX.
11: 8 bits. The address takes the form FF02::00XX. 11: 8 bits. The address takes the form FF02::00XX.
If M=1 and DAC=1: If M=1 and DAC=1:
00: 128 bits. The full address is carried in-line. 00: 48 bits. This format is designed to match Unicast-Prefix-
01: 48 bits. The address takes the form FFXX::XXLL:PPPP:PPPP: based IPv6 Multicast Addresses as defined in [RFC3306] and
XXXX:XXXX. L denotes nibbles used to encode the prefix [RFC3956]. The multicast address takes the form FFXX:XXLL:
length. P denotes nibbles used to encode the prefix itself. PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles
The prefix information is taken from the specified context. that are carried inline, in the order in which they appear
in this format. P denotes nibbles used to encode the prefix
itself. L denotes nibbles used to encode the prefix length.
The prefix information P and L is taken from the specified
context.
01: reserved
10: reserved 10: reserved
11: reserved 11: reserved
2.1.2. Context Identifier Extension 3.1.2. Context Identifier Extension
This specification expects that a concept of context is shared This specification expects that a conceptual context is shared
between the node that compresses a packet and the node(s) that need between the node that compresses a packet and the node(s) that need
to expand it. The specification enables a node to use of up to 16 to expand it. How the contexts are shared and maintained is out of
contexts. How the contexts are shared and maintained is out of scope. What information is contained within a context information is
scope. What the context information is is out of scope. Actions in out of scope. Actions in response to unknown and/or invalid contexts
response to unknown and/or invalid contexts are out of scope. are out of scope. The specification enables a node to use up to 16
contexts. The context used to encode the source address does not
have to be the same as the context used to encode the destination
address.
If the CIF field is set to '1' in the LOWPAN_IPHC encoding, then an If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an
additional octet extends the LOWPAN_IPHC encoding following the DAM additional octet extends the LOWPAN_IPHC encoding following the DAM
bits but before the IPv6 header fields that are carried in-line. The bits but before the IPv6 header fields that are carried in-line. The
additional octet identifies the prefix when the IPv6 source and/or additional octet identifies the pair of contexts to be used when the
destination address is compressed. The context identifier is 4 bits IPv6 source and/or destination address is compressed. The context
for each address, supporting up to 16 contexts. The encoding is identifier is 4 bits for each address, supporting up to 16 contexts.
shown in Figure 3. Context 0 is the default context. The encoding is shown in Figure 3.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| SCI | DCI | | SCI | DCI |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 3: LOWPAN_IPHC Encoding Figure 3: LOWPAN_IPHC Encoding
SCI: Source Context Identifier Identifies the prefix that is used SCI: Source Context Identifier Identifies the prefix that is used
when the IPv6 source address is compressed. when the IPv6 source address is statefully compressed.
DCI: Destination Context Identifier Identifies the prefix that is DCI: Destination Context Identifier Identifies the prefix that is
used when the IPv6 destination address is compressed. used when the IPv6 destination address is statefully compressed.
2.2. IPv6 Header Encoding 3.2. IPv6 Header Encoding
Fields carried in-line (in part or in whole) appear in the same order Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC2460]. The Version field is as they do in the IPv6 header format [RFC2460]. The Version field is
always elided. Unicast IPv6 addresses may be compressed to 64 or 16 always elided. Unicast IPv6 addresses may be compressed to 64 or 16
bits or completely elided. Multicast IPv6 addresses may be bits or completely elided. Multicast IPv6 addresses may be
compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST
always be elided and inferred from lower layers using the 6LoWPAN always be elided and inferred from lower layers using the 6LoWPAN
Fragmentation header or the IEEE 802.15.4 header. Fragmentation header or the IEEE 802.15.4 header.
2.2.1. Traffic Class and Flow Label Compression 3.2.1. Traffic Class and Flow Label Compression
The Traffic Class field in the IPv6 header comprises 6 bits of The Traffic Class field in the IPv6 header comprises 6 bits of
diffserv extension [RFC2474] and 2 bits of Explicit Congestion diffserv extension [RFC2474] and 2 bits of Explicit Congestion
Notification (ECN) [RFC3168]. If the ECN information is carried by Notification (ECN) [RFC3168]. If the ECN information is carried by
the Lower Layers in a compatible fashion then it can be elided from the Lower Layers in a compatible fashion then it can be elided from
the 6LoWPAN header. Otherwise, it has to be transported in one of the 6LoWPAN header. Otherwise, it has to be transported in one of
the following encodings. the following encodings.
The TF field in the LOWPAN_IPHC encoding indicate whether the Traffic The TF field in the LOWPAN_IPHC encoding indicates whether the
Class and Flow Label are carried in-line in the compressed IPv6 Traffic Class and Flow Label are carried in-line in the compressed
header. When Flow Label is included while the Traffic Class is IPv6 header. When Flow Label is included while the Traffic Class is
compressed, an additional 4 bits are included to maintain byte- compressed, an additional 4 bits are included to maintain byte-
alignment. Two of the 4 bits contain the ECN bits from the Traffic alignment. Two of the 4 bits contain the ECN bits from the Traffic
Class field. Class field.
To ensure that the ECN bits appear in the same location for all To ensure that the ECN bits appear in the same location for all
encodings that include them, the Traffic Class field is rotated right encodings that include them, the Traffic Class field is rotated right
by 2 bits in the compressed IPv6 header. The encodings are shown by 2 bits in the compressed IPv6 header. The encodings are shown
below: below:
1 2 3 1 2 3
skipping to change at page 10, line 5 skipping to change at page 10, line 24
TF = 01: Flow Label carried in-line. TF = 01: Flow Label carried in-line.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|ECN| DSCP | |ECN| DSCP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
TF = 10: Traffic Class carried in-line. TF = 10: Traffic Class carried in-line.
2.2.2. Stateless Multicast Addresses Compression 3.2.2. Stateless Multicast Addresses Compression
LOWPAN_IPHC supports stateless compression of multicast address when LOWPAN_IPHC supports stateless compression of multicast address when
M = 1 and SAC = 0. An IPv6 multicast address may be compressed down M = 1 and DAC = 0. An IPv6 multicast address may be compressed down
to 48, 32, 16, or 8 bits using stateless compression. The format to 48, 32, or 8 bits using stateless compression. The format
supports compression of the Solicited-Node Multicast Address (FF02:: supports compression of the Solicited-Node Multicast Address (FF02::
1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper
bits of the multicast group identifier are zero. The compressed bits of the multicast group identifier are zero. The compressed
forms only carry the least-significant bits of the multicast group forms only carry the least-significant bits of the multicast group
identifier. All compressed forms carry the multicast scope in-line identifier. The 48 and 32-bit compressed forms carry the multicast
and all (except DAM=10) carry the multicast flags as well. scope and flags in-line.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier | | Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier | | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) DAM = 01. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg)
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier | | Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 01. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). DAM = 10. 32-bit Compressed Multicast Address (FFfs:00gg:gggg).
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 10. 16-bit Compressed Multicast Address (FF0s::0ggg).
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). DAM = 11. 8-bit Compressed Multicast Address (FF02::gg).
2.2.3. Stateful Multicast Addresses Compression 3.2.3. Stateful Multicast Addresses Compression
LOWPAN_IPHC supports stateful compression of multicast addresses when LOWPAN_IPHC supports stateful compression of multicast addresses when
M = 1 and SAC = 1. This document currently defines SAM = 01: M = 1 and DAC = 1. This document currently defines DAM = 00:
context-based compression of Unicast-Prefix-based IPv6 Multicast context-based compression of Unicast-Prefix-based IPv6 Multicast
Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and
Network Prefix can be taken from a context. As a result, LOWPAN_IPHC Network Prefix can be taken from a context. As a result, LOWPAN_IPHC
can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6
octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and
32-bit Group Identifier in-line. 32-bit Group Identifier in-line.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Reserved | Group Identifier | | Flags | Scope | Rsvd / RIID | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier | | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression
Note that the Reserved field MUST carry the reserved bits from the Note that the Reserved field MUST carry the reserved bits from the
multicast address format as described in [RFC3306]. When a multicast address format as described in [RFC3306]. When a
Rendezvous Point is encoded in the multicast address as described in Rendezvous Point is encoded in the multicast address as described in
[RFC3956], the Reserved field carries the RIID bits in-line. [RFC3956], the Reserved field carries the RIID bits in-line.
3. IPv6 Next Header Compression 4. IPv6 Next Header Compression
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set
to 1. It also indicates the use of 6LoWPAN next header compression, to 1. It also indicates the use of 6LoWPAN next header compression,
LOWPAN_NHC. The value of IPv6 Next Header is recovered from the LOWPAN_NHC. The value of IPv6 Next Header is recovered from the
first bits in the LOWPAN_NHC encoding. The following bits are first bits in the LOWPAN_NHC encoding. The following bits are
specific to the IPv6 Next Header value. Figure 4 shows the structure specific to the IPv6 Next Header value. Figure 4 shows the structure
of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields | | Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
3.1. LOWPAN_NHC Format 4.1. LOWPAN_NHC Format
Compression formats for different next headers are identified by a Compression formats for different next headers are identified by a
variable length bit-pattern immediately following the LOWPAN_IPHC variable-length bit-pattern immediately following the LOWPAN_IPHC
compressed header. When defining a next header compression format, compressed header. When defining a next header compression format,
the number of bits used SHOULD be determined by the perceived the number of bits used SHOULD be determined by the perceived
frequency of using that format. However, the number of bits and any frequency of using that format. However, the number of bits and any
remaining encoding bits SHOULD respect octet alignment. The remaining encoding bits SHOULD respect octet alignment. The
following bits are specific to the next header compression format. following bits are specific to the next header compression format.
In this document, we define a compression format for UDP headers. This document defines a compression format for IPv6 Extension and UDP
headers.
+----------------+--------------------------- +----------------+---------------------------
| var-len NHC ID | compressed next header... | var-len NHC ID | compressed next header...
+----------------+--------------------------- +----------------+---------------------------
Figure 5: LOWPAN_NHC Encoding Figure 5: LOWPAN_NHC Encoding
3.2. IPv6 Extension Header Compression 4.2. IPv6 Extension Header Compression
A necessary property of encoding headers using LOWPAN_NHC is that the A necessary property of encoding headers using LOWPAN_NHC is that the
immediately preceding header must either be encoded using LOWPAN_IPHC immediately preceding header must either be encoded using LOWPAN_IPHC
or LOWPAN_NHC. In other words, all headers compressed using the or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN
6LoWPAN header compression format defined in this document must be encoding format defined in this document must be contiguous. As a
contiguous. As a result, this document defines a set of LOWPAN_NHC result, this document defines a set of LOWPAN_NHC encodings for
encodings for selected IPv6 Extension Headers such that the UDP selected IPv6 Extension Headers such that the UDP Header Compression
Header Compression defined in Section 3.3 may be used in the presence defined in Section 4.3 may be used in the presence of those extension
of those extension headers. headers.
The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a
single LOWPAN_NHC octet followed by the IPv6 Extension Header. The single LOWPAN_NHC octet followed by the IPv6 Extension Header. The
format of the LOWPAN_NHC octet is shown in Figure 6. The first 7 format of the LOWPAN_NHC octet is shown in Figure 6. The first 7
bits serve as an identifier for the IPv6 Extension Header immediately bits serve as an identifier for the IPv6 Extension Header immediately
following the LOWPAN_NHC octet. The remaining bit indicates whether following the LOWPAN_NHC octet. The remaining bit indicates whether
or not the following header utilizes LOWPAN_NHC encoding. or not the following header utilizes LOWPAN_NHC encoding.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH | | 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 6: IPv6 Extension Header Encoding Figure 6: IPv6 Extension Header Encoding
EID: IPv6 Extension Header ID: EID: IPv6 Extension Header ID:
0: IPv6 Hop-by-Hop Options [RFC2460] 0: IPv6 Hop-by-Hop Options Header[RFC2460]
1: IPv6 Routing [RFC2460] 1: IPv6 Routing Header[RFC2460]
2: IPv6 Fragment [RFC2460] 2: IPv6 Fragment Header[RFC2460]
3: IPv6 Destination Options [RFC2460] 3: IPv6 Destination Options Header[RFC2460]
4: IPv6 Mobility Header [RFC3775] 4: IPv6 Mobility Header [RFC3775]
5: Reserved 5: Reserved
6: Reserved 6: Reserved
7: IPv6 Header 7: IPv6 Header
NH: Next Header: NH: Next Header:
0: Full 8 bits for Next Header are carried in-line. 0: Full 8 bits for Next Header are carried in-line.
1: The Next Header field is compressed and the next header is 1: The Next Header field is elided and the next header is encoded
compressed using LOWPAN_NHC, which is discussed in Section 3. using LOWPAN_NHC, which is discussed in Section 4.
For the most part, the IPv6 Extension Header is carried verbatim in For the most part, the IPv6 Extension Header is carried verbatim in
the bytes immediately following the LOWPAN_NHC octet, with two the bytes immediately following the LOWPAN_NHC octet, with two
important exceptions: Length Field and Next Header Field. important exceptions: Length Field and Next Header Field.
The Next Header Field contained in IPv6 Extension Headers is elided The Next Header Field contained in IPv6 Extension Headers is elided
when the NH bit is set in the LOWPAN_NHC encoding octet. Note that when the NH bit is set in the LOWPAN_NHC encoding octet. Note that
doing so allows LOWPAN_NHC to utilize no more overhead than the non- doing so allows LOWPAN_NHC to utilize no more overhead than the non-
encoded IPv6 Extension Header. encoded IPv6 Extension Header.
The Length Field contained in IPv6 Extension Headers indicate the The Length Field contained in IPv6 Extension Headers indicate the
length of the IPv6 Extension Header in octets, not including the length of the IPv6 Extension Header in octets, not including the
LOWPAN_NHC byte. Note that this changes the standard Length Field LOWPAN_NHC byte. Note that this changes the Length Field definition
definition from indicating the header size in 8-octet units, not in [RFC2460] from indicating the header size in 8-octet units, not
including the first 8 octets. Changing the Length Field to be in including the first 8 octets. Changing the Length Field to be in
units of octets removes wasteful internal fragmentation. However, units of octets removes wasteful internal fragmentation. However,
specifying units in octets also means that LOWPAN_NHC CANNOT be used specifying units in octets also means that LOWPAN_NHC CANNOT be used
to encode IPv6 Extension Headers that exceed 255 octets. to encode IPv6 Extension Headers that exceed 255 octets.
IPv6 Hop-by-Hop and Destination Options Headers may use Pad1 and PadN IPv6 Hop-by-Hop and Destination Options Headers may use Pad1 and PadN
to pad out the header to a multiple of 8 octets in length. When to pad out the header for octet-alignment purposes. When using
using LOWPAN_NHC, those Pad1 and PadN options MAY be elided and the LOWPAN_NHC, those Pad1 and PadN options MAY be elided and the length
length of the header reduced by the size of those Pad1 and PadN of the header reduced by the size of those Pad1 and PadN options.
options. When converting from the LOWPAN_NHC encoding back to the When converting from the LOWPAN_NHC encoding back to the standard
standard IPv6 encoding, Pad1 and PadN options MUST be used to pad out IPv6 encoding, Pad1 and PadN options MUST be used to pad out the
the containing header to a multiple of 8 octets in length if containing header to a multiple of 8 octets in length if necessary.
necessary. Note that Pad1 and PadN options that do not appear at the Note that Pad1 and PadN options that do not appear at the end of the
end of the containing header MUST NOT be elided as they are used to containing header MUST be carried in-line as they are used to align
align subsequent options. subsequent options.
When the identified next header is an IPv6 Header (EID=7), the NH bit When the identified next header is an IPv6 Header (EID=7), the NH bit
of the LOWPAN_NHC encoding is unused and SHOULD be set to zero. The of the LOWPAN_NHC encoding is unused and SHOULD be set to zero. The
bytes following follow the LOWPAN_IPHC encoding as defined in bytes following follow the LOWPAN_IPHC encoding as defined in
Section 2. Section 3.
3.3. UDP Header Compression 4.3. UDP Header Compression
This document defines a compression format for UDP headers using This document defines a compression format for UDP headers using
LOWPAN_NHC. The UDP compression format is shown in Figure 7. Bits 0 LOWPAN_NHC. The UDP compression format is shown in Figure 7. Bits 0
through 4 represent the NHC ID and '11110' indicates the specific UDP through 4 represent the NHC ID and '11110' indicates the specific UDP
header compression encoding defined in this section. header compression encoding defined in this section.
3.3.1. Compressing UDP ports 4.3.1. Compressing UDP ports
This specification introduces a range of well-known port (0xF0Bx) This specification introduces a range of well-known ports (0xF0Bx)
that can be compressed to 4 bits. Considering that this represents that can be compressed to 4 bits. Considering that this represents
only 16 contiguous ports, it can be expected that many incompatible only 16 contiguous ports, it can be expected that many incompatible
applications will use the same port numbers of their own end-to-end applications will use the same port numbers of their own end-to-end
needs. needs.
The overloading of the 0xF0Bx ports increases the risk of getting the The overloading of the 0xF0Bx ports increases the risk of getting the
wrong type of payload and misinterpreting the content compared to wrong type of payload and misinterpreting the content compared to
ports that reserved at IANA. It is thus recommended that the use of ports that reserved at IANA. It is thus recommended that the use of
those ports be associated with a mechanism such as a Transport Layer those ports be associated with a mechanism such as a Transport Layer
Security (TLS) Message Integrity Check (MIC) that validates that the Security (TLS) Message Integrity Check (MIC) that validates that the
content is expected and checked for integrity. content is expected and checked for integrity.
3.3.2. Compressing UDP checksum 4.3.2. Compressing UDP checksum
The UDP checksum operation is mandatory with IPv6 [RFC2460] for all The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
packets. For that reason [RFC4944] disallows the compression of the packets. For that reason [RFC4944] disallows the compression of the
UDP checksum. UDP checksum.
With this specification, a compressor in the source transport With this specification, a compressor in the source transport
endpoint MAY elide the UDP checksum if it authorized by the Upper endpoint MAY elide the UDP checksum if it is authorized by the Upper
Layer. The compressor SHOULD NOT set the C bit unless it has Layer. The compressor SHOULD NOT set the C bit unless it has
received such authorization. The Upper Layer SHOULD only provide the received such authorization. The Upper Layer SHOULD only provide the
authorization in the following cases: authorization in the following cases:
Tunneling: In this case, 6LowPAN is deployed as a wireless pseudo- Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo-
fieldbus by tunneling existing field protocols over UDP. If the fieldbus by tunneling existing field protocols over UDP. If the
tunneled PDU possesses its own addressing, security and integrity tunneled PDU possesses its own addressing, security and integrity
check, the tunneling mechanism MAY authorize to elide the UDP check, the tunneling mechanism MAY authorize to elide the UDP
checksum in order to save on the encapsulation overhead. checksum in order to save on the encapsulation overhead.
Upper Layer Message Integrity Check: In this case, there is some Upper Layer Message Integrity Check: In this case, there is some
other form of integrity check in the UDP payload that covers at other form of integrity check in the UDP payload that covers at
least the same information as the UDP checksum (pseudo-header, least the same information as the UDP checksum (pseudo-header,
data) and has at least the same strength. data) and has at least the same strength.
A forwarding node MAY imply authorization from the incoming packet A forwarding node MAY imply authorization from an incoming packet if
being forwarded if the C bit was set there. The forwarding node that the C bit is set. A forwarding node that cannot unambiguously derive
can not derive the authorization in an non-ambiguous fashion SHOULD such authorization SHOULD NOT elide the UDP checksum when performing
NOT elide the UDP checksum when performing 6LoWPAN compression. The 6LoWPAN compression. The forwarding node that expands a 6LoWPAN
forwarding node that expands a 6LoWPAN packets with the C bit on MUST packet with the C bit on MUST compute the UDP checksum on behalf of
compute the UDP checksum on behalf of the source node and place that the source node and place that checksum in the restored UDP header as
checksum in the restored UDP header as specified in the incumbent specified in the incumbent standards [RFC0768], [RFC2460].
standards [RFC0768], [RFC2460].
If a 6LoWPAN termination is also the transport endpoint, and it If a 6LoWPAN termination is also the transport endpoint and it
receives a compressed packet that has the C bit set, then it is receives a compressed packet with the C bit set, then it is entitled
entitled to ignore the UDP checksum process completely. If the C bit to ignore the UDP checksum process completely. If the C bit is not
is not set, the packet might have been forwarded by an edge router, set, the packet might have been forwarded by an edge router, so this
so this is not an indication that the MIC is not present. If the is not an indication that the MIC is not present. If the terminating
terminating node knows that the message integrity will be validated node knows that the message integrity will be validated by the upper
by the upper layer by some state associated to the Service Access layer by some state associated to the Service Access Point, it is
Point, it is entitled to ignore the checksum operation as if the C entitled to ignore the checksum operation as if the C bit was set.
bit was set.
3.3.3. UDP LOWPAN_NHC Format 4.3.3. UDP LOWPAN_NHC Format
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P | | 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 7: UDP Header Encoding Figure 7: UDP Header Encoding
C: Checksum: C: Checksum:
0: All 16 bits of Checksum are carried in-line. 0: All 16 bits of Checksum are carried in-line.
1: All 16 bits of Checksum are elided. The Checksum is recovered 1: All 16 bits of Checksum are elided. The Checksum is recovered
by recomputing it on the 6LoWPAN termination point. by recomputing it on the 6LoWPAN termination point.
P: Ports: P: Ports:
00: All 16 bits for both Source Port and Destination Port are 00: All 16 bits for both Source Port and Destination Port are
carried in-line. carried in-line.
skipping to change at page 16, line 4 skipping to change at page 16, line 17
0: All 16 bits of Checksum are carried in-line. 0: All 16 bits of Checksum are carried in-line.
1: All 16 bits of Checksum are elided. The Checksum is recovered 1: All 16 bits of Checksum are elided. The Checksum is recovered
by recomputing it on the 6LoWPAN termination point. by recomputing it on the 6LoWPAN termination point.
P: Ports: P: Ports:
00: All 16 bits for both Source Port and Destination Port are 00: All 16 bits for both Source Port and Destination Port are
carried in-line. carried in-line.
01: All 16 bits for Source Port are carried in-line. First 8 01: All 16 bits for Source Port are carried in-line. First 8
bits of Destination Port is 0xF0 and elided. The remaining 8 bits of Destination Port is 0xF0 and elided. The remaining 8
bits of Destination Port are carried in-line. bits of Destination Port are carried in-line.
10: First 8 bits of Source Port are 0xF0 and elided. The 10: First 8 bits of Source Port are 0xF0 and elided. The
remaining 8 bits of Source Port are carried in-line. All 16 remaining 8 bits of Source Port are carried in-line. All 16
bits for Destination Port are carried in-line. bits for Destination Port are carried in-line.
11: First 12 bits of both Source Port and Destination Port are 11: First 12 bits of both Source Port and Destination Port are
0xF0B and elided. The remaining 4 bits for each are carried 0xF0B and elided. The remaining 4 bits for each are carried
in-line. in-line.
Fields carried in-line (in part or in whole) appear in the same order Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC2460]. IPv6 addresses may as they do in the UDP header format [RFC0768]. The UDP Length field
be compressed to 64 or 16 bits or completely elided. The UDP Length MUST always be elided and is inferred from lower layers using the
field MUST always be elided and is inferred from lower layers using 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
4. IANA Considerations 5. IANA Considerations
This document defines a new IPv6 header compression format for This document defines a new IPv6 header compression format for
6LoWPAN networks. The document allocates Dispatch type values of 6LoWPAN networks. The document allocates the following 32 Dispatch
0x08-0x0F (TBD) for LOWPAN_IPHC. type field values for LOWPAN_IPHC:
5. Security Considerations 01 100000
through
01 111111
This assignment preempts the assignment of 01 111111 for ESC
[RFC4944], which is possible as no extension bytes have been
allocated yet that would enable the use of ESC. Instead, the value:
01 000000
is reserved as a replacement value for ESC, to be finally assigned
with the first assignment of extension bytes.
6. Security Considerations
The definition of LOWPAN_IPHC permits the compression of header The definition of LOWPAN_IPHC permits the compression of header
information on communication that could take place in its absence, information on communication that could take place in its absence,
albeit in a less efficient form. It recognizes that a IEEE 802.15.4 albeit in a less efficient form. It recognizes that a IEEE 802.15.4
PAN may have associated with it a number of prefixes through shared PAN may have associated with it a number of prefixes through shared
context. How the shared context is assigned and managed is beyond context. How the shared context is assigned and managed is beyond
the scope of this document. the scope of this document.
The overloading of the 0xF0Bx ports increases the risk of getting the The overloading of the 0xF0Bx ports increases the risk of getting the
wrong type of payload and misinterpreting the content compared to wrong type of payload and misinterpreting the content compared to
ports that reserved at IANA. It is thus recommended that the use of ports that reserved at IANA. It is thus recommended that the use of
those ports be associated with a mechanism such as a Transport Layer those ports be associated with a mechanism such as a Transport Layer
Security (TLS) Message Integrity Check (MIC) that validates that the Security (TLS) Message Integrity Check (MIC) that validates that the
content is expected and checked for integrity. content is expected and checked for integrity.
6. Acknowledgements 7. Acknowledgements
Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik
Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen
Dawson-Haggerty, Jay Werb and Mathilde Durvy for useful design Dawson-Haggerty, Jay Werb and Mathilde Durvy for useful design
consideration and implementation feedback. consideration and implementation feedback.
7. Changes 8. Changes
Draft 06:
- Reworked introduction.
- Fixed description of number of bits used for IPHC encoding.
- Specify M=0 only for non-multicast addresses and M=1 only for
multicast addresses.
- Move 128-bit multicast encoding to DAC=0.
- Redefined ESC dispatch value to 01 000000.
- Many detailed edits.
Draft 05: Draft 05:
- Added LOWPAN_NHC encodings for IPv6 Extension Headers. - Added LOWPAN_NHC encodings for IPv6 Extension Headers.
- Specify use of context 0 when CID is 0. - Specify use of context 0 when CID is 0.
- Indicate that first 64-bits is link-local prefix padded with - Indicate that first 64-bits is link-local prefix padded with
zeros when link-local prefix is elided. zeros when link-local prefix is elided.
- Made prefix-based multicast encoding format more explicit for - Made prefix-based multicast encoding format more explicit for
clarity. clarity.
- Changed wording around stateful compression to allow for using - Changed wording around stateful compression to allow for using
the inline bits as an additional index to identify the compressed the inline bits as an additional index to identify the compressed
skipping to change at page 17, line 48 skipping to change at page 18, line 36
of scope of this document. of scope of this document.
Draft 01: Draft 01:
- HC back to 1 byte by default by stealing a few bits from the - HC back to 1 byte by default by stealing a few bits from the
dispatch field. dispatch field.
- Added better support for multicast address compression. - Added better support for multicast address compression.
- Fixed alignment for UDP port compression. - Fixed alignment for UDP port compression.
- Better support for Traffic Class and Flow Label compression. - Better support for Traffic Class and Flow Label compression.
- Pascal joined as an author. - Pascal joined as an author.
8. References 9. References
8.1. Normative References
9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[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 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
skipping to change at page 18, line 44 skipping to change at page 19, line 30
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[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.
8.2. Informative References 9.2. Informative References
[IEEE 802.15.4] [IEEE 802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2006", IEEE Computer Society, "IEEE Std. 802.15.4-2006",
October 2006. October 2006.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
 End of changes. 83 change blocks. 
229 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/