| Network Working Group | A. Petrescu |
| Internet-Draft | C. Janneteau |
| Intended status: Standards Track | CEA |
| Expires: May 12, 2013 | N. Demailly |
| iXXi | |
| S. Imadali | |
| CEA | |
| November 08, 2012 |
Router Advertisements for Routing between Moving Networks
draft-petrescu-autoconf-ra-based-routing-03.txt
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).
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 May 12, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 "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.
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.
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.
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.
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-+
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) |
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) |
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
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.
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:
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.
The message exchange for the scenario of simultaneous power-up of 3 MRs is pictured in the diagram below:
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) |
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----------------->|
| | |
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) 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. |
| | |
Router Advertisement is a message format defined in [RFC4861] as an ICMPv6 message. The document [RFC5175] proposes an option for RA extensibility: IPv6 Router Advetisement Flags Option. We propose to reserve bit 16 for Mobile Network Prefixes.
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
IANA no action.
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.
| [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. |
| [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. |
| [I-D.jhlee-mext-mnpp] | Tsukada, M, Ernst, T and J Lee, "Mobile Network Prefix Provisioning", Internet-Draft draft-jhlee-mext-mnpp-00, October 2009. |
| [I-D.petrescu-manemo-nano] | Petrescu, A and C Janneteau, "The NANO Draft (Scene Scenario for Mobile Routers and MNP in RA)", Internet-Draft draft-petrescu-manemo-nano-00, March 2007. |
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-02.txt to draft-petrescu-autoconf-ra-based-routing-03.txt:
From draft-petrescu-autoconf-ra-based-routing-01.txt to draft-petrescu-autoconf-ra-based-routing-02.txt:
From draft-petrescu-autoconf-ra-based-routing-00.txt to draft-petrescu-autoconf-ra-based-routing-01.txt:
From draft-petrescu-autoconf-ra-based-routing-00.txt to: