Transmission of Compressed IPv6 Packets over IEEE 802.15.4 Networks draft-bouchet-transmission-of-compressed-ipv6-00

Abstract

The document describes an IPv6 header compression format for transmission of IPv6 packets in 6LoWPAN networks. Specifications of the compression format rely on specific contexts for which the implementation of fragmentation and defragmentation/reassembly is not recommended. Specifications include frameworks for compressing and decompressing header as well as compression and decompression of source and destination addresses. This document complements "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", [draft-ietf-6lowpan-hc-07].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html"

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.

1. Introduction

It is increasingly common to notice several diverse areas of application in which a range of Low Power wireless Sensor Networks(WSN) is being deployed. If the current scale and growth of such deployments are any indication, it is likely that soon we would require very large scale internetwork of WSNs which may have to be connected to one or more global networks/internetworks. A reasonable number of such situations would likely benefit from a need based provisioning of relevant IP level communication capabilities where all the intervened nodes may have to have associated IP addresses. Since IPv4 is running out of its global address space even for conventional Internet based systems and applications it cannot be considered a viable IP addressing choice for

such sensor networks and internetworks. Moreover, thanks to the computation capabilities of the WSN nodes, it may not benefit to have a dual stack kind of support (IPv6 and IPv4) provisioned. It is in this context that IPv6 Low Power Wireless Personal Area Network (6LoWPAN) assumes significance.

The use cases of LoWPAN can be classified in three different situations: an all-nodes fixed situation, an all-nodes mobile situation and an hybrid situation. This document presents a simple approach for realization of 6LoWPAN. It addresses situations where all the deployed nodes are fixed or immobile. These situations include data collecting and monitoring changes over period of time. Additional complementary draft might be written to cover the other situations.

LoWPAN relies on standards including, but not limited, to the IEEE 802.15.4-2003 standard [IEEE802.15.4]. This document has been prepared in such a manner that almost all the recommendations made herein remain generic in nature so as to allow the central recommendations to be easily adaptable to any future standard including future variants of IEEE 802.15.4. However some of the sample formats herein have been based on the existing IEEE 802.15.4-2003 standard so as to make them immediately usable.

This draft defines a mechanism of header compression keeping overheads as minimum as possible by making suitable assumptions, saving on computation and energy and providing more octets for data.

1.1. Requirements Notation

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 [RFC2119].

2. Problem Background

IEEE 802.15.4 protocol specifies a maximum packet size of 127 octets. The physical layer imposes a maximum overhead of 25 octets leaving 102 octets for media access control layer. Link-layer security has its own overhead, which in the maximum case (AES-CCM-128 case) is 21 octets leaving only 81 octets available. Furthermore, the IPv6 header is 40 octets long, leaving only 41 octets for upper-layer protocols, like UDP. The latter uses 8 octets in the header which leaves only 33 octets for application data. The situation clearly emphasizes a need on header compression and fragmentation. The intensive use of fragmentation and reassembly would lead to an unnecessary waste of computational power and energy. Major problems faced with fragmentation and header compression include problems in the determination of a mechanism for fragments routing, complexity of the determination of fragment loss and recovery and ensuring that fragment offset remains unaffected by header compression. Use of Acknowledge/No Acknowledge signals could be employed to solve these problems (as reassembly will start once all packets have been received by the destination node) and would also ensure reliability. However this would lead to faster draining of battery due to overhead of Ack/NAck packet transfer.

Thus, to avoid the use of fragmentation and reassembly, header compression needs to be reconsidered and certain features of IPv6 have to be elided or minimized.

3. IPv6 Compressed Header Format:

This section specifies the format of the IPv6 compressed header. The remaining header is 6 octets long.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UnR |T| SO| N |L| HL | SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| DA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UnR: UnReserved Unused bits which can be used for future work. Currently, there are 7 bits to complete up the octet and can be assigned any random value.

T: Traffic Class: 1 bit 0: No Priority 1: High Priority It is further explained in Section No 10

SO: Security Option: 2 bits 00: No security 01: Authentication 10: Encryption 11: Reserved It is further explained in Section No 11

N: Next Header 00: No Next Header 01: UDP Header 10: Routing Header 11: Future uses Next Header is allocated 2 bits. Very few next header options are taken in their original form, while others have been modified or elided. See Section 9 for more details.

L: Loose Source Routing Loose Source Routing is assigned 1 bit. It is set to determine if the packet is sent as Routing Extension Header. More details can be found in Section 12.

HL: Hop Limit Hop Limit is not modified and remains 8 bits long. Therefore a maximum of 255 hops can be made. Should this number become insufficient in the future, the UnReserved bits could be used.

SA: Source Address Source Address is a 13-bit field. Address is configured as described in Section 7. Compression of 128-bit address to 13-bit address is detailed in Section 5.

D: Destination Address Type 0: Unicast 1: Multicast Destination Address Type is a 1-bit field. It determines whether the address is of type Unicast or Multicast.

DA: Destination Address Destination Address is a 13-bit field. Address is configured as described in Section 7. Compression of 128-bit address to 13-bit address is detailed in Section 5.

4. IPv6 compression and expansion Algorithm

This section describes how to compress the 40-octet long IPv6 header to its compressed 6-octet format and how to expend the compressed 6-octet format to a full 40-octet header. The algorithm elides some fields, which are assumed to remain common for 6LoWPAN communication: Version is 6; Flow Label is zero; Payload Length can be inferred from lower layers from the IEEE 802.15.4 header; Hop Limit will be set to a well-known value by the source, 128-bit IPv6 addresses are reduced to 13-bit addresses. To this date, the largest 6LoWPAN network ever put together counted 800 nodes. A 13-bit address allows an 8000-node network to function. The addressing model is described in Section 5; the algorithms for address translation are described in Section 6.

4.1 Compression of 40 octets to 6 octets

The following algorithm is used for the header compression:

V = 40_octets_header[1-4] //Read the first 4 bits for checking the version

if(V == 0100b) // It is an IPv4 address apply the IPv4toIPv6 algorithm

6_octets_header[1-6] = 0000000b// setting the unreserved bits to 0

if (traffic class != 0000 0000) 6_octets_header[7]=1 else 6_octets_header[7]=0

// Ignore the flow label

P = 40_octets_header[32-47]// reading the payload length field.

if(P< 0x0080h && P> 0x0000h ) continue else discard the packet

