One document matched: draft-toutain-6lo-local-extensions-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2460 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY rfc6553 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6553.xml'>
<!ENTITY rfc6554 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6554.xml'>
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" docName="draft-toutain-6lo-local-extensions-00.txt" ipr="trust200902">
<front>
<title abbrev="Local Extensions">6LoWPAN Local Extensions</title>
<author fullname="Laurent Toutain" initials="L." surname="Toutain">
<organization>Institut MINES TELECOM ; TELECOM Bretagne</organization>
<address>
<postal>
<street>2 rue de la Chataigneraie</street>
<street>CS 17607</street>
<city>35576 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>Laurent.Toutain@telecom-bretagne.eu</email>
</address>
</author>
<date month="June" year="2014" />
<!-- <workgroup>v6ops Working Group </workgroup> -->
<abstract>
<t>
<xref target="RFC2460"></xref> 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.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="IPv6 extensions">
<t>
<xref target="RFC2460"></xref> 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 <xref target="RFC2460"></xref> specifies:
</t><t>
<list style="empty">
<t>
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.
</t>
</list>
</t><t>
In other words, only the source can create an extension and routers
are not allowed to remove it.
</t><t>
On LoWPAN networks, some extensions are required to extend routing capabilities.
For instance, RPL defines a Hop by Hop extension <xref target="RFC6553"></xref> to specify a forwarding
plan (RPLInstanceID) or detect wrong direction packets. A routing header is
also defined for non storing mode <xref target="RFC6554"></xref> to specify the path to reach a leaf.
</t><t>
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.
</t><t>
<xref target="RFC6554"></xref> defines in figure following encapsulation:
<figure anchor="tunneling" title="Packet tunneling">
<artwork><![CDATA[
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
]]></artwork>
</figure>
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.
</t>
</section>
<section anchor="LOWPAN_LE" title="Local Extension Dispatch">
<t>
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 <xref target="RFC2460"></xref> extension
processing rules.
</t><t>
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.
</t>
<figure anchor="Extension" title="Extension header ">
<artwork><![CDATA[
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section anchor="execution" title="Compressing/Decompressing 6LoWPAN Header">
<t>
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 <xref target="tunneling" />.
</t>
<t>
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.
</t>
<t>
Note that this scheme remains compatible with tunneling described in
<xref target="RFC6554"></xref>. An outer IPHC header can be added before first LOWPAN_LE
DISPATCH, for instance to limit the scope of ICMP messages.
</t>
</section>
<section anchor="example" title="Examples">
<t>
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
<figure anchor="StoLN" title="Adding Local extensions ">
<artwork><![CDATA[
+---+ +---+ +---+
| 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
]]></artwork>
</figure>
A border router forwards traffic coming from a 6LN containing a Hop-by-Hop extension
to a node on the Internet.
<figure anchor="LNtoD" title="removing Local extensions ">
<artwork><![CDATA[
+---+ +---+ +---+
|6LN|-------------------|LBR|--------------------| D |
+---+ LOWPAN_LE +---+ IPv6 Header|Data +---+
[CH=0 Length Value]
LOWPAN_IPHC
[header values]
Data
]]></artwork>
</figure>
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:
<figure anchor="expand1" title="Local extensions received">
<artwork><![CDATA[
LOWPAN_LE
[CH=0 Length Value]
LOWPAN_LE
[CH=41, Length, Value]
LOWPAN_IPHC
[header values]
Destination H.
Data
]]></artwork>
</figure>
Will be expanded in:
<figure anchor="expand2" title="Uncompressed packet">
<artwork><![CDATA[
[IPv6 Header (NH=0)]
[HbH (NH=41)]
[Routing (NH=60)]
[Destination (NH=XX)]
Data
]]></artwork>
</figure>
For Mesh-Under, the process is transparent to 6LR, only 6LN may have to expand the packet.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The LOWPAN_LE is functionally equivalent to a tunnel.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2460;
&rfc6553;
&rfc6554;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:58:51 |