rfc6282.txt.pdf资源-CSDN文库

ipv6

需积分: 31 56 浏览量 2020-04-26 22:19:52 上传评论收藏 37KB PDF 举报

资源推荐

资源详情

资源评论

Internet Engineering Task Force (IETF) J. Hui, Ed.

Request for Comments: 6282 Arch Rock Corporation

Updates: 4944 P. Thubert

Category: Standards Track Cisco

ISSN: 2070-1721 September 2011

Compression Format for IPv6 Datagrams

over IEEE 802.15.4-Based Networks

Abstract

This document updates RFC 4944, "Transmission of IPv6 Packets over

IEEE 802.15.4 Networks". This document specifies an IPv6 header

compression format for IPv6 packet delivery in Low Power Wireless

Personal Area Networks (6LoWPANs). The compression format relies on

shared context to allow compression of arbitrary prefixes. How the

information is maintained in that shared context is out of scope.

This document specifies compression of multicast addresses and a

framework for compressing next headers. UDP header compression is

specified within this framework.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force

(IETF). It represents the consensus of the IETF community. It has

received public review and has been approved for publication by the

Internet Engineering Steering Group (IESG). Further information on

Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,

and how to provide feedback on it may be obtained at

http://www.rfc-editor.org/info/rfc6282.

Hui & Thubert Standards Track [Page 1]

RFC 6282 IPv6 Datagrams on IEEE 802.15.4 September 2011

This document is subject to BCP 78 and the IETF Trust’s Legal

Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Table of Contents

1. Introduction ....................................................3

1.1. Requirements Language ......................................4

2. Specific Updates to RFC 4944 ....................................4

3. IPv6 Header Compression .........................................5

3.1. LOWPAN_IPHC Encoding Format ................................6

3.1.1. Base Format .........................................6

3.1.2. Context Identifier Extension .......................10

3.2. IPv6 Header Encoding ......................................11

3.2.1. Traffic Class and Flow Label Compression ...........11

3.2.2. Deriving IIDs from the Encapsulating Header ........12

3.2.3. Stateless Multicast Address Compression ............13

3.2.4. Stateful Multicast Address Compression .............14

4. IPv6 Next Header Compression ...................................15

4.1. LOWPAN_NHC Format .........................................15

4.2. IPv6 Extension Header Compression .........................15

4.3. UDP Header Compression ....................................17

4.3.1. Compressing UDP Ports ..............................17

4.3.2. Compressing UDP Checksum ...........................18

4.3.3. UDP LOWPAN_NHC Format ..............................20

5. IANA Considerations ............................................20

6. Security Considerations ........................................21

7. Acknowledgements ...............................................22

8. References .....................................................22

8.1. Normative References ......................................22

8.2. Informative References ....................................23

Hui & Thubert Standards Track [Page 2]

RFC 6282 IPv6 Datagrams on IEEE 802.15.4 September 2011

1. Introduction

The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding

about 80 octets of actual Media Access Control (MAC) payload with

security enabled, on a wireless link with a link throughput of 250

kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified

to carry IPv6 datagrams over such constrained links, taking into

account limited bandwidth, memory, or energy resources that are

expected in applications such as wireless sensor networks. [RFC4944]

defines a Mesh Addressing header to support sub-IP forwarding, a

Fragmentation header to support the IPv6 minimum MTU requirement

[RFC2460], and stateless header compression for IPv6 datagrams

(LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and

UDP headers down to (in the best case) several bytes.

LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of

IPv6 in 6LoWPANs. LOWPAN_HC1 is most effective for link-local

unicast communication, where IPv6 addresses carry the link-local

prefix and an Interface Identifier (IID) directly derived from IEEE

802.15.4 addresses. In this case, both addresses may be completely

elided. However, though link-local addresses are commonly used for

local protocol interactions such as IPv6 Neighbor Discovery

[RFC4861], DHCPv6 [RFC3315], or routing protocols, they are usually

not used for application-layer data traffic, so the actual value of

this compression mechanism is limited.

Routable addresses must be used when communicating with devices

external to the 6LoWPAN or in a route-over configuration where IP

forwarding occurs within the 6LoWPAN. For routable addresses,

LOWPAN_HC1 requires both IPv6 source and destination addresses to

carry the prefix in-line. In cases where the Mesh Addressing header

is not used, the IID of a routable address must be carried in-line.

However, LOWPAN_HC1 requires 64 bits for the IID when carried in-line

and cannot be shortened even when it is derived from the IEEE

802.15.4 16-bit short address. When the destination is an IPv6

multicast address, LOWPAN_HC1 requires the full 128-bit address to be

carried in-line.

As a result, this document defines an encoding format, LOWPAN_IPHC,

for effective compression of Unique Local, Global, and multicast IPv6

Addresses based on shared state within contexts. In addition, this

document also introduces a number of additional improvements over the

header compression format defined in [RFC4944].

LOWPAN_IPHC allows for compression of some commonly used IPv6 Hop

Limit values. If the 6LoWPAN is a mesh-under stub, a Hop Limit of 1

for inbound and a default value such as 64 for outbound are usually

enough for application-layer data traffic. Additionally, a Hop Limit

Hui & Thubert Standards Track [Page 3]

RFC 6282 IPv6 Datagrams on IEEE 802.15.4 September 2011

value of 255 is often used to verify that a communication occurs over

a single-hop. This specification enables compression of the IPv6 Hop

Limit field in those common cases, whereas LOWPAN_HC1 does not.

This document also defines LOWPAN_NHC, an encoding format for

arbitrary next headers. LOWPAN_IPHC indicates whether the following

header is encoded using LOWPAN_NHC. If so, the bits immediately

following the compressed IPv6 header start the LOWPAN_NHC encoding.

In contrast, LOWPAN_HC1 could be extended to support compression of

next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6.

Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet

and uncompressed IPv6 header fields. This specification moves the

next header encoding bits to follow all IPv6-related bits, allowing

for a properly layered structure and direct support for IPv6

extension headers.

Using LOWPAN_NHC, this document defines a compression mechanism for

UDP. While [RFC4944] defines a compression mechanism for UDP, that

mechanism does not enable checksum compression when rendered possible

by additional upper-layer mechanisms such as upper-layer Message

Integrity Check (MIC). This specification adds the capability to

elide the UDP checksum over the 6LoWPAN, which enables saving of a

further two octets.

Also, using LOWPAN_NHC, this document defines encoding formats for

IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With

LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded

efficiently.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 [RFC2119].

2. Specific Updates to RFC 4944

This document specifies a header compression format that is intended

to replace that defined in Section 10 of [RFC4944]. Implementation

of Section 10 of [RFC4944] is now NOT RECOMMENDED. New

implementations MAY implement decompression according to Section 10

of [RFC4944] but SHOULD NOT send packets compressed according to

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

Hui & Thubert Standards Track [Page 4]

剩余23页未读，继续阅读

评论收藏

内容反馈

zangchang

粉丝: 4
资源: 23

rfc6282.txt.pdf

RFC 6282 （中文版）基于IEEE-802.15.4网路的IPv6报文压缩格式(6LoWPAN).pdf

RFC6282(中文版)基于IEEE 802.15.4网路的IPv6报文压缩格式(6LoWPAN)

6LoWPANs-RFC中文手册（RFC6282、RFC6568、 RFC4944）.rar

RFC4919_6LoWPAN

rfc3262.txt.zip_rfc3261_rfc3261.txt_rfc3262_sip 3261

rfc7011.txt.pdf

RFC系列文档大全（RFC1001-RFC2000）

rfc5102.txt.pdf

HTTP2-rfc7540.pdf

rfc7348.txt.pdf

rfc6787.txt.pdf

rfc7292.txt.pdf

rfc2030.txt.pdf

rfc1213.txt.pdf

rfc7012.txt.pdf

rfc5610.txt.pdf

rfc5470.txt.pdf

rfc2733.txt.pdf

RFC.rar_rfc_rfc1433.t

md5算法描述_rfc1321.txt.pdf

中文RFC文档.rar

rfc1112.rar_rfc1112

rfc2501-rfc3000

rfc中文翻译版本

rfc501-1000

RFC文档2501-3000

rfc5321（中）.txt

RFCs3001-3500.zip

rfc2236.rar_rfc2236

RFC3261中文版本

最新资源