H = 40_octets_header[48-55] // reading the next header field

while ( there exists a next header) if(H == 17) // if it is a UDP upper layer next header 6octet[10-11] = 01 //set the 'N' to 01, the next header bits to 01 else if (H == 59 ) 6octet[10-11] = 00 //set the 'N' to 00, the next header bits to 00 else if (H== 51) 6octet[8-9] = 01 //set the security bits to 01 else if (H==50 ) 6octet[8-9] = 10 //set the security bits to 10 else if (H==43 ) 6_octets_header[12] = 1 //set the loose source routing bit to 1 else go to the next header if there exists one.

if ( 6octet[8-9] != 10 && 6octet[8-9] != 01 ) //if the security bit //has already been not set by // considering the next header

6octet[8-9] = 00 // set the security bits to 00

if ( 6octet[12] != 1 ) //if the loose has already been not set by //considering the next header 6octet[12] = 0 // set the loose source routing bit to 0

L = 40_octets_header[56-63] //reading the hop limit field

if( L < 0x00ffh && L > 0x0001h) 6_octets_header[13-20] = L // set the hop limit accordingly else discard the packet

6_octets_header[21-32] = SA // SA is formed by using the algorithm given in Section 5. Set Source Address derived from the algorithm.

6_octets_header[33] = 0 or 1 // Decided by reading the 128 bit destination address.

6_octet_header[34-46] = DA // DA is formed by using the algorithm given in Section 5.Set Source Address derived from the algorithm.

4.2 Expansion of 6 octets to 40 octets

The following algorithm is to be used for Header Expansion/Decompression at the Gateway node:

Expansion6to40(header_6_initial[48], header_40_final[320] ){

header_40_final[0-3] <- 0x6h //Setting up version

if(header_6_initial[7]==0) //Traffic Class header_40_final[4-11] <- 0x00h else header_40_final[4-11] <- 0x3Fh

if header_6_initial [8-9]==0x0h) // Security option further detailed in Section 11 //no security else if(header_6_initial [8-9]==0x0h) //implement authentication else if(header_6_initial [8-9]==0x0h) //implement encryption else // do nothing

header_40_final [12-31] <- 0x00h //Flow label

header_40_final [32-47] <- payload length derived from IEEE 802.15.4 Header. // Payload Length

if(header_6_initial [10] ==0) //Loose Source Routing //No Source Routing else //Implement Loose Source Routing

header_40_final [48-55] <- Put up appropriate value // The Values must be in correct order as per the Extension Header mentioned in RFC 2460

header_40_final [56-63] <- header_6_initial [13-20] //Hop Limit

header_40_final [64-191] <- Source Address //Using Algorithm in Section 5 for header_6_initial [21-33]

if(header_6_initial [34]==0) //Check for Multicast/Unicast

header_40_final [192-319] <- Destination Address //Using Algorithm in Section 5 on header_6_initial [35-47] else header_40_final [192-319] <- Destination Address //Using Algorithm in Section 5 on header_6_initial [35-47] }

As described in Section 9, few Extension Header are taken as they are, few have been elided completely while others are implemented with minimal functionalities.

4.3 Translation of IPv4 packet into IPv6 packet

The following settings are to be used to translate an IPv4 packet into an IPv6 packet.

Version = 6

Traffic Class = IPv4 header TOS bits

Flow Label = 0

Payload Length = IPv4 header Total Length value + (IPv4 header length + IPv4 options length)

Next Header = IPv4 header Protocol field value

Hop Limit = IPv4 TTL field value - 1

Source IP Address = 0:0:0:0:FFFF::/80 concatenated with IPv4 header source IP address

Destination IP Address = 0:0:0:0:0:FFFF::/96 concatenated with IPv4 header destination IP address

5. Addressing

This section defines the addressing model of IPv6 compressed addresses.

5.1 Global Unicast Address

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global prefix and SID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ given by provider and network engineer (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P(5 bits)| 0::0 (46 bits) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0::0 | SA (13 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P: 5-bit 6LoWPAN prefix. This field indicates that the address is a 6LoWPAN address. This field is set to 11111b.

SA: 13-bit Short Address.

5.2 13-bit Short Address

The nodes within the network will have a 13-bit address. Also, 256 addresses are reserved for machines outside the 6LoWPAN network. These addresses are designated by a 5-bit prefix 11111b.

6. Address Translation

This section describes the translation of 128-bit addresses to 13-bit addresses and vice-versa. These algorithms require the implementation of a Translation table whose maximum size is 4kb.

6.1 Translation of a 128 bit address into a 13 bit address

The following algorithm is used to translate a 128-bit regular IPv6 address into a unique 13-bit address.

P = 128bit_address[65 -69] // read the 5 bits from 65th to 69th.

if(P == 11111b) Set the last 13 bits in Source/Destination Address field //the same as the last 13 bits of the 128 bit address else Read the translation table

if( 128-bit address is present in the table) set the corresponding 13 bit address in Source/Destination Address field else put it in the table, assign it a 13 bit address and set the 13 bit address in Source/Destination field

6.2 Translation of a 13-bits address into a 128 bits address

The following algorithm is used to translate a 13-bit address into a 128-bit regular IPv6 address.

F = 13bit_address[1-5] // read the 5 bits from 1st bit to 5th bit of the 13 bit address.

if(F == 11111b) read the translation table and set the correspondent 128-bit address in Source/Destination Address field else create the 128 bit address first 64 bits formed by concatenating the Global Prefix and SID, 65th to 68th bit set to 1 69th to 114th bits set to 0 13-bit address is set in the 13 last bits of the 128-bit address

7. Communication between outside world and inside the WSN

Consider a machine Ma, external to WSN network, which needs to communicate with a WSN node Wb, where 1<=a<=255; 1<=b<=2^13. Ma sends a request to the gateway to obtain the IPv6 address of the node Wb. The gateway sends the information to Ma.

Ma sends a packet to Wb with the full 128 bits destination address. This packet is intercepted by the gateway which is the only way to reach the WSN. When the packet is received by the Gateway, the Gateway translates the message in a WSN packet : the header is compressed, the destination address is replaced by the 13-bit equivalent address and the 128-bit address of Ma is registered in a look-up table in the

gateway. The gateway assigns a new 13-bit address to Ma which is registered in the look-up table and which corresponds to the 128-bit address of Ma. This 13-bit address is set in the Source Address Field. This address has a 11111-prefix in order to indicate that it corresponds to an outside machine. The translated message is then forwarded to Wb.

If Wb then needs to communicate with Ma, it sends a packet destined to Ma. This packet is intercepted by the gateway which translates the packet: the header is extended, the source address is replaced by a 128-bit address using the algorithm describes above and the destination address is obtained by getting the 128-bit address which corresponds to the 13 bit-address in the look-up table. Then the packet is forwarded to the outside network.

8. Address Autoconfiguration

The nodes will obtain their 13-bit address statelessly as soon as they power up. Their corresponding 128-bit addresses will have global scope and will be globally unique. Duplicate Address Detection will be performed to ensure that the 13-bit address obtained by the node is unique inside the WSN. If an assigned address is already in use, a new address will be taken up by the concerned node.

9. Next Header

This section describes the Next Header mentioned in [RFC 2460] and IPv6 Extension Headers Review and Consideration

9.1. Hop-by-Hop Options header

The problem with the Hop-by-hop field is that it must be seen, understood and acted upon by every node, which is an unnecessary wastage of energy. The data collected and conveyed in the majority of real life applications through wireless sensor networks do not require any special processing in intermediate nodes that may benefit from the provisioning of the hop-by-hop Extension Header. Thus we do not recommend the implementation of the Hop-by-hop option.

9.2. Routing header

The Routing Header is expressed explicitly only as Loose Source Routing described in Section 12.

9.3. Authentication header

The Authentication header is elided in its original form. ESP (Encapsulating Security Payload) covers all the functionalities that are to be carried out by an Authentication Header. In cases where only Authentication is needed, it is set in Security Bit described in Section 11.

9.4. Encapsulating Security Payload header

Encryption and Decryption consume more resources in terms of power and processing. Thus, their use is not recommended. Only in cases where some high security is required, minimal functionalities can be implemented. See Section 11 for more details.

9.5 Destination Options Header

Use of Destination Options is not recommended as the use of this extension header would lead to the extension of the packet size beyond MTU.

9.6 Fragment Header

The use of this header is totally elided as fragmentation is totally

avoided.

9.7 No Next Header

No next header is explicitly mentioned by 00 and in original IPv6 header it is denoted by 59.

9.8 Upper Layer Header

The value 01 is use to denote upper layer header which means that the transportation protocol used is UDP (denoted by value 17 in the original IPv6 header). TCP, although being reliable, is not used as a transportation protocol as handshaking will result in sending more packets, thus draining more energy.

10. Traffic Class

The original IPv6 Header as received by the gateway may contain 8-bit traffic class and 20-bit flow label specifications. In that case, our recommendation mandates this 28-bit specification to be abstracted into two classes: time-sensitive and time-insensitive. Therefore, our header compression specification uses just 1 bit which may be set or unset to denote the time-sensitivity of the packet. This is in keeping in with the fact that in most of the practical WSN application scenarios, we seldom come across situations which may warrant a more complex handling of WSN traffic.

11. Security Option

In most cases, WSN do not handle security sensitive data and hence implementing full fledged security as mentioned in RFC 4301, 4302 4303 and 2460, would lead to an unnecessary waste of computation and battery drainage. Basic security can be provided by lower layers. However, in cases where additional security measures at IP layer are required, the need for authentication or encryption-decryption can be specified thanks to the Security Option.

12. Loose Source Routing

Loose Source Routing is done to verify whether certain nodes are reachable from a particular source. In these cases, the payload could only contain addresses and nothing else. In cases where the content of the packet is more sensitive and as an additional security measure, payload data can be also be present along with the addresses. This is to ensure that the packet reaches its destination via a safe and known path. For this purpose some bits can be used from the UnReserved set of bits to specify the number of addresses present, some octets from the payload can also be taken up as an alternate. It is necessary to ensure that doing this SHOULD NOT lead to fragmentation.

13. Constraints:

a.) The Hop Limit implies a restriction of 255 hops. Should this number become insufficient in the future; the UnReserved bits could be used.

14. Consequences:

a.) Number of octets left for Payload are 67.

15. Security Considerations:

The scenarios considered in this draft have a low-security level. The recommendations given in this draft are not valid for sensitive scenarios.

16. References

16.1 Normative References:

[RFC 4944] Montenegro, G., Kushalnagar, N., Hui, J., Culler, J., "Transmission of IPv6 Packets over IEEE 802.15.4

Networks", September 2007

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460,December 1998.

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.

[draft-ietf-6lowpan-hc-07] J. Hui, P. Thubert, "Compression Format for

IPv6 Datagrams in 6LoWPAN Networks", April 2010

16.2 Informative References

[RFC 4301] Kent, S., Seo, K., "Security Architecture for the Internet Protocol"

[RFC 4302] Kent, S., "IP Authentication Header"

[RFC 4303] Kent, S., "IP Encapsulating Security Payload (ESP)"

16.3 URL References: [Extension Header] IPv6 Extension Headers Review and Considerations http://www.cisco.com/en/US/technologies/tk648/tk872 /technologies_white_paper0900aecd8054d37d.html

Authors' Addresses:

Lucie Bouchet lucie.bouchet@telecom-bretagne.eu

Jeremie Jambet jeremie.jambet@telecom-bretagne.eu

Anubhav Agarwal f2006125@bits-pilani.ac.in

Karanjit Singh Cheema

f2006071@bits-pilani.ac.in

Rahul Banerjee rahul@bits-pilani.ac.in

The work has been done in the premises of Birla Institute of Technology & Science, Pilani. For all correspondence after May 13th, 2010, kindly communicate to last author.

Lây truyền nén gói tin IPv6 trên mạng IEEE 802.15.4          dự thảo Bouchet-truyền-nén-ipv6-00

Tóm tắt

   Tài liệu này mô tả một định dạng nén header IPv6 cho   truyền tải các gói tin IPv6 trong các mạng 6LoWPAN. Thông số kỹ thuật   của định dạng nén dựa vào bối cảnh cụ thể mà   thực hiện phân mảnh và chống phân mảnh / reassembly   khuyến khích. Thông số kỹ thuật bao gồm các khuôn khổ cho nén và   giải nén tiêu đề cũng như nén và giải nén của   nguồn và địa chỉ đích. Tài liệu này bổ sung   "Nén Định dạng cho các gói IPv6 trong mạng 6LoWPAN",   [Dự thảo-IETF-6lowpan-hc-07].

Trạng thái của Memo này

   Dự thảo Internet này được nộp đầy đủ phù hợp với   quy định của BCP 78 và BCP 79. Internet nháp tài liệu làm việc   Engineering Task Force Internet (IETF), các khu vực của nó, và   làm việc nhóm. Lưu ý rằng các nhóm khác cũng có thể phân phối làm việc   tài liệu như Internet nháp.

   Internet-Nháp là dự thảo văn bản giá trị tối đa là sáu tháng   và có thể được cập nhật, thay thế, hoặc đã lỗi thời bằng các văn bản khác bất cứ lúc nào.   Nó là không thích hợp để sử dụng Internet nháp như tài liệu tham khảo hoặc   trích dẫn họ khác hơn là "công việc đang tiến."

   Danh sách nháp mạng Internet hiện nay có thể được truy cập tại   http://www.ietf.org/1id-abstracts.html

   Danh sách các mục Bóng Internet-Dự thảo có thể được truy cập tại   http://www.ietf.org/shadow.html "

   Tài liệu này là BCP 78 và Trust pháp lý của IETF   Điều khoản liên quan đến tài liệu IETF   (Http://trustee.ietf.org/license-info) có hiệu lực từ ngày   công bố tài liệu này. Vui lòng xem lại các tài liệu này   cẩn thận, như họ mô tả các quyền của mình và hạn chế đối với   tài liệu này. Mã thành phần chiết xuất từ tài liệu này phải   bao gồm văn bản đơn giản Giấy phép BSD như được mô tả trong 4.e mục   các quy định pháp lý tin tưởng và được cung cấp mà không có bảo hành như   được mô tả trong Giấy phép BSD giản.

   1. Giới thiệu

   Đó là ngày càng phổ biến để thông báo một số khu vực đa dạng của   ứng dụng trong một loạt các cảm biến không dây điện thấp   Networks (WSN) đang được triển khai. Nếu quy mô hiện tại và tăng trưởng   triển khai đó là bất kỳ dấu hiệu cho thấy, có khả năng là sớm   chúng tôi sẽ yêu cầu liên mạng quy mô rất lớn của WSNs có thể   phải được kết nối với một hoặc nhiều mạng lưới toàn cầu / một mạng.   Một số lượng hợp lý các tình huống như vậy có thể sẽ được hưởng lợi từ   một nhu cầu cung cấp dựa trên các thông tin liên lạc có liên quan cấp IP   khả năng mà tất cả các nút can thiệp có thể có   có liên quan đến các địa chỉ IP. Kể từ khi IPv4 đang chạy ra khỏi toàn cầu của nó   không gian địa chỉ ngay cả đối với hệ thống Internet thông thường dựa trên và   ứng dụng nó không thể được coi là một địa chỉ IP khả thi giải quyết sự lựa chọn cho   mạng cảm biến và một mạng như vậy. Hơn nữa, nhờ vào sự   khả năng tính toán của các nút WSN, nó có thể không lợi ích cho   một loại dual stack (IPv6 và IPv4) được cung cấp. Đó là trong   bối cảnh này rằng IPv6 điện năng thấp không dây cá nhân Area Network   (6LoWPAN) giả định ý nghĩa.

   Các trường hợp sử dụng LoWPAN có thể được phân loại trong ba khác nhau   tình huống: một nút tất cả các tình huống cố định, một tất cả-các nút tình hình điện thoại di động   và một tình huống lai. Tài liệu này trình bày một cách tiếp cận đơn giản cho   thực hiện của 6LoWPAN. Nó đề cập đến tình huống nơi mà tất cả các triển khai   các nút được cố định hoặc bất động. Những tình huống này bao gồm thu thập dữ liệu   và giám sát các thay đổi theo thời gian. Các bổ sung   dự thảo có thể được viết để trang trải các tình huống khác.

   LoWPAN dựa trên các tiêu chuẩn bao gồm, nhưng không giới hạn, IEEE   802.15.4-2003 tiêu chuẩn IEEE802.15.4]. Tài liệu này đã được chuẩn bị   theo cách thức như vậy mà hầu như tất cả các khuyến nghị được thực hiện ở đây vẫn còn   chung trong tự nhiên để cho phép các khuyến nghị trung ương được   dễ dàng thích ứng với bất kỳ tiêu chuẩn nào trong tương lai bao gồm cả các biến thể tương lai của   IEEE 802.15.4. Tuy nhiên một số các định dạng mẫu tài liệu này đã được   dựa trên các tiêu chuẩn hiện hành 802.15.4-2003 IEEE để làm cho họ   ngay lập tức có thể sử dụng.

   Dự thảo này quy định một cơ chế của các chi phí tiêu đề nén giữ   tối thiểu có thể bằng cách đưa ra những giả định phù hợp, tiết kiệm   tính toán, năng lượng và cung cấp các octet nhiều hơn cho dữ liệu.

1.1. Yêu cầu Ký hiệu

   Các từ khóa "phải", "phải không", "YÊU CẦU", "SẼ", "SẼ KHÔNG",

   "Nên", "không nên", "ĐỀ NGHỊ", "CÓ THỂ", và "TÙY CHỌN" trong này   tài liệu là để được giải thích như mô tả trong [RFC2119].

2. Vấn đề nền

   IEEE 802.15.4 giao thức xác định một gói kích thước tối đa trong 127 octet.   Các lớp vật lý áp đặt một chi phí tối đa là 25 octet để lại 102   octet cho lớp kiểm soát truy cập phương tiện truyền thông. Link-lớp bảo mật riêng của mình   trên không, mà trong trường hợp tối đa (AES-CCM-128 trường hợp) là 21 octet   để lại chỉ có 81 octet. Hơn nữa, tiêu đề IPv6 là 40   octet dài, để lại chỉ có 41 octet giao thức trên lớp, như   UDP. Sau đó sử dụng 8 octet trong tiêu đề lá chỉ có 33 octet   dữ liệu ứng dụng. Tình hình rõ ràng nhấn mạnh nhu cầu tiêu đề   nén và phân mảnh.   Việc sử dụng chuyên sâu của các phân mảnh và reassembly sẽ dẫn đến một   chất thải không cần thiết của sức mạnh tính toán và năng lượng. Vấn đề lớn   phải đối mặt với sự phân mảnh và nén tiêu đề bao gồm các vấn đề trong   xác định một cơ chế để các mảnh vỡ định tuyến, phức tạp của   xác định mất mảnh và phục hồi và đảm bảo rằng mảnh   bù đắp vẫn không bị ảnh hưởng bằng cách nén tiêu đề. Sử dụng Xác nhận / Không có   Thừa nhận các tín hiệu có thể được sử dụng để giải quyết những vấn đề này (như   reassembly sẽ bắt đầu một lần tất cả các gói tin đã nhận được.   điểm đến node) và cũng sẽ đảm bảo độ tin cậy. Tuy nhiên điều này sẽ   dẫn đến nhanh hơn thoát nước của pin do chi phí của gói tin Ack / Nack   chuyển nhượng.

   Vì vậy, để tránh việc sử dụng của phân mảnh và reassembly tiêu đề,   nén cần phải được xem xét lại và một số tính năng IPv6   elided hoặc giảm thiểu.

3. Định dạng IPv6 nén Tiêu đề:

   Phần này quy định các định dạng của tiêu đề nén IPv6. Các   còn lại tiêu đề là 6 octet.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+   | UNR | T | SO | N | L | HL | SA |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+   | D | DA |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   UNR: không hạn chế   Chưa sử dụng bit có thể được sử dụng cho công việc trong tương lai. Hiện nay, có 7 bit để hoàn thành các octet và có thể được chỉ định bất kỳ giá trị ngẫu nhiên.

   T: lớp đường truyền: 1 bit   0: Không có ưu tiên   1: ưu tiên cao   Nó được giải thích trong mục số 10

   SO: Bảo mật Tùy chọn: 2 bit   00: Không có an ninh   01: xác thực   10: Mã hóa   11: Dành   Nó được giải thích trong mục Không 11

   N: Tiếp theo Tiêu đề   00: Không có Tiêu đề Tiếp theo   01: UDP header   10: Routing Tiêu đề   11: sử dụng trong tương lai   Tiêu đề tiếp theo được phân bổ 2 bit. Rất ít các tùy chọn tiêu đề tiếp theo được đưa   ở dạng ban đầu của họ, trong khi những người khác đã được sửa đổi hoặc elided.   Xem Phần 9 để biết thêm chi tiết.

   L: Loose Source Routing   Loose Source Routing giao 1 bit. Được thiết lập để xác định xem   gói tin được gửi như Routing header mở rộng. Thông tin chi tiết có thể được tìm thấy   tại mục 12.

   HL: Hop Limit   Hạn chế Hop không được sửa đổi và vẫn còn dài 8 bit. Vì vậy tối đa   của 255 bước nhảy có thể được thực hiện. Nếu con số này trở thành không đủ trong   trong tương lai, các bit không hạn chế có thể được sử dụng.

   SA: địa chỉ nguồn   Địa chỉ nguồn là một lĩnh vực 13-bit. Địa chỉ là cấu hình như mô tả trong   Mục 7. Nén 128-bit địa chỉ 13-bit địa chỉ   chi tiết tại Mục 5.

   Địa chỉ Loại D: Điểm đến   0: Unicast   1: Multicast   Loại Điểm đến Địa chỉ là một lĩnh vực 1-bit. Nó xác định liệu

   địa chỉ Unicast loại hoặc Multicast.

   DA: Điểm đến Địa chỉ   Địa chỉ Điểm đến là một lĩnh vực 13-bit. Địa chỉ được cấu hình như mô tả trong Mục 7. Nén địa chỉ 128-bit-13 bit   địa chỉ chi tiết tại Mục 5.

4. IPv6 nén và thuật toán mở rộng

   Phần này mô tả làm thế nào để nén các tiêu đề dài 40-octet IPv6   định dạng nén của nó 6-bát và làm thế nào để rộng nén 6-octet   định dạng một tiêu đề 40-octet. Thuật toán elides một số lĩnh vực,   được cho là vẫn còn phổ biến cho 6LoWPAN giao tiếp: Phiên bản   6; Label dòng là không; Payload Length có thể được suy ra từ thấp   các lớp từ tiêu đề IEEE 802.15.4, Hop Giới hạn sẽ được thiết lập để một   giá trị gia nổi tiếng bởi nguồn, 128-bit địa chỉ IPv6 được giảm xuống   13-bit địa chỉ. Đến nay, mạng lưới lớn nhất 6LoWPAN bao giờ đặt   cùng tính 800 nút. Một địa chỉ 13-bit cho phép 8000-nút   mạng để hoạt động. Các mô hình giải quyết được mô tả trong Mục 5;   các thuật toán cho dịch địa chỉ được mô tả trong Mục 6. 

4.1 nén octet 40 octet đến 6

   Thuật toán sau đây được sử dụng cho nén tiêu đề:

   V = 40_octets_header [1-4] / / Đọc 4 bit đầu tiên để kiểm tra   phiên bản

   (V == 0100b) / / Đây là một địa chỉ IPv4          áp dụng các thuật toán IPv4toIPv6

   6_octets_header [1-6] = 0000000b / / thiết lập các bit không hạn chế 0

   (giao thông class = 0000 0000)      6_octets_header [7] = 1   khác      6_octets_header [7] = 0

   / / Bỏ qua các nhãn dòng chảy

   P = 40_octets_header [32-47] / / đọc các lĩnh vực chiều dài tải trọng.

   if (P <0x0080h & P> 0x0000h)       tiếp tục   khác       loại bỏ các gói

   H = 40_octets_header [48-55] / / đọc lĩnh vực tiêu đề tiếp theo

   trong khi (có tồn tại một tiêu đề tiếp theo)        nếu (H == 17) / / nếu nó là tiêu đề lớp kế tiếp UDP trên           6octet [11/10] = 01 / / thiết lập 'N' đến 01, các bit tiêu đề tiếp theo 01        if (H == 59)           6octet [11/10] = 00 / / thiết lập 'N' đến 00, các bit tiêu đề tiếp theo về 00        if (H == 51)           6octet [8-9] = 01 / / thiết lập các bit bảo mật 01        if (H == 50)           6octet [8-9] = 10 / / thiết lập các bit an ninh đến 10        if (H == 43)           6_octets_header [12] = 1 / / thiết lập nguồn lỏng định tuyến bit đến 1        khác          đi tiêu đề tiếp theo nếu có tồn tại một.

   (6octet [8-9] = 10 &! & 6octet [8-9] = 01) / / nếu bit an ninh                                                  / / Đã không được thiết lập bởi     / / Xem xét các tiêu đề tiếp theo6octet [8-9] = 00 / / thiết lập các bit bảo mật về 00

   nếu (6octet [12] = 1) / / nếu lỏng lẻo đã không được thiết lập bởi      / / Xem xét các tiêu đề tiếp theo      6octet [12] = 0 / / thiết lập nguồn lỏng định tuyến bit là 0

   L = 40_octets_header [56-63] / / đọc các lĩnh vực giới hạn hop

   if (L <0x00ffh & L> 0x0001h)      6_octets_header [13-20] = L / / thiết lập giới hạn hop phù hợp   khác      loại bỏ các gói

   6_octets_header [21-32] = SA / / SA được hình thành bằng cách sử dụng các thuật toán   được đưa ra trong Mục 5. Đặt Địa chỉ nguồn xuất phát từ thuật toán.

   6_octets_header [33] = 0 hoặc 1 / / Quyết định bằng cách đọc 128 bit   địa chỉ đích.

   6_octet_header [34-46] = DA / / DA được hình thành bằng cách sử dụng các thuật toán nhất định   Mục Địa chỉ nguồn 5.Set bắt nguồn từ thuật toán.

