| 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
[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.
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 (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.
[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:
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.
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
Figure 1: Packet tunneling
[RFC6554] defines in figure following encapsulation:
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
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.
+---+ +---+ +---+
| 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
+---+ +---+ +---+
|6LN|-------------------|LBR|--------------------| D |
+---+ LOWPAN_LE +---+ IPv6 Header|Data +---+
[CH=0 Length Value]
LOWPAN_IPHC
[header values]
Data
Figure 4: removing Local extensions
LOWPAN_LE [CH=0 Length Value] LOWPAN_LE [CH=41, Length, Value] LOWPAN_IPHC [header values] Destination H. Data
Figure 5: Local extensions received
[IPv6 Header (NH=0)] [HbH (NH=41)] [Routing (NH=60)] [Destination (NH=XX)] Data
Figure 6: Uncompressed packet
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
The LOWPAN_LE is functionally equivalent to a tunnel.
| [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. |