draft-ietf-6lowpan-hc-11.txt   draft-ietf-6lowpan-hc-12.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: March 5, 2011 September 1, 2010 Expires: March 25, 2011 September 21, 2010
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-11 draft-ietf-6lowpan-hc-12
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 March 5, 2011. This Internet-Draft will expire on March 25, 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . 9 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 9
3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 10
3.2.1. Traffic Class and Flow Label Compression . . . . . . . 10 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 10
3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11 3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11
3.2.3. Stateless Multicast Address Compression . . . . . . . 12 3.2.3. Stateless Multicast Address Compression . . . . . . . 12
3.2.4. Stateful Multicast Address Compression . . . . . . . . 13 3.2.4. Stateful Multicast Address Compression . . . . . . . . 13
4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 13 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 14
4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . 17
4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 17 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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 (e.g. 802.15.4 or IPv6 source address) as specified header (e.g. 802.15.4 or IPv6 source address) as specified
in Section 3.2.2. 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. Any bits of the IID not
covered by context information are taken directly from their
corresponding bits in the 16-bit to IID mapping given by
0000:00ff:fe00:XXXX, where XXXX are 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 (e.g. 802.15.4 or IPv6 source from the encapsulating header (e.g. 802.15.4 or IPv6 source
address) as specified in Section 3.2.2. 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.
skipping to change at page 8, line 35 skipping to change at page 8, line 41
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 (e.g. 802.15.4 or IPv6 destination address) as header (e.g. 802.15.4 or IPv6 destination address) as
specified in Section 3.2.2. 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. Any bits of the IID not
covered by context information are taken directly from their
corresponding bits in the 16-bit to IID mapping given by
0000:00ff:fe00:XXXX, where XXXX are 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 (e.g. 802.15.4 or IPv6 from the encapsulating header (e.g. 802.15.4 or IPv6
destination address) as specified in Section 3.2.2. 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 20, line 9 skipping to change at page 20, line 9
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, Shoichi Sakane, Zach Shelby, Dario Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach
Tedeschi, Tony Viscardi, and Jay Werb for useful design consideration Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design
and implementation feedback. consideration and implementation feedback.
8. Changes 8. Changes
(This section to be removed by the RFC editor.) (This section to be removed by the RFC editor.)
Draft 12:
- 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.
Draft 11: Draft 11:
- Removed incorrect and unnecessary text in specifying how to - Removed incorrect and unnecessary text in specifying how to
derive the IID bits not covered by the context. derive the IID bits not covered by the context.
- Adjust formatting to reduce orphans and widows.. - Adjust formatting to reduce orphans and widows.
Draft 10: Draft 10:
- Specify that the IID has the form 0000:00ff:fe00:XXXX when SAC/ - Specify that the IID has the form 0000:00ff:fe00:XXXX when SAC/
DAC=0 and SAM/DAM=10. DAC=0 and SAM/DAM=10.
Draft 09: Draft 09:
- Indicate that a mechanism to learn decompressor's capabilities - Indicate that a mechanism to learn decompressor's capabilities
to decode additional (future) NHCs is out of scope. to decode additional (future) NHCs is out of scope.
- Clarify how to derive IID bits not covered by the context when - Clarify how to derive IID bits not covered by the context when
only 16 bits are carried inline. only 16 bits are carried inline.
 End of changes. 12 change blocks. 
13 lines changed or deleted 27 lines changed or added

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