4.2 Mở rộng 6 octet đến 40 octet

   Các thuật toán sau đây là để được sử dụng cho Đầu trang   Mở rộng / nén tại nút Gateway: 

   Expansion6to40 (header_6_initial [48], header_40_final [320]) {

     header_40_final [0-3] <- 0x6h / / Thiết lập phiên bản

     (header_6_initial [7] == 0) / / lớp đường truyền          header_40_final [11/04] <- 0x00h     khác          [11/04] <- 0x3Fh header_40_final

     nếu header_6_initial [8-9] == 0x0h) / / An ninh tùy chọn thêm     chi tiết tại mục 11          / / Không có an ninh     nếu người nào khác (header_6_initial [8-9] == 0x0h)          / / Thực hiện xác thực     nếu người nào khác (header_6_initial [8-9] == 0x0h)          / / Thực hiện mã hóa     khác          / / Không làm gì cả

     header_40_final [31/12] <- 0x00h / / Lưu lượng nhãn

     header_40_final [32-47] <- tải trọng chiều dài có nguồn gốc từ IEEE     802.15.4 Tiêu đề. / / Payload Length

     nếu (header_6_initial [10] == 0) / / Loose Source Routing          / / Không có định tuyến nguồn     khác          / / Thực hiện định tuyến Nguồn Loose

     header_40_final [48-55] <- giá trị thích hợp     / / Giá trị phải được theo đúng thứ tự như mỗi Header Extension     đề cập trong RFC 2460

     header_40_final [56-63] <- header_6_initial [13-20] / / Hop Limit

     header_40_final [64-191] <- Địa chỉ / / Sử dụng thuật toán trong     Mục 5 cho header_6_initial [21-33]

     if (header_6_initial [34] == 0) / / Kiểm tra Multicast / Unicast

          header_40_final [192-319] <- Điểm đến Địa chỉ / / Sử dụng          Thuật toán trong mục 5 trên header_6_initial [35-47]     khác          header_40_final [192-319] <- Điểm đến Địa chỉ / / Sử dụng          Thuật toán trong mục 5 trên header_6_initial [35-47]   }

   Như được mô tả tại mục 9, vài Tiêu đề mở rộng được như họ,   đã được elided hoàn toàn trong khi những người khác được thực hiện với   tối thiểu chức năng.

4.3 Dịch IPv4 gói thành gói tin IPv6

   Các thiết lập sau đây được sử dụng để dịch một gói tin IPv4   một gói tin IPv6.

   Phiên bản = 6

   Lớp đường truyền = IPv4 TOS tiêu đề bit

   Dòng Label = 0

   Payload Length = IPv4 tiêu đề Tổng chiều dài giá trị + (tiêu đề dài IPv4 +   IPv4 lựa chọn chiều dài)

   Tiếp theo Tiêu đề = tiêu đề giao thức IPv4 lĩnh vực giá trị

   Hạn chế Hop = IPv4 TTL lĩnh vực giá trị - 1

   Địa chỉ IP nguồn = 0:0:0:0: FFFF:: / 80 nối với IPv4 tiêu đề   nguồn địa chỉ IP

   Địa chỉ IP đích = 0:0:0:0:0: FFFF:: / 96 nối với IPv4   điểm đến địa chỉ IP tiêu đề

5. Giải quyết

   Phần này xác định các mô hình giải quyết của địa chỉ IPv6 nén.

5,1 Địa chỉ Unicast toàn cầu

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+   | Toàn cầu tiền tố và SID   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+          được đưa ra bởi nhà cung cấp dịch vụ và mạng lưới kỹ sư (64 bit) |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+   | P (5 bit) | 0:: 0 (46 bit)   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+         0:: 0 | SA (13 bit) |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+

   P: 5-bit 6LoWPAN tiền tố.   Trường này chỉ ra rằng địa chỉ là một địa chỉ 6LoWPAN. Lĩnh vực này   được thiết lập để 11111b.

   SA: Địa chỉ 13-bit ngắn.

5,2 13-bit ngắn Địa chỉ

   Các nút trong mạng sẽ có một địa chỉ 13-bit. Ngoài ra, 256   địa chỉ được dành riêng cho máy bên ngoài mạng 6LoWPAN. Những   địa chỉ được chỉ định bởi một 11111b tiền tố 5-bit.

6. Address Translation

   Phần này mô tả các dịch địa chỉ 128-bit-13 bit   địa chỉ và ngược lại. Những thuật toán này đòi hỏi việc thực hiện   một bảng dịch có kích thước tối đa là 4KB.

6.1 Dịch địa chỉ 128 bit vào một địa chỉ 13 bit

   Thuật toán sau đây được sử dụng để dịch một 128-bit IPv6 thường xuyên   địa chỉ vào một địa chỉ 13-bit duy nhất.

   P = 128bit_address [65 -69] / / 5 bit từ 65 đến 69.

   if (P == 11111b)      Thiết lập 13 bit cuối cùng trong nguồn / Điểm đến Địa chỉ trường      / / Giống như 13 bit cuối cùng của địa chỉ 128 bit   khác      Đọc các bảng dịch

   (128-bit địa chỉ là có mặt trong bảng)      thiết lập địa chỉ 13 bit tương ứng Source / Điểm đến Địa chỉ      lĩnh vực   khác      đặt nó trong bảng, gán cho nó một địa chỉ 13 bit và thiết lập các bit 13      địa chỉ Source / Điểm đến lĩnh vực

