draft-ietf-6lowpan-hc-00.txt   draft-ietf-6lowpan-hc-01.txt 
Network Working Group J. Hui Network Working Group J. Hui, Ed.
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Intended status: Standards Track October 6, 2008 Updates: 4944 (if approved) P. Thubert
Expires: April 9, 2009 Intended status: Standards Track Cisco
Expires: April 12, 2009 October 9, 2008
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-00 draft-ietf-6lowpan-hc-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 9, 2009. This Internet-Draft will expire on April 12, 2009.
Abstract Abstract
This document specifies an IPv6 header compression format for IPv6 This document specifies an IPv6 header compression format for IPv6
packet delivery in 6LoWPAN networks. The compression format relies packet delivery in 6LoWPAN networks. The compression format relies
on shared context to allow compression of arbitrary prefixes. This on shared context to allow compression of arbitrary prefixes. This
document specifies compression of well-known multicast addresses and document specifies compression of multicast addresses and a framework
a framework for compressing next headers. UDP compression is for compressing next headers. This framework specifies UDP
specified within this framework. compression and is prepared for additional transports.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4
2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5
2.2. IPv6 Unicast Address Compression . . . . . . . . . . . . . 6 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5
2.3. IPv6 Multicast Address Compression . . . . . . . . . . . . 7 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7
2.4. 16-bit Compressed Address Ranges . . . . . . . . . . . . . 8 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8
3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 9 2.2.1. Traffic Class and Flow Label Encoding . . . . . . . . 8
3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 9 2.2.2. IPv6 Address Encoding for Unicast Destinations . . . . 9
3.2. LOWPAN_UDP Header Compression . . . . . . . . . . . . . . 9 2.2.3. IPv6 Address Encoding for Multicast Destinations . . . 9
3.3. ISA100_UDP Header Compression . . . . . . . . . . . . . . 10 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The IEEE 802.15.4 standard specifies an MTU of 128 bytes, (including The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding
the length byte) on a wireless link with a link throughput of 250 about 80 octets of actual MAC payload once security is turned on, on
kbps or less[ieee802.15.4]. The 6LoWPAN adaptation format [RFC4944] a wireless link with a link throughput of 250 kbps or less. The
was specified to carry IPv6 datagrams over IEEE 802.15.4 links, 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6
taking into account limited bandwidth, memory, or energy resources datagrams over such constrained links, taking into account limited
that are expected in IEEE 802.15.4 applications. The 6LoWPAN bandwidth, memory, or energy resources that are expected in
adaptation format defines a Mesh Addressing header to support sub-IP applications such as wireless Sensor Networks. [RFC4944] defines a
forwarding, a Fragmentation header to support the IPv6 minimum MTU Mesh Addressing header to support sub-IP forwarding, a Fragmentation
requirement [RFC2460], and stateless header compression for IPv6 header to support the IPv6 minimum MTU requirement [RFC2460], and
datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large stateless header compression for IPv6 datagrams (LOWPAN_HC1 and
IPv6 and UDP headers down to (in the best case) several bytes. LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down
to (in the best case) several bytes.
LOWPAN_HC1 is most effective for link-local unicast communication, LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of
where IPv6 addresses carry the link-local prefix and an Interface 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local
Identifier (IID) directly derived from IEEE 802.15.4 addresses. In unicast communication, where IPv6 addresses carry the link-local
this case, both addresses may be completely elided. This scenario is prefix and an Interface Identifier (IID) directly derived from IEEE
most effective when communication remains local to a mesh-under 802.15.4 addresses. In this case, both addresses may be completely
network where any forwarding occurs below IP and all 6LoWPAN nodes elided. However, though link local addresses are commonly used for
are connected by a single IP hop. Even so, LOWPAN_HC1 cannot elide local protocol interactions such as IPv6 ND [RFC4861], DHCPv6
the IPv6 Hop Limit. In cases where communication only occurs over a [RFC3315] or routing protocols, they are usually not used for
single IP hop, there may be cases where a common IPv6 Hop Limit is application layer data traffic, so the actual value of this
used. compression mechanism is limited.
Routable addresses must be used when communicating in a route-over Routable addresses must be used when communicating with devices
network where forwarding occurs at IP or when communicating with external to the LoWPAN or in a route-over configuration where IP
devices external to the 6LoWPAN network. In this scenario, forwarding occurs within the LoWPAN. For routable addresses,
LOWPAN_HC1 requires both IPv6 source and destination addresses to LOWPAN_HC1 requires both IPv6 source and destination addresses to
carry the prefix in-line. Furthermore, in route-over networks, the carry the prefix in-line. In cases where the Mesh Addressing header
Mesh Addressing header may not be used and the IID must be carried is not used, the IID of a routable address must be carried in-line.
in-line. However LOWPAN_HC1 requires 64-bits for the IID when However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line
carried in-line and cannot be shortened even when it is derived and cannot be shortened even when it is derived from the IEEE
directly from the IEEE 802.15.4 16-bit short address. When sending 802.15.4 16-bit short address.
to an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit
multicast address to be carried in-line. Multicast addresses are When the destination is an IPv6 multicast address, LOWPAN_HC1
commonly used for neighbor discovery, such as in IPv6 ND. requires the full 128-bit address to be carried in-line. This
specification provides an additional mechanism to compress Unique
Local, Global and multicast IPv6 Addresses based on shared states
within contexts. It also introduces a number of additional
improvements over [RFC4944].
LOWPAN_HC1 cannot elide the IPv6 Hop Limit in the IPv6 header, even
though a limited set of values are useful in many practical cases.
For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1
for inbound and a default value such as 64 for outbound are usually
enough for application layer data traffic. Compressing that field
enables saving one octet per packet.
LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support
compression of UDP, TCP, or ICMPv6. RFC 4944 [RFC4944] only defines compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed
compression for UDP, where UDP ports may be compressed and the UDP right after the LOWPAN_HC1 octet and before the uncompressed IP
Length may be elided. However, LOWPAN_HC1 also does not provide any fields. This specification moves the transport control octet after
flexibility in supporting future compression mechanisms for next the uncompressed IP fields for a more properly layered structure.
headers other than UDP, TCP or ICMPv6.
[RFC4944] defines a compression mechanism for UDP, but that mechanism
does not enable checksum compression when rendered possible by
additional upper layer mechanisms such as upper layer Message
Integrity Check (MIC). This specification adds the capability to
compress the UDP checksum over the LoWPAN, which enables to save an
additional pair of octets.
Finally, LOWPAN_HC1 lacks the flexibility to support the compression
of additional transport mechanisms that could be introduced in the
future.
This document specifies a header compression format for IPv6 This document specifies a header compression format for IPv6
datagrams. This format improves on the header compression format datagrams. This format improves on the header compression format
defined in RFC 4944 [RFC4944] by generalizing it to support a broader defined in [RFC4944] by generalizing it to support a broader range of
range of communication paradigms, including both mesh-under and communication paradigms, including both mesh-under and route-over
route-over configurations; communication to nodes internal and configurations; communication to nodes internal and external to the
external to the 6LoWPAN network; and multicast communication. This 6LoWPAN network; and multicast communication. This document also
document also defines a flexible framework for compressing arbitrary defines a flexible framework for compressing arbitrary next headers
next headers and defines UDP header compression within this and defines UDP header compression within this framework. This
framework. This compression format carries forward the design compression format carries forward the design concepts in RFC 4944
concepts in RFC 4944 [RFC4944], minimizing any state and relying on [RFC4944], minimizing any state and relying on shared context among
shared context among all nodes in a 6LoWPAN network. all nodes in a 6LoWPAN network.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. IPv6 Header Compression 2. 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
skipping to change at page 4, line 35 skipping to change at page 5, line 10
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 single routable prefix assigned to the entire 6LoWPAN
network; addresses assigned to 6LoWPAN interfaces are formed with an network; addresses assigned to 6LoWPAN interfaces are formed with an
IID derived directly from either the 64-bit extended or 16-bit short IID derived directly from either the 64-bit extended or 16-bit short
IEEE 802.15.4 addresses. IEEE 802.15.4 addresses.
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 2 | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-------------------------------------+------------------------
| LOWPAN_IPHC | Uncompressed fields follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LOWPAN_IPHC Header Figure 1: LOWPAN_IPHC Header
The LOWPAN_IPHC encoding utilizes a two octets, with uncompressed The LOWPAN_IPHC encoding utilizes 11 bits, 3 of which are taken from
fields following, as shown in Figure 1. With the above scenario, the the rightmost bit of the dispatch type. The encoding may be extended
LOWPAN_IPHC can compress the IPv6 header down to two octets (the by another octet to support additional contexts. Uncompressed IPv6
LOWPAN_IPHC encoding) with link-local communication. When header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1.
communicating over multiple IP hops, LOWPAN_IPHC can compress the With the above scenario, the LOWPAN_IPHC can compress the IPv6 header
IPv6 header down to 7 octets (2-octet LOWPAN_IPHC, 1-octet Hop Limit, down to two octets (the dispatch octet and the LOWPAN_IPHC encoding)
2-octet Source Address, and 2-octet Destination Address). with link-local communication. When routing over multiple IP hops,
LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet
dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source
Address, and 2-octet Destination Address).
2.1. LOWPAN_IPHC Encoding Format 2.1. LOWPAN_IPHC Encoding Format
2.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
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| T |VF |NH | HLIM | rsv | SAM | SAC | DAM | DAC | | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC Encoding Figure 2: LOWPAN_IPHC Encoding
T: Traffic Class (bit 0): TF: Traffic Class, Flow Label:
0: Full 8 bits for Traffic Class are carried in-line. 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes)
1: Traffic Class is elided and implicitly 0. 01: ECN + 2-bit Pad + Flow Label (3 bytes)
VF: Version and Flow Label (bit 1): 10: Traffic Class (1 byte)
0: Full 4 bits for Version and 20 bits for Flow Label are carried 11: Version, Traffic Class, and Flow Label are compressed.
in-line. NH: Next Header:
1: Version and Flow Label are elided. Version is implicitly 6.
Traffic Class and Flow Label are implicitly 0.
NH: Next Hop (bit 2): 0: Full 8 bits for Next Header are carried in-line.
0: Full 8 bits for Next Hop are carried in-line. 1: The Next Header field is compressed and the next header is
1: Next Hop is elided and the next header is compressed using compressed using LOWPAN_NHC, which is discussed in Section 3.
LOWPAN_NHC, which is discussed in Section 3. HLIM: Hop Limit:
00: The Hop Limit field is carried in-line.
01: The Hop Limit field is compressed and the the hop limit is 1.
10: The Hop Limit field is compressed and the the hop limit is
64.
11: The Hop Limit field is compressed and the hop limit is 255.
DDF: Destination Dependant Field:
00: Destination and Source are Global or Unique Local Addresses
01: Destination and Source are Global or Unique Local Addresses
and one additional context octet extends the LOWPAN_IPHC field
to disambiguate an elided prefix or address described by the
SAM or DAM fields.
10: Destination and Source are Link Local Addresses
11: Destination is a Multicast Address, Source is either the
unspecified address or a Link Local Address
SAM: Source Address Mode:
When the Destination is a Global or Unique Local Addresses:
00: 128 bits: The whole Source Address is carried in-line.
01: 64 bits: the prefix of Source Address is elided.
10: 16 bits: the first 112 bits of the Source Address are
elided.
11: 0 bit: The Source Address is fully elided.
When the Destination is a Link Local Addresses:
00: Reserved, should not be used
01: 64 bits: the prefix of Source Address is elided.
10: 16 bits: the first 112 bits of the Source Address are
elided.
11: 0 bit: The Source Address is fully elided.
When the Destination is a Multicast Addresses: For the value of
SAM of 00, the Source Address is the unspecified address. For
all values of SAM except 00, the Source Address is the Link
Local Address of the node.
00: 0 bit: The Source Address is the unspecified address and
it is fully elided.
01: 64 bits: the prefix of Source Address is elided.
10: 16 bits: the first 112 bits of the Source Address are
elided.
11: 0 bit: The Source Address is fully elided.
DAM: Destination Address Mode:
When the Destination is a Global or Unique Local Addresses:
00: 128 bits: The whole Destination Address is carried in-
line.
HLIM: Hop Limit (bits 3-4): 01: 64 bits: the prefix of Destination Address is elided.
00: All 8 bits of Hop Limit are carried in-line. 10: 16 bits: the first 112 bits of the Destination Address are
01: All 8 bits of Hop Limit are elided and the Hop Limit is elided.
assumed to be 1. 11: 0 bit: The Destination Address is fully elided.
10: All 8 bits of Hop Limit are elided and the Hop Limit is When the Destination is a Link Local Addresses:
assumed to be 64. 00: Reserved, should not be used
11: All 8 bits of Hop Limit are elided and the Hop Limit is 01: 64 bits: the prefix of Source Address is elided.
assumed to be 255. 10: 16 bits: the first 112 bits of the Source Address are
elided.
11: 0 bit: The Source Address is fully elided.
When the Destination is a Multicast Addresses:
00: 8 bits. Used to compress the most used permanently-
assigned multicast addresses. A prefix of FF02::/120 is
elided.
01: 24 bits. Used to compress Solicited-Node multicast
addresses. A prefix of FF02:0:0:0:0:1:FF00/104 is elided.
10: 16 bits: The Compressed Multicast address fsmg where f is
4-bit flags, s is 4-bit scope, and mg is the least
significant 8 bits of the multicast group identifier FFfs::
00mg.
11: 24 bits: The Compressed Multicast address fsmgmg where f
is 4-bit flags, s is 4-bit scope, and mgmg is the least
significant 16 bits of the multicast group identifier FFfs::
mgmg.
rsv: Reserved (bit 5-7) 2.1.2. Context Identifier Extension
SAC: Source Address Mode (bits 8-9): If the DDF field is set to '01' in the LOWPAN_HC encoding, then an
00: All 128 bits of Source Address are carried in-line. additional octet extends the LOWPAN_HC encoding following the DAM
01: 64-bit Compressed IPv6 address. bits but before the IPv6 header fields that are carried in-line. The
10: 16-bit Compressed IPv6 address. additional octet identifies the prefix when the IPv6 source and/or
11: All 128 bits of Source Address are elided. destination address is compressed. The context identifier is 4 bits
for each address, supporting up to 16 contexts. The encoding is
shown in Figure 3.
SAC: Source Address Context (bits 10-11): Identifies the compression 0 1 2 3 4 5 6 7
context when the source address is compressed. The value '00' is +---+---+---+---+---+---+---+---+
reserved and indicates a link-local address. | SAC | DAC |
+---+---+---+---+---+---+---+---+
DAM: Destination Address Mode (bits 12-13): Figure 3: LOWPAN_IPHC Encoding
00: All 128 bits of Destination Address are carried in-line. SAC: Source Address Context Identifies the prefix that is used when
01: 64-bit Compressed IPv6 address. the IPv6 source address is compressed.
10: 16-bit Compressed IPv6 address. DAC: Destination Address Context Identifies the prefix that is used
11: All 128 bits of Destination Address are elided. when the IPv6 destination address is compressed.
DAC: Destination Address Context (bits 14-15): Identifies the 2.2. IPv6 Header Encoding
compression context when the destination address is compressed.
The value '00' is reserved and indicates a link-local address.
Fields carried in-line (in part or in whole) appear in the same order Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC2460]. IPv6 addresses may as they do in the IPv6 header format [RFC2460]. The Version field is
be compressed to 64 or 16 bits or completely elided. The IPv6 always elided. Unicast IPv6 addresses may be compressed to 64 or 16
Payload Length field MUST always be elided and inferred from lower bits or completely elided. Multicast IPv6 addresses may be
layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST
header. always be elided and inferred from lower layers using the 6LoWPAN
Fragmentation header or the IEEE 802.15.4 header.
2.2. IPv6 Unicast Address Compression
IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. When
an IPv6 unicast address is compressed, the compression context
identifies the value of the elided bits. A compression value of '00'
indicates the link-local prefix. The mapping between a specific
context and prefix may be obtained through simple modifications to
IPv6 Neighbor Discovery. However, the specification of those
mechanisms are out of scope of this document. Care should be taken
when renumbering a network. Nodes SHOULD only use a context after
all of its neighbors have been configured with the same context
information with high probability. New information within a context
SHOULD only be assigned after all nodes in the network have received
notification of its deprecation with high probability.
There may be cases where the compressor and decompressor are out of 2.2.1. Traffic Class and Flow Label Encoding
sync within a context. In this cases, the decompressor may
reconstruct the IPv6 address using the incorrect prefix. To prevent
such errors, upper-layer integrity checks (e.g. psuedo-header
checksum) that cover both source and destination addresses SHOULD be
used.
When an IPv6 unicast address is compressed to 64 bits, the last 64 The TF field in the LOWPAN_HC encoding indicate whether the Traffic
bits are carried in-line. When an IPv6 unicast address is compressed Class and Flow Label are carried in-line in the compressed IPv6
to 16 bits, the last 16 bits are carried in line. Because the 16-bit header. When Flow Label is included while the Traffic Class is
compressed form is also used for IPv6 multicast address compression, compressed, an additional 4 bits are included to maintain byte-
the 16-bit address space is divided into multiple ranges. For alignment. Two of the 4 bits contain the ECN bits from the Traffic
unicast addresses, the first bit carried in-line must be zero. Class field.
1 To ensure that the ECN bits appear in the same location for all
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 encodings that include them, the Traffic Class field is rotated right
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ by 2 bits in the compressed IPv6 header. The encodings are shown
|0| Last 15 bits of IPv6 Addr | below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 16-bit Compressed IPv6 Unicast Address Encoding 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When an address is completely elided, the IID is inferred from lower TF = 00
layers (either from the 6LoWPAN Mesh Addressing header or from the
IEEE 802.15.4 header). The prefix is inferred from the identified
context. Any remaining bits in between are implicitly zero.
To elide the IID, it MUST be derivable from IEEE 802.15.4 addresses. 1 2
An IID may be derived from the IEEE EUI-64 address by creating a 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
Modified EUI-64 IID from the IEEE EUI-64 address, as defined in RFC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4291 [RFC4291]. The universal/local bit in the Modified IEEE EUI-64 |ECN|rsv| Flow Label |
IID must be set to '1', indicating universal scope. An IID may also +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
be derived from the 16-bit short address and PAN ID, as defined in TF = 01
RFC 4944 [RFC4944]. Note, however, that the most significant bit in
the short address must be zero.
2.3. IPv6 Multicast Address Compression 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN| DSCP |
+-+-+-+-+-+-+-+-+
IPv6 multicast addresses may be compressed to 16 bits by utilizing a TF = 10
different 6LoWPAN short address range. This document allocates
another range of 8192 values to be used for well-known IPv6 multicast
addresses.
1 2.2.2. IPv6 Address Encoding for Unicast Destinations
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Range| Scope | Mapped Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Compressed IPv6 Multicast Address Encoding IPv6 unicast addresses may be carried in-line in full or or
compressed to 64, 16, or 0 bits. When compressed, the bits carried
in-line represent the least significant bits of the suffix. The
value of the prefix depends on the value of the DDF field and
possibly the SAC field in the Context Identifier Extension.
Range (bits 0-2): Must be set to '101' (TBD), which identifies the Destination is Global with No Context ID (DDF = 00): When the
6LoWPAN short address range for compressed IPv6 multicast source and/or destination addresses are compressed, the prefix is
addresses. identified by context 0.
Scope (bits 3-6): 4-bit multicast scope as specified in RFC 4007 Destination is Global with Context ID (DDF = 01): When the source
[RFC4007]. and/or destination addresses are compressed, the prefix is
Mapped Group ID (bits 7-15): 9-bit mapped multicast group identified by the SAC and DAC fields in the Context Identifier
identifier. Extension, respectively.
Destination is Link-Local Unicast (DDF = 10): When the source
and/or destination addresses are compressed, the prefix is the
link-local unicast prefix (FE80::/10).
The full 128-bit multicast address can be reconstructed from the 16- When an address is completely elided, the lower bits are inferred
bit mapped multicast address. By definition, the 3-bit range from lower layers (either from the 6LoWPAN Mesh Addressing header or
identifier indicates the well-known multicast prefix (0xFF) in from the IEEE 802.15.4 header). Specifically, if the lower-layer
addition to a flags field set to all zeros (indicating a permanently header contains an extended 802.15.4 address, then a 64-bit suffix is
assigned multicast address, that the multicast address is not derived from the lower-layer header. If the lower-layer header
assigned based on the network prefix, and that it doesn't embed the contains short 802.15.4 address, then a 16-bit suffix is derived from
address of a Rendezvous Point). The 4-bit scope is carried in-line the lower-layer header.
and the 112-bit group ID is derived from the 9-bit mapped group ID
using a well-known mapping maintained by the Internet Assigned
Numbers Authority (IANA).
Nodes MUST accept both the compressed and uncompressed form of well- 2.2.3. IPv6 Address Encoding for Multicast Destinations
known multicast addresses that they subscribe to. Doing so removes
any ambiguity of which form to use as both will work. Conversely,
nodes MUST NOT subscribe to well-known multicast addresses that are
not defined by the well-known mapping.
This document defines an initial mapping. Additional mappings IPv6 source addresses with link-local scope may be compressed when
between 9-bit mapped group IDs and 112-bit group IDs may be specified the destination address is a multicast address. The IPv6 source
in the future. address may be compressed to 64, 16, or 0 bits. The encoding also
supports the compression of the unspecified address (::).
+-------+---------+-----------------------+ SAM = 00: Source Address is the unspecified address and all 128 bits
| 9-bit | 112-bit | Description | are elided.
+-------+---------+-----------------------+ SAM = 01: 64-bit prefix is elided and is the link-local (FE80::/10).
| 1 | 1 | All Nodes Addresses | 64-bit Suffix is carried in-line.
| 2 | 2 | All Routers Addresses | SAM = 10: 112-bit prefix is elided and is the link-local
+-------+---------+-----------------------+ (FE80::/10). 16-bit Suffix is carried in-line.
SAM = 11: All 128 bits of Source Address are elided. The prefix is
the link-local prefix (FE80::/10). The suffix is derived from
lower-layer headers.
9-bit to 112-bit Group ID Mapping IPv6 multicast addresses may be comrpessed down to 24, 16, or 8 bits.
The format supports compression of the Solicited-Node Multicast
Address (FF02::1:FFXX:XXXX) as well as any IPv6 multicast address
where the upper 104 bits of the multicast group identifier are zero
(FFXX::XXXX). The encoding format also compressed link-local
multicast addresses of the form (FF02::00XX) down to a single byte.
The compressed form only carries least-significant bits of the
multicast group identifier.
2.4. 16-bit Compressed Address Ranges 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+
To use the 16-bit compressed address format for different kinds of DAM = 00. 8-bit Compressed Multicast Address (FF02::00mg)
addresses (e.g. unicast or multicast), LOWPAN_IPHC utilizes the 16-
bit short address ranges as specified in RFC 4944. This document
specifies another range, for compressed multicast addresses.
Range 0, 0xxxxxxxxxxxxxxx: As specified in RFC 4944. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last 24 bits of Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Range 2, 100xxxxxxxxxxxxx: As specified in RFC 4944. DAM = 01. Compressed Solicited-Node Address (FF02::1:FFXX:XXXX).
Range 1, 101xxxxxxxxxxxxx: The remaining 13 bits represent a 1
compressed IPv6 multicast address, as described in Section 2.3. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 10. 16-bit Compressed Multicast Address (FFfs::00mg).
Range 3, 110xxxxxxxxxxxxx: Reserved. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Last 16 bits of Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Range 4, 111xxxxxxxxxxxxx: Reserved. DAM = 11. 24-bit Compressed Multicast Address (FFfs::mgmg).
3. IPv6 Next Header Compression 3. IPv6 Next Header Compression
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set
to 1. It also indicates the use of 6LoWPAN next header compression, to 1. It also indicates the use of 6LoWPAN next header compression,
LOWPAN_NHC. The value of IPv6 Next Header is recovered from the LOWPAN_NHC. The value of IPv6 Next Header is recovered from the
first bits in the LOWPAN_NHC encoding. The following bits are first bits in the LOWPAN_NHC encoding. The following bits are
specific to the IPv6 Next Header value. Figure 5 shows the structure specific to the IPv6 Next Header value. Figure 4 shows the structure
of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields | | Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
Figure 5: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
3.1. LOWPAN_NHC Format 3.1. LOWPAN_NHC Format
Compression formats for different next headers are identified by a Compression formats for different next headers are identified by a
variable length bit-pattern immediately following the LOWPAN_IPHC variable length bit-pattern immediately following the LOWPAN_IPHC
compressed header. When defining a next header compression format, compressed header. When defining a next header compression format,
the number of bits used SHOULD be determined by the perceived the number of bits used SHOULD be determined by the perceived
frequency of using that format. However, the number of bits and any frequency of using that format. However, the number of bits and any
remaining encoding bits SHOULD respect octet alignment. The remaining encoding bits SHOULD respect octet alignment. The
following bits are specific to the next header compression format. following bits are specific to the next header compression format.
In this document, we define a compression format for UDP headers. In this document, we define a compression format for UDP headers.
+----------------+--------------------------- +----------------+---------------------------
| var-len NHC ID | compressed next header... | var-len NHC ID | compressed next header...
+----------------+--------------------------- +----------------+---------------------------
Figure 5: LOWPAN_NHC Encoding
Figure 6: LOWPAN_NHC Encoding 3.2. UDP Header Compression
3.2. LOWPAN_UDP Header Compression
This document defines a compression format for UDP headers using
LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7.
Bits 0 through 5 represent the NHC ID and '111110' indicates the
specific UDP header compression encoding defined in this section.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 0 | S | D |
+---+---+---+---+---+---+---+---+
Figure 7: Compressed UDP Header Encoding
S: Source Port (bit 6):
0: All 16 bits of Source Port are carried in-line.
1: First 12 bits of Source Port are elided and the remaining 4
bits are carried in-line. The Source Port is recovered by: P +
short_port, where P is 61616 (0xF0B0).
D: Destination Port (bit 7):
0: All 16 bits of Destination Port are carried in-line.
1: First 12 bits of Destination Port are elided and the remaining
4 bits are carried in-line. The Destination Port is recovered
by: P + short_port, where P is 61616 (0xF0B0).
Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC0768]. IPv6 addresses may
be compressed to 64 or 16 bits or completely elided. The UDP Length
field MUST always be elided and is inferred from lower layers using
the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
3.3. ISA100_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 LOWPAN_UDP compression format is shown in Figure 8. LOWPAN_NHC. The UDP compression format is shown in Figure 6. Bits 0
Bits 0 through 4 represent the NHC ID and '11110' indicates the through 4 represent the NHC ID and '11110' indicates the specific UDP
specific UDP header compression encoding defined in this section. header compression encoding defined in this section.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | S | D | | 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 8: Compressed ISA100.11a UDP Header Encoding Figure 6: UDP Header Encoding
C: Checksum (bit 5): C: Checksum:
0: All 16 bits of Checksum are carried in-line. The Checksum MUST 0: All 16 bits of Checksum are carried in-line. The Checksum MUST
be included if there are no other end-to-end integrity checks be included if there are no other end-to-end integrity checks
that are stronger than what is provided by the UDP checksum. that are stronger than what is provided by the UDP checksum.
Such an integrity check MUST be end-to-end and cover the IPv6 Such an integrity check MUST be end-to-end and cover the IPv6
pseudo-header, UDP header, and UDP payload. pseudo-header, UDP header, and UDP payload.
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. by recomputing it.
P: Ports:
S: Source Port (bit 6): 00: All 16 bits for both Source Port and Destination Port are
0: All 16 bits of Source Port are carried in-line. carried in-line.
1: First 12 bits of Source Port are elided and the remaining 4 01: All 16 bits for Source Port are carried in-line. First 8
bits are carried in-line. The Source Port is recovered by: P + bits of Destination Port is 0xF0 and elided. The remaining 8
short_port, where P is 61616 (0xF0B0). bits of Destination Port are carried in-line.
10: First 8 bits of Source Port are 0xF0 and elided. The
D: Destination Port (bit 7): remaining 8 bits of Source Port are carried in-line. All 16
0: All 16 bits of Destination Port are carried in-line. bits for Destination Port are carried in-line.
1: First 12 bits of Destination Port are elided and the remaining 11: First 12 bits of both Source Port and Destination Port are
4 bits are carried in-line. The Destination Port is recovered 0xF0B and elided. The remaining 4 bits for each are carried
by: P + short_port, where P is 61616 (0xF0B0). in-line.
Fields carried in-line (in part or in whole) appear in the same order Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC0768]. IPv6 addresses may as they do in the IPv6 header format [RFC2460]. IPv6 addresses may
be compressed to 64 or 16 bits or completely elided. The UDP Length be compressed to 64 or 16 bits or completely elided. The UDP Length
field MUST always be elided and is inferred from lower layers using field MUST always be elided and is inferred from lower layers using
the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
4. IANA Considerations 4. 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 a new Dispatch type value 6LoWPAN networks. The document allocates Dispatch type values of
of 0x03 (TBD) for LOWPAN_IPHC. 0x08-0x0F (TBD) for LOWPAN_IPHC.
This document reserves another 16-bit short address range from RFC
4944 for use with 16-bit compressed well-known IPv6 multicast
addresses.
This document creates a new IANA registry for mapped well-known
multicast addresses, mapping 112-bit group identifiers to compressed
9-bit ones. The registry MUST include the All Nodes Address (1) and
the All Routers Address (2).
5. Security Considerations 5. Security Considerations
The definition of LOWPAN_IPHC permits the compression of header The definition of LOWPAN_IPHC permits the compression of header
information on communication that could take place in its absence, information on communication that could take place in its absence,
albeit in a less efficient form. It recognizes that a IEEE 802.15.4 albeit in a less efficient form. It recognizes that a IEEE 802.15.4
PAN may have associated with it a global prefix. How that global PAN may have associated with it a number of prefixes through shared
prefix is assigned and managed is beyond the scope of this document. context. How the shared context is assigned and managed is beyond
the scope of this document.
6. Acknowledgements 6. Acknowledgements
Thanks to Pascal Thubert for useful discussions in helping shape the Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, and Jay
header compression mechanisms. Thanks to Carsten Bormann for useful Werb for useful feedback and discussion.
feedback and discussion.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[ieee802.15.4] 7.2. Informative References
[IEEE 802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2006", IEEE Computer Society, "IEEE Std. 802.15.4-2006",
October 2006. October 2006.
7.2. Informative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Text on Security Considerations", BCP 72, RFC 3552, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
July 2003. September 2007.
Author's Address Authors' Addresses
Jonathan W. Hui 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
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 70 change blocks. 
311 lines changed or deleted 357 lines changed or added

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