AUTOCONF                                                     A. Petrescu
Internet-Draft                                              C. Janneteau
Intended status: Standards Track                                     CEA
Expires: January 6, 2011                                    July 5, 2010


       Router Advertisements for Routing between Moving Networks
            draft-petrescu-autoconf-ra-based-routing-00.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 6, 2011.

Copyright Notice

   Copyright (c) 2010 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



Petrescu & Janneteau     Expires January 6, 2011                [Page 1]


Internet-Draft              RA-based Routing                   July 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Operation on a Mobile Router . . . . . . . . . . . . . . .  4
     3.3.  Message Exchange . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Message Formats  . . . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  ChangeLog . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13





























Petrescu & Janneteau     Expires January 6, 2011                [Page 2]


Internet-Draft              RA-based Routing                   July 2010


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 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.


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.



Petrescu & Janneteau     Expires January 6, 2011                [Page 3]


Internet-Draft              RA-based Routing                   July 2010


   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.  Protocol

3.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:1::/24                       2001:2::/24



   In this figure, the Mobile Network Prefix (MNP) deployed in vehicle 1
   is 2001:1::/24, for example.  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.

3.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



Petrescu & Janneteau     Expires January 6, 2011                [Page 4]


Internet-Draft              RA-based Routing                   July 2010


   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.

3.3.  Message Exchange

   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                |
                     |<-----------------|----------------->|



Petrescu & Janneteau     Expires January 6, 2011                [Page 5]


Internet-Draft              RA-based Routing                   July 2010


                     |           (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.

   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-
      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.

   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.

   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.

   For the scenario of arrival of an MR in a zone where other MRs are
   present, the message exchange diagram is depicted below:



Petrescu & Janneteau     Expires January 6, 2011                [Page 6]


Internet-Draft              RA-based Routing                   July 2010


                         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:


















Petrescu & Janneteau     Expires January 6, 2011                [Page 7]


Internet-Draft              RA-based Routing                   July 2010


                 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.





Petrescu & Janneteau     Expires January 6, 2011                [Page 8]


Internet-Draft              RA-based Routing                   July 2010


                         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.           |
                          |                  |                  |


3.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 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:





Petrescu & Janneteau     Expires January 6, 2011                [Page 9]


Internet-Draft              RA-based Routing                   July 2010


     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)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Petrescu & Janneteau     Expires January 6, 2011               [Page 10]


Internet-Draft              RA-based Routing                   July 2010


    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.

   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.


4.  Security Considerations

   RA security.

   It is of utmost importance that the Mobile Routers exchange the
   special Router Advertisements securely.




Petrescu & Janneteau     Expires January 6, 2011               [Page 11]


Internet-Draft              RA-based Routing                   July 2010


   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.


5.  IANA Considerations

   IANA no action.


6.  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.



Petrescu & Janneteau     Expires January 6, 2011               [Page 12]


Internet-Draft              RA-based Routing                   July 2010


   The work presented in this draft was supported in part by the French
   ANR ("Agence Nationale de la Recherche", fr.)


7.  References

7.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.

   [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.

7.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.


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-00.txt to:

   o  changed.








Petrescu & Janneteau     Expires January 6, 2011               [Page 13]


Internet-Draft              RA-based Routing                   July 2010


Authors' Addresses

   Alexandru Petrescu
   CEA
   CEA, LIST, Communicating Systems Laboratory, Point Courrier 94
   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 94
   Gif-sur-Yvette, Essonne  F-91191
   France

   Phone: +33 0169089182
   Email: alexandru.petrescu@cea.fr































Petrescu & Janneteau     Expires January 6, 2011               [Page 14]