6.2 Dịch một địa chỉ 13-bit vào một địa chỉ 128 bit

   Thuật toán sau đây được sử dụng để dịch một địa chỉ 13-bit vào một   128-bit địa chỉ IPv6 thường xuyên.

   F = 13bit_address [1-5] / / đọc 5 bit từ 1 bit bit thứ 5                             địa chỉ 13 bit.

   (F == 11111b)       đọc các bảng dịch và thiết lập các phóng viên 128-bit       địa chỉ Source / Điểm đến Địa chỉ trường   khác       tạo ra 64 bit địa chỉ 128 bit đầu tiên được hình thành bằng cách nối       Tiền tố toàn cầu và SID,       65 để thiết lập bit 68 đến 1       69 để bit 114 thiết lập là 0       Địa chỉ 13-bit được thiết lập trong 13 bit cuối của địa chỉ 128-bit

7. Truyền thông giữa thế giới bên ngoài và bên trong WSN

   Hãy xem xét một Ma máy bên ngoài để WSN mạng, mà cần phải   giao tiếp với một nút WSN Wb, trong đó 1 <= a <= 255; 1 <= b <= 2 ^ 13. Ma gửi một   yêu cầu đến gateway để có được địa chỉ IPv6 của Wb nút. Các   cổng sẽ gửi thông tin đến Ma.

   Ma sẽ gửi một gói tin đến Wb với đầy đủ địa chỉ 128 bit điểm đến.   Gói tin này bị chặn bởi các cổng đó là cách duy nhất để   đạt các WSN. Khi gói tin được nhận bởi Gateway, Gateway   dịch tin nhắn trong một gói WSN: tiêu đề là nén,   địa chỉ đích được thay thế bằng địa chỉ tương đương 13-bit và   địa chỉ 128-bit của Ma được đăng ký trong một cái nhìn lên bảng   gateway. Cổng giao một địa chỉ 13-bit mới để Ma là   đăng ký trong bảng nhìn lên và tương ứng với 128-bit   địa chỉ của Ma. Địa chỉ 13-bit được thiết lập trong lĩnh vực địa chỉ nguồn.   Địa chỉ này có một tiền tố 11111 để thể hiện các   tương ứng với một máy tính bên ngoài. Các thông báo dịch sau đó được   chuyển tiếp để Wb.

   Nếu Wb sau đó cần phải giao tiếp với Ma, nó sẽ gửi một gói tin đến

   Ma. Gói tin này bị chặn bởi các cửa ngõ mà dịch   gói: tiêu đề là mở rộng, địa chỉ nguồn được thay thế bằng một   Địa chỉ 128-bit bằng cách sử dụng các thuật toán mô tả ở trên và điểm đến   địa chỉ thu được bằng cách nhận được địa chỉ 128-bit tương ứng với   số 13-bit địa chỉ trong cái nhìn lên bảng. Sau đó, gói tin được chuyển tiếp   với mạng bên ngoài.

8. Địa chỉ Autoconfiguration

   Các nút sẽ có được 13-bit địa chỉ của họ statelessly ngay sau khi họ   sức mạnh lên. Địa chỉ 128-bit tương ứng của họ sẽ có phạm vi toàn cầu   và sẽ được toàn cầu duy nhất. Địa chỉ phát hiện trùng lặp sẽ được   thực hiện để đảm bảo rằng địa chỉ 13-bit thu được bằng nút   duy nhất bên trong WSN. Nếu một địa chỉ được giao đã được sử dụng, mới   địa chỉ sẽ được thực hiện bởi các nút có liên quan.

9. Next header

   Phần này mô tả Header Tiếp theo được đề cập trong [RFC 2460] và IPv6   Đánh giá và xem xét mở rộng Headers

9.1. Hop-by-Hop Tùy chọn tiêu đề

   Vấn đề đối với lĩnh vực Hop-by-hop là nó phải được nhìn thấy,   hiểu và hành động thuận của tất cả các nút, mà là một không cần thiết   lãng phí năng lượng. Các dữ liệu thu thập và chuyển tải trong phần lớn các   ứng dụng thực tế đời sống thông qua các mạng cảm biến không dây không yêu cầu   bất kỳ chế biến đặc biệt trong các nút trung gian có thể hưởng lợi từ việc   dự phòng của các Header mở rộng hop-by-hop. Như vậy chúng ta không   đề nghị việc thực hiện của các tùy chọn Hop-by-hop.

9.2. Routing tiêu đề

   Header Routing được thể hiện một cách rõ ràng như nguồn Loose định tuyến   được mô tả tại mục 12.

9.3. Xác thực tiêu đề

   Các tiêu đề xác thực là elided dưới hình thức ban đầu của nó. ESP   (Encapsulating Security Payload) bao gồm tất cả các chức năng mà   được thực hiện bởi một Header Authentication. Trong trường hợp chỉ   Xác thực là cần thiết, nó được thiết lập trong Bit bảo mật được mô tả trong   Điều 11.

9.4. Đóng gói an Payload tiêu đề

   Mã hóa và giải mã tiêu thụ nhiều tài nguyên hơn về quyền lực và   chế biến. Vì vậy, việc sử dụng của họ là không khuyến khích. Chỉ trong trường hợp   một số bảo mật cao là cần thiết, các chức năng tối thiểu có thể được   thực hiện. Xem phần 11 để biết thêm chi tiết.

9,5 Tùy chọn Tiêu đề Điểm đến

   Sử dụng các lựa chọn Điểm đến là không được khuyến cáo như là việc sử dụng này   tiêu đề mở rộng sẽ dẫn đến sự mở rộng của kích thước gói tin vượt ra ngoài   MTU.

9,6 Fragment header

   Việc sử dụng của tiêu đề này là hoàn toàn elided là phân mảnh là hoàn toàn

   tránh được.

9,7 Không có Tiêu đề Tiếp theo

   Không có tiêu đề tiếp theo là một cách rõ ràng đề cập đến 00 và IPv6 ban đầu   tiêu đề được ký hiệu là 59.

