Internet Engineering Task Force Lucie Bouchet Internet-Draft Jeremie Jambet Intended Status: Standard Tracks Telecom Bretagne Expires: November 14, 2010 Anubhav Agarwal Karanjit Singh Cheema Rahul Banerjee Birla Institute of Technology & Science, Pilani May 21, 2010 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 Internet-Draft will expire on October 21, 2008 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Bouchet, Jambet, Expires October 21, 2010 [Page 1] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirement Notation. . . . . . . . . . . . . . . . . . . . 3 2. Problem Background . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 Compressed Header Format . . . . . . . . . . . . . . . . . 4 4. IPv6 compression and expansion Algorithm . . . . . . . . . . . 6 4.1. Compression of 40 octets to 6 octets . . . . . . . . . . . 6 4.2. Expansion of 6 octets to 40 octets . . . . . . . . . . . . 7 4.3. Translation of IPv4 packet into IPv6 packet . . . . . . . . 9 5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Global Unicast Address . . . . . . . . . . . . . . . . . . 9 5.2. 13-bit Short Address . . . . . . . . . . . . . . . . . . . 10 6. Address Translation . . . . . . . . . . . . . . . . . . . . . 10 6.1. Translation of a 128 bit address into a 13 bit address . . 10 6.2. Translation of a 13 bit address into a 128 bit address . . 10 7. Communication between outside world and inside the WSN . . . . 11 8. Address configuration . . . . . . . . . . . . . . . . . . . . 11 9. Next Header . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 9.2. Routing Header . . . . . . . . . . . . . . . . . . . . . . 12 9.3. Authentication Header . . . . . . . . . . . . . . . . . . 12 9.4. Encapsulating Security Payload Header . . . . . . . . . . 12 9.5. Destination Options Header . . . . . . . . . . . . . . . . 12 9.6. Fragment Header . . . . . . . . . . . . . . . . . . . . . 12 9.7. No Next Header . . . . . . . . . . . . . . . . . . . . . . 13 9.8. Upper Layer Header . . . . . . . . . . . . . . . . . . . . 13 10. Traffic Class . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Security Option . . . . . . . . . . . . . . . . . . . . . . . 13 12. Loose Source Routing . . . . . . . . . . . . . . . . . . . . . 13 13. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. Consequences . . . . . . . . . . . . . . . . . . . . . . . . 14 15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 16. Loose Source Routing . . . . . . . . . . . . . . . . . . . . 14 16.1. Normative References . . . . . . . . . . . . . . . . . . . 14 16.2. Informative References . . . . . . . . . . . . . . . . . . 15 Bouchet, Jambet, Expires October 21, 2010 [Page 2] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 16.3. URL References . . . . . . . . . . . . . . . . . . . . . . 15 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", Bouchet, Jambet, Expires October 21, 2010 [Page 3] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks "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 Bouchet, Jambet, Expires October 21, 2010 [Page 4] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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 Bouchet, Jambet, Expires October 21, 2010 [Page 5] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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 Bouchet, Jambet, Expires October 21, 2010 [Page 6] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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: Bouchet, Jambet, Expires October 21, 2010 [Page 7] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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] } Bouchet, Jambet, Expires October 21, 2010 [Page 8] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bouchet, Jambet, Expires October 21, 2010 [Page 9] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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. Bouchet, Jambet, Expires October 21, 2010 [Page 10] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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 Bouchet, Jambet, Expires October 21, 2010 [Page 11] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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 Bouchet, Jambet, Expires October 21, 2010 [Page 12] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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 Bouchet, Jambet, Expires October 21, 2010 [Page 13] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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 Bouchet, Jambet, Expires October 21, 2010 [Page 14] Agarwal, Cheema & Banerjee Internet-Draft Transmission of Compressed IPv6 Packets over May 2010 IEEE 802.15.4 Networks 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.