Upload
van-phuong
View
38
Download
1
Embed Size (px)
Citation preview
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 [email protected]
Jeremie Jambet [email protected]
Anubhav Agarwal [email protected]
Karanjit Singh Cheema
Rahul Banerjee [email protected]
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 [email protected]
Karanjit Singh Cheema [email protected]
Rahul Banerjee [email protected]
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.