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]