Network Working Group L. Toutain Internet-Draft Institut TELECOM ; TELECOM Intended status: Informational Bretagne Expires: February 21, 2009 G. Chelius INRIA Y. Lee ICU Y. DONG Southeast University August 20, 2008 Neighbor Discovery Suppression draft-toutain-6lowpan-ra-suppression-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 21, 2009. Abstract The 6LoWPAN IETF working group is developing protocols to allow IPv6 end-to-end communication with sensors networks. Low-power MAC protocols such as IEEE 802.15.4 impose a slightly reduced frame size. To enable IPv6 communication, 6LoWPAN proposes to use fragmentation and header compression techniques. This document proposes an extension to the 6LoWPAN proposal and defines a class of sensors that Toutain, et al. Expires February 21, 2009 [Page 1] Internet-Draft Point6box August 2008 can be joined at the network level while ignoring their own global IPv6 address. This architecture centralizes the address management on the sensor network gateway (the PAN Coordinator) and allows the suppression of the Neighbor Discovery Protocol. Consequently, the insertion of sensors in such a network is faster and the traffic within the network, largely composed of broadcast messages generated by Neighbor Discovery Protocol, is reduced. We investigate the impact of this architecture on star and mesh topologies. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Suppression of sollicited RA . . . . . . . . . . . . . . . . . 4 2.1. Stateless 6LoWPAN header compression . . . . . . . . . . . 4 2.2. Impact of anycast address for default router . . . . . . . 6 3. ULP checksum adaptation . . . . . . . . . . . . . . . . . . . 8 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Toutain, et al. Expires February 21, 2009 [Page 2] Internet-Draft Point6box August 2008 1. Introduction 6LoWPAN [RFC4944] is an adaptation layer used to transport IPv6 packets in Wireless Sensor Networks (WSN) using a layer-2 technology imposing a reduced frame size, such as IEEE 802.15.4. In order to improve energy efficiency, IEEE 802.15.4 limits the maximum frame size to 127 bits, which results in an incompatibility with IPv6 specifications. 6LoWPAN solves this issue for large data packets by implementing a fragmentation header. For small packets, for instance Neighbor Discovery Protocol (NDP) messages, 6LoWPAN introduces a simple header compression scheme, which allows NDP messages to fit into a single frame. 6LoWPAN supports different kinds of topology from the simple star topology to more complex architectures based on layer 2 mesh network or on layer 3 routing. In all topologies, a PAN Coordinator (PC), refered also in this document as the gateway, is in charge of network management. This equipment is located at the boundary between the WSN and the "traditional" Internet and acts also as a router. If some solutions have been proposed to optimize the encapsulation of NDP messages, the load imposed by this protocol is similar in WSN and in Ethernet-based networks. Some proposals suggest limiting the use of broadcast, which may be energy consuming on WSN, by maintaining stateful information on the PAN Coordinator. [I-D.chakrabarti-6lowpan-ipv6-nd] proposes some optimizations to minimize the number of messages generated by NDP and to limit the use of broadcasts in the network. NDP functionalities are concentrated on the PC instead of being distributed in the network. Duplicate Address Detection (DAD) and Neighbor Solicitation (NS) are performed using point-to-point requests from the sensors to the PC rather than multicast packets spanning over the whole WSN. Furthermore, nodes intercept initial multicast Router Solicitation (RS) messages and forward them directly to the PC instead of broadcasting it to the whole network. [I-D.thubert-6lowpan-backbone-router] extends this proposal by allowing multiple routers in a WSN which share the same prefix. Backbone routers only have a partial view of the addresses allocated on the link. They use a transit link to proxy NS for DAD and address resolution procedures. In addition, backbone routers have an L2 anycast address allowing sensors to easily contact the nearest router. Our proposal to further optimize NDP on WSN focuses on the bootstrap phase of NDP. Our goal is to avoid the announcement of the IPv6 prefix to some sensors that do not need to know their global IPv6 address while still guaranteeing end-to-end communications between any equipment on the Internet and these sensors. Indeed, several Toutain, et al. Expires February 21, 2009 [Page 3] Internet-Draft Point6box August 2008 sensors do not require the knowledge of the network prefix, as long as gateways are able to add and remove this information. For instance: o a mobile sensor reporting periodically a value to a central database located outside the WSN does not need to know its IPv6 address; o a fixed sensor may have its address stored in the DNS database and can therefore be contacted from outside the WSN without having to know its own global address. Our proposal is based on the 6LoWPAN header compression scheme that suppresses the network prefix in compressed IPv6 headers. This scheme is, in a sense, quite similar to the deployment of private addresses in an IPv4 network using Network Address Translation (NAT). The private IPv4 address is analogous to our Interface Identifier (IID) and the public IPv4 address to the prefix. However, there are fundamental differences between our proposal and address translation: o this mechanism can be deactivated when a sensor needs to know its public IPv6 address. A Router Solicitation (RS) message can be sent in the sensors network, using the optimization mentioned above, to get an explicit answer from the gateway. o this mechanism does not break the end-to-end connectivity, since no additional memory is required on the gateway that stores the network prefix rather than an address matching table. 2. Suppression of sollicited RA A solicited RA message carries information regarding a node insertion on the link. Suppressing the initial RS/RA exchange requires some changes in nodes' behavior: o sensor nodes do not learn the prefix by default. With 6LoWPAN header compression, the source address prefix usage can be avoided on the link. o sensor nodes are not explicitly aware of the default router's address. We propose to use a predefined anycast address to identify default routers in a WSN. 2.1. Stateless 6LoWPAN header compression 6LoWPAN defines in [RFC4944] a header compression scheme that divides the IPv6 address into two distinct parts. The first 64 bits designate the prefix and the last 64 bits contain the IID. A bitmap in the IPv6 header allows toggling of implicit and explicit reference of the prefix in both the source and destination addresses. 6LoWPAN assumes that a compressed prefix refers to the link-local context. Hui [I-D.hui-6lowpan-hc1g] proposed a new header compression discriminator for global addresses, called HC1g. This discriminator Toutain, et al. Expires February 21, 2009 [Page 4] Internet-Draft Point6box August 2008 works in the same way as the standardized 6LoWPAN HC1, but instead of adding the link-local prefix, the global prefix of the link is added when the full IPv6 packet has to be built. In our proposal, a new discriminator is not necessary; the 6LoWPAN compression mechanism does not have to be changed. Only the PC behavior has to be slightly modified. By examining the type of the destination address (local or global) and the value of the prefix (same as the WSN's or different) to define which source address prefix must be used. When a sensor communicates towards the outside world, the destination prefix cannot be compressed, since the prefix can be any IPv6 prefix and no restriction is made on the IID value. In the PC, a simple algorithm could be used to discriminate which prefix must be added by the PC when reconstructing the IPv6 header: o if the destination prefix is compressed or equal to FE80::/64 then the source prefix is FE80::/64 o in any other case, especially when the packet is directed outside of the WSN, the source prefix is the one allocated to the WSN and is known by the PC, since it also acts as a router. In the reverse direction, when the PC receives a packet from outside the WSN, it checks the destination prefix to see if it matches the WSN's and suppresses it when compressing the IPv6 header. Outgoing packets Sensor -------------------> PC ----------> IEEE 802.15.4 L2 1 6LoWPAN Dispatch 40 IPv6 (Mesh Header) Source:WSN pref + L2 src addr 1 HC1 : 1100 xxxx Dest:Global address 16 Global Addr. 1 HL Incoming packets Sensor <------------------- PC <---------- byte IEEE 802.15.4 byte L2 1 6LoWPAN Dispatch 40 IPv6 (Mesh Header) Source:Global address 1 HC1 : 1100 xxxx Dest:WSN pref + L2 src addr 16 Global Addr. 1 HL Figure 1: Address compression with RFC 4944 The PANid must reflect the value of prefix allocated to the link. This can be done manually, when the PC is configured, or automatically, based on the prefix value (not described here). In Toutain, et al. Expires February 21, 2009 [Page 5] Internet-Draft Point6box August 2008 case of multiple attachments as depicted on Figure 1, a single small change to the IEEE 802.15.4 standard is necessary. The IEEE 802.15.4 standard stipulates that in case of a conflict between two PCs on the PANid value, one of them has to change its PANid value. In our case, since the PANid value is dependent on the prefix value, the PANid value cannot be changed. So in that case, only one PC must remain active, the others may become backup PC but continue to act as a gateway. 2.2. Impact of anycast address for default router The RA also carries the L2 address of the default router. If no RA is sent, the sensor ignores the physical address where packets have to be sent. To solve this issue, sensors may be configured with a predefined L2 anycast address that can be overloaded if a RA is received. Figure 2 represents a star topology with a sensor node located in an area reachable by two PCs. No mesh header is assumed in this configuration. The use of an anycast address could lead to sending duplicate packets on the Internet bearing two different source addresses, starting with the prefix associated to each PC and the same interface ID. The use of PANid prevents this situation since each star topology has a different PANid (a different prefix is assigned to each PC). The sensors have to select one of the PANids to send a frame and only one PC will consider the frame. ---------+-----------+------- | | +--+--+ +--+--+ | PC | _| PC | ,'| |`.,' | |. ` +-----+ `` +-----+ ` / / \ \ | | | | | |(S) | | | | | | \ \ / / . PANid1 \/ PANid2 / ',pref1 ,'',pref2 , `''-''` `''-''` Figure 2: Star Topology Toutain, et al. Expires February 21, 2009 [Page 6] Internet-Draft Point6box August 2008 Figure 3 represents a mesh topology; a routing protocol is necessary at layer 2 to establish the mesh. A layer-2 anycast address is similar to a layer-3 anycast address and can be considered as if it identified a virtual equipment behind the true gateway. Both gateways inject a route for this address. Sensor Nodes are configured with this default L2 address in their routing table and forward all the packets towards that address. Gateways intercept packets destined to this address by examining in the mesh header. A layer-2 anycast address is used in the mesh header only when a sensor node sends a packet and only as the destination address. The next hop is obtained from the mesh routing table. In Figure 3 S sends a packet toward the gateway. The route goes through R which is in reach of two gateways. Since R has to select a Next Hop only one gateway will receive the packet even if they share the same PANid. Normally, anycast addresses should not be used as source addresses. Therefore, when a gateway forwards a packet to a sensor node, it includes its physical address in the mesh header. One drawback of this approach appears when messages sent by the sensor have to be fragmented: if the routes are unstable within the sensor network, some fragments may reach one default router and other fragments another gateway, making reassembly impossible. However, such situation is expected to be very uncommon and the sensors may use the gateway address received in the mesh header to increase stability. A trade-off is required between the sensors' mobility and the stability of the default router location. The use of anycast addresses is also a solution for the issue of dead router detection. When a gateway fails, the routing protocol automatically forwards the frame to another active one. Toutain, et al. Expires February 21, 2009 [Page 7] Internet-Draft Point6box August 2008 -------+----------------------------+-------------- | | +-+--+ +--+-+ /---| |----------------------| |------\ | | PC1|X------\ /-------->| PC2| | | +----+ \ / +----+ | | |L2 Anycast \/ |L2 Anycast | L2 Anycast / MAC R->pC2 | | / Mesh S->Anycast | | (R) | | ^ | | | MAC: S -> R | | | Mesh: S -> Anycast | | (S) | | | | | \-------------------------------------------/ Figure 3: Mesh Topology 3. ULP checksum adaptation Sensors may use their own layer-4 protocol (ULP: Upper Layer Protocol) however, regarding 6LoWPAN layer-4 compression values, UDP, TCP or ICMP are expected. IPv6 mandates the use of an L4 checksum for these protocols. L4 checksum includes data and also on a pseudo- header including IPv6 source and destination addresses. The checksum algorithm is based on a sum of all the 16 bits words of the message. In our scheme, when a sensor sends a packet to the outside world, it does not know its global IPv6 address to fill the source address field. Therefore, it has to compute an incomplete L4 checksum, setting the prefix part of the source address to zero. When receiving such a packet, the border gateway can verify the validity of the checksum and adapt the value by adding the sum corresponding to the prefix using the same algorithm. When receiving a packet from the outside world, the border gateway can also adapt the L4 checksum by subtracting the corresponding value. 4. Conclusion Despite this proposal suppress first Neighbor Discovery exchanges, to allow very simple equipment to communicate with any IPv6 hosts, the current IPv6 model is not broken. These optimizations may be applied to some classes of the sensors which do not require the knowledge of Toutain, et al. Expires February 21, 2009 [Page 8] Internet-Draft Point6box August 2008 their own global IPv6 address. These optimizations enhance the performance of the network by limiting the number of packet sent, especially broadcast, and by reducing the time required before a node enters the network. These optimizations are not mandatory and are fully compatible with the current behavior of the 6LoWPAN network. 5. Acknowledgement This work is supported by the French Ministry of Foreign Affair within the Tiny6 project and by NIA (National Information Society Agency) of Korea with the MoMo project. A special thank to Ratnajit Bhattacharjee, Claude Chaudet, Younghee Lee, Neelesh Srivastava, Bruno Stevant and Deepanshu Vasal. 6. Security Considerations 7. Normative References [I-D.chakrabarti-6lowpan-ipv6-nd] Chakrabarti, S. and E. Nordmark, "LowPan Neighbor Discovery Extensions", draft-chakrabarti-6lowpan-ipv6-nd-05 (work in progress), July 2008. [I-D.hui-6lowpan-hc1g] Hui, J. and D. Cullerot, "Stateless IPv6 Header Compression for Globally Routable Packets in 6LoWPAN Subnetworks", draft-hui-6lowpan-hc1g-00 (work in progress), July 2007. [I-D.thubert-6lowpan-backbone-router] Thubert, P., "6LoWPAN Backbone Router", draft-thubert-6lowpan-backbone-router-01 (work in progress), July 2008. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. Toutain, et al. Expires February 21, 2009 [Page 9] Internet-Draft Point6box August 2008 Authors' Addresses Laurent Toutain Institut TELECOM ; TELECOM Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@telecom-bretagne.eu Guillaume Chelius INRIA 21, avenue Jean Capelle 69621 Villeurbanne France Email: Guillaume.Chelius@inria.fr Yoongsoo Lee ICU 119, MunjiRo, YusongGu, Daejon, 305-732 Korea Email: jslee@icu.ac.kr Yongqiang DONG Southeast University Sipailou 2# Nanjing 210096 China Email: dongyq@seu.edu.cn Toutain, et al. Expires February 21, 2009 [Page 10] Internet-Draft Point6box August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Toutain, et al. Expires February 21, 2009 [Page 11]