draft-ietf-6lowpan-hc-14.txt   draft-ietf-6lowpan-hc-15.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: August 18, 2011 February 14, 2011 Expires: August 28, 2011 February 24, 2011
Compression Format for IPv6 Datagrams in Low Power and Lossy Networks Compression Format for IPv6 Datagrams in Low Power and Lossy Networks
(6LoWPAN) (6LoWPAN)
draft-ietf-6lowpan-hc-14 draft-ietf-6lowpan-hc-15
Abstract Abstract
This document updates RFC 4944, "Transmission of IPv6 Packets over This document updates RFC 4944, "Transmission of IPv6 Packets over
IEEE 802.15.4 Networks". This document specifies an IPv6 header IEEE 802.15.4 Networks". This document specifies an IPv6 header
compression format for IPv6 packet delivery in Low Power and Lossy compression format for IPv6 packet delivery in Low Power and Lossy
Networks (6LoWPANs). The compression format relies on shared context Networks (6LoWPANs). The compression format relies on shared context
to allow compression of arbitrary prefixes. How the information is to allow compression of arbitrary prefixes. How the information is
maintained in that shared context is out of scope. This document maintained in that shared context is out of scope. This document
specifies compression of multicast addresses and a framework for specifies compression of multicast addresses and a framework for
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 August 18, 2011. This Internet-Draft will expire on August 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 39 skipping to change at page 2, line 39
4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 17 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 17
4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 17 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 17
4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 19 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The [IEEE 802.15.4] standard specifies an MTU of 127 bytes, yielding The [IEEE 802.15.4] standard specifies an MTU of 127 bytes, yielding
about 80 octets of actual Media Access Control (MAC) payload with about 80 octets of actual Media Access Control (MAC) payload with
security enabled, on a wireless link with a link throughput of 250 security enabled, on a wireless link with a link throughput of 250
kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified
to carry IPv6 datagrams over such constrained links, taking into to carry IPv6 datagrams over such constrained links, taking into
account limited bandwidth, memory, or energy resources that are account limited bandwidth, memory, or energy resources that are
expected in applications such as wireless sensor networks. [RFC4944] expected in applications such as wireless sensor networks. [RFC4944]
skipping to change at page 6, line 4 skipping to change at page 6, line 4
IID derived directly from either the 64-bit extended or 16-bit short IID derived directly from either the 64-bit extended or 16-bit short
IEEE 802.15.4 addresses. IEEE 802.15.4 addresses.
+-------------------------------------+---------------------------- +-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+---------------------------- +-------------------------------------+----------------------------
Figure 1: LOWPAN_IPHC Header Figure 1: LOWPAN_IPHC Header
The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from
the rightmost bit of the dispatch type. The encoding may be extended the rightmost bits of the dispatch type. The encoding may be
by another octet to support additional contexts. Any information extended by another octet to support additional contexts. Any
from the uncompressed IPv6 header fields carried in-line follow the information from the uncompressed IPv6 header fields carried in-line
LOWPAN_IPHC encoding, as shown in Figure 1. In the best case, the follow the LOWPAN_IPHC encoding, as shown in Figure 1. In the best
LOWPAN_IPHC can compress the IPv6 header down to two octets (the case, the LOWPAN_IPHC can compress the IPv6 header down to two octets
dispatch octet and the LOWPAN_IPHC encoding) with link-local (the dispatch octet and the LOWPAN_IPHC encoding) with link-local
communication. communication.
When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6
header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC,
1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination
Address). The Hop Limit may not be compressed because it needs to Address). The Hop Limit may not be compressed because it needs to
decremented at each hop and may take any value. Stateful address decremented at each hop and may take any value. Stateful address
compression must be applied to the source and destination IPv6 compression must be applied to the source and destination IPv6
addresses because they do not statelessly match the source and addresses because they do not statelessly match the source and
destination link layer addresses on intermediate hops. destination link layer addresses on intermediate hops.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
security and integrity check (e.g. IPsec Encapsulating Security security and integrity check (e.g. IPsec Encapsulating Security
Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the
tunneling mechanism MAY authorize to elide the UDP checksum in tunneling mechanism MAY authorize to elide the UDP checksum in
order to save on the encapsulation overhead. order to save on the encapsulation overhead.
Message Integrity Check: In this case, either IPsec Authentication Message Integrity Check: In this case, either IPsec Authentication
Header [RFC4302] or some other form of integrity check in the UDP Header [RFC4302] or some other form of integrity check in the UDP
payload that covers at least the same information as the UDP payload that covers at least the same information as the UDP
checksum (pseudo-header, data) and has at least the same strength. checksum (pseudo-header, data) and has at least the same strength.
The Upper Layer MUST NOT provide the authorization when neither of
the above two cases applies.
To help ensure that the UDP Checksum will be properly restored when To help ensure that the UDP Checksum will be properly restored when
expanding a 6LoWPAN packet, an additional integrity check (e.g. L2 expanding a 6LoWPAN packet, an additional integrity check (e.g. L2
Message Integrity Check) MUST be used whenever transmitting link Message Integrity Check) MUST be used whenever transmitting link
frames that carry a compressed UDP datagram that elides the checksum. frames that carry a compressed UDP datagram that elides the checksum.
Without this additional integrity check, a UDP packet may be Without this additional integrity check, a UDP packet may be
delivered to an unintended destination since corruption in data delivered to an unintended destination since corruption in data
covered by the pseudo-header can go undetected. covered by the pseudo-header can go undetected.
A compressor MUST verify the UDP Checksum before it is elided and A compressor MUST verify the UDP Checksum before it is elided and
SHOULD ensure that the additional integrity check is in place before SHOULD ensure that the additional integrity check is in place before
skipping to change at page 21, line 15 skipping to change at page 21, line 15
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) [RFC5246] Message Integrity Check (MIC) that validates Security (TLS) [RFC5246] Message Integrity Check (MIC) that validates
that the content is expected and checked for integrity. that the 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, Joseph Reddy, Shoichi Sakane, Zach Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach
Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design
consideration and implementation feedback. consideration and implementation feedback. Special thanks to David
Black, Lars Eggert and Carsten Bormann for their contribution in
closing the security issues around UDP compression.
8. Changes 8. Changes
(This section to be removed by the RFC editor.) (This section to be removed by the RFC editor.)
Draft 15:
- Edits in response to IESG comments.
Draft 14: Draft 14:
- Edits in response to IESG comments. - Edits in response to IESG comments.
Draft 13: Draft 13:
- Specify that address bits not covered by the context or IID are - Specify that address bits not covered by the context or IID are
zero. zero.
Draft 12: Draft 12:
- Specify that 16-bit to IID mapping is used to derive IID bits - Specify that 16-bit to IID mapping is used to derive IID bits
when SAC/DAC=1 and the context does not cover those bits. when SAC/DAC=1 and the context does not cover those bits.
 End of changes. 8 change blocks. 
11 lines changed or deleted 19 lines changed or added

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