One document matched: draft-thubert-6man-reverse-routing-header-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc sySRNefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="std" docName="draft-thubert-6man-reverse-routing-header-00" ipr="trust200902">
<front>
<title abbrev="RRH">Reverse Routing Header</title>
<author role="editor" fullname="Pascal Thubert" initials="P"
surname="Thubert">
<organization abbrev="Cisco Systems">Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<date/>
<area>Routing Area</area>
<workgroup>6MAN</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>For new classes of devices such as highly constrained nodes,
forward and return Record Route capabilities are required to enable
basic forwarding operations. This memo defines
a such a technique for IPv6.</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_introduction' title="Introduction">
<t>This document assumes that the reader is familiar with the
IPv6 RH0 operation as specified in <xref target='RFC2460' /> and the RH2
as previously defined in <xref target='RFC3775' /> and the RH4 defined
for <xref target="I-D.ietf-roll-rpl"> RPL </xref> in
<xref target="I-D.hui-6man-rpl-routing-header"/>.</t>
<t>This specification defines a Forward Record Routing Header (FRRH), that
is a controlled variant of the Loose Source and Record Route (LSRR)
defined for IPv4 in <xref target='RFC0791' /> and hereby adapted for IPv6.
FRRH records the path of a packet within a closed Source Routing Domain (SRD) such
as a RPL network. The FRRH can be trivially
converted into a RH4 to force further packets to follow an
identical path within the same RPL network.
</t>
<t>This specification also introduces a new Routing Header, called the Reverse
Routing Header (RRH), to perform source routing within the RPL network
along the way back. As opposed to the FRRH that records a forward path,
RRH stacks the route bottom up and can be trivially
converted into a RH4 to force packets to follow an
identical reverse path within the same RPL network.</t>
<section anchor='recu' title="Motivations">
<t> A Low Power Lossy Network (LLN) forms a dynamic NBMA Subnetwork of devices
that might be so constrained in memory that they cannot
hold all the states that would be required to route within their own
Subnetwork. In some instances, default routes to some border routers can
be maintained, but the way back to specific destination cannot. In other
instances, even the route to the border router will be lost rapidly.
<xref target="I-D.ietf-roll-rpl"> RPL </xref> is a Subnetwork Gateway Protocol
(SGP), that is a routing protocol that is especially designed to build and
maintain a routing topology within the LLN.
</t>
<t>The path information must be somehow
aggregated to provide the source with consistent snapshots of the full
path across the Source Route Domain. This is achieved by IPv6 forms of
LSRR, introduced in
<xref target="I-D.hui-6man-rpl-routing-header"/> that defines the RH type 4
for the routing part and augmented hereby for the record part.</t>
<t>
<!--In order to enforce that the recorded path stays within the scope of the
SRD, the capture is performed hop-by-hop using packets with a link scope. -->
The protocol in the packet determines the propagation of the record RHs
and thus the path that is being recorded. To enforce the hop-by-hop recording operation,
The source and the destination of packet with a record RH MUST have the scope of a link.
The source address MUST be link local address, whereas the destination MUST be
either a link local address (typically for a RPL DAO message) or a
link-scoped multicast address when performing some form of flooding
(typically for a RPL DIS or DIO message). </t>
</section>
</section>
<!-- **************************************************************** -->
<section anchor='sec_terminology' title="Terminology">
<t>This document assumes that the reader is familiar with ROLL terminology defined in
<xref target='I-D.ietf-roll-terminology'/>.
</t>
<t> Additional terms are defined hereafter:
<list style='hanging'>
<t hangText='DAG'> Directed Acyclic Graph.</t>
<t hangText='SRN'>
Source Routing Node. A host or a router with the capability to support
this specification and make use of RRH within its NBMA Subnetwork .</t>
<t hangText='SRD'>
Source Routing Domain. A domain in which the Source Route operation is
accepted. All intermediate addresses within the same RH
must belong to the same SRD.
A domain can be:
<list style="symbols">
<t> A node or a contiguous set of nodes such as a dominating set</t>
<t> A Subnetwork such as a RPL Network </t>
<t> A network serving the same Unique Local Aggregation.</t>
</list>
</t>
<t hangText='SRA:'>
Source Routable Address. An address that can be inserted in a RH/RRH.
An SRA is an Ipv6 address that belongs to the SR domain with a
scope that is valid across the SR domain.</t>
<t hangText='TA:'>
Target Address. The last Address in the Routing Header identifying
the target. There is no constraint on that address.</t>
<t hangText='CRH:'>
Constrained Routing Header. A constrained routing header is a routing header
that can be forwarded only within an SRD. It is formed of a list of SRA, followed
by at most one TA.</t>
<t hangText='FRRH:'>
Forward Record Routing Header, defined in this specification;
a variable size record route header used to learn a path
hop-by-hop. It is preferably formed of addresses that are located
on the ingress interface of the packets.</t>
<t hangText='RRH:'>
Reverse Routing Header, defined in this specification;
a variable size reverse route header used to learn a path back
hop-by-hop. It is formed of addresses that are located
on the egress interface of the packets.</t>
<t hangText='NULL RH:'>
An FRRH or an RRH with a zero "Segments Used".</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_example' title="Examples">
<t>For the sake of the example, the RPL Network in the following
figure assumes the logical shape of a tree towards a border router.
This abstraction is chosen because it is simpler to represent than
the actual Directed Acyclic Graph shape that most RPL Networks
will form.</t>
<figure title=" A tree shaped RPL network">
<artwork><![CDATA[
+---------------------+
| Internet |---CN
+---------------|-----+
Border Router
|
======?======
SRN1
|
====?=============?==============?===
SRN5 SRN2 SRN6
| | |
=========== ===?========= =============
SRN3
|
===========?==
RPL Network SRN4
|
=========
]]></artwork>
</figure>
<t>This example focuses on a SRD node at depth 3 identified as
Source Routing Node 3 (SRN3). The path to the border router and then the Internet is
<figure>
<artwork><![CDATA[
SRN3 -> SRN2 -> SRN1 -> Border Router ->Internet
]]></artwork>
</figure>
In one example, the Border Routers first initiates a multicast flooding to build
a Reverse Routing Header that records
the source route path from each node towards itself. In another example, a node
that wishes to be reachable starts a record route towards the border router.
</t>
<t>A node that wishes to be reachable
inserts a reverse routing header with a number of N
pre-allocated slots that derive from its estimation of its depth.
</t>
<section anchor='sec_example_flood' title="Flooding downwards">
<t>In this example, no preexisting routing structure exists and the
routing header is being assembled by a flooding mechanism from the
Border Router (BR) downwards.</t>
<t>The packet has source the Border Router link local Address, BR_LLA, and
destination a multicast link scope address that is used for the flooding:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------++-------+--------+--------+ +---
| SRC | DST |: :| | slotN || slot2 | slot1 | source | |
| BR |all XXX|: EXT:|RRH | || | BR | BR | | NH
| LLA |L scope|: :| | || | SRA | TA | |
+-------+-------++ -- ++----+-------++-------+--------+--------+ +---
]]></artwork>
</figure>
The BR-SRA acts as locator and it is possible that this address has a limited reach
such as ULA. The BR-TA is a global identifier for the BR. It might be omitted when
the source of the RRH is only used as an intermediate router and not as a destination.</t>
<t>
It must be noted that BR-SRA is preferably an address on the BR interface towards SRN1,
that is directly visible from SRN1, in case there is no routing between BR and SRN1.</t>
<t>
BR-SRA is also preferably an address that has a scope as large as the Source Route Domain,
enabling the hop-by-hop recording process to possibly omit tracing some intermediate
hops and thus form a loose source route header.
</t>
<t>The routers one hop away figure the best message they receive and propagate it,
including the augmented RRH. </t>
<t>For SRN1, this gives:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------++-------+--------+--------+ +---
| SRC | DST |: :| | slotN || slot2 | slot1 | source | |
| SRN1 |all XXX|: EXT:| RRH| || SRN1 | BR | BR | | NH
| LLA |L scope|: :| | || SRA | SRA | TA | |
+-------+-------++ -- ++----+-------++-------+--------+--------+ +---
]]></artwork>
</figure>
</t>
<t>When SRN3 gets the packet, it receives:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----++-------+-------+--------+--------+ +---
| SRC | DST |: :| || slot3 | slot2 | slot1 | source | |
|SRN2 |all XXX|: EXT:| RRH|| SRN2 | SRN1 | BR | BR | | NH
|LLA |L scope|: :| || SRA | SRA | SRA | TA | |
+-------+-------++ -- ++----++-------+-------+--------+--------+ +---
]]></artwork>
</figure>
</t>
<t>The RH4 is trivially built by picking the tail of the incoming RRH, to be inserted
when sending a packet to the border router. Additionally, the node might create a tunnel
interface towards the border and install a default route there.
</t>
<t> So an arbitrary destination
in the Internet can replace the BR TA and will cause a packet flow like this:
</t>
<figure title="Message going out of SRN3 to the BR">
<artwork><![CDATA[
transport mode (1 slot consumed if SRN3 TA is included)):
+-------+-------+----+-------+-------+-------+---------++ -- + +---
| SRC | DST | RH | slot3 | slot2 | slot1 | destin. |: : |
|SRN3 |SRN2 |type| SRN3 | SRN1 | BR | arbitr. |: EXT: | NH
|SRA |SRA | 4 | TA | SRA | SRA | destin. |: : |
+-------+-------+----+-------+-------+-------+---------++ -- + +---
tunnel mode (nothing consumed):
+-------+-------+----+-------+-------+ +-------+-------++ -- + +---
|oSRC |oDST | RH | slot1 | slot0 | |iSRC |iDST |: : |
|SRN3 |SRN2 |type| SRN1 | BR | |SRN3 |arbitr.|: EXT: | NH
|SRA |SRA | 4 | SRA | SRA | |TA |destin.|: : |
+-------+-------++--++-------+-------+ +-------+-------++ -- + +---
]]></artwork>
</figure>
<t>That reaches the Border Router as this:</t>
<figure title="Message coming in the border router from SRN3">
<artwork><![CDATA[
transport mode (consumed up to slot 1):
+-------+-------+----+-------+-------+-------+---------++ -- + +---
| SRC | DST | RH | slot3 | slot2 | slot1 | destin. |: : |
|SRN3 |BR |type| SRN3 | SRN2 | SRN1 | arbitr. |: EXT: | NH
|TA |SRA | 4 | SRA | SRA | SRA | destin. |: : |
+-------+-------+----+-------+-------+-------+---------++ -- + +---
tunnel mode (all consumed):
+-------+-------+----+-------+-------+ +-------+-------++ -- + +---
|oSRC |oDST | RH | slot1 | slot0 | |iSRC |iDST |: : |
|SRN3 |BR |type| SRN2 | SRN1 | |SRN3 |arbitr.|: EXT: | NH
|SRA |SRA | 4 | SRA | SRA | |TA |destin.|: : |
+-------+-------++--++------+-------+ +-------+-------++ -- + +---
Message going out of BR:
+-------+-------++ -- + +---
| SRC | DST |: : |
|SRN3 |arbitr.|: EXT: | NH
|TA |destin.|: : |
+-------+-------++ -- + +---
]]></artwork>
</figure>
<t>
Upon decapsulation, it is up to the border router to decide by policy whether it should
route the packet or not. In particular in Transport mode, security reasons might dictate
to drop the packet.
</t>
</section>
<section anchor='sec_example_uni' title="Following an implicit upwards path">
<t>In this example, a preexisting routing structure exists that leads
to a well-known border router. The RRH is assembled along that path.</t>
<!--Choosing the right value for N is discussed in
<xref target='sec_icmp'/>. -->.
<t>
The last (bottom) slot contains a global identifier for the SRN, SRN3 TA.
there is no constraint with regard to the type of IPv6 address
used there.
It might be omitted if SRN3 uses its SRA to terminate its connections.
Then SRN3 inserts its SRA in the slot directly above. </t>
<t>The IPv6 header in the packet has source SRN3's link local Address, SRN3_LLA, and
destination SRN3's next hop LLA, SRN2_LLA, on the link between SRN2 and SRN3:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------++-------+-------+---------+ +---
| SRC | DST |: :| | slotN || slot2 | slot1 | source | |
|SRN3 |SRN2 |: EXT:| RRH| || | SRN3 | SRN3 | | NH
|LLA |LLA |: :| | || | SRA | TA | |
+-------+-------++ -- ++----+-------++-------+-------+---------+ +---
]]></artwork>
</figure>
</t>
<t>The second router on the path, SRN2, receives that the packet.
If it is not the border router, then it might wish to propagate
the protocol payload towards the border router that is the implicit
termination of the propagation as dictated by the protocol operation.</t>
<t>The outer packet now has source SRN2 LLA and destination SRN1 LLA; the
RRH from top to bottom is: empty_slots | SRN2_SRA | SRN3_SRA | SRN3_TA:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------++-------+-------+---------+ +---
| SRC | DST |: :| | slotN || slot2 | slot1 | source | |
|SRN2 |SRN1 |: EXT:| RRH| || SRN2 | SRN3 | SRN3 | | NH
|LLA |LLA |: :| | || SRA | SRA | TA | |
+-------+-------++ -- ++----+-------++-------+-------+---------+ +---
]]></artwork>
</figure>
</t>
<t>In general the process followed by the second router is repeated by
all the routers on the path, till the border router that receives and absorbs:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----++-------+-------+-------+---------+ +---
| SRC | DST |: :| || slot3 | slot2 | slot1 | source | |
|SRN1 |BR |: EXT:| RRH|| SRN1 | SRN2 | SRN3 | SRN3 | | NH
|LLA |LLA |: :| || SRA | SRA | SRA | TA | |
+-------+-------++ -- ++----++-------+-------+-------+---------+ +---
]]></artwork>
</figure>
</t>
<t>When the border router, receives the packet, it MAY store the information in RRH
to build an RH4 back to SRN3 TA (or SRN3 SRA if the TA is omitted)</t>
<t>Again, the RH is trivially built by picking the trail of the previous RRH, to be inserted
by the border router into any packet flowing down to SRN3:
</t>
<figure >
<artwork><![CDATA[
Message coming in the border router from the infrastructure behind:
+-------+-------++ -- + +---
| SRC | DST |: : |
|arbitr.|SRN3 |: EXT: | NH
|source |TA |: : |
+-------+-------++ -- + +---
Message going out the border router:
transport mode:
+-------+-------+----+-------+-------+---------++ -- + +---
| SRC | DST | RH | slot2 | slot1 | destin |: : |
|arbitr.|SRN1 |type| SRN2 | SRN3 | SRN3 |: EXT: | NH
|source |SRA | 4 | SRA | SRA | TA |: : |
+-------+-------+----+-------+-------+---------++ -- + +---
Tunnel mode:
+-------+-------++----+-------+--------+ +-------+-------++ -- + +---
|oSRC |oDST || RH | slot2 | slot1 | |iSRC |iDST |: : |
|SRN3 |SRN1 ||type| SRN2 | SRN3 | |arbitr.|SRN3 |: EXT: | NH
|SRA |SRA || 4 | SRA | SRA | |source |TA |: : |
+-------+-------++----+-------+--------+ +-------+-------++ -- + +---
]]></artwork>
</figure>
<t>The RH type 4 is consumed along the source route path to SRN3 as a
deprecated <xref target='RFC2460'/> RH type 0 would, and the last hop
(SRN3 SRA to SRN3 TA) is consumed internally in SRN3, if it was present
in the first place, like a RH type 2 would be in the case of
<xref target='RFC3775'> Mobile IPv6 </xref>.
</t>
</section>
<section anchor='sec_example_rec' title="Recording a forward path">
<t>In this example, a Forward Record RH is filled as the protocol information
is propagated along the same upwards path.</t>
<!--Choosing the right value for N is discussed in
<xref target='sec_icmp'/>. -->.
<t>
The FRRH is initially empty. The source SRN3 might virtually start from SRN3-TA in
which case that address is added to the FRRH. Then, as any node along the path,
SRN3 adds it SRA and passes the packet long.</t>
<t>The IPv6 header in the packet has source SRN3's link local Address, SRN3_LLA, and
destination SRN3's next hop LLA, SRN2_LLA, on the link between SRN2 and SRN3:
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------++-------+-------+-------+ +---
| SRC | DST |: :| | slot0 ||slotn-2|slotN-1| slotN | |
|SRN3 |SRN2 |: EXT:|FRRH| SRN3 || | | | | NH
|LLA |LLA |: :| | SRA || | | | |
+-------+-------++ -- ++----+-------++-------+-------+-------+ +---
]]></artwork>
</figure>
</t>
<t>The second router on the path, SRN2, receives that the packet.
Again, it might wish to propagate protocol payload towards
the border router that is the implicit termination of the propagation.</t>
<t>The outer packet now has source SRN2 LLA and destination SRN1 LLA; the
FRRH from top to bottom is SRN3_SRA | SRN2_SRA | empty_slots :
</t>
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------+-------++-------+-------+ +---
| SRC | DST |: :| | slot0 | slot1 ||slotN-1| slotN | |
|SRN2 |SRN1 |: EXT:|FRRH| SRN3 | SRN2 || | | | NH
|LLA |LLA |: :| | SRA | SRA || | | |
+-------+-------++ -- ++----+-------+-------++-------+-------+ +---
]]></artwork>
</figure>
<t>
It must be noted that SRN2-SRA is preferably an address on the SRN2 ingress interface from SRN3,
that is directly visible from SRN3, in case there is no routing between SRN3 and SRN.</t>
<t>In general the process followed by the second router is repeated by
all the routers on the path, till the border router that receives:
</t>
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------+-------+-------++-------+ +---
| SRC | DST |: :| | slot0 | slot1 | slot2 || slotN | |
|SRN1 |BR |: EXT:|FRRH| SRN3 | SRN2 | SRN1 || | | NH
|LLA |LLA |: :| | SRA | SRA | SRA || | |
+-------+-------++ -- ++----+-------+-------+-------++-------+ +---
]]></artwork>
</figure>
<t>The BR also adds its own information for the internal hop to BR_TA:
</t>
<figure>
<artwork><![CDATA[
+-------+-------++ -- ++----+-------+-------+-------+-------++ +---
| SRC | DST |: :| | slot0 | slot1 | slot2 | slot3 || |
|SRN1 |BR |: EXT:|FRRH| SRN3 | SRN2 | SRN1 | BR || | NH
|LLA |LLA |: :| | SRA | SRA | SRA | SRA || |
+-------+-------++ -- ++----+-------+-------+-------+-------++ +---
]]></artwork>
</figure>
<t>At this point, the BR possesses a source route path that is usable from any address
along that path back to the BR. It may trivially transform the FRRH into a completed RRH
and pass it back to SRN3. SRN3 may then transform the RRH into a RH type 4
and send further packets along the same path.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_rh_types'
title="New Routing Headers">
<t>This draft introduces new loose source and record Constrained Route Headers
for IPv6. The headers have the same format decribed below and only differ
from the Routing type.</t>
<!-- vspace blankLines='100'/ -->
<!-- **************************************************************** -->
<section anchor='sec_rh_type_2' title="FRRH and RRH formats">
<t>The FRRH and the RRH share the following format:
<figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address slot +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address slot +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address slot +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<list style='hanging'>
<t hangText='Next Header'>
<vspace blankLines='1' />
8-bit selector. Identifies the type of header immediately
following the Routing header. Uses the same values as the IPv4
Protocol field <xref target='RFC3232'/>.</t>
<t hangText='Hdr Ext Len'>
<vspace blankLines='1' />
8-bit unsigned integer. Length of the Routing header in 8-octet
units, not including the first 8 octets. For the Type 2 Routing
header, Hdr Ext Len is equal to two times the number of addresses
in the header.</t>
<t hangText='Routing Type'>
<vspace blankLines='1' />
8-bit unsigned integer. Set (tentatively) to 3 for FRRH and 5 for RRH.</t>
<t hangText='Segments Left'>
<vspace blankLines='1' />
8-bit unsigned integer. Number of route segments remaining.</t>
<t hangText='Reserved'>
<vspace blankLines='1' />
32-bit reserved field. Initialized to zero for transmission;
ignored on reception.</t>
<t hangText='Address slot []'>
<vspace blankLines='1' />
Vector of 128-bit addresses, numbered 0 to N in LRRH and N to 0 in RRH.</t>
</list>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_icmp' title="Optimum number of slots">
<!--t>If its current Attachment Router conforms to Tree Discovery
as specified in <xref target='I-D.thubert-tree-discovery'/>,
a SRN knows its current tree depth from the Tree Information
Option (RA-TIO). The maximum number of slots needed in the RRH
is the same value as the SRN's own tree depth (that is the TreeDepth
as received from the AR incremented by one).</t -->
<t>A SRN always initializes the number
of slots in the F/RRH to the maximum of DEF_RRH_SLOTS and its estimation of its depth,
if the latter is known from a reliable hint such as a routing protocol.
The message may have a number of unused (NULL) slots,
when it is received by the Border Router.
The receiver end point crops out the extra entries in order to generates a RH.
</t>
<list>
<t>
From a RRH, the receiver generates a RH type 4 that it can use for
a response back.</t>
<t>
From a FRRH, the receiver generates a RRH that is
fully consumed, and send that back to the sender which in turn will generate
a RH type 4. None of those operations need to change the order of the
slots in the header and are mostly plain copies.
</t>
</list>
<t>
The RH type 4 contains the number of
required slots that the SRN now uses until it gets a hint that the
topology changes or until the next route recording.
</t>
<!-- t>In the case of a NULL RRH, the border router does not
include a RH 2 at all. This may happen in the process of a DHAAD
message (see
<xref target='sec_dhaad' />)
</t -->
<t>The number of slots in the RRH MUST NOT be larger than
MAX_RRH_SLOTS. If a SRN is deeper than MAX_RRH_SLOTS, it is
expected that the rest of the way is already known ot the endpoint.
</t>
<t>In runtime, it may happen that the RRH has fewer slots than
required for the number of SRNs in the path
because either the NBMA Subnetwork topology is changing too
quickly,
or the SRN that inserted the RRH had a wrong representation of the
topology.</t>
<t>To solve this problem a new ICMP message is introduced, "RRH
Warning", type 64. A SRN on the upwards path that gets a packet
without a free slot in the F/RRH MAY send that ICMP "RRH warning"
back to the SRN that inserted the RRH in the first place.</t>
<t>This message allows a SRN on the path to propose a larger number of
slots to the SRN that creates the RRH. The Proposed Size
MUST NOT be larger than MAX_RRH_SLOTS.
The originating SRN must rate-limit the ICMP messages to avoid
excessive ICMP traffic in the case of the source failing to operate as
requested.</t>
<t>The originating SRN must insert an RH type 4 based on the F/RRH in the
associated IP header, in order to route the ICMP message back to the
source of the reverse tunnel. A SRN that receives this ICMP message is
the actual destination and it MUST NOT forward it to the source
of the packet if the tunnel mode is being used.</t>
<t>The type 64 ICMP has the following format:
<figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 64 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Size | Proposed Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet headers |
+ as will fit without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style='hanging'>
<t hangText='Type'>
<vspace blankLines='1' />
64 [To Be Assigned]</t>
<t hangText='Code'> 0: RRH too small; 1: FRRH too small.
<vspace blankLines='1' />
The originating SRN requires the source to set the RRH size to a
larger value. The packet that triggered the ICMP will still be
forwarded by the SRN, but the path cannot be totally optimized (see
<xref target='sec_rrh_full' />).</t>
<t hangText='Checksum'>
<vspace blankLines='1' />
The ICMP checksum <xref target='RFC2463'/>.</t>
<t hangText='Current Size'>
<vspace blankLines='1' />
RRH size of the invoking packet, as a reference.</t>
<t hangText='Proposed Size'>
<vspace blankLines='1' />
The new value, expressed as a number of IPv6 addresses that can fit
in the RRH.</t>
<t hangText='Reserved'>
<vspace blankLines='1' />
16-bit reserved field. Initialized to zero for transmission;
ignored on reception.</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_SRN_operation' title="Source Routing Node Operation">
<t></t>
<!-- **************************************************************** -->
<section anchor='sec_rh_icmp_64_processing'
title='Processing of ICMP "RRH too small"'>
<t>The New ICMP message "RRH too Small" is presented in <xref
target='sec_icmp'/>. This message is addressed to the SRN which
performs the tunnel encapsulation and generates the RRH.</t>
<t>Hence, a SRN that receives the ICMP "RRH too small" MUST NOT
propagate it to the originating SRN or inner tunnel source, but MUST
process it for itself.</t>
<t>If the Current Size in the ICMP messages matches the actual current
number of slots in RRH, and if the ICMP passes some safety checks as
described in <xref target='sec_icmp'/>, then the SRN MAY adapt the number of
slots to the Proposed Size.</t>
</section>
<!-- **************************************************************** -->
<section anchor='sec_rh_icmp_processing' title="Processing of ICMP error">
<t>
When the SRN receives an ICMP error message, it checks whether it is
the final destination of the packet by looking at the included
packet. If the included packet has an RRH, then the SRN should
transform it in a RH type 4 to forward the ICMP to the original source
of the packet. If the included packet has an FRRH, then the SRN may
reverse it into a RH type 4 to forward the ICMP to the original source
of the packet.
</t>
</section>
<!-- **************************************************************** -->
<section anchor='sec_rrh_full' title="Processing of RRH Packets">
<t>A router that receives a RRH is a link scoped protocol packet may save
that RRH and associate it with the propagation of the protocol information.
the router performs ULP checksum validation and security header checks
including the RRH as received
</t>
<t>
When the router sends the propagated protocol information over an interface,
the router adds one of its addresses from that interface at the head of the
RRH, and then computes upper layer checksums and IPSec/AH signatures as
required.
</t>
<t>It is preferred that the address as a scope that is as large
as the Source Route Domain, in order to enable a loose operation.
In particular, if the router has consistent states to
route to the seconds most recent entry via the source link local of the
packet, then it can overwrite the most recent entry with its own.
</t>
<t>
The node at the end of the propagation and any node on the way may
decide to keep a source route state towards the address located in slot 0
using a source route path that is directly inferred from the RRH.
</t>
</section>
<!-- **************************************************************** -->
<section anchor='sec_frrh_full' title="Processing of FRRH Packets">
<t>A router that receives a FRRH is a link scoped protocol packet may save
that RRH and associate it with the propagation of the protocol information.
the router performs ULP checksum validation and security header checks
including the FRRH as received.
</t>
<t>
Then the router adds an address from the ingress interface at the end of the
FRRH, which is now ready to be associated to the propagation of the
protocol.
When the router sends the propagated protocol information over an interface,
it adds the FRRH as and computes upper layer checksums and IPSec/AH signatures as
required.
</t>
<t>
The node at the end of the propagation and any node on the way may
decide to reverse the FRRH into a RRH and send it back to the source
located in slot 0 for the FRRH,
which in turn can reverse it again, this time into a RH type 4.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_security' title="Security Considerations">
<t>The FRRH and the RRH are propagated as part of a higher hop-by-hop protocol operation,
so it is not mutable. Each hop adds its info, then computes the checksum and IPSec headers and
then it transmits with a link scope to the next node(s) on the way of the upper layer
protocol operation.</t>
<t>This section is not complete; further work is needed to analyze
and solve the security problems of record and source route.</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA considerations">
<t>This document requires IANA to define 2 new IPv6 Routing Header types
for Forward Record Routing Header and Reverse Routing Header.
The allocation is governed by
<xref target="I-D.ietf-6man-iana-routing-header"/></t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_const' title="Protocol Constants">
<t>
<list style='hanging'>
<t> DEF_RRH_SLOTS: 7</t>
<t> MAX_RRH_SLOTS: 10</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_acknowledgements' title="Acknowledgements">
</section>
</middle>
<back>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<references title="informative reference">
<?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
<?rfc include='reference.I-D.ietf-6man-iana-routing-header.xml'?>
<?rfc include='reference.I-D.hui-6man-rpl-routing-header.xml'?>
<?rfc include='reference.I-D.ietf-roll-rpl.xml'?>
</references>
<references title="normative reference">
<!-- The include magic works because we set the environment variable
XML_LIBRARY in .xml2rfc.rc to point to the reference directory. -->
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2401" ?>
<?rfc include="reference.RFC.2402" ?>
<?rfc include="reference.RFC.2406" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.2463" ?>
<?rfc include="reference.RFC.3775" ?>
<?rfc include="reference.RFC.3232" ?>
<?rfc include="reference.RFC.3971" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:10:11 |