Internet DRAFT - draft-petrescu-autoconf-ra-based-routing
draft-petrescu-autoconf-ra-based-routing
Network Working Group A. Petrescu
Internet-Draft C. Janneteau
Intended status: Standards Track CEA
Expires: January 23, 2015 N. Demailly
iXXi
S. Imadali
CEA
July 22, 2014
Router Advertisements for Routing between Moving Networks
draft-petrescu-autoconf-ra-based-routing-05.txt
Abstract
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).
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 January 23, 2015.
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
Petrescu, et al. Expires January 23, 2015 [Page 1]
Internet-Draft RA-based Routing July 2014
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Communication between Security Vehicle and RATP Vehicle . 5
3.2. RATP Vehicle (bus) Approaching a Bus Stop . . . . . . . . 5
3.3. Visualizing Bus Stop Prior to Arrival . . . . . . . . . . 6
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Operation on a Mobile Router . . . . . . . . . . . . . . . 7
4.3. Message Exchange . . . . . . . . . . . . . . . . . . . . . 7
4.4. Message Formats . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Petrescu, et al. Expires January 23, 2015 [Page 2]
Internet-Draft RA-based Routing July 2014
1. Introduction
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).
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.
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 [RFC4291] or local
[RFC4193]. In practice, applications may treat "Unique Local
Addresses" [RFC4193] as global scoped addresses.
The mechanism presented in this draft is an evolution of an earlier
work [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.
A similar mechanism is presented in "Routers auto-configuration using
Route Information Option from ICMPv6 Router Advertisements"
[I-D.pfister-moving-net-autoconf]. This draft uses a rather
different encoding mechanism in the Router Advertisement. It uses an
available bit in the Router Information Option (RIO) option - the bit
'M' - instead of using the IPv6 Router Advertisement Flags Option.
Additionally, it reserves 2 bits named 'R' for a future extension of
this mechanism, that may involve more than just one link.
A similar mechanism is presented in "Mobile Network Prefix
Provisioning" [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.
Petrescu, et al. Expires January 23, 2015 [Page 3]
Internet-Draft RA-based Routing July 2014
An additional mechanism that also relies on Router Advertisement
options to communicate routes to be installed in the routing table is
presented in [I-D.sarikaya-6man-next-hop-ra]. That mechanism is
suggested as a means to communicate routes to end nodes such as
multiply-interfaced Hosts (terminals such as smartphones), and not
necessarily to Routers. It describes further enhancements, such as
the use of source addresses as additional parameters to communicate
and install in the routing tables.
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.
2. Terminology
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 [RFC2119].
Mobile Router (MR) - a Mobile Router.
Mobile Network Prefix (MNP) - the Mobile Network Prefix is
topologically correct on the ingress interface of a Mobile Router.
Egress interface of MR - the interface sending the special Router
Advertisements to other egress interface of other Mobile Routers (by
this draft's recommendation).
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.
3. Use-cases
Several use-cases in the context of a City public transportation may
Petrescu, et al. Expires January 23, 2015 [Page 4]
Internet-Draft RA-based Routing July 2014
take advantage of direct communications between vehicles (without
infrastructure), or between a vehicle and a bus stop.
3.1. Communication between Security Vehicle and RATP Vehicle
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:
|wifi wifi\
+------------+-+ \/--------\_
| bus(webcam)| | car(agent)|
+-O-------O--+ +-o-------o-+
3.2. RATP Vehicle (bus) Approaching a Bus Stop
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").
|wifi wifi\
+------------+-+ \/----------\
| bus(webcam)| | bus stop |
+-O-------O--+ | (display) |
Petrescu, et al. Expires January 23, 2015 [Page 5]
Internet-Draft RA-based Routing July 2014
3.3. Visualizing Bus Stop Prior to Arrival
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.
|wifi wifi\
+------------+-+ \/----------\
|bus(display)| | bus stop |
+-O-------O--+ | (webcam) |
4. Protocol
4.1. Topology
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.
For example, two moving networks connecting via their egress
interfaces are depicted below:
Vehicle 1 Vehicle 2
egress| |egress
---- ---- ---- ---- ---- ----
| LFN| |LFN | | MR | | MR | |LFN | |LFN |
---- ---- ---- ---- ---- ----
| | ingress| |ingress | |
--------------------- ---------------------
2001:db8:1::/40 2001:db8:2::/40
Petrescu, et al. Expires January 23, 2015 [Page 6]
Internet-Draft RA-based Routing July 2014
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
[RFC4193] It is also possible for a MR to generate ULA prefixes based
on its Vehicular Identification Number (VIN). The use of VIN numbers
to generate ULA prefixes will be detailed in a future draft. 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.
4.2. Operation on a Mobile Router
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).
Each Mobile Router maintains a forwarding information structure that
contains entries of the form:
o Mobile Network Prefix
o Gateway address
o Lifetime
o Name of outgoing interface
o Optionally link-layer address of Gateway
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.
We present more details of the MR operation in the following section.
4.3. Message Exchange
The message exchange for the scenario of simultaneous power-up of 3
MRs is pictured in the diagram below:
Petrescu, et al. Expires January 23, 2015 [Page 7]
Internet-Draft RA-based Routing July 2014
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) |
o 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.
o 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).
o 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
[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 [RFC4193] and global addresses [RFC4291] in the same
packet. This is not forbidden though.
o 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.
o Before leaving the Fixed Scene, a Mobile Router sends another
special RA to all routers this time informing them that the MNP-
Petrescu, et al. Expires January 23, 2015 [Page 8]
Internet-Draft RA-based Routing July 2014
linklocaladdress pair is no longer present at the scene (lifetime
0 as per [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.
o 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.
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.
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 [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.
For the scenario of arrival of an MR in a zone where other MRs are
present, the message exchange diagram is depicted below:
MR1 MR2 MR3
| | |
| RA3 (MNP3-LL3) |
|<-----------------o------------------|
| MLD "JOIN" |
|<-----------------o------------------|
| RS | |
|<-----------------o------------------|
| | |
| RA1 (MNP1-LL1) |
|------------------o----------------->|
| | |
| | RA2 (MNP2-LL2) |
| o----------------->|
Petrescu, et al. Expires January 23, 2015 [Page 9]
Internet-Draft RA-based Routing July 2014
| | |
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.
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:
MR1 MR2 MR3
| | | \
| | | |
| | | |
| | | > timeout
| | | |
| RS | | |
|<-----------------o------------------| / deletion
| | | \
| RA1 (MNP1-LL1) | |
|------------------o----------------->| |
| | | > renewal
| | RA2 (MNP2-LL2) | |(eventually)
| o----------------->| |
| | | /
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)
Petrescu, et al. Expires January 23, 2015 [Page 10]
Internet-Draft RA-based Routing July 2014
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.
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).
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.
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. |
| | |
4.4. Message Formats
Router Advertisement is a message format defined in [RFC4861] as an
ICMPv6 message. The document [RFC5175] proposes an option for RA
extensibility: IPv6 Router Advertisement Flags Option. We propose to
reserve bit 16 for Mobile Network Prefixes.
Petrescu, et al. Expires January 23, 2015 [Page 11]
Internet-Draft RA-based Routing July 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'M' - Mobile Network Prefix present. Set to 1 if this Router
Advertisement contains a Mobile Network Prefix.
If the RA Flags Option contais the flag M, and set to 1, then the
Router Advertisement MUST contain a Route Information Option
[RFC4191] followed optionally by a Source-Link Layer Address Option
[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.)
A complete diagram of the Router Advertisement is presented in the
figure below:
Base Header (RFC 2460)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RA (RFC 4861)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Petrescu, et al. Expires January 23, 2015 [Page 12]
Internet-Draft RA-based Routing July 2014
| 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Address
IPv6 Link Layer Address of sending MR. To be installed as
the Gateway address in the manemo forwarding information
structure.
Destination Address
IPv6 all-routers multicast address with link-scope.
Prf
Preference, value 0x09; this route should not be preferred
over other default routes.
Petrescu, et al. Expires January 23, 2015 [Page 13]
Internet-Draft RA-based Routing July 2014
Prefix (in Router Information Option)
The Mobile Network Prefix of this Mobile Router.
Link-Layer Address (optional)
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.
A Mobile Router MUST NOT include Prefix Information Options [RFC4861]
into the special Router Advertisements so that the receiving Mobile
Routers don't auto-configure addresses based on these prefixes.
A Mobile Router MUST NOT auto-configure an address derived from the
Mobile Network Prefix found within a received special Router
Advertisement.
5. Security Considerations
RA security.
It is of utmost importance that the Mobile Routers exchange the
special Router Advertisements securely.
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.
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.
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.
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.
Petrescu, et al. Expires January 23, 2015 [Page 14]
Internet-Draft RA-based Routing July 2014
6. IANA Considerations
IANA no action.
7. Acknowledgements
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.
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.
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.
Authors would like to thank Jong-Hyouk Lee for comments on the MEXT
WG email list about a similar idea implemented at INRIA.
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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Petrescu, et al. Expires January 23, 2015 [Page 15]
Internet-Draft RA-based Routing July 2014
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement
Flags Option", RFC 5175, March 2008.
8.2. Informative References
[I-D.jhlee-mext-mnpp]
Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix
Provisioning", draft-jhlee-mext-mnpp-00 (work in
progress), October 2009.
[I-D.petrescu-manemo-nano]
Petrescu, A. and C. Janneteau, "The NANO Draft (Scene
Scenario for Mobile Routers and MNP in RA)",
draft-petrescu-manemo-nano-00 (work in progress),
March 2007.
[I-D.pfister-moving-net-autoconf]
Pfister, P. and A. Petrescu, "Routers auto-configuration
using Route Information Option from ICMPv6 Router
Advertisements", draft-pfister-moving-net-autoconf-00
(work in progress), July 2013.
[I-D.sarikaya-6man-next-hop-ra]
Sarikaya, B., "IPv6 RA Options for Next Hop Routes",
draft-sarikaya-6man-next-hop-ra-02 (work in progress),
June 2014.
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-petrescu-autoconf-ra-based-routing-04.txt to
draft-petrescu-autoconf-ra-based-routing-05.txt:
o Added a reference and brief review of draft
[I-D.sarikaya-6man-next-hop-ra].
From draft-petrescu-autoconf-ra-based-routing-03.txt to
draft-petrescu-autoconf-ra-based-routing-04.txt:
o Added a reference to a new draft [I-D.pfister-moving-net-autoconf]
describing a similar idea, but with a different encoding and an
Petrescu, et al. Expires January 23, 2015 [Page 16]
Internet-Draft RA-based Routing July 2014
expansion possibility beyond a single link between vehicles.
From draft-petrescu-autoconf-ra-based-routing-02.txt to
draft-petrescu-autoconf-ra-based-routing-03.txt:
o Added explanatory text to the case where the ULA prefixes are
generated based on a Vehicular Identification Number (VIN).
From draft-petrescu-autoconf-ra-based-routing-01.txt to
draft-petrescu-autoconf-ra-based-routing-02.txt:
o Added explanatory text to the case where several vehicles are in a
Fixed Scene about the use of random delay before sending special
RAs.
o Added explanations about MNP exchange between vehicles in the case
ULA prefixes are used.
o Updated the authorship.
o Added a reference to RFC4193 and RFC4291.
o Updated the example IPv6 addresses to use the ULA prefixes.
From draft-petrescu-autoconf-ra-based-routing-00.txt to
draft-petrescu-autoconf-ra-based-routing-01.txt:
o 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.
o Updated the authorship.
o Added a reference to draft-hampel-mext-ro-without-ha-00 and short
explanatory text, in the Introduction.
o Updated the example IPv6 addresses to use the Documentation Prefix
2001:db8:: instead of the real 2001:1::.
From draft-petrescu-autoconf-ra-based-routing-00.txt to:
o changed.
Petrescu, et al. Expires January 23, 2015 [Page 17]
Internet-Draft RA-based Routing July 2014
Authors' Addresses
Alexandru Petrescu
CEA
CEA, LIST, Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, Essonne F-91191
France
Phone: +33 0169089223
Email: alexandru.petrescu@cea.fr
Christophe Janneteau
CEA
CEA, LIST, Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, Essonne F-91191
France
Phone: +33 0169089182
Email: christophe.janneteau@cea.fr
Nicolas Demailly
iXXi
1 Avenue Montaigne, Immeuble Central 4
Noisy-le-Grand F-93160
France
Email: nicolas.demailly@ixxi.biz
Sofiane Imadali
CEA
CEA, LIST, Communicating Systems Laboratory, Point Courrier 173
Gif-sur-Yvette, Essonne F-91191
France
Phone: +33 0169080727
Email: sofiane.imadali@cea.fr
Petrescu, et al. Expires January 23, 2015 [Page 18]
