< draft-hui-6lowpan-hc-00.txt   draft-hui-6lowpan-hc-01.txt >
Network Working Group J. Hui Network Working Group J. Hui
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Intended status: Standards Track March 10, 2008 Intended status: Standards Track July 28, 2008
Expires: September 11, 2008 Expires: January 29, 2009
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-hui-6lowpan-hc-00 draft-hui-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 34
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 September 11, 2008. This Internet-Draft will expire on January 29, 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 well-known multicast addresses and
a framework for compressing next headers. UDP compression is a framework for compressing next headers. UDP compression is
specified within this framework. specified within this framework.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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.2. IPv6 Unicast Address Compression . . . . . . . . . . . . . 6
2.3. IPv6 Multicast Address Compression . . . . . . . . . . . . 7 2.3. IPv6 Multicast Address Compression . . . . . . . . . . . . 7
2.4. 16-bit Compressed Address Ranges . . . . . . . . . . . . . 8 2.4. 16-bit Compressed Address Ranges . . . . . . . . . . . . . 8
3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 9 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 9
3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 9 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 9
3.2. LOWPAN_UDP Header Compression . . . . . . . . . . . . . . 9 3.2. LOWPAN_UDP Header Compression . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 3.3. ISA100_UDP Header Compression . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
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, (including
the length byte) on a wireless link with a link throughput of 250 the length byte) on a wireless link with a link throughput of 250
kbps or less[ieee802.15.4]. The 6LoWPAN adaptation format [RFC4944] kbps or less[ieee802.15.4]. The 6LoWPAN adaptation format [RFC4944]
was specified to carry IPv6 datagrams over IEEE 802.15.4 links, was specified to carry IPv6 datagrams over IEEE 802.15.4 links,
taking into account limited bandwidth, memory, or energy resources taking into account limited bandwidth, memory, or energy resources
that are expected in IEEE 802.15.4 applications. The 6LoWPAN that are expected in IEEE 802.15.4 applications. The 6LoWPAN
adaptation format defines a Mesh Addressing header to support sub-IP adaptation format defines a Mesh Addressing header to support sub-IP
skipping to change at page 3, line 46 skipping to change at page 3, line 46
in-line. However LOWPAN_HC1 requires 64-bits for the IID when in-line. However LOWPAN_HC1 requires 64-bits for the IID when
carried in-line and cannot be shortened even when it is derived carried in-line and cannot be shortened even when it is derived
directly from the IEEE 802.15.4 16-bit short address. When sending directly from the IEEE 802.15.4 16-bit short address. When sending
to an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit to an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit
multicast address to be carried in-line. Multicast addresses are multicast address to be carried in-line. Multicast addresses are
commonly used for neighbor discovery, such as in IPv6 ND. commonly used for neighbor discovery, such as in IPv6 ND.
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. RFC 4944 [RFC4944] only defines
compression for UDP, where UDP ports may be compressed and the UDP compression for UDP, where UDP ports may be compressed and the UDP
Length may be elided. However, there currently is no defined Length may be elided. However, LOWPAN_HC1 also does not provide any
mechanism to elide the UDP Checksum. In some cases, the same or flexibility in supporting future compression mechanisms for next
stronger integrity checks may be provided by other mechanisms, such headers other than UDP, TCP or ICMPv6.
as end-to-end security. Such security may be provided at the network
layer similar to IPsec or at the transport-layer similar to TLS. In
either case, security mechanisms that cover the IPv6 pseudo-header
and transport-layer header and payload may limit the utility of UDP
checksums. LOWPAN_HC1 also does not provide any flexibility in
supporting future compression mechanisms for next headers other than
UDP, TCP or ICMPv6.
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 RFC 4944 [RFC4944] by generalizing it to support a broader
range of communication paradigms, including both mesh-under and range of communication paradigms, including both mesh-under and
route-over configurations; communication to nodes internal and route-over configurations; communication to nodes internal and
external to the 6LoWPAN network; and multicast communication. This external to the 6LoWPAN network; and multicast communication. This
document also defines a flexible framework for compressing arbitrary document also defines a flexible framework for compressing arbitrary
next headers and defines UDP header compression within this next headers and defines UDP header compression within this
framework. This compression format carries forward the design framework. This compression format carries forward the design
skipping to change at page 4, line 50 skipping to change at page 4, line 43
IEEE 802.15.4 addresses. IEEE 802.15.4 addresses.
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 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 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOWPAN_IPHC | Uncompressed fields follow... | LOWPAN_IPHC | Uncompressed fields follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LOWPAN_IPHC Header Figure 1: LOWPAN_IPHC Header
The LOWPAN_IPHC encoding utilizes a single octet, with uncompressed The LOWPAN_IPHC encoding utilizes a two octets, with uncompressed
fields following, as shown in Figure 1. With the above scenario, the fields following, as shown in Figure 1. With the above scenario, the
LOWPAN_IPHC can compress the IPv6 header down to a single octet (the LOWPAN_IPHC can compress the IPv6 header down to two octets (the
LOWPAN_IPHC encoding octet) with link-local communication. When LOWPAN_IPHC encoding) with link-local communication. When
communicating over multiple IP hops, LOWPAN_IPHC can compress the communicating over multiple IP hops, LOWPAN_IPHC can compress the
IPv6 header down to 6 octets (1-octet LOWPAN_IPHC, 1-octet Hop Limit, IPv6 header down to 7 octets (2-octet LOWPAN_IPHC, 1-octet Hop Limit,
2-octet Source Address, and 2-octet Destination Address). 2-octet Source Address, and 2-octet Destination Address).
2.1. LOWPAN_IPHC Encoding Format 2.1. LOWPAN_IPHC Encoding Format
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-----+-----+-----+-----+-----+-----+-----+-----+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| VTF | NH |HLIM | SC | DC | rsv | | T |VF |NH | HLIM | rsv | SAM | SAC | DAM | DAC |
+-----+-----+-----+-----+-----+-----+-----+-----+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC Encoding Figure 2: LOWPAN_IPHC Encoding
VTF: Version, Traffic Class, and Flow Label (bit 0): T: Traffic Class (bit 0):
0: Full 4 bits for Version, 8 bits for Traffic Class, and 20 bits 0: Full 8 bits for Traffic Class are carried in-line.
for Flow Label are carried in-line. 1: Traffic Class is elided and implicitly 0.
1: Version, Traffic Class, and Flow Label are elided. Version is VF: Version and Flow Label (bit 1):
implicitly 6. Traffic Class and Flow Label are implicitly 0. 0: Full 4 bits for Version and 20 bits for Flow Label are carried
in-line.
1: Version and Flow Label are elided. Version is implicitly 6.
Traffic Class and Flow Label are implicitly 0.
NH: Next Hop (bit 1): NH: Next Hop (bit 2):
0: Full 8 bits for Next Hop are carried in-line. 0: Full 8 bits for Next Hop are carried in-line.
1: Next Hop is elided and the next header is compressed using 1: Next Hop is elided and the next header is compressed using
LOWPAN_NHC, which is discussed in Section 3. LOWPAN_NHC, which is discussed in Section 3.
HLIM: Hop Limit (bit 2): HLIM: Hop Limit (bits 3-4):
0: All 8 bits of Hop Limit are carried in-line. 00: All 8 bits of Hop Limit are carried in-line.
1: All 8 bits of Hop Limit are elided. If the IPv6 destination 01: All 8 bits of Hop Limit are elided and the Hop Limit is
address is not assigned to the receiving interface, Hop Limit assumed to be 1.
is assumed to be 64 (TBD). If the IPv6 destination address is 10: All 8 bits of Hop Limit are elided and the Hop Limit is
assigned to the receiving interface, Hop Limit is assumed to be assumed to be 64.
1. XXX: What is the correct way to specify when the Hop Limit 11: All 8 bits of Hop Limit are elided and the Hop Limit is
can be elided? assumed to be 255.
SRC: Source Address (bits 3 and 4): rsv: Reserved (bit 5-7)
SAC: Source Address Mode (bits 8-9):
00: All 128 bits of Source Address are carried in-line. 00: All 128 bits of Source Address are carried in-line.
01: 64-bit Compressed IPv6 address. 01: 64-bit Compressed IPv6 address.
10: 16-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address.
11: All 128 bits of Source Address are elided. 11: All 128 bits of Source Address are elided.
DST: Destination Address (bits 5 and 6): SAC: Source Address Context (bits 10-11): Identifies the compression
00: All 128 bits of Destination Address are carried in-line. context when the source address is compressed. The value '00' is
reserved and indicates a link-local address.
DAM: Destination Address Mode (bits 12-13):
00: All 128 bits of Destination Address are carried in-line.
01: 64-bit Compressed IPv6 address. 01: 64-bit Compressed IPv6 address.
10: 16-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address.
11: All 128 bits of Destination Address are elided. 11: All 128 bits of Destination Address are elided.
rsv: Reserved (bit 7). DAC: Destination Address Context (bits 14-15): Identifies the
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]. IPv6 addresses may
be compressed to 64 or 16 bits or completely elided. The IPv6 be compressed to 64 or 16 bits or completely elided. The IPv6
Payload Length field MUST always be elided and inferred from lower Payload Length field MUST always be elided and inferred from lower
layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4
header. header.
2.2. IPv6 Unicast Address Compression 2.2. IPv6 Unicast Address Compression
IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. When IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. When
an IPv6 unicast address is compressed, the elided bits are implicitly an IPv6 unicast address is compressed, the compression context
the Common Prefix (CP). The CP can either be the link-local prefix identifies the value of the elided bits. A compression value of '00'
or Common Routable Prefix (CRP). The 6LoWPAN dispatch value indicates the link-local prefix. The mapping between a specific
identifies which CP is being used. A 6LoWPAN dispatch value of 0x03 context and prefix may be obtained through simple modifications to
(TBD) indicates a LOWPAN_IPHC compressed IPv6 header and the CP is IPv6 Neighbor Discovery. However, the specification of those
the link-local prefix. A 6LoWPAN dispatch value of 0x04 (TBD) mechanisms are out of scope of this document. Care should be taken
indicates a LOWPAN_IPHC compressed IPv6 header and the CP is the when renumbering a network. Nodes SHOULD only use a context after
Common Routable Prefix. The Common Routable Prefix may be obtained all of its neighbors have been configured with the same context
with IPv6 Stateless Address Autoconfiguration when autoconfiguring an information with high probability. New information within a context
address[RFC4862]. Other mechanisms for obtaining the CRP or SHOULD only be assigned after all nodes in the network have received
selecting a CRP among two or more routable prefixes are out of scope notification of its deprecation with high probability.
of this document.
There may be cases where the compressor and decompressor are out of There may be cases where the compressor and decompressor are out of
sync on the CRP. In this cases, the decompressor may reconstruct the sync within a context. In this cases, the decompressor may
IPv6 address using the incorrect CRP. Fortunately, end-to-end reconstruct the IPv6 address using the incorrect prefix. To prevent
integrity checks that cover the pseudo-header (e.g. UDP checksum) such errors, upper-layer integrity checks (e.g. psuedo-header
should catch this error and is why they are required. The time spent checksum) that cover both source and destination addresses SHOULD be
in the inconsistent state with respect to the CRP should be used.
minimized.
When an IPv6 unicast address is compressed to 64 bits, the last 64 When an IPv6 unicast address is compressed to 64 bits, the last 64
bits are carried in-line. When an IPv6 unicast address is compressed bits are carried in-line. When an IPv6 unicast address is compressed
to 16 bits, the last 16 bits are carried in line. Because the 16-bit to 16 bits, the last 16 bits are carried in line. Because the 16-bit
compressed form is also used for IPv6 multicast address compression, compressed form is also used for IPv6 multicast address compression,
the 16-bit address space is divided into multiple ranges. For the 16-bit address space is divided into multiple ranges. For
unicast addresses, the first bit carried in-line must be zero. unicast addresses, the first bit carried in-line must be zero.
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Last 15 bits of IPv6 Addr | |0| Last 15 bits of IPv6 Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 16-bit Compressed IPv6 Unicast Address Encoding Figure 3: 16-bit Compressed IPv6 Unicast Address Encoding
When an address is completely elided, the IID is inferred from lower When an address is completely elided, the IID is inferred from lower
layers (either from the 6LoWPAN Mesh Addressing header or from the layers (either from the 6LoWPAN Mesh Addressing header or from the
IEEE 802.15.4 header). The prefix is inferred from the CP. Any IEEE 802.15.4 header). The prefix is inferred from the identified
remaining bits in between are implicitly zero. context. Any remaining bits in between are implicitly zero.
To elide the IID, it MUST be derivable from IEEE 802.15.4 addresses. To elide the IID, it MUST be derivable from IEEE 802.15.4 addresses.
An IID may be derived from the IEEE EUI-64 address by creating a An IID may be derived from the IEEE EUI-64 address by creating a
Modified EUI-64 IID from the IEEE EUI-64 address, as defined in RFC 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 4291 [RFC4291]. The universal/local bit in the Modified IEEE EUI-64
IID must be set to '1', indicating universal scope. An IID may also IID must be set to '1', indicating universal scope. An IID may also
be derived from the 16-bit short address by setting the first 48 bits be derived from the 16-bit short address and PAN ID, as defined in
to zero and the remaining 16 bits to the short address. Note that RFC 4944 [RFC4944]. Note, however, that the most significant bit in
the most significant bit in the short address must be zero. XXX: the short address must be zero.
RFC4944 requires the PANID to be included, but is this really
necessary?
2.3. IPv6 Multicast Address Compression 2.3. IPv6 Multicast Address Compression
IPv6 multicast addresses may be compressed to 16 bits by utilizing a IPv6 multicast addresses may be compressed to 16 bits by utilizing a
different 6LoWPAN short address range. This document allocates different 6LoWPAN short address range. This document allocates
another range of 8192 values to be used for well-known IPv6 multicast another range of 8192 values to be used for well-known IPv6 multicast
addresses. addresses.
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
skipping to change at page 8, line 4 skipping to change at page 7, line 47
|Range| Scope | Mapped Group ID | |Range| Scope | Mapped Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Compressed IPv6 Multicast Address Encoding Figure 4: Compressed IPv6 Multicast Address Encoding
Range (bits 0-2): Must be set to '101' (TBD), which identifies the Range (bits 0-2): Must be set to '101' (TBD), which identifies the
6LoWPAN short address range for compressed IPv6 multicast 6LoWPAN short address range for compressed IPv6 multicast
addresses. addresses.
Scope (bits 3-6): 4-bit multicast scope as specified in RFC 4007 Scope (bits 3-6): 4-bit multicast scope as specified in RFC 4007
[RFC4007]. [RFC4007].
Mapped Group ID (bits 7-15): 9-bit mapped multicast group Mapped Group ID (bits 7-15): 9-bit mapped multicast group
identifier. identifier.
The full 128-bit multicast address can be reconstructed from the 16- The full 128-bit multicast address can be reconstructed from the 16-
bit mapped multicast address. By definition, the 3-bit range bit mapped multicast address. By definition, the 3-bit range
identifier indicates the well-known multicast prefix (0xFF) in identifier indicates the well-known multicast prefix (0xFF) in
addition to a flags field set to all zeros (indicating a permanently addition to a flags field set to all zeros (indicating a permanently
assigned multicast address, that the multicast address is not assigned multicast address, that the multicast address is not
assigned based on the network prefix, and that it doesn't embed the assigned based on the network prefix, and that it doesn't embed the
address of a Rendezvous Point). The 4-bit scope is carried in-line address of a Rendezvous Point). The 4-bit scope is carried in-line
and the 112-bit group ID is derived from the 9-bit mapped group ID 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 using a well-known mapping maintained by the Internet Assigned
Numbers Authority (IANA). Numbers Authority (IANA).
Nodes MUST accept both the compressed and uncompressed form of well-
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 This document defines an initial mapping. Additional mappings
between 9-bit mapped group IDs and 112-bit group IDs may be specified between 9-bit mapped group IDs and 112-bit group IDs may be specified
in the future. in the future.
+-------+---------+-----------------------+ +-------+---------+-----------------------+
| 9-bit | 112-bit | Description | | 9-bit | 112-bit | Description |
+-------+---------+-----------------------+ +-------+---------+-----------------------+
| 1 | 1 | All Nodes Addresses | | 1 | 1 | All Nodes Addresses |
| 2 | 2 | All Routers Addresses | | 2 | 2 | All Routers Addresses |
+-------+---------+-----------------------+ +-------+---------+-----------------------+
9-bit to 112-bit Group ID Mapping 9-bit to 112-bit Group ID Mapping
2.4. 16-bit Compressed Address Ranges 2.4. 16-bit Compressed Address Ranges
To use the 16-bit compressed address format for different kinds of To use the 16-bit compressed address format for different kinds of
addresses (e.g. unicast or multicast), LOWPAN_IPHC utilzies the 16- addresses (e.g. unicast or multicast), LOWPAN_IPHC utilizes the 16-
bit short address ranges as specified in RFC 4944. This document bit short address ranges as specified in RFC 4944. This document
specifies another range, for compressed multicast addresses. specifies another range, for compressed multicast addresses.
Range 0, 0xxxxxxxxxxxxxxx: As specified in RFC 4944. Range 0, 0xxxxxxxxxxxxxxx: As specified in RFC 4944.
Range 2, 100xxxxxxxxxxxxx: As specified in RFC 4944. Range 2, 100xxxxxxxxxxxxx: As specified in RFC 4944.
Range 1, 101xxxxxxxxxxxxx: The remaining 13 bits represent a Range 1, 101xxxxxxxxxxxxx: The remaining 13 bits represent a
compressed IPv6 multicast address, as described in Section 2.3. compressed IPv6 multicast address, as described in Section 2.3.
skipping to change at page 9, line 27 skipping to change at page 9, line 27
+-------------+-------------+-------------+-----------------+-------- +-------------+-------------+-------------+-----------------+--------
Figure 5: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration Figure 5: 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. The following bits are specific to frequency of using that format. However, the number of bits and any
the next header compression format. In this document, we define a remaining encoding bits SHOULD respect octet alignment. The
compression format for UDP headers. Because we expect UDP to be used following bits are specific to the next header compression format.
most frequently, it is identified by only a single bit. 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 6: LOWPAN_NHC Encoding Figure 6: LOWPAN_NHC Encoding
3.2. LOWPAN_UDP Header Compression 3.2. LOWPAN_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 7. 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 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|ID | S | D | C | rsv | | 1 | 1 | 1 | 1 | 1 | 0 | S | D |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 7: Compressed IPv6 Multicast Address Encoding Figure 7: Compressed UDP Header Encoding
ID: Identifier (bit 0):
0: Identities an IPv6 Next Header value of 17 and the LOWPAN_UDP
compression format.
1: Identifies an IPv6 Next Header value other than 17, the
following bits are used to identify the particular Next Header
value and compression format. The bit-patterns for other Next
Header values are left undefined in this document.
S: Source Port (bit 1): S: Source Port (bit 6):
0: All 16 bits of Source Port are carried in-line. 0: All 16 bits of Source Port are carried in-line.
1: First 12 bits of Source Port are elided and the remaining 4 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 + bits are carried in-line. The Source Port is recovered by: P +
short_port, where P is 61616 (0xF0B0). short_port, where P is 61616 (0xF0B0).
D: Destination Port (bit 2): D: Destination Port (bit 7):
0: All 16 bits of Destination Port are carried in-line. 0: All 16 bits of Destination Port are carried in-line.
1: First 12 bits of Destination Port are elided and the remaining 1: First 12 bits of Destination Port are elided and the remaining
4 bits are carried in-line. The Destination Port is recovered 4 bits are carried in-line. The Destination Port is recovered
by: P + short_port, where P is 61616 (0xF0B0). by: P + short_port, where P is 61616 (0xF0B0).
C: Checksum (bit 3): 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
LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 8.
Bits 0 through 4 represent the NHC ID and '11110' indicates the
specific UDP header compression encoding defined in this section.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | S | D |
+---+---+---+---+---+---+---+---+
Figure 8: Compressed ISA100.11a UDP Header Encoding
C: Checksum (bit 5):
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.
rsv: Reserved (bits 4-7). 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 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 [RFC0768]. 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 a new Dispatch type value
of 0x03 (TBD) when using LOWPAN_IPHC with link-local addresses and of 0x03 (TBD) for LOWPAN_IPHC.
0x04 (TBD) when using LOWPAN_IPHC with addresses formed using a
Common Routable Prefix.
This document reserves another 16-bit short address range from RFC This document reserves another 16-bit short address range from RFC
4944 for use with 16-bit compressed well-known IPv6 multicast 4944 for use with 16-bit compressed well-known IPv6 multicast
addresses. addresses.
This document creates a new IANA registry for mapped well-known This document creates a new IANA registry for mapped well-known
multicast addresses, mapping 112-bit group identifiers to compressed multicast addresses, mapping 112-bit group identifiers to compressed
9-bit ones. The registry MUST include the All Nodes Address (1) and 9-bit ones. The registry MUST include the All Nodes Address (1) and
the All Routers Address (2). the All Routers Address (2).
 End of changes. 34 change blocks. 
92 lines changed or deleted 119 lines changed or added

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