One document matched: draft-petrescu-autoconf-ra-based-routing-02.xml
<?xml version="1.0" encoding = "US-ASCII" ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc='yes'?>
<?rfc tocdepth="4"?>
<?rfc tocompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc ipr="trust200902" category='std'
docName="draft-petrescu-autoconf-ra-based-routing-02.txt">
<front>
<title abbrev='RA-based Routing'>
Router Advertisements for Routing between Moving Networks
</title>
<author initials='A.' surname='Petrescu' fullname='Alexandru Petrescu'>
<organization abbrev='CEA'>
CEA
</organization>
<address>
<postal>
<street>
CEA, LIST, Communicating Systems Laboratory,
Point Courrier 173
</street>
<city>Gif-sur-Yvette</city>
<region>Essonne</region>
<code>F-91191</code>
<country>France</country>
</postal>
<phone> +33 0169089223 </phone>
<email> alexandru.petrescu@cea.fr</email>
</address>
</author>
<author initials='C.' surname='Janneteau'
fullname='Christophe Janneteau'>
<organization abbrev='CEA'>
CEA
</organization>
<address>
<postal>
<street>
CEA, LIST, Communicating Systems Laboratory,
Point Courrier 173
</street>
<city>Gif-sur-Yvette</city>
<region>Essonne</region>
<code>F-91191</code>
<country>France</country>
</postal>
<phone> +33 0169089182 </phone>
<email> christophe.janneteau@cea.fr</email>
</address>
</author>
<author initials='N.' surname="Demailly" fullname='Nicolas
Demailly'>
<organization>iXXi</organization>
<address>
<postal>
<street>
1 Avenue Montaigne, Immeuble Central 4
</street>
<city>
Noisy-le-Grand
</city>
<!-- <region> -->
<!-- </region> -->
<code>
F-93160
</code>
<country>
France
</country>
</postal>
<!-- <phone> -->
<!-- +33 1xx -->
<!-- </phone> -->
<email>
nicolas.demailly@ixxi.biz
</email>
</address>
</author>
<author initials='S.' surname='Imadali'
fullname='Sofiane Imadali'>
<organization abbrev='CEA'>
CEA
</organization>
<address>
<postal>
<street>
CEA, LIST, Communicating Systems Laboratory,
Point Courrier 173
</street>
<city>Gif-sur-Yvette</city>
<region>Essonne</region>
<code>F-91191</code>
<country>France</country>
</postal>
<phone> +33 0169080727 </phone>
<email> sofiane.imadali@cea.fr</email>
</address>
</author>
<date day='09' month='February' year='2012'/>
<area>Internet Area</area>
<workgroup>Network Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>XML</keyword>
<abstract>
<t>
This draft specifies extensions to the ICMPv6 Router
Advertisement messages and processing. Traditionally,
prefixes contained in RAs are used for on-link determination,
on-link address auto-configuration, but not for path setup
towards multi-hop destinations. The extensions proposed here
still rely on RAs being communicated on a single link (not
across several IP hops), but upon RA reception the prefixes
are installed in the routing table; they are thus used for
forwarding packets further than a single link (multi IP hop).
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t>
This draft specifies extensions to the ICMPv6 Router
Advertisement messages and processing. Traditionally,
prefixes contained in RAs are used for on-link determination,
on-link address auto-configuration, but not for path setup
towards multi-hop destinations. The extensions proposed here
still rely on RAs being communicated on a single link (not
across several IP hops), but upon RA reception the prefixes
are installed in the routing table; they are thus used for
forwarding packets further than a single link (multi IP hop).
</t>
<t>
We present the message exchange diagrams, message formats and
algorithm executed by a node. The scenarios implying route
addition are: simultaneous power-up of 3 Mobile Routers,
arrival of a MR in a zone where other MRs are present; and
scenarios for route deletion: timeout expiration of route
entry, and explicit deletion of route entry.
</t>
<t>
These RA extensions are intended for path establishment
between LFNs in separate moving networks. The Mobile Routers
in charge of moving networks exchange their prefixes (with
RAs), and set up their routing tables. The exchanged prefixes scopes
are global <xref target='RFC4291'/> or local <xref target='RFC4193'/>.
In practice, applications may treat "Unique Local Addresses"
<xref target='RFC4193'/> as global scoped addresses.
</t>
<t>
The mechanism presented in this draft is an evolution of an
earlier work <xref target='I-D.petrescu-manemo-nano' />. This
document adds the behaviour for MR arrival at a zone where
other MRs are present, and the behaviour for route deletion.
</t>
<t>
A similar mechanism is presented in "Mobile Network Prefix
Provisioning" <xref target='I-D.jhlee-mext-mnpp' />. The
'MNPP' draft addresses a specific need of inter-connecting
vehicular networks; it considers use cases with or without
fixed Access Point (infrastructure-based and
infrastructure-less scenarios). In this draft we do not
consider the use of an Access Point, neither the
infrastructure-based scenario. On another hand, this draft
describes additional route deletion scenarios, whereas the
MNPP draft doesn't.
</t>
<t>
Communicating directly between two Mobile Routers, using their
egress interfaces, and without access to infrastructure can be
considered as Route Optimization: traffic between LFNs of
different moving networks is avoiding reaching the respective
Home Agents (presumably placed in the infrastructure).
Whereas this RA-based work is not explicitely addressing Route
Optimization, the effect of updating routing tables can be
considered to be so; such an effect can be also achieved by
extensions to the Mobile IPv6 protocol, as is suggested, for
example, by a recent Internet Draft titled "Mobile IPv6 Route
Optimization without Home Agent", authored by G. Hampel and
T. Klein, named draft-hampel-mext-ro-without-ha-00, and posted
on February 23rd, 2011. It proposes extensions to Mobile IPv6
protocol to conduct Route Optimization without Home Agent, in
particular by introducing a concept of virtual home link and
virtual home address.
</t>
</section>
<section anchor='terminology' title='Terminology'>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target='RFC2119'/>.
</t>
<t>
Mobile Router (MR) - a Mobile Router.
</t>
<t>
Mobile Network Prefix (MNP) - the Mobile Network Prefix is
topologically correct on the ingress interface of a Mobile
Router.
</t>
<t>
Egress interface of MR - the interface sending the special
Router Advertisements to other egress interface of other
Mobile Routers (by this draft's recommendation).
</t>
<t>
Ingress interface of MR - the interface towards the Local Fixed
Nodes in the moving network and on which the Mobile Network
Prefix (MNP) is topologically correct.
</t>
</section>
<section anchor='use-cases' title='Use-cases'>
<t>
Several use-cases in the context of a City public
transportation may take advantage of direct communications
between vehicles (without infrastructure), or between a
vehicle and a bus stop.
</t>
<section title='Communication between Security Vehicle and RATP
Vehicle'>
<t>
The environment consists of a Security Vehicle (such as
public safety) and a RATP Vehicle (a bus). The goal: during
an incident happenning within the bus, use a webcam to
inform the security agents (in the security vehicle) about
the ongoing event developments. The use-case: a bus is
driven along a typical scheduled drive. A passenger
aggression incident is declared within bus. The driver
silently triggers the red-button alarm. The security
vehicle approaches bus and agents query the live video feed
sent by the bus webcam. This is illustrated in the
following figure:
</t>
<figure align="center">
<artwork align="center">
<![CDATA[
|wifi wifi\
+------------+-+ \/--------\_
| bus(webcam)| | car(agent)|
+-O-------O--+ +-o-------o-+
]]>
</artwork>
</figure>
</section>
<section title='RATP Vehicle (bus) Approaching a Bus Stop'>
<t>
The environment consists of an RATP vehicle (a typical
public transportation bus) and a bus stop equipped of a WiFi
Access Point. The goal: augment the precision of waiting
time reporting to passenger waiting at the bus stop.
Currently, the waiting time is reported on a display at the
bus stop; its precision is in the order of 1-2 minutes
(i.e. it may happen that the display reports 2minute wait
time whereas the bus is actually at 30second distance). The
bus is equipped of a GPS receiver. Use-case: the passenger
is waiting at the bus stop. S/he scans the wait time
reported on the display. When the bus is within a range of
200 meter the display reports "Approaching"; when the bus is
within a 25 meter range the display reports ("At the stop").
</t>
<figure align="center">
<artwork align="center">
<![CDATA[
|wifi wifi\
+------------+-+ \/----------\
| bus(webcam)| | bus stop |
+-O-------O--+ | (display) |
]]>
</artwork>
</figure>
</section>
<section title='Visualizing Bus Stop Prior to Arrival'>
<t>
The environments consists of a RATP vehicle and a WiFi
station at the bus stop. Goal: ability to access a webcam
deployed at the bus stop, which allows the bus driver to see
how crowded the stop is and the type of potential
passengers. It thus offers the driver the opportunity to
plan the fitting of the bus on the arrival ramp. Use-case:
the bus approaches the bus stop; the driver sees on the
screen the passengers waiting at the stop; the driver
notices the presence of a stroller and a wheelchair; the
driver prepares the correct arrival at the ramp and
extension of the arm serving mobility.
</t>
<figure align="center">
<artwork align="center">
<![CDATA[
|wifi wifi\
+------------+-+ \/----------\
|bus(display)| | bus stop |
+-O-------O--+ | (webcam) |
]]>
</artwork>
</figure>
</section>
</section>
<section anchor='protocol' title='Protocol'>
<section title='Topology'>
<t>
These RA protocol extensions were conceived in a context of
vehicular networks. It was considered that a vehicle contains
a moving network. A moving network is composed of one Mobile
Router (MR) and several Local Fixed Nodes (LFNs). The MR has
one egress interface and one ingress interface. The egress
interface is used to connect to other vehicles whereas the
ingress interface connects to the LFNs in the vehicle.
</t>
<t>
For example, two moving networks connecting via their egress
interfaces are depicted below:
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
Vehicle 1 Vehicle 2
egress| |egress
---- ---- ---- ---- ---- ----
| LFN| |LFN | | MR | | MR | |LFN | |LFN |
---- ---- ---- ---- ---- ----
| | ingress| |ingress | |
--------------------- ---------------------
2001:db8:1::/40 2001:db8:2::/40
]]>
</artwork>
</figure>
</t>
<t>
In this figure, the Mobile Network Prefix (MNP) deployed in
vehicle 1 is 2001:db8:1::/40, for example. If ULA addresses are in
use inside the vehicles (convenient for communications between a
limited set of sites), the above figure prefixes could be, for
example: FD78:ADC8:857A::/48 and FDD3:48A5:2D72::/48 for vehicles 1
and 2, respectively. For more information about ULA prefixes
generation, please refer to <xref target='RFC4193'/>. The problem is
how to establish IP paths between the LFNs between the two
vehicles; initially the MR in one vehicle only knows about the
MNP in its own vehicle.
</t>
</section>
<section title='Operation on a Mobile Router'>
<t>
We propose to use a special kind of prefixes in the Router
Advertisements. MR sends RA on its egress interface. A
receiving MR installs the pair MNP-LL in its forwarding
information base (routing table, destination cache, tbd).
</t>
<t>
Each Mobile Router maintains a forwarding information
structure that contains entries of the form:
</t>
<t>
<list style='symbols'>
<t>
Mobile Network Prefix
</t>
<t>
Gateway address
</t>
<t>
Lifetime
</t>
<t>
Name of outgoing interface
</t>
<t>
Optionally link-layer address of Gateway
</t>
</list>
</t>
<t>
This data structure is managed mainly at the reception of the
special Router Advertisements, and when timers expire. This
structure can be implemented as part of the Destination Cache,
Binding Cache, Routing Table or Forwarding Information Base.
</t>
<t>
We present more details of the MR operation in the following
section.
</t>
</section>
<section title="Message Exchange">
<t>
The message exchange for the scenario of simultaneous
power-up of 3 MRs is pictured in the diagram below:
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
MR1 MR2 MR3
| | |
| MLD REPORT (LL1) | |
|----------------->|----------------->|multicast
| |MLD REPORT (LL3) |
|<-----------------|<-----------------|
| MLD|REPORT (LL2) |
|<-----------------|----------------->|
| | |
| Special RA | |
|----------------->|----------------->|
| (MNP1-LL1) | |
| | Special RA |
|<-----------------|<-----------------|
| | (MNP3-LL3) |
| | |
| Special|RA |
|<-----------------|----------------->|
| (MNP2-LL2) |
]]>
</artwork>
</figure>
</t>
<t>
<list style='symbols'>
<t>
All Mobile Routers connect their egress interface with a
wireless MAC protocol, for example 802.11 MAC. We
consider mainly the case where the "ad-hoc" mode is
used; we do not consider the presence of an Access Point
- the two moving networks should be able to connect to
each other without the use of fixed Access Points.
</t>
<t>
Following link-layer successful connectivity, each
Mobile Router joins the all-routers multicast address on
the egress interface (typically using a link-local
address, pictured as LL1).
</t>
<t>
Each Mobile Router multicasts special RAs on the egress
interface, containing the Mobile Network Prefix that is
assigned to its moving network. A Mobile Router SHOULD wait
for a random delay <xref target='RFC4861'/> before sending the
special RA. If the first special RA contains a ULA prefix,
the next special RAs sent should contain ULA prefixes as well,
if available. This is to avoid "mixing" ULA addresses
<xref target='RFC4193'/> and global addresses
<xref target='RFC4291'/> in the same packet. This is not
forbidden though.
</t>
<t>
When receiving the special RA from another MR, a MR
parses the packet for the link-local address of the
sending MR, for the MNP sent by that MR and for the
lifetime. It then installs the corresponding entry into
the data structure mentioned earlier.
</t>
<t>
Before leaving the Fixed Scene, a Mobile Router sends
another special RA to all routers this time informing
them that the MNP-linklocaladdress pair is no longer
present at the scene (lifetime 0 as per <xref
target='RFC4191'/>), so the other routers delete the
corresponding route. It could also courteously
multicast a MLD REPORT to leave the all-routers
multicast group, if necessary. This Mobile Router SHOULD wait
for a random delay before sending the special RA message.
</t>
<t>
Operation of the Mobile Router when forwarding packets
(after installation of the MNP-ll route) is similar to
that of any router: for each packet not addressed to
itself, longest-prefix match the destination address of
the packet to an entry in the table, select the
'gateway' address, solicit that neighbour's MAC address
and put the received MAC address in the link-layer dst
address then send it.
</t>
</list>
</t>
<t>
With this mechanism, the various LFNs in the moving networks
are capable to exchange IP messages, routed by two Mobile
Routers each time. Longest-prefix match can still be used to take
the next hop forwarding decision regardless whether the
destination address is global scoped or Unique Local IPv6 address.
</t>
<t>
For faster discovery of the Mobile Network Prefixes of
the other Mobile Routers, a certain Mobile Router can
send a special Router Solicitation right after joining
the scene. A random delay <xref target='RFC4861'/> SHOULD be
introduced before sending any RS/RA message in order to prevent
RS/RA storms when several Mobile Routers join or leave the Fixed
Scene.
</t>
<t>
For the scenario of arrival of an MR in a zone where other
MRs are present, the message exchange diagram is depicted
below:
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
MR1 MR2 MR3
| | |
| RA3 (MNP3-LL3) |
|<-----------------o------------------|
| MLD "JOIN" |
|<-----------------o------------------|
| RS | |
|<-----------------o------------------|
| | |
| RA1 (MNP1-LL1) |
|------------------o----------------->|
| | |
| | RA2 (MNP2-LL2) |
| o----------------->|
| | |
]]>
</artwork>
</figure>
</t>
<t>
The arriving MR is the one using the Mobile Router MR3. MR1
and MR2 have already exchanged their respective routes using
the message exchange presented in the previous scenario.
The algorithm executed by MR3 is the following: (1) Send an
RA containing the prefix(es) allocated to its subnets to
which the ingress interfaces are connected (2) "Join" the
all-routers multicast address with link-scope, on its egress
interface (3) Send a Router Solicitation (RS) on its egress
interface requesting RAs from MR1 and MR2 (4) Receive their
special RAs: RA1 and RA2 (5) For each received RA, extract
the source address and the prefixes and insert the
corresponding number of routing table entries; these entries
will help reach the LFNs in the moving networks of MR1 and
MR2.
</t>
<t>
For route deletion, we consider two scenarios: timeout
expiration of route entry, and explicit deletion of route
entry. The following diagram depicts timeout expiration of
a route entry:
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
MR1 MR2 MR3
| | | \
| | | |
| | | |
| | | > timeout
| | | |
| RS | | |
|<-----------------o------------------| / deletion
| | | \
| RA1 (MNP1-LL1) | |
|------------------o----------------->| |
| | | > renewal
| | RA2 (MNP2-LL2) | |(eventually)
| o----------------->| |
| | | /
]]>
</artwork>
</figure>
</t>
<t>
This first scenario for deleting a routing table entry
consists in associating a timeout value on each entry
present in the routing table. Such an entry typically
contains the destination prefix, the IP address of the next
hop gateway and eventually the interface name. The new
timeout value is obtained from the "Lifetime" field of the
RA. With this value, each MR executes the following
algorithm for each entry present in its routing table: (1)
Set variable lt to the contents of the timeout value of the
routing table entry (2) Decrement lt (3) Wait 1 milisecond
(4) If lt is different than 0 jump to step 2, otherwise jump
to step 5 (5) Delete this entry (6) Send an RS to the
next-hop IP address of this routing table entry (7) If an RA
is received then re-insert the routing table entry.
</t>
<t>
The second scenario for deleting routing table entries
consists in an explicit indication by a Mobile Router to
other Mobile Routers about its intention to quit the subnet,
instructing them to remove the routing table entries
relative to its subnets (their MNPs: Mobile Network
Prefixes). The explicit indication is part of the same
special Router Advertisement. In practice, this effect
could be achieved in two different ways: either specify a
'D' flag for a certain MNP, or alternatively use a lifetime
'0' attached to same MNP ('0' meaning that the deletion
request is immediate).
</t>
<t>
The message exchange for explicit deletion is depicted in
the figure below. The Mobile Router MR1 sends RA1
containing the indication for immediate deletion (flag 'D',
or lifetime '0') and the mobile network prefix MNP1. Upon
receipt of this message, MR2 and MR3 search their respective
routing tables for the MNP1 and then delete these routing
table entries.
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
MR1 MR2 MR3
| | |
| RA1 (MNP1) |
|------------------o----------------->|
| ('D' flag or '0' lifetime) |
| | |
| | |
| | Upon reception of|
| |this RA, MR2 and 3|
| |delete their routes
| |for MNP1 from |
| |their routing |
| |tables. |
| | |
]]>
</artwork>
</figure>
</t>
</section>
<section title='Message Formats'>
<t>
Router Advertisement is a message format defined in <xref
target='RFC4861'/> as an ICMPv6 message. The document <xref
target='RFC5175' /> proposes an option for RA extensibility:
IPv6 Router Advetisement Flags Option. We propose to
reserve bit 16 for Mobile Network Prefixes.
</t>
<t>
<figure align="center">
<artwork align="center">
<![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 | Length |M| Bit fields available ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
'M' - Mobile Network Prefix present. Set to 1 if this Router
Advertisement contains a Mobile Network Prefix.
</t>
<t>
If the RA Flags Option contais the flag M, and set to 1,
then the Router Advertisement MUST contain a Route
Information Option <xref target='RFC4191'/> followed
optionally by a Source-Link Layer Address Option <xref
target='RFC4861'/>. (If this SLLAO option is used then it
avoids the necessity of doing NS/NA exchange for the
link-local address of the Gateway entry in the data
structure mentioned earlier.)
</t>
<t>
A complete diagram of the Router Advertisement is presented
in the figure below:
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
Base Header (RFC 2460)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RA (RFC 4861)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Router Advetisement Flags Option (RFC 5175)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |M| Bit fields available ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Information Option (RFC 4191)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SLLAO (RFC 4861)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
<list hangIndent="8" style="hanging">
<t hangText='Source Address'>
<vspace blankLines='1' />
IPv6 Link Layer Address of sending MR. To be installed
as the Gateway address in the manemo forwarding
information structure.
</t>
<t hangText="Destination Address">
<vspace blankLines="1" />
IPv6 all-routers multicast address with link-scope.
<vspace blankLines="1" />
</t>
<t hangText='Prf'>
<vspace blankLines='1' />
Preference, value 0x09; this route should not be
preferred over other default routes.
</t>
<t hangText='Prefix (in Router Information Option)'>
<vspace blankLines='1' />
The Mobile Network Prefix of this Mobile Router.
</t>
<t hangText='Link-Layer Address (optional)'>
<vspace blankLines='1' />
Link-layer address of the egress interface of the MR.
The receiving MR can use this address for sending
packets to the MR that advertises a certain MNP.
</t>
</list>
</t>
<t>
A Mobile Router MUST NOT include Prefix Information Options
<xref target='RFC4861'/> into the special Router
Advertisements so that the receiving Mobile Routers don't
auto-configure addresses based on these prefixes.
</t>
<t>
A Mobile Router MUST NOT auto-configure an address derived
from the Mobile Network Prefix found within a received
special Router Advertisement.
</t>
</section>
</section>
<section anchor='seccons' title='Security Considerations'>
<t>
RA security.
</t>
<t>
It is of utmost importance that the Mobile Routers exchange the
special Router Advertisements securely.
</t>
<t>
SeND [RFC3971] permits to bind an address to a public key. But not a
prefix. This may involve concepts of the prefix-ownership problem
space.
</t>
<t>
It is necessary to build a threat model for this scenario and
mechanism, analyze the security tools offered by SeND and identify
the potential risks and their mitigation.
</t>
<t>
In some cases it is possible that a moving network is
connected to the Internet, in addition to being connected to
other moving networks. If so, it may be advantageous to
update PKI certificates, or similar operation, in order to
ensure a more secure connectivity to other moving networks.
</t>
<t>
Some kinds of link layers used for establishing the link
connectivity between the egress interfaces (e.g. IEEE 802.11b)
offer several means of authentication and confidentiality - at
link-layer: e.g. WEP, WPA, more. It may be advantageous to
make use of these secure link-layer mechanisms.
</t>
</section>
<section anchor='IANA'
title='IANA Considerations'>
<t>
IANA no action.
</t>
</section>
<section anchor='Acknowledgements'
title='Acknowledgements'>
<t>
The authors would like to thank people who contributed
stimulating discussion on the manemo@mobileip.jp list during
November 2006 to February 2007: Pascal Thubert, Ryuji
Wakikawa, Jim Bound, Jari Arkko, Roberto Baldessari, Ben
McCarthy, Teco Boot, Nicolas Chevrollier, Jean Lorchat, Fred
Templin, Carlos Jesus Bernardos Cano, Thierry Ernst, Bryan
McLaughlin, Theo De Jongh, Thomas Heide Clausen, Lim Hyung
Jin, David Binet, Samita Chakrabarti, Shubhranshu, Richard
Bernhardt, Martin Dunmore, Emmanuel Baccelli.
</t>
<t>
The authors would like to acknowledge a number of co-workers
at Motorola who strongly supported work in this area several
years ago. Their names will appear when deemed necessary.
</t>
<t>
Authors would like to thank several interns during July 2009
to September 2010 for their support in implementing, testing
and demonstrating the feasibility of the concepts presented in
this draft: Maxence Dalmais, Miljan Babovic and Nicolas
Gressin.
</t>
<t>
Authors would like to thank Jong-Hyouk Lee for comments on the
MEXT WG email list about a similar idea implemented at INRIA.
</t>
<t>
The work presented in this draft was supported in part by the
French ANR ("Agence Nationale de la Recherche", fr.) project
named SEAMLESS, which lasted between September 2010 and
January 2011.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4191" ?>
<?rfc include="reference.RFC.4193" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.5175" ?>
</references>
<references title='Informative References'>
<?rfc include="reference.I-D.jhlee-mext-mnpp" ?>
<?rfc include="reference.I-D.petrescu-manemo-nano" ?>
</references>
<section anchor='changelog'
title='ChangeLog'>
<t>
The changes are listed in reverse chronological order, most
recent changes appearing at the top of the list.
</t>
<t>
From draft-petrescu-autoconf-ra-based-routing-01.txt to
draft-petrescu-autoconf-ra-based-routing-02.txt:
<list style='symbols'>
<t>
Added explanatory text to the case where several vehicles are in
a Fixed Scene about the use of random delay before sending
special RAs.
</t>
<t>
Added explanations about MNP exchange between vehicles in the
case ULA prefixes are used.
</t>
<t>
Updated the authorship.
</t>
<t>
Added a reference to RFC4193 and RFC4291.
</t>
<t>
Updated the example IPv6 addresses to use the ULA prefixes.
</t>
</list>
</t>
<t>
From draft-petrescu-autoconf-ra-based-routing-00.txt to
draft-petrescu-autoconf-ra-based-routing-01.txt:
<list style='symbols'>
<t>
Added a section with three Use-cases issued from a public
transportation setting: communications between a security
vehicle and a bus, between bus and bus stop and
vice-versa.
</t>
<t>
Updated the authorship.
</t>
<t>
Added a reference to draft-hampel-mext-ro-without-ha-00
and short explanatory text, in the Introduction.
</t>
<t>
Updated the example IPv6 addresses to use the
Documentation Prefix 2001:db8:: instead of the real
2001:1::.
</t>
</list>
</t>
<t>
From draft-petrescu-autoconf-ra-based-routing-00.txt to:
<list style='symbols'>
<t>
changed.
</t>
</list>
</t>
</section>
<!--
XML ChangeLog
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:59 |