draft-ietf-6lowpan-hc-07.txt   draft-ietf-6lowpan-hc-08.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: October 10, 2010 April 8, 2010 Expires: January 27, 2011 July 26, 2010
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-07 draft-ietf-6lowpan-hc-08
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 October 10, 2010. This Internet-Draft will expire on January 27, 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 26 skipping to change at page 2, line 26
3.1.2. Context Identifier Extension . . . . . . . . . . . . . 8 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 8
3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9
3.2.1. Traffic Class and Flow Label Compression . . . . . . . 9 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 9
3.2.2. Mapping Link-Layer Addresses to Interface IDs . . . . 10 3.2.2. Mapping Link-Layer Addresses to Interface IDs . . . . 10
3.2.3. Stateless Multicast Addresses Compression . . . . . . 11 3.2.3. Stateless Multicast Addresses Compression . . . . . . 11
3.2.4. Stateful Multicast Addresses Compression . . . . . . . 12 3.2.4. Stateful Multicast Addresses Compression . . . . . . . 12
4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 13 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 13
4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 13 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . 15
4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . 16 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding
about 80 octets of actual MAC payload with security enabled, on a about 80 octets of actual MAC payload with security enabled, on a
wireless link with a link throughput of 250 kbps or less. The wireless link with a link throughput of 250 kbps or less. The
6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6
datagrams over such constrained links, taking into account limited datagrams over such constrained links, taking into account limited
skipping to change at page 7, line 28 skipping to change at page 7, line 28
If SAC=0: If SAC=0:
00: 128 bits. The full address is carried in-line. 00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided. 01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried 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 link-layer The remaining 64 bits are computed from the encapsulating
address as defined in Section 3.2.2. header.
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 link-layer address as defined in Section 3.2.2. from the encapsulating header.
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 17 skipping to change at page 8, line 17
address: address:
00: 128 bits. The full address is carried in-line. 00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided. 01: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried 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 link-layer The remaining 64 bits are computed from the encapsulating
address as defined in Section 3.2.2. header.
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 link-layer address as defined in Section 3.2.2. from the encapsulating header.
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 10, line 43 skipping to change at page 10, line 43
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. Mapping Link-Layer Addresses to Interface IDs
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. This section defines the mapping SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived
from IEEE 802.15.4 link-layer addresses to IIDs for both short and from the encapsulating header. When the encapsulating header carries
extended IEEE 802.15.4 addresses. IID bits not covered by the IPv6 addresses, the corresponding bits map directly.
context information MAY be elided if they match the link-layer
address mapping and MUST NOT be elided if they do not. The remainder of this section defines the mapping from IEEE 802.15.4
link-layer addresses to IIDs for both short and extended IEEE
802.15.4 addresses. IID bits not covered by the context information
MAY be elided if they match the link-layer address mapping and MUST
NOT be elided if they do not.
An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 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
transform an IEEE EUI-64 identifier to an interface identifier is to transform an IEEE EUI-64 identifier to an interface identifier is to
invert the universal/local bit. invert the universal/local bit.
A short IEEE 802.15.4 address is 16 bits in length. Short addresses A short IEEE 802.15.4 address is 16 bits in length. Short addresses
are mapped into the restricted space of IEEE EUI-64 addresses by are mapped into the restricted space of IEEE EUI-64 addresses by
setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
skipping to change at page 18, line 25 skipping to change at page 18, line 38
wrong type of payload and misinterpreting the content compared to wrong type of payload and misinterpreting the content compared to
ports that reserved at IANA. It is thus recommended that the use of ports that reserved at IANA. It is thus recommended that the use of
those ports be associated with a mechanism such as a Transport Layer those ports be associated with a mechanism such as a Transport Layer
Security (TLS) Message Integrity Check (MIC) that validates that the Security (TLS) Message Integrity Check (MIC) that validates that the
content is expected and checked for integrity. content is expected and checked for integrity.
7. Acknowledgements 7. Acknowledgements
Thanks to Julien Abeille, 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, Shoishi 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
Draft 08:
- 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 "derived from link-layer header" to "derived from
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.
skipping to change at page 20, line 23 skipping to change at page 20, line 41
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[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.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
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.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[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.
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.
 End of changes. 15 change blocks. 
29 lines changed or deleted 29 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/