draft-ietf-6lowpan-hc-08.txt   draft-ietf-6lowpan-hc-09.txt 
Network Working Group J. Hui, Ed. Network Working Group J. Hui, Ed.
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Updates: 4944 (if approved) P. Thubert Updates: 4944 (if approved) P. Thubert
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 27, 2011 July 26, 2010 Expires: February 24, 2011 August 23, 2010
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-08 draft-ietf-6lowpan-hc-09
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. How on shared context to allow compression of arbitrary prefixes. How
the information is maintained in that shared context is out of scope. the information is maintained in that shared context is out of scope.
This document specifies compression of multicast addresses and a This document specifies compression of multicast addresses and a
framework for compressing next headers. UDP header compression is framework for compressing next headers. UDP header compression is
specified within this framework. specified within this framework.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2011. This Internet-Draft will expire on February 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . 6 3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 6
3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Context Identifier Extension . . . . . . . . . . . . . 8 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 9
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 . . . . . . . 10
3.2.2. Mapping Link-Layer Addresses to Interface IDs . . . . 10 3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11
3.2.3. Stateless Multicast Addresses Compression . . . . . . 11 3.2.3. Stateless Multicast Address Compression . . . . . . . 12
3.2.4. Stateful Multicast Addresses Compression . . . . . . . 12 3.2.4. Stateful Multicast Address Compression . . . . . . . . 13
4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 13 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 13
4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 13 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 14
4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 14 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 14
4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 15 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 16
4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 16 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 16
4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 16 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 16
4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 17 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 127 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
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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
2. Specific Updates to RFC 4944 2. Specific Updates to RFC 4944
This document specifies a header compression format that is intended This document specifies a header compression format that is intended
to replace that defined in Section 10 of [RFC4944]. Implementation to replace that defined in Section 10 of [RFC4944]. Implementation
of Section 10 of [RFC4944] is now NOT RECOMMENDED. New of Section 10 of [RFC4944] is now NOT RECOMMENDED. New
implementations MAY implement compression according to Section 10 of implementations MAY implement compression according to Section 10 of
[RFC4944], but SHOULD NOT send packets compressed according to [RFC4944], but SHOULD NOT send packets compressed according to
Section 10 of [RFC4944]. Section 10 of [RFC4944].
A compliant implementation of [RFC4944] as updated by this document
MUST be able to properly process a packet received that makes use of
the provisions of this document. A compliant implementation MAY
implement additional LOWPAN_NHC types (Section 4) that may be
registered (Section 5) in the future. It is out of scope of this
document how a compressor learns that a decompressor has additional
capabilities.
Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 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 datagrams that do not fit within a single link frame. Section 5.3 of
[RFC4944] defines the fragment header's datagram_size and [RFC4944] defines the fragment header's datagram_size and
datagram_offset values as the size and offset of the IPv6 datagram datagram_offset values as the size and offset of the IPv6 datagram
before compression. As a result, all fragment payload outside the before compression. As a result, all fragment payload outside the
first fragment must carry their respective portions of the IPv6 first fragment must carry their respective portions of the IPv6
datagram before compression. This document does not change that datagram before compression. This document does not change that
requirement. When using the fragmentation mechanism described in requirement. When using the fragmentation mechanism described in
Section 5.3 of [RFC4944], any header that cannot fit within the first Section 5.3 of [RFC4944], any header that cannot fit within the first
fragment MUST NOT be compressed. fragment MUST NOT be compressed.
skipping to change at page 7, line 29 skipping to change at page 7, line 38
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 in-line. 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 in-line. 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 encapsulating The remaining 64 bits are computed from the encapsulating
header. header (e.g. 802.15.4 or IPv6 source address) as specified
in Section 3.2.2.
If SAC=1: If SAC=1:
00: The UNSPECIFIED address, :: 00: The UNSPECIFIED address, ::
01: 64 bits. The address is derived using context information 01: 64 bits. The address is derived using context information
and the 64 bits carried in-line. 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 in-line. and the 16 bits carried in-line.
11: 0 bits. The address is fully elided. The prefix is 11: 0 bits. The address is fully elided. The prefix is
derived using context information. Any of the remaining 64 derived using context information. Any of the remaining 64
bits not covered by the context information are computed bits not covered by the context information are computed
from the encapsulating header. from the encapsulating header (e.g. 802.15.4 or IPv6 source
address) as specified 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.
skipping to change at page 8, line 18 skipping to change at page 8, line 27
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 in-line. 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 in-line. 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 encapsulating The remaining 64 bits are computed from the encapsulating
header. header (e.g. 802.15.4 or IPv6 destination address) as
specified in Section 3.2.2.
If M=0 and DAC=1: If M=0 and DAC=1:
00: Reserved. 00: Reserved.
01: 64 bits. The address is derived using context information 01: 64 bits. The address is derived using context information
and the 64 bits carried in-line. 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 in-line. and the 16 bits carried in-line.
11: 0 bits. The address is fully elided. The prefix is 11: 0 bits. The address is fully elided. The prefix is
derived using context information. Any of the remaining 64 derived using context information. Any of the remaining 64
bits not covered by the context information are computed bits not covered by the context information are computed
from the encapsulating header. from the encapsulating header (e.g. 802.15.4 or IPv6
destination address) as specified 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
skipping to change at page 9, line 46 skipping to change at page 10, line 11
always elided. Unicast IPv6 addresses may be compressed to 64 or 16 always elided. Unicast IPv6 addresses may be compressed to 64 or 16
bits or completely elided. Multicast IPv6 addresses may be bits or completely elided. Multicast IPv6 addresses may be
compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST
always be elided and inferred from lower layers using the 6LoWPAN always be elided and inferred from lower layers using the 6LoWPAN
Fragmentation header or the IEEE 802.15.4 header. Fragmentation header or the IEEE 802.15.4 header.
3.2.1. Traffic Class and Flow Label Compression 3.2.1. Traffic Class and Flow Label Compression
The Traffic Class field in the IPv6 header comprises 6 bits of The Traffic Class field in the IPv6 header comprises 6 bits of
diffserv extension [RFC2474] and 2 bits of Explicit Congestion diffserv extension [RFC2474] and 2 bits of Explicit Congestion
Notification (ECN) [RFC3168]. If the ECN information is carried by Notification (ECN) [RFC3168]. The TF field in the LOWPAN_IPHC
the Lower Layers in a compatible fashion then it can be elided from encoding indicates whether the Traffic Class and Flow Label are
the 6LoWPAN header. Otherwise, it has to be transported in one of carried in-line in the compressed IPv6 header. When Flow Label is
the following encodings. included while the Traffic Class is compressed, an additional 4 bits
are included to maintain byte-alignment. Two of the 4 bits contain
The TF field in the LOWPAN_IPHC encoding indicates whether the the ECN bits from the Traffic Class field.
Traffic Class and Flow Label are carried in-line in the compressed
IPv6 header. When Flow Label is included while the Traffic Class is
compressed, an additional 4 bits are included to maintain byte-
alignment. Two of the 4 bits contain the ECN bits from the Traffic
Class field.
To ensure that the ECN bits appear in the same location for all To ensure that the ECN bits appear in the same location for all
encodings that include them, the Traffic Class field is rotated right encodings that include them, the Traffic Class field is rotated right
by 2 bits in the compressed IPv6 header. The encodings are shown by 2 bits in the compressed IPv6 header. The encodings are shown
below: below:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label | |ECN| DSCP | rsv | Flow Label |
skipping to change at page 10, line 40 skipping to change at page 11, line 12
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. Mapping Link-Layer Addresses to Interface IDs 3.2.2. Deriving IIDs from the Encapsulating Header
LOWPAN_IPHC elides the IIDs of source or destination addresses when LOWPAN_IPHC elides the IIDs of source or destination addresses when
SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived
from the encapsulating header. When the encapsulating header carries from the encapsulating header. When the encapsulating header carries
IPv6 addresses, the corresponding bits map directly. IPv6 addresses, bits for the source and destination addresses are
copied verbatim from the source and destination addresses of the
encapsulating IPv6 header.
The remainder of this section defines the mapping from IEEE 802.15.4 The remainder of this section defines the mapping from IEEE 802.15.4
link-layer addresses to IIDs for both short and extended IEEE link-layer addresses to IIDs for both short and extended IEEE
802.15.4 addresses. IID bits not covered by the context information 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 MAY be elided if they match the link-layer address mapping and MUST
NOT be elided if they do not. NOT be elided if they do not.
An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64
address. Generating an IID from an extended address is identical to address. Generating an IID from an extended address is identical to
that defined in Appendix A of [RFC4291]. The only change needed to that defined in Appendix A of [RFC4291]. The only change needed to
skipping to change at page 11, line 30 skipping to change at page 11, line 45
setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
address, and all other bits to zero. As a result, an IID generated address, and all other bits to zero. As a result, an IID generated
from a short address has the form: from a short address has the form:
0000:00ff:fe00:XXXX 0000:00ff:fe00:XXXX
where XXXX carries the short address. The universal/local bit is where XXXX carries the short address. The universal/local bit is
zero to indicate local scope. zero to indicate local scope.
This mapping for non-EUI-64 identifiers differs from that presented This mapping for non-EUI-64 identifiers differs from that presented
in Appendix A of [RFC4291] for a couple reasons. Using the in Appendix A of [RFC4291]. Using the restricted space ensures no
restricted space ensures no overlap with IIDs generated from overlap with IIDs generated from unrestricted IEEE EUI-64 addresses.
unrestricted IEEE EUI-64 addresses. Also, including 0xfffe in the Also, including 0xfffe in the middle of the IID helps avoid overlap
middle of the IID helps avoid overlap with other locally managed with other locally managed IIDs.
IIDs.
3.2.3. Stateless Multicast Addresses Compression This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
also used to reconstruct any part of an IID not covered by context
information when only 16 bits are carried in-line (SAC/DAC=10).
LOWPAN_IPHC supports stateless compression of multicast address when 3.2.3. Stateless Multicast Address Compression
M = 1 and DAC = 0. An IPv6 multicast address may be compressed down
to 48, 32, or 8 bits using stateless compression. The format LOWPAN_IPHC supports stateless compression of multicast addresses
when M = 1 and DAC = 0. An IPv6 multicast address may be compressed
down 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 8-bit bits of the multicast group identifier are zero. The 8-bit
compressed form only carries the least-significant bits of the compressed form only carries the least-significant bits of the
multicast group identifier. The 48 and 32-bit compressed forms carry multicast group identifier. The 48 and 32-bit compressed forms carry
the multicast scope and flags in-line, in addition to the least- the multicast scope and flags in-line, in addition to the least-
significant bits of the multicast group identifier. significant bits of the multicast group identifier.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 12, line 30 skipping to change at page 13, line 5
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.4. Stateful Multicast Addresses Compression 3.2.4. Stateful Multicast Address Compression
LOWPAN_IPHC supports stateful compression of multicast addresses when LOWPAN_IPHC supports stateful compression of multicast addresses when
M = 1 and DAC = 1. This document currently defines DAM = 00: M = 1 and DAC = 1. This document currently defines DAM = 00:
context-based compression of Unicast-Prefix-based IPv6 Multicast context-based compression of Unicast-Prefix-based IPv6 Multicast
Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and
Network Prefix can be taken from a context. As a result, LOWPAN_IPHC Network Prefix can be taken from a context. As a result, LOWPAN_IPHC
can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6
octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and
32-bit Group Identifier in-line. 32-bit Group Identifier in-line.
skipping to change at page 13, line 23 skipping to change at page 13, line 34
DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression
Note that the Reserved field MUST carry the reserved bits from the Note that the Reserved field MUST carry the reserved bits from the
multicast address format as described in [RFC3306]. When a multicast address format as described in [RFC3306]. When a
Rendezvous Point is encoded in the multicast address as described in Rendezvous Point is encoded in the multicast address as described in
[RFC3956], the Reserved field carries the RIID bits in-line. [RFC3956], the Reserved field carries the RIID bits in-line.
4. IPv6 Next Header Compression 4. IPv6 Next Header Compression
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set
to 1. It also indicates the use of 6LoWPAN next header compression, to 1. This also indicates the use of 6LoWPAN next header
LOWPAN_NHC. The value of IPv6 Next Header is recovered from the compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered
first bits in the LOWPAN_NHC encoding. The following bits are from the first bits in the LOWPAN_NHC encoding. The following bits
specific to the IPv6 Next Header value. Figure 4 shows the structure are specific to the IPv6 Next Header value. Figure 4 shows the
of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. structure of an IPv6 datagram compressed using LOWPAN_IPHC and
LOWPAN_NHC.
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields | | Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
4.1. LOWPAN_NHC Format 4.1. LOWPAN_NHC Format
skipping to change at page 15, line 19 skipping to change at page 15, line 29
For the most part, the IPv6 Extension Header is carried verbatim in For the most part, the IPv6 Extension Header is carried verbatim in
the bytes immediately following the LOWPAN_NHC octet, with two the bytes immediately following the LOWPAN_NHC octet, with two
important exceptions: Length Field and Next Header Field. important exceptions: Length Field and Next Header Field.
The Next Header Field contained in IPv6 Extension Headers is elided The Next Header Field contained in IPv6 Extension Headers is elided
when the NH bit is set in the LOWPAN_NHC encoding octet. Note that when the NH bit is set in the LOWPAN_NHC encoding octet. Note that
doing so allows LOWPAN_NHC to utilize no more overhead than the non- doing so allows LOWPAN_NHC to utilize no more overhead than the non-
encoded IPv6 Extension Header. encoded IPv6 Extension Header.
The Length Field contained in IPv6 Extension Headers indicate the The Length Field contained in a compressed IPv6 Extension Header
length of the IPv6 Extension Header in octets, not including the indicates the number of octets that pertain to the (compressed)
LOWPAN_NHC byte. Note that this changes the Length Field definition extension header following the Length Field. Note that this changes
in [RFC2460] from indicating the header size in 8-octet units, not the Length Field definition in [RFC2460] from indicating the header
including the first 8 octets. Changing the Length Field to be in size in 8-octet units, not including the first 8 octets. Changing
units of octets removes wasteful internal fragmentation. However, the Length Field to be in units of octets removes wasteful internal
specifying units in octets also means that LOWPAN_NHC MUST NOT be fragmentation.
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 a trailing
to pad out the header for octet-alignment purposes. When using Pad1 or PadN to achieve 8-octet alignment. When there is a single
LOWPAN_NHC, Pad1 and PadN options that appear at the end of the trailing Pad1 or PadN option of 7 octets or less and the containing
options header MAY be elided. When converting from the LOWPAN_NHC header is a multiple of 8 octets, the trailing Pad1 or PadN option
encoding back to the standard IPv6 encoding, Pad1 and PadN options MAY be elided by the compressor. A decompressor MUST ensure that the
MUST be used to pad out the containing header to a multiple of 8 containing header is padded out to a multiple of 8 octets in length,
octets in length. Note that Pad1 and PadN options that appear in using a Pad1 or PadN option if necessary. Note that Pad1 and PadN
locations other than the end MUST be carried in-line as they are used options that appear in locations other than the end MUST be carried
to align subsequent options. in-line as they are used to align subsequent options.
Note that specifying units in octets means that LOWPAN_NHC MUST NOT
be used to encode IPv6 Extension Headers that have more than 255
octets following the Length Field after compression.
When the identified next header is an IPv6 Header (EID=7), the NH bit When the identified next header is an IPv6 Header (EID=7), the NH bit
of the LOWPAN_NHC encoding is unused and SHOULD be set to zero. The of the LOWPAN_NHC encoding is unused and MUST be set to zero. The
following bytes MUST be encoded using LOWPAN_IPHC as defined in following bytes MUST be encoded using LOWPAN_IPHC as defined in
Section 3. Section 3.
4.3. UDP Header Compression 4.3. UDP Header Compression
This document defines a compression format for UDP headers using This document defines a compression format for UDP headers using
LOWPAN_NHC. The UDP compression format is shown in Figure 7. Bits 0 LOWPAN_NHC. The UDP compression format is shown in Figure 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.
skipping to change at page 18, line 18 skipping to change at page 18, line 25
This assignment preempts the assignment of 01 111111 for ESC This assignment preempts the assignment of 01 111111 for ESC
[RFC4944], which is possible as no extension bytes have been [RFC4944], which is possible as no extension bytes have been
allocated yet that would enable the use of ESC. Instead, the value: allocated yet that would enable the use of ESC. Instead, the value:
01 000000 01 000000
is reserved as a replacement value for ESC, to be finally assigned is reserved as a replacement value for ESC, to be finally assigned
with the first assignment of extension bytes. with the first assignment of extension bytes.
This document also creates a new IANA registry for the LOWPAN_NHC
header type, with the following initial content:
00000000 to 11011111: (unassigned)
1110000N: IPv6 Hop-by-Hop Options Header [RFCthis]
1110001N: IPv6 Routing Header [RFCthis]
1110010N: IPv6 Fragment Header [RFCthis]
1110011N: IPv6 Destination Options Header [RFCthis]
1110100N: IPv6 Mobility Header [RFCthis]
1110101N: (Reserved for future extension headers)
1110110N: (Reserved for future extension headers)
1110111N: IPv6 Header [RFCthis]
11110CPP: UDP Header [RFCthis]
11111000 to 11111110: (unassigned)
11111111: (unassigned, reserved for extensions)
Capital letters in bit positions represent class-specific bit
assignments. N indicates whether or not additional LOWPAN_NHC
encodings follow, as defined in Section 4.2. CPP represents
variables specific to UDP header compression defined in Section 4.3.
The policy for this registry [RFC5226] is IETF Review. In this
process, new values SHOULD be assigned in a way that preserves the
NHC ID abstraction of Section 4 (i.e., k one-bits followed by one
zero-bit identify the general class of NHC, followed by class-
specific bit assignments).
6. Security Considerations 6. Security Considerations
The definition of LOWPAN_IPHC permits the compression of header The definition of LOWPAN_IPHC permits the compression of header
information on communication that could take place in its absence, information on communication that could take place in its absence,
albeit in a less efficient form. It recognizes that a IEEE 802.15.4 albeit in a less efficient form. It recognizes that a IEEE 802.15.4
PAN may have associated with it a number of prefixes through shared PAN may have associated with it a number of prefixes through shared
context. How the shared context is assigned and managed is beyond context. How the shared context is assigned and managed is beyond
the scope of this document. the scope of this document.
The overloading of the 0xF0Bx ports increases the risk of getting the The overloading of the 0xF0Bx ports increases the risk of getting the
skipping to change at page 18, line 44 skipping to change at page 19, line 31
7. Acknowledgements 7. Acknowledgements
Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten
Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik
Nordmark, Christos Polyzois, Shoichi Sakane, Zach Shelby, Tony Nordmark, Christos Polyzois, Shoichi Sakane, Zach Shelby, Tony
Viscardi, and Jay Werb for useful design consideration and Viscardi, and Jay Werb for useful design consideration and
implementation feedback. implementation feedback.
8. Changes 8. Changes
(This section to be removed by the RFC editor.)
Draft 09:
- Indicate that a mechanism to learn decompressor's capabilities
to decode additional (future) NHCs is out of scope.
- Clarify how to derive IID bits not covered by the context when
only 16 bits are carried inline.
- Clarify the value of the Length field for compressed extension
headers.
- Added an IANA registry for LOWPAN_NHC types.
Draft 08: Draft 08:
- Clarified that the lower bits of an IPv6 address may be derived - Clarified that the lower bits of an IPv6 address may be derived
from an IPv6 header, not just an 802.15.4 header. Change text from an IPv6 header, not just an 802.15.4 header. Change text
from "derived from link-layer header" to "derived from from "derived from link-layer header" to "derived from
encapsulating header". encapsulating header".
Draft 07: Draft 07:
- Added section on mapping link-layer addresses to IIDs. - Added section on mapping link-layer addresses to IIDs.
- Added text on restricting compressed headers to first fragment - Added text on restricting compressed headers to first fragment
when using fragment headers defined in Section 5.3 of [RFC4944]. when using fragment headers defined in Section 5.3 of [RFC4944].
- Minor editorial edits. - Minor editorial edits.
Draft 06: Draft 06:
- Reworked introduction. - Reworked introduction.
- Added section on updates to [RFC4944]. - 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
skipping to change at page 20, line 48 skipping to change at page 21, line 48
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
9.2. Informative References 9.2. Informative References
[IEEE 802.15.4] [IEEE 802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2006", IEEE Computer Society, "IEEE Std. 802.15.4-2006",
October 2006. October 2006.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
 End of changes. 29 change blocks. 
69 lines changed or deleted 128 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/