draft-ietf-6lowpan-hc-13.txt   draft-ietf-6lowpan-hc-14.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: March 31, 2011 September 27, 2010 Expires: August 18, 2011 February 14, 2011
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in Low Power and Lossy Networks
draft-ietf-6lowpan-hc-13 (6LoWPAN)
draft-ietf-6lowpan-hc-14
Abstract Abstract
This document specifies an IPv6 header compression format for IPv6 This document updates RFC 4944, "Transmission of IPv6 Packets over
packet delivery in 6LoWPAN networks. The compression format relies IEEE 802.15.4 Networks". This document specifies an IPv6 header
on shared context to allow compression of arbitrary prefixes. How compression format for IPv6 packet delivery in Low Power and Lossy
the information is maintained in that shared context is out of scope. Networks (6LoWPANs). The compression format relies on shared context
This document specifies compression of multicast addresses and a to allow compression of arbitrary prefixes. How the information is
framework for compressing next headers. UDP header compression is maintained in that shared context is out of scope. This document
specified within this framework. specifies compression of multicast addresses and a framework for
compressing next headers. UDP header compression is specified within
this framework.
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 March 31, 2011. This Internet-Draft will expire on August 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 24 skipping to change at page 2, line 27
3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 6 3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 6
3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Context Identifier Extension . . . . . . . . . . . . . 9 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 9
3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 10 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 10
3.2.1. Traffic Class and Flow Label Compression . . . . . . . 10 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 10
3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11 3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11
3.2.3. Stateless Multicast Address Compression . . . . . . . 12 3.2.3. Stateless Multicast Address Compression . . . . . . . 12
3.2.4. Stateful Multicast Address Compression . . . . . . . . 13 3.2.4. Stateful Multicast Address Compression . . . . . . . . 13
4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 14 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 14
4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 14 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 14
4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 14 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 15
4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 16 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 16
4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 16 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 17
4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 17 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 17
4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 18 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The [IEEE 802.15.4] standard specifies an MTU of 127 bytes, yielding The [IEEE 802.15.4] standard specifies an MTU of 127 bytes, yielding
about 80 octets of actual MAC payload with security enabled, on a about 80 octets of actual Media Access Control (MAC) payload with
wireless link with a link throughput of 250 kbps or less. The security enabled, on a wireless link with a link throughput of 250
6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified
datagrams over such constrained links, taking into account limited to carry IPv6 datagrams over such constrained links, taking into
bandwidth, memory, or energy resources that are expected in account limited bandwidth, memory, or energy resources that are
applications such as wireless sensor networks. [RFC4944] defines a expected in applications such as wireless sensor networks. [RFC4944]
Mesh Addressing header to support sub-IP forwarding, a Fragmentation defines a Mesh Addressing header to support sub-IP forwarding, a
header to support the IPv6 minimum MTU requirement [RFC2460], and Fragmentation header to support the IPv6 minimum MTU requirement
stateless header compression for IPv6 datagrams (LOWPAN_HC1 and [RFC2460], and stateless header compression for IPv6 datagrams
LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and
to (in the best case) several bytes. UDP headers down 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 IPv6 in Low Power and Lossy Networks (6LoWPANs). LOWPAN_HC1 is most
unicast communication, where IPv6 addresses carry the link-local effective for link-local unicast communication, where IPv6 addresses
prefix and an Interface Identifier (IID) directly derived from IEEE carry the link-local prefix and an Interface Identifier (IID)
802.15.4 addresses. In this case, both addresses may be completely directly derived from IEEE 802.15.4 addresses. In this case, both
elided. However, though link-local addresses are commonly used for addresses may be completely elided. However, though link-local
local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 addresses are commonly used for local protocol interactions such as
[RFC3315] or routing protocols, they are usually not used for IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315] or routing
application-layer data traffic, so the actual value of this protocols, they are usually not used for application-layer data
compression mechanism is limited. traffic, so the actual value of this 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 6LoWPAN or in a route-over configuration where IP
forwarding occurs within the LoWPAN. For routable addresses, forwarding occurs within the 6LoWPAN. 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. When the destination is an IPv6 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 multicast address, LOWPAN_HC1 requires the full 128-bit address to be
carried in-line. carried in-line.
As a result, this document defines an encoding format, LOWPAN_IPHC, As a result, this document defines an encoding format, LOWPAN_IPHC,
for effective compression of Unique Local, Global, and multicast IPv6 for effective compression of Unique Local, Global, and multicast IPv6
Addresses based on shared state within contexts. In addition, this Addresses based on shared state within contexts. In addition, this
document also introduces a number of additional improvements over the document also introduces a number of additional improvements over the
header compression format defined in [RFC4944]. header compression format defined in [RFC4944].
LOWPAN_IPHC allows for compression of some commonly-used IPv6 Hop LOWPAN_IPHC allows for compression of some commonly-used IPv6 Hop
Limit values. If the LoWPAN is a mesh-under stub, a Hop Limit of 1 Limit values. If the 6LoWPAN 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. Additionally, a hop-limit enough for application layer data traffic. Additionally, a hop-limit
value of 255 is often used to verify that a communication occurs over value of 255 is often used to verify that a communication occurs over
a single-hop. This specification enables compression of the IPv6 Hop a single-hop. This specification enables compression of the IPv6 Hop
Limit field in those common cases, whereas LOWPAN_HC1 does not. Limit field in those common cases, whereas LOWPAN_HC1 does not.
This document also defines LOWPAN_NHC, an encoding format for This document also defines LOWPAN_NHC, an encoding format for
arbitrary next headers. LOWPAN_IPHC indicates whether the following arbitrary next headers. LOWPAN_IPHC indicates whether the following
header is encoded using LOWPAN_NHC. If so, the bits immediately header is encoded using LOWPAN_NHC. If so, the bits immediately
following the compressed IPv6 header start the LOWPAN_NHC encoding. following the compressed IPv6 header start the LOWPAN_NHC encoding.
skipping to change at page 4, line 25 skipping to change at page 4, line 26
and uncompressed IPv6 header fields. This specification moves the and uncompressed IPv6 header fields. This specification moves the
next header encoding bits to follow all IPv6-related bits, allowing next header encoding bits to follow all IPv6-related bits, allowing
for a properly layered structure and direct support for IPv6 for a properly layered structure and direct support for IPv6
extension headers. extension headers.
Using LOWPAN_NHC, this document defines a compression mechanism for Using LOWPAN_NHC, this document defines a compression mechanism for
UDP. While [RFC4944] defines a compression mechanism for UDP, that UDP. While [RFC4944] defines a compression mechanism for UDP, that
mechanism does not enable checksum compression when rendered possible mechanism does not enable checksum compression when rendered possible
by additional upper layer mechanisms such as upper layer Message 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
elide the UDP checksum over the LoWPAN, which enables saving of a elide the UDP checksum over the 6LoWPAN, which enables saving of a
further two octets. further two octets.
Also using LOWPAN_NHC, this document defines encoding formats for Also using LOWPAN_NHC, this document defines encoding formats for
IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With
LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded
efficiently. efficiently.
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. Specific Updates to RFC 4944 2. Specific Updates to RFC 4944
This document specifies a header compression format that is intended This document specifies a header compression format that is intended
to replace that defined in Section 10 of [RFC4944]. Implementation to replace that defined in Section 10 of [RFC4944]. Implementation
of Section 10 of [RFC4944] is now NOT RECOMMENDED. New of Section 10 of [RFC4944] is now NOT RECOMMENDED. New
implementations MAY implement compression according to Section 10 of implementations MAY implement decompression according to Section 10
[RFC4944], but SHOULD NOT send packets compressed according to of [RFC4944], but SHOULD NOT send packets compressed according to
Section 10 of [RFC4944]. Section 10 of [RFC4944].
A compliant implementation of [RFC4944] as updated by this document A compliant implementation of [RFC4944] as updated by this document
MUST be able to properly process a packet received that makes use of MUST be able to properly process a packet received that makes use of
the provisions of this document. A compliant implementation MAY the provisions of this document. A compliant implementation MAY
implement additional LOWPAN_NHC types (Section 4) that may be implement additional LOWPAN_NHC types (Section 4) that may be
registered (Section 5) in the future. It is out of scope of this registered (Section 5) in the future. It is out of scope of this
document how a compressor learns that a decompressor has additional document how a compressor learns that a decompressor has additional
capabilities. capabilities.
skipping to change at page 5, line 29 skipping to change at page 5, line 30
The header compression format defined in this document preempts the The header compression format defined in this document preempts the
ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the
value of 01 000000 is reserved as a replacement value for ESC, to be value of 01 000000 is reserved as a replacement value for ESC, to be
finally assigned with the first assignment of extension bytes. finally assigned with the first assignment of extension bytes.
3. IPv6 Header Compression 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 LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN
for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label communication: Version is 6; Traffic Class and Flow Label are both
are both zero; Payload Length can be inferred from lower layers from zero; Payload Length can be inferred from lower layers from either
either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; Hop
Hop Limit will be set to a well-known value by the source; addresses 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
prefix or a small set of routable prefixes assigned to the entire prefix or a small set of routable prefixes assigned to the entire
6LoWPAN network; addresses assigned to 6LoWPAN interfaces are formed 6LoWPAN; addresses assigned to 6LoWPAN interfaces are formed with an
with an IID derived directly from either the 64-bit extended or 16- IID derived directly from either the 64-bit extended or 16-bit short
bit short IEEE 802.15.4 addresses. IEEE 802.15.4 addresses.
+-------------------------------------+---------------------------- +-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+---------------------------- +-------------------------------------+----------------------------
Figure 1: LOWPAN_IPHC Header Figure 1: LOWPAN_IPHC Header
The LOWPAN_IPHC encoding utilizes 13 bits, 5 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. Any information by another octet to support additional contexts. Any information
skipping to change at page 6, line 31 skipping to change at page 6, line 32
This section specifies the format of the LOWPAN_IPHC encoding that This section specifies the format of the LOWPAN_IPHC encoding that
describes how an IPv6 header is compressed. The encoding can be 2 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 octets long for the base encoding or 3 octets long when an additional
context encoding is present. The IPv6 header fields that are not context encoding is present. The IPv6 header fields that are not
fully elided are placed immediately after the LOWPAN_IPHC, either in fully elided are placed immediately after the LOWPAN_IPHC, either in
a compressed form if the field is partially elided, or literally. a compressed form if the field is partially elided, or literally.
3.1.1. Base Format 3.1.1. Base Format
0 1
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 base Encoding Figure 2: LOWPAN_IPHC base Encoding
TF: Traffic Class, Flow Label: TF: Traffic Class, Flow Label: As specified in [RFC3168], the 8-bit
IPv6 Traffic Class field is split into two fields: 2-bit Explicit
Congestion Notification (ECN) and 6-bit Differentiated Services
Code Point (DSCP).
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes) 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided
10: ECN + DSCP (1 byte), Flow Label is elided 10: ECN + DSCP (1 byte), Flow Label is elided
11: Traffic Class and Flow Label are elided. 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
encoded using LOWPAN_NHC, which is discussed in Section 4. encoded using LOWPAN_NHC, which is discussed in Section 4.1.
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 compressed and the hop limit is 1. 01: The Hop Limit field is compressed and the hop limit is 1.
10: The Hop Limit field is compressed and the hop limit is 64. 10: The Hop Limit field is compressed and the hop limit is 64.
11: The Hop Limit field is compressed and the hop limit is 255. 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 SAC or DAC, context-based compression is specified in either SAC or DAC,
skipping to change at page 7, line 41 skipping to change at page 7, line 47
padded with zeros. The following 64 bits are 0000:00ff: padded with zeros. The following 64 bits are 0000:00ff:
fe00:XXXX, where XXXX are the 16 bits carried in-line. fe00:XXXX, where XXXX are the 16 bits carried in-line.
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 encapsulating The remaining 64 bits are computed from the encapsulating
header (e.g. 802.15.4 or IPv6 source address) as specified header (e.g. 802.15.4 or IPv6 source address) as specified
in Section 3.2.2. in Section 3.2.2.
If SAC=1: If SAC=1:
00: The UNSPECIFIED address, :: 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 in-line. Any bits of the IID not and the 64 bits carried in-line. Bits covered by context
covered by context information are taken directly from the information are always used. Any IID bits not covered by
context information are taken directly from the
corresponding bits carried in-line. Any remaining bits are corresponding bits carried in-line. Any remaining bits are
zero. zero.
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 in-line. Any bits of the IID not and the 16 bits carried in-line. Bits covered by context
covered by context information are taken directly from their information are always used. Any IID bits not covered by
context information are taken directly from their
corresponding bits in the 16-bit to IID mapping given by corresponding bits in the 16-bit to IID mapping given by
0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-
line. Any remaining bits are zero. line. Any remaining bits are zero.
11: 0 bits. The address is fully elided and is derived using
11: 0 bits. The address is fully elided. The prefix is context information and the encapsulating header (e.g.
derived using context information. Any bits of the IID not 802.15.4 or IPv6 source address). Bits covered by context
covered by the context information are computed from the information are always used. Any IID bits not covered by
encapsulating header (e.g. 802.15.4 or IPv6 source address) context information are computed from the encapsulating
as specified in Section 3.2.2. Any remaining bits are zero. header as specified in Section 3.2.2. Any remaining bits
are zero.
M: Multicast Compression M: Multicast Compression
0: Destination address is not a multicast address. 0: Destination address is not a multicast address.
1: Destination address is a multicast address. 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.
skipping to change at page 8, line 39 skipping to change at page 8, line 48
padded with zeros. The following 64 bits are 0000:00ff: padded with zeros. The following 64 bits are 0000:00ff:
fe00:XXXX, where XXXX are the 16 bits carried in-line. fe00:XXXX, where XXXX are the 16 bits carried in-line.
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 encapsulating The remaining 64 bits are computed from the encapsulating
header (e.g. 802.15.4 or IPv6 destination address) as header (e.g. 802.15.4 or IPv6 destination address) as
specified in Section 3.2.2. specified in Section 3.2.2.
If M=0 and DAC=1: If M=0 and DAC=1:
00: Reserved. 00: Reserved.
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 in-line. Any bits of the IID not and the 64 bits carried in-line. Bits covered by context
covered by context information are taken directly from the information are always used. Any IID bits not covered by
corrseponding bits carried in-line. Any remaining bits are context information are taken directly from the
corresponding bits carried in-line. Any remaining bits are
zero. zero.
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 in-line. Any bits of the IID not and the 16 bits carried in-line. Bits covered by context
covered by context information are taken directly from their information are always used. Any IID bits not covered by
context information are taken directly from their
corresponding bits in the 16-bit to IID mapping given by corresponding bits in the 16-bit to IID mapping given by
0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-
line. Any remaining bits are zero. line. Any remaining bits are zero.
11: 0 bits. The address is fully elided and is derived using
11: 0 bits. The address is fully elided. The prefix is context information and the encapsulating header (e.g.
derived using context information. Any bits of the IID not 802.15.4 or IPv6 destination address). Bits covered by
covered by the context information are computed from the context information are always used. Any IID bits not
encapsulating header (e.g. 802.15.4 or IPv6 destination covered by context information are computed from the
address) as specified in Section 3.2.2. Any remaining bits encapsulating header as specified in Section 3.2.2. Any
are zero. remaining bits are zero.
If M=1 and DAC=0: If M=1 and DAC=0:
00: 128 bits. The full address is carried in-line. 00: 128 bits. The full address is carried in-line.
01: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 01: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX.
10: 32 bits. The address takes the form FFXX::00XX:XXXX. 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: 48 bits. This format is designed to match Unicast-Prefix- 00: 48 bits. This format is designed to match Unicast-Prefix-
based IPv6 Multicast Addresses as defined in [RFC3306] and based IPv6 Multicast Addresses as defined in [RFC3306] and
[RFC3956]. The multicast address takes the form FFXX:XXLL: [RFC3956]. The multicast address takes the form FFXX:XXLL:
PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles
skipping to change at page 10, line 49 skipping to change at page 11, line 11
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label | |ECN| DSCP | rsv | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TF = 00: Traffic Class and Flow Label carried in-line. Figure 4: TF = 00: Traffic Class and Flow Label carried in-line.
1 2 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv| Flow Label | |ECN|rsv| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TF = 01: Flow Label carried in-line. Figure 5: 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. Figure 6: TF = 10: Traffic Class carried in-line.
3.2.2. Deriving IIDs from the Encapsulating Header 3.2.2. Deriving IIDs from the Encapsulating Header
LOWPAN_IPHC elides the IIDs of source or destination addresses when LOWPAN_IPHC elides the IIDs of source or destination addresses when
SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived
from the encapsulating header. When the encapsulating header carries from the encapsulating header. When the encapsulating header carries
IPv6 addresses, bits for the source and destination addresses are IPv6 addresses, bits for the source and destination addresses are
copied verbatim from the source and destination addresses of the copied from the source and destination addresses of the encapsulating
encapsulating IPv6 header. IPv6 header.
The remainder of this section defines the mapping from IEEE 802.15.4 The remainder of this section defines the mapping from IEEE 802.15.4
link-layer addresses to IIDs for both short and extended IEEE [IEEE 802.15.4] link-layer addresses to IIDs for both short and
802.15.4 addresses. IID bits not covered by the context information extended IEEE 802.15.4 addresses. IID bits not covered by the
MAY be elided if they match the link-layer address mapping and MUST context information MAY be elided if they match the link-layer
NOT be elided if they do not. address mapping and MUST NOT be elided if they do not.
An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64
address. Generating an IID from an extended address is identical to address. Generating an IID from an extended address is identical to
that defined in Appendix A of [RFC4291]. The only change needed to that defined in Appendix A of [RFC4291]. The only change needed to
transform an IEEE EUI-64 identifier to an interface identifier is to transform an IEEE EUI-64 identifier to an interface identifier is to
invert the universal/local bit. invert the universal/local bit.
A short IEEE 802.15.4 address is 16 bits in length. Short addresses A short IEEE 802.15.4 address is 16 bits in length. Short addresses
are mapped into the restricted space of IEEE EUI-64 addresses by are mapped into the restricted space of IEEE EUI-64 addresses by
setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
skipping to change at page 12, line 41 skipping to change at page 13, line 13
significant bits of the multicast group identifier. significant bits of the multicast group identifier.
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 = 01. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) Figure 7: 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 = 10. 32-bit Compressed Multicast Address (FFfs::00gg:gggg). Figure 8: DAM = 10. 32-bit Compressed Multicast Address (FFfs::00gg:
gggg).
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). Figure 9: DAM = 11. 8-bit Compressed Multicast Address (FF02::gg).
3.2.4. Stateful Multicast Address Compression 3.2.4. Stateful Multicast Address Compression
LOWPAN_IPHC supports stateful compression of multicast addresses when LOWPAN_IPHC supports stateful compression of multicast addresses when
M = 1 and DAC = 1. This document currently defines DAM = 00: 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 | Rsvd / RIID | Group Identifier | | Flags | Scope | Rsvd / RIID | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier | | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression Figure 10: DAM = 00. 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.
4. 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. This also indicates the use of 6LoWPAN next header to 1. This also indicates the use of 6LoWPAN next header
compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered
from the first bits in the LOWPAN_NHC encoding. The following bits from the first bits in the LOWPAN_NHC encoding. The following bits
are specific to the IPv6 Next Header value. Figure 4 shows the are specific to the IPv6 Next Header value. Figure 11 shows the
structure of an IPv6 datagram compressed using LOWPAN_IPHC and structure of an IPv6 datagram compressed using LOWPAN_IPHC and
LOWPAN_NHC. 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 11: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
4.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.
This document defines a compression format for IPv6 Extension and UDP This document defines a compression format for IPv6 Extension and UDP
headers. headers.
+----------------+--------------------------- +----------------+---------------------------
| var-len NHC ID | compressed next header... | var-len NHC ID | compressed next header...
+----------------+--------------------------- +----------------+---------------------------
Figure 5: LOWPAN_NHC Encoding Figure 12: LOWPAN_NHC Encoding
4.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 encoded using the 6LoWPAN or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN
encoding format defined in this document must be contiguous. As a encoding format defined in this document must be contiguous. As a
result, this document defines a set of LOWPAN_NHC encodings for result, this document defines a set of LOWPAN_NHC encodings for
selected IPv6 Extension Headers such that the UDP Header Compression selected IPv6 Extension Headers such that the UDP Header Compression
defined in Section 4.3 may be used in the presence of those extension defined in Section 4.3 may be used in the presence 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 13. 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 13: IPv6 Extension Header Encoding
EID: IPv6 Extension Header ID: EID: IPv6 Extension Header ID:
0: IPv6 Hop-by-Hop Options Header[RFC2460] 0: IPv6 Hop-by-Hop Options Header[RFC2460]
1: IPv6 Routing Header[RFC2460] 1: IPv6 Routing Header[RFC2460]
2: IPv6 Fragment Header[RFC2460] 2: IPv6 Fragment Header[RFC2460]
3: IPv6 Destination Options Header[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 elided and the next header is encoded 1: The Next Header field is elided and the next header is encoded
using LOWPAN_NHC, which is discussed in Section 4. using LOWPAN_NHC, which is discussed in Section 4.1.
For the most part, the IPv6 Extension Header is carried verbatim in For the most part, the IPv6 Extension Header is carried unmodified 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 a compressed IPv6 Extension Header The Length Field contained in a compressed IPv6 Extension Header
indicates the number of octets that pertain to the (compressed) indicates the number of octets that pertain to the (compressed)
skipping to change at page 16, line 35 skipping to change at page 16, line 49
octets following the Length Field after compression. octets following the Length Field after compression.
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 MUST be set to zero. The of the LOWPAN_NHC encoding is unused and MUST be set to zero. The
following bytes MUST be encoded using LOWPAN_IPHC as defined in following bytes MUST be encoded using LOWPAN_IPHC as defined in
Section 3. Section 3.
4.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 14. Bits
through 4 represent the NHC ID and '11110' indicates the specific UDP 0 through 4 represent the NHC ID and '11110' indicates the specific
header compression encoding defined in this section. UDP header compression encoding defined in this section.
4.3.1. Compressing UDP ports 4.3.1. Compressing UDP ports
This specification introduces a range of well-known ports (0xF0Bx) This specification allows a particular range of ports number (0xF0B0
that can be compressed to 4 bits. Considering that this represents to 0xF0BF) to be compressed down to 4 bits. This is a stateless
only 16 contiguous ports, it can be expected that many incompatible compression that is inherited from [RFC4944], as opposed to a new
applications will use the same port numbers for their own end-to-end stateful compression.
needs.
The range of ports compressible down to 4 bits is not in a reserved
range. A network stack implementation that is designed to
communicate over a 6LoWPAN should avoid using those ports as dynamic
ports whenever possible.
Considering that this represents only 16 contiguous ports, it can be
expected that many incompatible applications will use the same value
of port numbers for their own end-to-end needs. Thus a port number
in the (0xF0B0 to 0xF0BF) range provides very little information
about the application at the remote end.
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 are reserved at IANA. As a result, it is recommended that ports that are reserved at IANA. As a result, it is recommended that
the use of those ports be associated with a mechanism such as a the use of those ports be associated with a mechanism such as a
Transport Layer Security (TLS) Message Integrity Check (MIC) that Transport Layer Security (TLS) [RFC5246] Message Integrity Check
validates that the content is expected and checked for integrity. (MIC) that makes sure that the content is what is expected and is
checked.
4.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 is 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 MUST NOT set the C bit unless it has received
received such authorization. The Upper Layer SHOULD only provide the such authorization. Requiring Upper Layer authorization ensures that
authorization in the following cases: the intended transport peer will have sufficient means to deal with
any data corruption that occurs before reaching the destination. The
Upper Layer MAY only provide the 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 Protocol Data Unit (PDU) possesses its own addressing,
check, the tunneling mechanism MAY authorize to elide the UDP security and integrity check (e.g. IPsec Encapsulating Security
checksum in order to save on the encapsulation overhead. Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the
Upper Layer Message Integrity Check: In this case, there is some tunneling mechanism MAY authorize to elide the UDP checksum in
other form of integrity check in the UDP payload that covers at order to save on the encapsulation overhead.
least the same information as the UDP checksum (pseudo-header,
data) and has at least the same strength.
A forwarding node MAY imply authorization from an incoming packet if Message Integrity Check: In this case, either IPsec Authentication
the C bit is set. A forwarding node that cannot unambiguously derive Header [RFC4302] or some other form of integrity check in the UDP
such authorization SHOULD NOT elide the UDP checksum when performing payload that covers at least the same information as the UDP
6LoWPAN compression. The forwarding node that expands a 6LoWPAN checksum (pseudo-header, data) and has at least the same strength.
packet with the C bit on MUST compute the UDP checksum on behalf of
the source node and place that checksum in the restored UDP header as
specified in the incumbent standards [RFC0768], [RFC2460].
If a 6LoWPAN termination is also the transport endpoint and it To help ensure that the UDP Checksum will be properly restored when
receives a compressed packet with the C bit set, then it is entitled expanding a 6LoWPAN packet, an additional integrity check (e.g. L2
to ignore the UDP checksum process completely. If the C bit is not Message Integrity Check) MUST be used whenever transmitting link
set, the packet might have been forwarded by an edge router, so this frames that carry a compressed UDP datagram that elides the checksum.
is not an indication that the MIC is not present. If the terminating Without this additional integrity check, a UDP packet may be
node knows that the message integrity will be validated by the upper delivered to an unintended destination since corruption in data
layer by some state associated to the Service Access Point, it is covered by the pseudo-header can go undetected.
entitled to ignore the checksum operation as if the C bit was set.
A compressor MUST verify the UDP Checksum before it is elided and
SHOULD ensure that the additional integrity check is in place before
verifying and eliding the checksum. If verification of the UDP
Checksum fails, the compressor MUST drop the packet.
A decompressor that expands a 6LoWPAN packet with the C bit set MUST
compute the UDP Checksum on behalf of the source node and place that
value in the restored UDP header as specified in the incumbent
standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously
determine that an additional integrity check was put in place by the
compressor and verify the integrity check, and SHOULD do so after
restoring the UDP Checksum. If the decompressor cannot unambiguously
determine the presence of an integrity check or verification fails,
the decompressor MUST drop the packet.
The recommended ordering of computing and verify the UDP Checksum and
additional integrity check ensures that data is never stored
unprotected in memory. In practice, functionality separation between
layers may preclude the recommended ordering. However, implementors
should take special note and understand the risks when dealing with
unprotected data covered by the pseudo-header.
To allow intermediate nodes to compress the UDP Checksum, a
forwarding node MAY infer Upper Layer authorization for an incoming
packet if it has the C bit set and it can unambiguously determine
that an integrity check covering the same data as the UDP Checksum
was in place while the UDP Checksum was elided. A forwarding node
MUST NOT infer authorization if it cannot unambiguously determine the
presence of and verify an integrity check while the UDP Checksum was
elided.
4.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 14: 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.
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
skipping to change at page 18, line 40 skipping to change at page 19, line 40
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 UDP header format [RFC0768]. The UDP Length field as they do in the UDP header format [RFC0768]. The UDP Length field
MUST always be elided and is inferred from lower layers using the MUST always be elided and is inferred from lower layers using the
6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
5. 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 the following 32 Dispatch 6LoWPAN. The document allocates the following 32 Dispatch type field
type field values for LOWPAN_IPHC: values for LOWPAN_IPHC:
01 100000 01 100000
through through
01 111111 01 111111
This assignment preempts the assignment of 01 111111 for ESC This assignment preempts the assignment of 01 111111 for ESC
[RFC4944], which is possible as no extension bytes have been [RFC4944], which is possible as no extension bytes have been
allocated yet that would enable the use of ESC. Instead, the value: allocated yet that would enable the use of ESC. Instead, the value:
01 000000 01 000000
skipping to change at page 19, line 50 skipping to change at page 21, line 6
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) [RFC5246] Message Integrity Check (MIC) that validates
content is expected and checked for integrity. that the content is expected and checked for integrity.
7. Acknowledgements 7. Acknowledgements
Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten
Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik
Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach
Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design
consideration and implementation feedback. consideration and implementation feedback.
8. Changes 8. Changes
(This section to be removed by the RFC editor.) (This section to be removed by the RFC editor.)
Draft 14:
- Edits in response to IESG comments.
Draft 13: Draft 13:
- Specify that address bits not covered by the context or IID are - Specify that address bits not covered by the context or IID are
zero. zero.
Draft 12: Draft 12:
- Specify that 16-bit to IID mapping is used to derive IID bits - Specify that 16-bit to IID mapping is used to derive IID bits
when SAC/DAC=1 and the context does not cover those bits. when SAC/DAC=1 and the context does not cover those bits.
Draft 11: Draft 11:
- Removed incorrect and unnecessary text in specifying how to - Removed incorrect and unnecessary text in specifying how to
skipping to change at page 23, line 22 skipping to change at page 24, line 31
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
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Jonathan W. Hui (editor) Jonathan W. Hui (editor)
Arch Rock Corporation Arch Rock Corporation
501 2nd St. Ste. 410 501 2nd St. Ste. 410
San Francisco, California 94107 San Francisco, California 94107
USA USA
Phone: +415 692 0828 Phone: +415 692 0828
Email: jhui@archrock.com Email: jhui@archrock.com
 End of changes. 56 change blocks. 
143 lines changed or deleted 213 lines changed or added

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