draft-ietf-6lowpan-hc-06.txt   draft-ietf-6lowpan-hc-07.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: April 8, 2010 October 5, 2009 Expires: October 10, 2010 April 8, 2010
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-06 draft-ietf-6lowpan-hc-07
Abstract
This document specifies an IPv6 header compression format for IPv6
packet delivery in 6LoWPAN networks. The compression format relies
on shared context to allow compression of arbitrary prefixes. How
the information is maintained in that shared context is out of scope.
This document specifies compression of multicast addresses and a
framework for compressing next headers. UDP header compression is
specified within this framework.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 10, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies an IPv6 header compression format for IPv6 described in the Simplified BSD License.
packet delivery in 6LoWPAN networks. The compression format relies
on shared context to allow compression of arbitrary prefixes. How
the information is maintained in that shared context is out of scope.
This document specifies compression of multicast addresses and a
framework for compressing next headers. This framework specifies UDP
compression.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Specific Updates to RFC 4944 . . . . . . . . . . . . . . . . . 4 2. Specific Updates to RFC 4944 . . . . . . . . . . . . . . . . . 4
3. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 5
3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 8 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 8
3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9
3.2.1. Traffic Class and Flow Label Compression . . . . . . . 9 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 9
3.2.2. Stateless Multicast Addresses Compression . . . . . . 10 3.2.2. Mapping Link-Layer Addresses to Interface IDs . . . . 10
3.2.3. Stateful Multicast Addresses Compression . . . . . . . 11 3.2.3. Stateless Multicast Addresses Compression . . . . . . 11
4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 12 3.2.4. Stateful Multicast Addresses Compression . . . . . . . 12
4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 13
4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 12 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 13
4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 14 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 14
4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 14 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 15
4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 15 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 15
4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 15 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 with security enabled, on a about 80 octets of actual MAC payload with security enabled, on 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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
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 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. Additionally, a hop-limit enough for application layer data traffic. Additionally, a hop-limit
value of 255 is often used for verify that a communication occurs value of 255 is often used to verify that a communication occurs over
over a single-hop. This specification enables to compress the IPv6 a single-hop. This specification enables compression of the IPv6 Hop
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.
In contrast, LOWPAN_HC1 could be extended to support compression of In contrast, LOWPAN_HC1 could be extended to support compression of
next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6.
Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet
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 to save an elide the UDP checksum over the LoWPAN, which enables saving of a
additional pair of 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 can not 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 Section 10 decompression, but SHOULD implementations MAY implement compression according to Section 10 of
NOT send section-10-compressed packets. [RFC4944], but SHOULD NOT send packets compressed according to
Section 10 of [RFC4944].
Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6
datagrams that do not fit within a single link frame. Section 5.3 of
[RFC4944] defines the fragment header's datagram_size and
datagram_offset values as the size and offset of the IPv6 datagram
before compression. As a result, all fragment payload outside the
first fragment must carry their respective portions of the IPv6
datagram before compression. This document does not change that
requirement. When using the fragmentation mechanism described in
Section 5.3 of [RFC4944], any header that cannot fit within the first
fragment MUST NOT be compressed.
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 is reserved as a replacement value for ESC, to value of 01 000000 is reserved as a replacement value for ESC, to be
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 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
prefix or a single routable prefix assigned to the entire 6LoWPAN prefix or a small set of routable prefixes assigned to the entire
network; addresses assigned to 6LoWPAN interfaces are formed with an 6LoWPAN network; addresses assigned to 6LoWPAN interfaces are formed
IID derived directly from either the 64-bit extended or 16-bit short with an IID derived directly from either the 64-bit extended or 16-
IEEE 802.15.4 addresses. bit short IEEE 802.15.4 addresses.
+-------------------------------------+------------------------ +-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header | 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. Uncompressed IPv6 by another octet to support additional contexts. Any information
header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. from the uncompressed IPv6 header fields carried in-line follow the
With the above scenario, the LOWPAN_IPHC can compress the IPv6 header LOWPAN_IPHC encoding, as shown in Figure 1. In the best case, the
down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) LOWPAN_IPHC can compress the IPv6 header down to two octets (the
with link-local communication. dispatch octet and the LOWPAN_IPHC encoding) with link-local
communication.
When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6
header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC,
1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination
Address). The Hop Limit may not be compressed because it needs to Address). The Hop Limit may not be compressed because it needs to
decremented at each hop and may take any value. Stateful address decremented at each hop and may take any value. Stateful address
compression must be applied to the source and destination IPv6 compression must be applied to the source and destination IPv6
addresses because they do not statelessly match the source and addresses because they do not statelessly match the source and
destination link layer addresses on intermediate hops. destination link layer addresses on intermediate hops.
3.1. LOWPAN_IPHC Encoding Format 3.1. LOWPAN_IPHC Encoding Format
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 litteraly. a compressed form if the field is partially elided, or literally.
3.1.1. Base Format 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 base Encoding Figure 2: LOWPAN_IPHC base Encoding
skipping to change at page 6, line 28 skipping to change at page 6, line 43
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.
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 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 the hop limit is 10: The Hop Limit field is compressed and the hop limit is 64.
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,
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
skipping to change at page 7, line 4 skipping to change at page 7, line 18
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:
If SAC=0: If SAC=0:
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 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 in-line.
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 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 link-layer The remaining 64 bits are computed from the link-layer
address as defined in [RFC4944]. address as defined 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 inline. and the 64 bits carried in-line.
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 in-line.
11: 0 bits. The address is derived using context information 11: 0 bits. The address is fully elided. The prefix is
and possibly the link-layer addresses. derived using context information. Any of the remaining 64
bits not covered by the context information are computed
from the link-layer address as defined in Section 3.2.2.
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.
DAM: Destination Address Mode: DAM: Destination Address Mode:
If M=0 and DAC=0 This case matches SAC=0 but for the destination If M=0 and DAC=0 This case matches SAC=0 but for the destination
address: 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 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 in-line.
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 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 link-layer The remaining 64 bits are computed from the link-layer
address as defined in [RFC4944]. address as defined 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 inline. and the 64 bits carried in-line.
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 in-line.
11: 0 bits. The address is derived using context information 11: 0 bits. The address is fully elided. The prefix is
and possibly the link-layer addresses. derived using context information. Any of the remaining 64
bits not covered by the context information are computed
from the link-layer address as defined in Section 3.2.2.
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
that are carried inline, in the order in which they appear that are carried in-line, in the order in which they appear
in this format. P denotes nibbles used to encode the prefix in this format. P denotes nibbles used to encode the prefix
itself. L denotes nibbles used to encode the prefix length. itself. L denotes nibbles used to encode the prefix length.
The prefix information P and L is taken from the specified The prefix information P and L is taken from the specified
context. context.
01: reserved 01: reserved
10: reserved 10: reserved
11: reserved 11: reserved
3.1.2. Context Identifier Extension 3.1.2. Context Identifier Extension
skipping to change at page 10, line 24 skipping to change at page 10, line 40
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.
3.2.2. Stateless Multicast Addresses Compression 3.2.2. Mapping Link-Layer Addresses to Interface IDs
LOWPAN_IPHC elides the IIDs of source or destination addresses when
SAM = 3 or DAM = 3, respectively. This section defines the mapping
from IEEE 802.15.4 link-layer addresses to IIDs for both short and
extended IEEE 802.15.4 addresses. IID bits not covered by the
context information MAY be elided if they match the link-layer
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
address. Generating an IID from an extended address is identical 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
invert the universal/local bit.
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
setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
address, and all other bits to zero. As a result, an IID generated
from a short address has the form:
0000:00ff:fe00:XXXX
where XXXX carries the short address. The universal/local bit is
zero to indicate local scope.
This mapping for non-EUI-64 identifiers differs from that presented
in Appendix A of [RFC4291] for a couple reasons. Using the
restricted space ensures no overlap with IIDs generated from
unrestricted IEEE EUI-64 addresses. Also, including 0xfffe in the
middle of the IID helps avoid overlap with other locally managed
IIDs.
3.2.3. 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 DAC = 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, 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 8-bit
forms only carry the least-significant bits of the multicast group compressed form only carries the least-significant bits of the
identifier. The 48 and 32-bit compressed forms carry the multicast multicast group identifier. The 48 and 32-bit compressed forms carry
scope and flags in-line. the multicast scope and flags in-line, in addition to the least-
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) 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). 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). DAM = 11. 8-bit Compressed Multicast Address (FF02::gg).
3.2.3. Stateful Multicast Addresses Compression 3.2.4. 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 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.
skipping to change at page 14, line 8 skipping to change at page 15, line 13
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 Length Field definition LOWPAN_NHC byte. Note that this changes the Length Field definition
in [RFC2460] 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 MUST NOT be
to encode IPv6 Extension Headers that exceed 255 octets. used 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 for octet-alignment purposes. When using to pad out the header for octet-alignment purposes. When using
LOWPAN_NHC, those Pad1 and PadN options MAY be elided and the length LOWPAN_NHC, Pad1 and PadN options that appear at the end of the
of the header reduced by the size of those Pad1 and PadN options. options header MAY be elided. When converting from the LOWPAN_NHC
When converting from the LOWPAN_NHC encoding back to the standard encoding back to the standard IPv6 encoding, Pad1 and PadN options
IPv6 encoding, Pad1 and PadN options MUST be used to pad out the MUST be used to pad out the containing header to a multiple of 8
containing header to a multiple of 8 octets in length if necessary. octets in length. Note that Pad1 and PadN options that appear in
Note that Pad1 and PadN options that do not appear at the end of the locations other than the end MUST be carried in-line as they are used
containing header MUST be carried in-line as they are used to align to 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 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 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.
4.3.1. Compressing UDP ports 4.3.1. Compressing UDP ports
This specification introduces a range of well-known ports (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 for 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 are reserved at IANA. As a result, it is recommended that
those ports be associated with a mechanism such as a Transport Layer the use of those ports be associated with a mechanism such as a
Security (TLS) Message Integrity Check (MIC) that validates that the Transport Layer Security (TLS) Message Integrity Check (MIC) that
content is expected and checked for integrity. validates that the content is expected and checked for integrity.
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 SHOULD NOT set the C bit unless it has
skipping to change at page 17, line 23 skipping to change at page 18, line 23
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.
7. Acknowledgements 7. Acknowledgements
Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten
Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik
Dawson-Haggerty, Jay Werb and Mathilde Durvy for useful design Nordmark, Christos Polyzois, Shoishi Sakane, Zach Shelby, Tony
consideration and implementation feedback. Viscardi, and Jay Werb for useful design consideration and
implementation feedback.
8. Changes 8. Changes
Draft 07:
- Added section on mapping link-layer addresses to IIDs.
- Added text on restricting compressed headers to first fragment
when using fragment headers defined in Section 5.3 of [RFC4944].
- Minor editorial edits.
Draft 06: Draft 06:
- Reworked introduction. - Reworked introduction.
- Added section on updates to [RFC4944].
- Fixed description of number of bits used for IPHC encoding. - Fixed description of number of bits used for IPHC encoding.
- Specify M=0 only for non-multicast addresses and M=1 only for - Specify M=0 only for non-multicast addresses and M=1 only for
multicast addresses. multicast addresses.
- Move 128-bit multicast encoding to DAC=0. - Move 128-bit multicast encoding to DAC=0.
- Redefined ESC dispatch value to 01 000000. - Redefined ESC dispatch value to 01 000000.
- Many detailed edits. - 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 in-line bits as an additional index to identify the compressed
address. address.
- Removed support for compressing unspecified address. - Removed support for compressing unspecified address.
- Full 128-bit addr inline only in stateless encoding. - Full 128-bit addr in-line only in stateless encoding.
Draft 04: Draft 04:
- Fixed typos leftover from the changes in 03. - Fixed typos leftover from the changes in 03.
- Gave more details on UDP checksum compression. - Gave more details on UDP checksum compression.
- Clarify that the context information is out of scope. - Clarify that the context information is out of scope.
- Added security concern on 0xF0Bx port overloading. - Added security concern on 0xF0Bx port overloading.
Draft 03: Draft 03:
- Decoupled meaning of SAM bits from the destination address. - Decoupled meaning of SAM bits from the destination address.
- Have separate bit to indicate multicast address compression. - Have separate bit to indicate multicast address compression.
 End of changes. 47 change blocks. 
119 lines changed or deleted 173 lines changed or added

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