Network Working Group L. Toutain Internet-Draft Institut MINES TELECOM ; TELECOM Bretagne Intended status: Informational June 27, 2014 Expires: December 29, 2014 6LoWPAN Local Extensions draft-toutain-6lo-local-extensions-00.txt Abstract [RFC2460] defines an extension mechanism to add functionalities to the basic IPv6 header. On LoWPAN networks, some extensions are required to extend routing capabilities. These specific extensions should not leak in the global internet. To optimize encapsulation, a 6LoWPAN dispatch to carry local extensions is defined. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 29, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Toutain Expires December 29, 2014 [Page 1] Internet-Draft Local Extensions June 2014 1. IPv6 extensions [RFC2460] defines an extension mechanism to add functionalities to the basic IPv6 header. Extensions are processed differently regarding their nature: for Hop by Hop each router will process it and for the others, routers will ignore them, only the sender and the receiver will take them into account. More precisely, the [RFC2460] specifies: With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. In other words, only the source can create an extension and routers are not allowed to remove it. On LoWPAN networks, some extensions are required to extend routing capabilities. For instance, RPL defines a Hop by Hop extension [RFC6553] to specify a forwarding plan (RPLInstanceID) or detect wrong direction packets. A routing header is also defined for non storing mode [RFC6554] to specify the path to reach a leaf. These specific extensions should not leak in the global internet, especially for an Hop-by-Hop extension which will decrease the forwarding performances. A border router cannot add routing extension to incoming packets. To solve this problem tunneling is required. [RFC6554] defines in figure following encapsulation: +--------+---------+--------+-------------//-+ | Outer | Source | Inner | IPv6 | | IPv6 | Routing | IPv6 | Payload | | Header | Header | Header | | +--------+---------+--------+-------------//-+ <--- Original Packet ---> <--- Tunneled Packet ---> Figure 1: Packet tunneling Outer header carries LoWPAN IP addresses of a LOWPAN node and a border router and Inner header contains the source and destination. This encapsulation is sub-optimal since two IP headers are needed and the inner one cannot be compressed since Next Header in the Source Routing header contains the IPv6 protocol as defined in [rfc2460]; no reference to a 6LoWPAN dispatch is possible. Toutain Expires December 29, 2014 [Page 2] Internet-Draft Local Extensions June 2014 2. Local Extension Dispatch To overcome this situation where the scope of an extension is local to a specific area, a 6LoWPAN dispatch to carry extensions. It will improve performances. This extension can be easily added or removed by the border router. The work is done at the 6LoWPAN layer, so there is violation of [RFC2460] extension processing rules. A 8 bit dispatch called LOWPAN_LE (code TBD) is defined to carry extensions inside a LoWPAN. This dispatch can be repeated several times. They are located just before LOWPAN_IPHC. A single Extension header follows each LOWPAN_LE dispatch. The syntax remains the same, with one exception: Current Header field replaces the Next Header field. Instead of giving the next protocol identifier, it will describe the protocol in the structure. The length contained in the extension is used to find the extension end, which is followed by another dispatch either LOWPAN_LE or LOWPAN_IPHC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Current Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Payload . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Extension header 3. Compressing/Decompressing 6LoWPAN Header The conversion between the 6LoWPAN header format and the IPv6 header format is quite simple. The main difficulties is to manage global extensions already present in a packet, or to make the distinction between global extension which must be carried end to end and those local to the LoWPAN. A simple approach is to consider the scope imposed by tunneling, as described in Figure 1. If a packet carrying arrives from the global Internet to a 6LBR, these extensions are viewed has payload by the 6LoWPAN compression mechanism and do not use the LOWPAN_LE dispatch. Note that this scheme remains compatible with tunneling described in [RFC6554]. An outer IPHC header can be added before first LOWPAN_LE DISPATCH, for instance to limit the scope of ICMP messages. Toutain Expires December 29, 2014 [Page 3] Internet-Draft Local Extensions June 2014 4. Examples A border router receives traffic from outside the LoWPAN network and forwards the traffic to a 6LN. The 6LBR add a Hob-by-hop and Routing extensions +---+ +---+ +---+ | S |-------------------|LBR|--------------------|6LN| +---+ IPv6 Header +---+ LOWPAN_LE +---+ Destination H. [CH=0 Length Value] Data LOWPAN_LE [CH=41, Length, Value] LOWPAN_IPHC [header values] Destination H. Data Figure 3: Adding Local extensions A border router forwards traffic coming from a 6LN containing a Hop- by-Hop extension to a node on the Internet. +---+ +---+ +---+ |6LN|-------------------|LBR|--------------------| D | +---+ LOWPAN_LE +---+ IPv6 Header|Data +---+ [CH=0 Length Value] LOWPAN_IPHC [header values] Data Figure 4: removing Local extensions In a route-over mode a 6LR receiving a packet with a LOWPAW_LE can be decompressed to a compatible IPv6 packet by adding extension in the transmission order before the payload. For instance: LOWPAN_LE [CH=0 Length Value] LOWPAN_LE [CH=41, Length, Value] LOWPAN_IPHC [header values] Destination H. Data Figure 5: Local extensions received Will be expanded in: Toutain Expires December 29, 2014 [Page 4] Internet-Draft Local Extensions June 2014 [IPv6 Header (NH=0)] [HbH (NH=41)] [Routing (NH=60)] [Destination (NH=XX)] Data Figure 6: Uncompressed packet For Mesh-Under, the process is transparent to 6LR, only 6LN may have to expand the packet. 5. Security Considerations The LOWPAN_LE is functionally equivalent to a tunnel. 6. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012. [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012. Author's Address Laurent Toutain Institut MINES TELECOM ; TELECOM Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@telecom-bretagne.eu Toutain Expires December 29, 2014 [Page 5]