idnits 2.17.1 draft-petrescu-autoconf-ra-based-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (July 5, 2010) is 5043 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3971' is mentioned on line 470, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AUTOCONF A. Petrescu 3 Internet-Draft C. Janneteau 4 Intended status: Standards Track CEA 5 Expires: January 6, 2011 July 5, 2010 7 Router Advertisements for Routing between Moving Networks 8 draft-petrescu-autoconf-ra-based-routing-00.txt 10 Abstract 12 This draft specifies extensions to the ICMPv6 Router Advertisement 13 messages and processing. Traditionally, prefixes contained in RAs 14 are used for on-link determination, on-link address auto- 15 configuration, but not for path setup towards multi-hop destinations. 16 The extensions proposed here still rely on RAs being communicated on 17 a single link (not across several IP hops), but upon RA reception the 18 prefixes are installed in the routing table; they are thus used for 19 forwarding packets further than a single link (multi IP hop). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Operation on a Mobile Router . . . . . . . . . . . . . . . 4 60 3.3. Message Exchange . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Message Formats . . . . . . . . . . . . . . . . . . . . . 9 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 68 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 This draft specifies extensions to the ICMPv6 Router Advertisement 74 messages and processing. Traditionally, prefixes contained in RAs 75 are used for on-link determination, on-link address auto- 76 configuration, but not for path setup towards multi-hop destinations. 77 The extensions proposed here still rely on RAs being communicated on 78 a single link (not across several IP hops), but upon RA reception the 79 prefixes are installed in the routing table; they are thus used for 80 forwarding packets further than a single link (multi IP hop). 82 We present the message exchange diagrams, message formats and 83 algorithm executed by a node. The scenarios implying route addition 84 are: simultaneous power-up of 3 Mobile Routers, arrival of a MR in a 85 zone where other MRs are present; and scenarios for route deletion: 86 timeout expiration of route entry, and explicit deletion of route 87 entry. 89 These RA extensions are intended for path establishment between LFNs 90 in separate moving networks. The Mobile Routers in charge of moving 91 networks exchange their prefixes (with RAs), and set up their routing 92 tables. 94 The mechanism presented in this draft is an evolution of an earlier 95 work [I-D.petrescu-manemo-nano]. This document adds the behaviour 96 for MR arrival at a zone where other MRs are present, and the 97 behaviour for route deletion. 99 A similar mechanism is presented in "Mobile Network Prefix 100 Provisioning" [I-D.jhlee-mext-mnpp]. The 'MNPP' draft addresses a 101 specific need of inter-connecting vehicular networks; it considers 102 use cases with or without fixed Access Point (infrastructure-based 103 and infrastructure-less scenarios). In this draft we do not consider 104 the use of an Access Point, neither the infrastructure-based 105 scenario. On another hand, this draft describes additional route 106 deletion scenarios, whereas the MNPP draft doesn't. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 Mobile Router (MR) - a Mobile Router. 116 Mobile Network Prefix (MNP) - the Mobile Network Prefix is 117 topologically correct on the ingress interface of a Mobile Router. 119 Egress interface of MR - the interface sending the special Router 120 Advertisements to other egress interface of other Mobile Routers (by 121 this draft's recommendation). 123 Ingress interface of MR - the interface towards the Local Fixed Nodes 124 in the moving network and on which the Mobile Network Prefix (MNP) is 125 topologically correct. 127 3. Protocol 129 3.1. Topology 131 These RA protocol extensions were conceived in a context of vehicular 132 networks. It was considered that a vehicle contains a moving 133 network. A moving network is composed of one Mobile Router (MR) and 134 several Local Fixed Nodes (LFNs). The MR has one egress interface 135 and one ingress interface. The egress interface is used to connect 136 to other vehicles whereas the ingress interface connects to the LFNs 137 in the vehicle. 139 For example, two moving networks connecting via their egress 140 interfaces are depicted below: 142 Vehicle 1 Vehicle 2 144 egress| |egress 145 ---- ---- ---- ---- ---- ---- 146 | LFN| |LFN | | MR | | MR | |LFN | |LFN | 147 ---- ---- ---- ---- ---- ---- 148 | | ingress| |ingress | | 149 --------------------- --------------------- 150 2001:1::/24 2001:2::/24 152 In this figure, the Mobile Network Prefix (MNP) deployed in vehicle 1 153 is 2001:1::/24, for example. The problem is how to establish IP 154 paths between the LFNs between the two vehicles; initially the MR in 155 one vehicle only knows about the MNP in its own vehicle. 157 3.2. Operation on a Mobile Router 159 We propose to use a special kind of prefixes in the Router 160 Advertisements. MR sends RA on its egress interface. A receiving MR 161 installs the pair MNP-LL in its forwarding information base (routing 162 table, destination cache, tbd). 164 Each Mobile Router maintains a forwarding information structure that 165 contains entries of the form: 167 o Mobile Network Prefix 169 o Gateway address 171 o Lifetime 173 o Name of outgoing interface 175 o Optionally link-layer address of Gateway 177 This data structure is managed mainly at the reception of the special 178 Router Advertisements, and when timers expire. This structure can be 179 implemented as part of the Destination Cache, Binding Cache, Routing 180 Table or Forwarding Information Base. 182 We present more details of the MR operation in the following section. 184 3.3. Message Exchange 186 The message exchange for the scenario of simultaneous power-up of 3 187 MRs is pictured in the diagram below: 189 MR1 MR2 MR3 190 | | | 191 | MLD REPORT (LL1) | | 192 |----------------->|----------------->|multicast 193 | |MLD REPORT (LL3) | 194 |<-----------------|<-----------------| 195 | MLD|REPORT (LL2) | 196 |<-----------------|----------------->| 197 | | | 198 | Special RA | | 199 |----------------->|----------------->| 200 | (MNP1-LL1) | | 201 | | Special RA | 202 |<-----------------|<-----------------| 203 | | (MNP3-LL3) | 204 | | | 205 | Special|RA | 206 |<-----------------|----------------->| 207 | (MNP2-LL2) | 209 o All Mobile Routers connect their egress interface with a wireless 210 MAC protocol, for example 802.11 MAC. We consider mainly the case 211 where the "ad-hoc" mode is used; we do not consider the presence 212 of an Access Point - the two moving networks should be able to 213 connect to each other without the use of fixed Access Points. 215 o Following link-layer successful connectivity, each Mobile Router 216 joins the all-routers multicast address on the egress interface 217 (typically using a link-local address, pictured as LL1). 219 o Each Mobile Router multicasts special RAs on the egress interface, 220 containing the Mobile Network Prefix that is assigned to its 221 moving network. 223 o When receiving the special RA from another MR, a MR parses the 224 packet for the link-local address of the sending MR, for the MNP 225 sent by that MR and for the lifetime. It then installs the 226 corresponding entry into the data structure mentioned earlier. 228 o Before leaving the Fixed Scene, a Mobile Router sends another 229 special RA to all routers this time informing them that the MNP- 230 linklocaladdress pair is no longer present at the scene (lifetime 231 0 as per [RFC4191]), so the other routers delete the corresponding 232 route. It could also courteously multicast a MLD REPORT to leave 233 the all-routers multicast group, if necessary. 235 o Operation of the Mobile Router when forwarding packets (after 236 installation of the MNP-ll route) is similar to that of any 237 router: for each packet not addressed to itself, longest-prefix 238 match the destination address of the packet to an entry in the 239 table, select the 'gateway' address, solicit that neighbour's MAC 240 address and put the received MAC address in the link-layer dst 241 address then send it. 243 With this mechanism, the various LFNs in the moving networks are 244 capable to exchange IP messages, routed by two Mobile Routers each 245 time. 247 For faster discovery of the Mobile NEtwork Prefixes of the other 248 Mobile Routers, a certain Mobile Router can send a special Router 249 Solicitation right after joining the scene. 251 For the scenario of arrival of an MR in a zone where other MRs are 252 present, the message exchange diagram is depicted below: 254 MR1 MR2 MR3 255 | | | 256 | RA3 (MNP3-LL3) | 257 |<-----------------o------------------| 258 | MLD "JOIN" | 259 |<-----------------o------------------| 260 | RS | | 261 |<-----------------o------------------| 262 | | | 263 | RA1 (MNP1-LL1) | 264 |------------------o----------------->| 265 | | | 266 | | RA2 (MNP2-LL2) | 267 | o----------------->| 268 | | | 270 The arriving MR is the one using the Mobile Router MR3. MR1 and MR2 271 have already exchanged their respective routes using the message 272 exchange presented in the previous scenario. The algorithm executed 273 by MR3 is the following: (1) Send an RA containing the prefix(es) 274 allocated to its subnets to which the ingress interfaces are 275 connected (2) "Join" the all-routers multicast address with link- 276 scope, on its egress interface (3) Send a Router Solicitation (RS) on 277 its egress interface requesting RAs from MR1 and MR2 (4) Receive 278 their special RAs: RA1 and RA2 (5) For each received RA, extract the 279 source address and the prefixes and insert the corresponding number 280 of routing table entries; these entries will help reach the LFNs in 281 the moving networks of MR1 and MR2. 283 For route deletion, we consider two scenarios: timeout expiration of 284 route entry, and explicit deletion of route entry. The following 285 diagram depicts timeout expiration of a route entry: 287 MR1 MR2 MR3 288 | | | \ 289 | | | | 290 | | | | 291 | | | > timeout 292 | | | | 293 | RS | | | 294 |<-----------------o------------------| / deletion 295 | | | \ 296 | RA1 (MNP1-LL1) | | 297 |------------------o----------------->| | 298 | | | > renewal 299 | | RA2 (MNP2-LL2) | |(eventually) 300 | o----------------->| | 301 | | | / 303 This first scenario for deleting a routing table entry consists in 304 associating a timeout value on each entry present in the routing 305 table. Such an entry typically contains the destination prefix, the 306 IP address of the next hop gateway and eventually the interface name. 307 The new timeout value is obtained from the "Lifetime" field of the 308 RA. With this value, each MR executes the following algorithm for 309 each entry present in its routing table: (1) Set variable lt to the 310 contents of the timeout value of the routing table entry (2) 311 Decrement lt (3) Wait 1 milisecond (4) If lt is different than 0 jump 312 to step 2, otherwise jump to step 5 (5) Delete this entry (6) Send an 313 RS to the next-hop IP address of this routing table entry (7) If an 314 RA is received then re-insert the routing table entry. 316 The second scenario for deleting routing table entries consists in an 317 explicit indication by a Mobile Router to other Mobile Routers about 318 its intention to quit the subnet, instructing them to remove the 319 routing table entries relative to its subnets (their MNPs: Mobile 320 Network Prefixes). The explicit indication is part of the same 321 special Router Advertisement. In practice, this effect could be 322 achieved in two different ways: either specify a 'D' flag for a 323 certain MNP, or alternatively use a lifetime '0' attached to same MNP 324 ('0' meaning that the deletion request is immediate). 326 The message exchange for explicit deletion is depicted in the figure 327 below. The Mobile Router MR1 sends RA1 containing the indication for 328 immediate deletion (flag 'D', or lifetime '0') and the mobile network 329 prefix MNP1. Upon receipt of this message, MR2 and MR3 search their 330 respective routing tables for the MNP1 and then delete these routing 331 table entries. 333 MR1 MR2 MR3 334 | | | 335 | RA1 (MNP1) | 336 |------------------o----------------->| 337 | ('D' flag or '0' lifetime) | 338 | | | 339 | | | 340 | | Upon reception of| 341 | |this RA, MR2 and 3| 342 | |delete their routes 343 | |for MNP1 from | 344 | |their routing | 345 | |tables. | 346 | | | 348 3.4. Message Formats 350 Router Advertisement is a message format defined in [RFC4861] as an 351 ICMPv6 message. The document [RFC5175] proposes an option for RA 352 extensibility: IPv6 Router Advetisement Flags Option. We propose to 353 reserve bit 16 for Mobile Network Prefixes. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Length |M| Bit fields available ... 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 ... for assignment | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 'M' - Mobile Network Prefix present. Set to 1 if this Router 364 Advertisement contains a Mobile Network Prefix. 366 If the RA Flags Option contais the flag M, and set to 1, then the 367 Router Advertisement MUST contain a Route Information Option 368 [RFC4191] followed optionally by a Source-Link Layer Address Option 369 [RFC4861]. (If this SLLAO option is used then it avoids the 370 necessity of doing NS/NA exchange for the link-local address of the 371 Gateway entry in the data structure mentioned earlier.) 373 A complete diagram of the Router Advertisement is presented in the 374 figure below: 376 Base Header (RFC 2460) 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |Version| Traffic Class | Flow Label | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Payload Length | Next Header | Hop Limit | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 + + 384 | | 385 + Source Address + 386 | | 387 + + 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 + + 392 | | 393 + Destination Address + 394 | | 395 + + 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 RA (RFC 4861) 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Code | Checksum | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Reachable Time | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Retrans Timer | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 IPv6 Router Advetisement Flags Option (RFC 5175) 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length |M| Bit fields available ... 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 ... for assignment | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Route Information Option (RFC 4191) 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Route Lifetime | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Prefix (Variable Length) | 421 . . 422 . . 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 SLLAO (RFC 4861) 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | Link-Layer Address ... 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Source Address 432 IPv6 Link Layer Address of sending MR. To be installed as 433 the Gateway address in the manemo forwarding information 434 structure. 436 Destination Address 438 IPv6 all-routers multicast address with link-scope. 440 Prf 442 Preference, value 0x09; this route should not be preferred 443 over other default routes. 445 Prefix (in Router Information Option) 447 The Mobile Network Prefix of this Mobile Router. 449 Link-Layer Address (optional) 451 Link-layer address of the egress interface of the MR. The 452 receiving MR can use this address for sending packets to the 453 MR that advertises a certain MNP. 455 A Mobile Router MUST not include Prefix Information Options [RFC4861] 456 into the special Router Advertisements so that the receiving Mobile 457 Routers don't auto-configure addresses based on these prefixes. 459 A Mobile Router MUST NOT auto-configure an address derived from the 460 Mobile Network Prefix found within a received special Router 461 Advertisement. 463 4. Security Considerations 465 RA security. 467 It is of utmost importance that the Mobile Routers exchange the 468 special Router Advertisements securely. 470 SeND [RFC3971] permits to bind an address to a public key. But not a 471 prefix. This may involve concepts of the prefix-ownership problem 472 space. 474 It is necessary to build a threat model for this scenario and 475 mechanism, analyze the security tools offered by SeND and identify 476 the potential risks and their mitigation. 478 In some cases it is possible that a moving network is connected to 479 the Internet, in addition to being connected to other moving 480 networks. If so, it may be advantageous to update PKI certificates, 481 or similar operation, in order to ensure a more secure connectivity 482 to other moving networks. 484 Some kinds of link layers used for establishing the link connectivity 485 between the egress interfaces (e.g. IEEE 802.11b) offer several 486 means of authentication and confidentiality - at link-layer: e.g. 487 WEP, WPA, more. It may be advantageous to make use of these secure 488 link-layer mechanisms. 490 5. IANA Considerations 492 IANA no action. 494 6. Acknowledgements 496 The authors would like to thank people who contributed stimulating 497 discussion on the manemo@mobileip.jp list during November 2006 to 498 February 2007: Pascal Thubert, Ryuji Wakikawa, Jim Bound, Jari Arkko, 499 Roberto Baldessari, Ben McCarthy, Teco Boot, Nicolas Chevrollier, 500 Jean Lorchat, Fred Templin, Carlos Jesus Bernardos Cano, Thierry 501 Ernst, Bryan McLaughlin, Theo De Jongh, Thomas Heide Clausen, Lim 502 Hyung Jin, David Binet, Samita Chakrabarti, Shubhranshu, Richard 503 Bernhardt, Martin Dunmore, Emmanuel Baccelli. 505 The authors would like to acknowledge a number of co-workers at 506 Motorola who strongly supported work in this area several years ago. 507 Their names will appear when deemed necessary. 509 Authors would like to thank several interns during July 2009 to 510 September 2010 for their support in implementing, testing and 511 demonstrating the feasibility of the concepts presented in this 512 draft: Maxence Dalmais, Miljan Babovic and Nicolas Gressin. 514 Authors would like to thank Jong-Hyouk Lee for comments on the MEXT 515 WG email list about a similar idea implemented at INRIA. 517 The work presented in this draft was supported in part by the French 518 ANR ("Agence Nationale de la Recherche", fr.) 520 7. References 522 7.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 528 More-Specific Routes", RFC 4191, November 2005. 530 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 531 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 532 September 2007. 534 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 535 Flags Option", RFC 5175, March 2008. 537 7.2. Informative References 539 [I-D.jhlee-mext-mnpp] 540 Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix 541 Provisioning", draft-jhlee-mext-mnpp-00 (work in 542 progress), October 2009. 544 [I-D.petrescu-manemo-nano] 545 Petrescu, A. and C. Janneteau, "The NANO Draft (Scene 546 Scenario for Mobile Routers and MNP in RA)", 547 draft-petrescu-manemo-nano-00 (work in progress), 548 March 2007. 550 Appendix A. ChangeLog 552 The changes are listed in reverse chronological order, most recent 553 changes appearing at the top of the list. 555 From draft-petrescu-autoconf-ra-based-routing-00.txt to: 557 o changed. 559 Authors' Addresses 561 Alexandru Petrescu 562 CEA 563 CEA, LIST, Communicating Systems Laboratory, Point Courrier 94 564 Gif-sur-Yvette, Essonne F-91191 565 France 567 Phone: +33 0169089223 568 Email: alexandru.petrescu@cea.fr 570 Christophe Janneteau 571 CEA 572 CEA, LIST, Communicating Systems Laboratory, Point Courrier 94 573 Gif-sur-Yvette, Essonne F-91191 574 France 576 Phone: +33 0169089182 577 Email: alexandru.petrescu@cea.fr