draft-ietf-6lowpan-hc-03.txt   draft-ietf-6lowpan-hc-04.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: May 21, 2009 November 17, 2008 Expires: June 11, 2009 December 8, 2008
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-03 draft-ietf-6lowpan-hc-04
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 35 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 May 21, 2009. This Internet-Draft will expire on June 11, 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 information to allow compression of arbitrary
document specifies compression of multicast addresses and a framework prefixes and addresses. This document specifies an interface to an
for compressing next headers. This framework specifies UDP abstract context database but the content and the management of the
compression and is prepared for additional transports. database are out of scope. This document specifies compression of
multicast addresses and a framework for compressing next headers.
This framework specifies UDP 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.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7
2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8
2.2.1. Traffic Class and Flow Label Compression . . . . . . . 8 2.2.1. Traffic Class and Flow Label Compression . . . . . . . 9
2.2.2. Stateless Multicast Addresses Compression . . . . . . 9 2.2.2. Stateless Multicast Addresses Compression . . . . . . 10
2.2.3. Stateful Multicast Addresses Compression . . . . . . . 10 2.2.3. Stateful Multicast Addresses Compression . . . . . . . 11
3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11
3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 11 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12
3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12 3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Compressing UDP ports . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 3.2.2. Compressing UDP checksum . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 14
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding
about 80 octets of actual MAC payload once security is turned on, on about 80 octets of actual MAC payload once security is turned on, on
a wireless link with a link throughput of 250 kbps or less. The a wireless link with a link throughput of 250 kbps or less. The
6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6
datagrams over such constrained links, taking into account limited datagrams over such constrained links, taking into account limited
bandwidth, memory, or energy resources that are expected in bandwidth, memory, or energy resources that are expected in
applications such as wireless Sensor Networks. [RFC4944] defines a applications such as Wireless Sensor Networks. [RFC4944] defines a
Mesh Addressing header to support sub-IP forwarding, a Fragmentation Mesh Addressing header to support sub-IP forwarding, a Fragmentation
header to support the IPv6 minimum MTU requirement [RFC2460], and header to support the IPv6 minimum MTU requirement [RFC2460], and
stateless header compression for IPv6 datagrams (LOWPAN_HC1 and stateless header compression for IPv6 datagrams (LOWPAN_HC1 and
LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down
to (in the best case) several bytes. to (in the best case) several bytes.
LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of
6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local
unicast communication, where IPv6 addresses carry the link-local unicast communication, where IPv6 addresses carry the link-local
prefix and an Interface Identifier (IID) directly derived from IEEE prefix and Interface Identifiers (IID) directly derived from IEEE
802.15.4 addresses. In this case, both addresses may be completely 802.15.4 addresses. In this case, both addresses may be completely
elided. However, though link local addresses are commonly used for elided. However, though link-local addresses are commonly used for
local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6
[RFC3315] or routing protocols, they are usually not used for [RFC3315] or routing protocols, they are not normally used for
application layer data traffic, so the actual value of this application layer data traffic, so the actual value of this
compression mechanism is limited. compression mechanism is limited.
Routable addresses must be used when communicating with devices Routable addresses must be used when communicating with devices
external to the LoWPAN or in a route-over configuration where IP external to the LoWPAN or in a route-over configuration where IP
forwarding occurs within the LoWPAN. For routable addresses, forwarding occurs within the LoWPAN. For routable addresses,
LOWPAN_HC1 requires both IPv6 source and destination addresses to LOWPAN_HC1 requires both IPv6 source and destination addresses to
carry the prefix in-line. In cases where the Mesh Addressing header carry the prefix in-line. In cases where the Mesh Addressing header
is not used, the IID of a routable address must be carried in-line. is not used, the IID of a routable address must be carried in-line.
However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line
skipping to change at page 4, line 16 skipping to change at page 4, line 16
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; that LOWPAN_HC2 octet is placed compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed
right after the LOWPAN_HC1 octet and before the uncompressed IP right after the LOWPAN_HC1 octet and before the uncompressed IP
fields. This specification moves the transport control octet after fields. This specification moves the transport control octet after
the uncompressed IP fields for a more properly layered structure. the uncompressed IP fields for a more properly layered structure.
[RFC4944] defines a compression mechanism for UDP, but that mechanism [RFC4944] defines a compression mechanism for UDP, but that mechanism
does not enable checksum compression when rendered possible by does not enable checksum compression when rendered possible by
additional upper layer mechanisms such as upper layer Message additional upper layer mechanisms such as upper layer Message
Integrity Check (MIC). This specification adds the capability to Integrity Check (MIC). This specification adds the capability to
compress the UDP checksum over the LoWPAN, which enables to save an elide the UDP checksum over the LoWPAN, which allows savings of two
additional pair of octets. additional octets.
Finally, LOWPAN_HC1 lacks the flexibility to support the compression Finally, LOWPAN_HC1 lacks the flexibility to support the compression
of additional transport mechanisms that could be introduced in the of additional transport mechanisms that could be introduced in the
future. 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 [RFC4944] by generalizing it to support a broader range of defined in [RFC4944] by generalizing it to support a broader range of
communication paradigms, including both mesh-under and route-over communication paradigms, including both mesh-under and route-over
configurations; communication to nodes internal and external to the configurations; communication to nodes internal and external to the
6LoWPAN network; and multicast communication. This document also 6LoWPAN network; and multicast communication. This document also
defines a flexible framework for compressing arbitrary next headers defines a flexible framework for compressing arbitrary next headers
and defines UDP header compression within this framework. This and defines UDP header compression within this framework. This
compression format carries forward the design concepts in RFC 4944 compression format carries forward the design concepts in RFC 4944
[RFC4944], minimizing any state and relying on shared context among [RFC4944], minimizing compression state and state maintenance by
all nodes in a 6LoWPAN network. relying on shared context among all nodes in a 6LoWPAN network.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. IPv6 Header Compression 2. 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 5, line 16 skipping to change at page 5, line 16
network; addresses assigned to 6LoWPAN interfaces are formed with an network; addresses assigned to 6LoWPAN interfaces are formed with an
IID derived directly from either the 64-bit extended or 16-bit short IID derived directly from either the 64-bit extended or 16-bit short
IEEE 802.15.4 addresses. IEEE 802.15.4 addresses.
+-------------------------------------+------------------------ +-------------------------------------+------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header
+-------------------------------------+------------------------ +-------------------------------------+------------------------
Figure 1: LOWPAN_IPHC Header Figure 1: LOWPAN_IPHC Header
The LOWPAN_IPHC encoding utilizes 11 bits, 3 of which are taken from The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from
the rightmost bit of the dispatch type. The encoding may be extended the rightmost bits of the dispatch type. The encoding may be
by another octet to support additional contexts. Uncompressed IPv6 extended by another octet to support additional contexts.
header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. Uncompressed IPv6 header fields follow the LOWPAN_IPHC encoding, as
With the above scenario, the LOWPAN_IPHC can compress the IPv6 header shown in Figure 1. With the above scenario, the LOWPAN_IPHC can
down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) compress the IPv6 header down to two octets (the dispatch octet and
with link-local communication. When routing over multiple IP hops, the LOWPAN_IPHC encoding) with link-local communication. When
LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6
dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source header down to 7 octets (2-octets dispatch/LOWPAN_IPHC, 1-octet Hop
Address, and 2-octet Destination Address). 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 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
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC Encoding Figure 2: LOWPAN_IPHC Encoding
TF: Traffic Class, Flow Label: TF: Traffic Class, Flow Label:
00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) 00: Traffic Class + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes) 01: ECN + 2-bit Pad + Flow Label (3 bytes)
10: Traffic Class (1 byte) 10: Traffic Class (1 byte)
11: Version, Traffic Class, and Flow Label are compressed. 11: Version, Traffic Class, and Flow Label are compressed.
NH: Next Header: NH: Next Header:
0: Full 8 bits for Next Header are carried in-line. 0: Full 8 bits for Next Header are carried in-line.
1: The Next Header field is compressed and the next header is 1: The Next Header field is compressed and the next header is
compressed using LOWPAN_NHC, which is discussed in Section 3. compressed using LOWPAN_NHC, which is discussed in Section 3.
HLIM: Hop Limit: HLIM: Hop Limit:
skipping to change at page 7, line 47 skipping to change at page 7, line 47
If M=1 and DAC=1: If M=1 and DAC=1:
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::XX[plen]: 01: 48 bits. The address takes the form FFXX::XX[plen]:
[prefix]:XXXX:XXXX. The values of plen and prefix are taken [prefix]:XXXX:XXXX. The values of plen and prefix are taken
from the specified context. from the specified context.
10: reserved 10: reserved
11: reserved 11: reserved
2.1.2. Context Identifier Extension 2.1.2. Context Identifier Extension
This specification expects that a concept of context is shared This specification expects that an abstract set of states called
between the node that compresses a packet and the node(s) that need contexts is shared between the node that compresses a packet and the
to expand it. The specification enables a node to use of up to 16 node(s) that need to expand it. The specification enables the
contexts. How the contexts are shared and maintained is out of transport of an opaque index that is used to lookup the abstract
scope. Actions in response to unknown and/or invalid contexts are context database. The index in encoded with 4 bits enabling to
out of scope. address up to 16 contexts.
If the CMF field is set to '01' in the LOWPAN_HC encoding, then an This specification requires that services associated to the abstract
context database implement an interface to the 6LoWPAN compressor to
help compress and uncompress an address based on the parameters
passed by the compressor and the information in the abstract context
database.
The interface MUST provide the methods to lookup a context ID from a
prefix and a prefix length for encoding, and reversely lookup a
prefix and a prefix length from a context ID for decoding.
How the contexts are shared and maintained is out of scope. The
actual context information is out of scope. Actions in response to
unknown and/or invalid contexts are out of scope.
The interface might be extended to allow for further stateful
compression, for instance for SAC = 11, additional context
information might be used to store the full IPv6 address using the
Link layer Address as an additional index.
If the CID field is set to '1' in the LOWPAN_HC encoding, then an
additional octet extends the LOWPAN_HC encoding following the DAM additional octet extends the LOWPAN_HC encoding following the DAM
bits but before the IPv6 header fields that are carried in-line. The bits but before the IPv6 header fields that are carried in-line. The
additional octet identifies the prefix when the IPv6 source and/or additional octet identifies the prefix when the IPv6 source and/or
destination address is compressed. The context identifier is 4 bits destination address is compressed. The context identifier is 4 bits
for each address, supporting up to 16 contexts. The encoding is for each address, supporting up to 16 contexts. The encoding is
shown in Figure 3. shown in Figure 3.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| SAC | DAC | | SCI | DCI |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 3: LOWPAN_IPHC Encoding Figure 3: LOWPAN_IPHC Encoding
SAC: Source Address Context Identifies the prefix that is used when SCI: Source Context Identifier Identifies the prefix that is used
the IPv6 source address is compressed. when the IPv6 source address is compressed.
DAC: Destination Address Context Identifies the prefix that is used DCI: Destination Context Identifier Identifies the prefix that is
when the IPv6 destination address is compressed. used when the IPv6 destination address is compressed.
2.2. IPv6 Header Encoding 2.2. IPv6 Header Encoding
Fields carried in-line (in part or in whole) appear in the same order Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC2460]. The Version field is as they do in the IPv6 header format [RFC2460]. The Version field is
always elided. Unicast IPv6 addresses may be compressed to 64 or 16 always elided. The IPv6 Payload Length field MUST always be elided
bits or completely elided. Multicast IPv6 addresses may be and inferred from lower layers using the 6LoWPAN Fragmentation header
compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST or the IEEE 802.15.4 header. Unicast IPv6 addresses may be
always be elided and inferred from lower layers using the 6LoWPAN compressed to 64 or 16 bits or completely elided. Multicast IPv6
Fragmentation header or the IEEE 802.15.4 header. addresses may be compressed to 8, 16, or 24 bits.
2.2.1. Traffic Class and Flow Label Compression 2.2.1. Traffic Class and Flow Label Compression
The Traffic Class field in the IPv6 header comprises 6 bits of
diffserv extension [RFC2474] and 2 bits of Explicit Congestion
Notification (ECN) [RFC3168]. If the ECN information is carried by
the Lower Layers in a compatible fashion then it can be elided from
the 6LoWPAN header. Otherwise, it has to be transported in one of
the following encodings.
The TF field in the LOWPAN_HC encoding indicate whether the Traffic The TF field in the LOWPAN_HC encoding indicate whether the Traffic
Class and Flow Label are carried in-line in the compressed IPv6 Class and Flow Label are carried in-line in the compressed IPv6
header. When Flow Label is included while the Traffic Class is header. When Flow Label is included while the Traffic Class is
compressed, an additional 4 bits are included to maintain byte- compressed, an additional 4 bits are included to maintain byte-
alignment. Two of the 4 bits contain the ECN bits from the Traffic alignment. Two of the 4 bits contain the ECN bits from the Traffic
Class field. Class field.
To ensure that the ECN bits appear in the same location for all To ensure that the ECN bits appear in the same location for all
encodings that include them, the Traffic Class field is rotated right encodings that include them, the Traffic Class field is rotated right
by 2 bits in the compressed IPv6 header. The encodings are shown by 2 bits in the compressed IPv6 header. The encodings are shown
skipping to change at page 9, line 37 skipping to change at page 10, line 21
2.2.2. Stateless Multicast Addresses Compression 2.2.2. Stateless Multicast Addresses Compression
LOWPAN_HC supports stateless compression of multicast address when M LOWPAN_HC supports stateless compression of multicast address when M
= 1 and SAC = 0. An IPv6 multicast address may be compressed down to = 1 and SAC = 0. An IPv6 multicast address may be compressed down to
48, 32, 16, or 8 bits using stateless compression. The format 48, 32, 16, or 8 bits using stateless compression. The format
supports compression of the Solicited-Node Multicast Address (FF02:: supports compression of the Solicited-Node Multicast Address (FF02::
1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper
bits of the multicast group identifier are zero. The compressed bits of the multicast group identifier are zero. The compressed
forms only carry the least-significant bits of the multicast group forms only carry the least-significant bits of the multicast group
identifier. All compressed forms carry the multicast scope in-line identifier.
and all (except DAM=10) carry the multicast flags as well.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier | | Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier | | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg)
skipping to change at page 11, line 16 skipping to change at page 11, line 36
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Reserved | Group Identifier | | Flags | Scope | Reserved | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier | | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression
Note that the Reserved field MUST carry the reserved bits from the The Reserved field MUST carry the reserved bits from the multicast
multicast address format as described in [RFC3306]. When a address format as described in [RFC3306]. When a Rendezvous Point is
Rendezvous Point is encoded in the multicast address as described in encoded in the multicast address as described in [RFC3956], the
[RFC3956], the Reserved field carries the RIID bits in-line. Reserved field carries the RIID bits in-line.
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 4 shows the structure specific to the IPv6 Next Header value. Figure 4 shows the structure
of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
skipping to change at page 12, line 18 skipping to change at page 12, line 41
Figure 5: LOWPAN_NHC Encoding Figure 5: LOWPAN_NHC Encoding
3.2. UDP Header Compression 3.2. 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 6. Bits 0 LOWPAN_NHC. The UDP compression format is shown in Figure 6. Bits 0
through 4 represent the NHC ID and '11110' indicates the specific UDP through 4 represent the NHC ID and '11110' indicates the specific UDP
header compression encoding defined in this section. header compression encoding defined in this section.
3.2.1. Compressing UDP ports
This specification introduces a range of well-known port (0xF0Bx)
that can be compressed to 4 bits. Considering that this represents
only 16 contiguous ports, it can be expected that many incompatible
applications will use the same port numbers of their own end-to-end
needs.
The overloading of the 0xF0Bx ports increases the risk of getting the
wrong type of payload and misinterpreting the content compared to
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
Security (TLS) Message Integrity Check (MIC) that validates that the
content is expected and checked for integrity.
3.2.2. Compressing UDP checksum
The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
packets. For that reason [RFC4944] disallows the compression of the
UDP checksum.
With this specification, a compressor in the source transport
endpoint MAY elide the UDP checksum in certain cases for instance:
Upper Layer Message Integrity Check: In this case, there is some
other form of integrity check in the UDP payload that covers at
least the same information as the UDP checksum (pseudo-header,
data) and has at least the same strength.
Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo-
fieldbus by tunneling existing field protocols over UDP. If the
tunneled PDU possesses its own addressing, security and integrity
check, the tunneling mechanism MAY authorize to elide the UDP
checksum in order to save on the encapsulation overhead.
This elision is indicated by setting the 'C' bit in the LOWPAN_NHC
header.
A 6LoWPAN endpoint that compresses the LOWPAN_NHC header MUST NOT
elide the UDP checksum (set the C bit) unless it has been authorized
to do so by the source of the packet. In the source transport
endpoint, this authorization can come from upper layer transport or
application protocol instance that originated the packet. In a
forwarding node, this authorization is implied when the incoming
packet had the optimization applied (had the C bit set).
A 6LoWPAN endpoint that expands the LOWPAN_NHC header MUST
reconstitute the UDP checksum by computing the valid value for the
datagram as specified in [RFC0768] and [RFC2460], and place the
result of that computation in the restored UDP header, unless it has
been authorized to ignore the checksum operation. In the destination
transport endpoint this authorization can come from upper layer
transport that will receive the packet and would ignore the UDP
checksum should it be restored.
3.2.3. UDP LOWPAN_NHC Format
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P | | 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 6: UDP Header Encoding Figure 6: UDP Header Encoding
C: Checksum: 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.
be included if there are no other end-to-end integrity checks
that are stronger than what is provided by the UDP checksum.
Such an integrity check MUST be end-to-end and cover the IPv6
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 on the 6LoWPAN termination point.
P: Ports: P: Ports:
00: All 16 bits for both Source Port and Destination Port are 00: All 16 bits for both Source Port and Destination Port are
carried in-line. carried in-line.
01: All 16 bits for Source Port are carried in-line. First 8 01: All 16 bits for Source Port are carried in-line. First 8
bits of Destination Port is 0xF0 and elided. The remaining 8 bits of Destination Port is 0xF0 and elided. The remaining 8
bits of Destination Port are carried in-line. bits of Destination Port are carried in-line.
10: First 8 bits of Source Port are 0xF0 and elided. The 10: First 8 bits of Source Port are 0xF0 and elided. The
remaining 8 bits of Source Port are carried in-line. All 16 remaining 8 bits of Source Port are carried in-line. All 16
bits for Destination Port are carried in-line. bits for Destination Port are carried in-line.
skipping to change at page 13, line 22 skipping to change at page 15, line 8
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 number of prefixes through shared PAN may have associated with it a number of prefixes through shared
context. How the shared context is assigned and managed is beyond context. How the shared context is assigned and managed is beyond
the scope of this document. the scope of this document.
The overloading of the 0xF0Bx ports increases the risk of getting the
wrong type of payload and misinterpreting the content compared to
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
Security (TLS) Message Integrity Check (MIC) that validates that the
content is expected and checked for integrity.
6. Acknowledgements 6. Acknowledgements
Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, and Jay Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik
Werb for useful feedback and discussion. Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen
Dawson-Haggerty, Jay Werb, and Mathilde Durvy for useful design
consideration and implementation feedback.
7. Changes 7. Changes
Draft 04:
- Fixed typos leftover from the changes in 03.
- Gave more details on UDP checksum compression.
- Greater discussion on the use of context information and
clarification that its details are out of scope.
- 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.
- More extensive support for multicast address compression, - More extensive support for multicast address compression,
including Unicast-Prefix-based Multicast Addresses. including Unicast-Prefix-based Multicast Addresses.
Draft 02: Draft 02:
- Updated wording with compression mode to clarify that a - Updated wording with compression mode to clarify that a
compression mode does not enforce what kind of destination address compression mode does not enforce what kind of destination address
is being used. Specifically changed Destination Dependent Field is being used. Specifically changed Destination Dependent Field
skipping to change at page 14, line 16 skipping to change at page 16, line 16
dispatch field. dispatch field.
- Added better support for multicast address compression. - Added better support for multicast address compression.
- Fixed alignment for UDP port compression. - Fixed alignment for UDP port compression.
- Better support for Traffic Class and Flow Label compression. - Better support for Traffic Class and Flow Label compression.
- Pascal joined as an author. - Pascal joined as an author.
8. References 8. References
8.1. Normative References 8.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.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[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.
[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.
 End of changes. 31 change blocks. 
70 lines changed or deleted 181 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/