Internet DRAFT - draft-toutain-6lo-local-extensions

draft-toutain-6lo-local-extensions







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]