9,8 Upper lớp Tiêu đề

   01 giá trị là sử dụng để biểu thị tiêu đề lớp trên có nghĩa là   giao thông vận tải giao thức được sử dụng là UDP (biểu thị bằng giá trị 17 trong   IPv6 tiêu đề ban đầu). TCP, mặc dù là đáng tin cậy, không được sử dụng như là một   giao thông vận tải giao thức như bắt tay sẽ cho kết quả trong việc gửi nhiều hơn   các gói dữ liệu, do đó thoát nhiều năng lượng hơn.

10. Lớp đường truyền

   Tiêu đề IPv6 ban đầu nhận được bởi gateway có thể chứa 8-bit   lớp lưu lượng truy cập và thông số kỹ thuật nhãn dòng 20-bit. Trong trường hợp đó, chúng tôi   nhiệm vụ giới thiệu đặc điểm kỹ thuật 28-bit này được trừu tượng vào   hai lớp học: thời gian nhạy cảm và thời gian nhạy cảm. Vì vậy, chúng tôi tiêu đề   đặc điểm kỹ thuật nén chỉ sử dụng 1 bit có thể được thiết lập hoặc bỏ đặt   biểu thị thời gian nhạy cảm của gói tin. Điều này là trong việc giữ với   thực tế là trong hầu hết các kịch bản ứng dụng thực tế WSN, chúng tôi   hiếm khi gặp tình huống có thể đảm bảo một xử lý phức tạp hơn   WSN giao thông.

11. An ninh Tùy chọn

   Trong hầu hết trường hợp, WSN không xử lý bảo mật dữ liệu nhạy cảm và do đó   thực hiện đầy đủ an ninh chính thức như đã đề cập trong RFC 4301, 4302 4303   và 2460, sẽ dẫn đến một sự lãng phí không cần thiết của tính toán và pin   thoát nước. An ninh cơ bản có thể được cung cấp bởi lớp thấp hơn. Tuy nhiên, trong   trường hợp các biện pháp an ninh bổ sung ở lớp IP được yêu cầu,   cần để xác thực hoặc mã hóa-giải mã có thể được quy định cụ thể   Lựa chọn Security.

12. Loose Source Routing

   Nguồn Loose định tuyến được thực hiện để xác minh xem các nút nhất định   thể truy cập từ một nguồn cụ thể. Trong những trường hợp này, tải trọng có thể   chỉ chứa địa chỉ và không có gì khác. Trong trường hợp nội dung của   gói dữ liệu nhạy cảm hơn và như là một biện pháp an ninh bổ sung,   dữ liệu tải trọng có thể được cũng có mặt cùng với các địa chỉ. Đây là   để đảm bảo rằng gói tin đến đích của nó thông qua một cách an toàn và được biết đến   đường dẫn. Đối với mục đích này, một số bit có thể được sử dụng từ các thiết lập không hạn chế   bit để xác định số lượng địa chỉ hiện tại, một số octet.   tải trọng cũng có thể được đưa lên thay thế. Nó là cần thiết để đảm bảo   rằng làm này KHÔNG NÊN dẫn đến phân mảnh.

13. Hạn chế:

   a.) Hạn chế Hop ngụ ý một hạn chế của 255 bước nhảy. Nếu con số này   trở thành không đầy đủ trong tương lai, các bit không hạn chế có thể được sử dụng.

14. Hậu quả:

   a.) Số octet còn lại cho Payload là 67.

15. An ninh cân nhắc:

   Các kịch bản được xem xét trong dự thảo này có một mức độ an ninh thấp. Các   kiến nghị được đưa ra trong dự thảo này là không hợp lệ nhạy cảm   kịch bản.

16. Tài liệu tham khảo

16,1 bản quy phạm Tài liệu tham khảo:

   [RFC 4944] Montenegro, G., Kushalnagar, N., Hui, J., Culler, J.,"Truyền của gói tin IPv6 trên IEEE 802.15.4 Mạng",Tháng 9 năm 2007

   [RFC2119] Bradner, S., "từ khóa để sử dụng trong các RFC Cho biết                   Mức độ yêu cầu ", 14 BCP, RFC 2119, tháng ba năm 1997.

   [RFC2460] Deering, S. và R. Hinden, "Internet Protocol, phiên bản 6                   (IPv6) Đặc điểm kỹ thuật ", RFC 2460, tháng 12 năm 1998.

   [RFC2464] Crawford, M., "truyền các gói tin IPv6 qua Ethernet                   Mạng ", RFC 2464, tháng 12 năm 1998.

   [RFC4291] Hinden, R. và S. Deering, "IP phiên bản 6 biểu                   Kiến trúc ", RFC 4291, tháng 2 năm 2006.

   [RFC4862] Thomson, S., Narten, T. và T. Jinmei ", IPv6 không quốc tịch                   Địa chỉ Autoconfiguration ", RFC 4862, tháng 9 năm 2007.

   Ieee802.15.4] IEEE Computer Society, "IEEE Std 802.15.4-2003."                   Tháng 10 năm 2003.

   [Dự thảo-IETF-6lowpan-hc-07] J. Hui, P. Thubert, "nén Định dạng cho

                         Gói tin IPv6 trong mạng 6LoWPAN ", Tháng Tư 2010

16,2 thông tin Tài liệu tham khảo

   [RFC 4301] Kent, S., Seo, K., "Kiến trúc bảo mật cho Internet                  Nghị định thư "

   [RFC 4302] Kent, S., "IP Authentication Header"

   [RFC 4303] Kent, S., "IP Encapsulating an Payload (ESP)

16,3 Tài liệu tham khảo URL:   [Tiêu đề mở rộng tiêu đề mở rộng IPv6 Xem xét và cân nhắc                      http://www.cisco.com/en/US/technologies/tk648/tk872                      / Technologies_white_paper0900aecd8054d37d.html

'Địa chỉ của tác giả:

   Lucie Bouchet   lucie.bouchet @ viễn thông-bretagne.eu

   Jeremie Jambet   jeremie.jambet @ viễn thông-bretagne.eu

   Anubhav Agarwal   f2006125@bits-pilani.ac.in

   Karanjit Singh Cheema   f2006071@bits-pilani.ac.in

   Rahul Banerjee   rahul@bits-pilani.ac.in

   Làm việc đã được thực hiện trong khuôn viên của Viện Công nghệ Birla   Khoa học, Pilani. Đối với tất cả các thư từ sau ngày 13 tháng năm 2010, xin vui lòng   giao tiếp với tác giả cuối cùng.