idnits 2.17.1 draft-petrescu-autoconf-ra-based-routing-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3844 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 583, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Petrescu 3 Internet-Draft C. Janneteau 4 Intended status: Standards Track CEA 5 Expires: April 20, 2014 N. Demailly 6 iXXi 7 S. Imadali 8 CEA 9 October 17, 2013 11 Router Advertisements for Routing between Moving Networks 12 draft-petrescu-autoconf-ra-based-routing-04.txt 14 Abstract 16 This draft specifies extensions to the ICMPv6 Router Advertisement 17 messages and processing. Traditionally, prefixes contained in RAs 18 are used for on-link determination, on-link address auto- 19 configuration, but not for path setup towards multi-hop destinations. 20 The extensions proposed here still rely on RAs being communicated on 21 a single link (not across several IP hops), but upon RA reception the 22 prefixes are installed in the routing table; they are thus used for 23 forwarding packets further than a single link (multi IP hop). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 20, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Communication between Security Vehicle and RATP Vehicle . 4 63 3.2. RATP Vehicle (bus) Approaching a Bus Stop . . . . . . . . 5 64 3.3. Visualizing Bus Stop Prior to Arrival . . . . . . . . . . 5 65 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Operation on a Mobile Router . . . . . . . . . . . . . . . 7 68 4.3. Message Exchange . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Message Formats . . . . . . . . . . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 This draft specifies extensions to the ICMPv6 Router Advertisement 82 messages and processing. Traditionally, prefixes contained in RAs 83 are used for on-link determination, on-link address auto- 84 configuration, but not for path setup towards multi-hop destinations. 85 The extensions proposed here still rely on RAs being communicated on 86 a single link (not across several IP hops), but upon RA reception the 87 prefixes are installed in the routing table; they are thus used for 88 forwarding packets further than a single link (multi IP hop). 90 We present the message exchange diagrams, message formats and 91 algorithm executed by a node. The scenarios implying route addition 92 are: simultaneous power-up of 3 Mobile Routers, arrival of a MR in a 93 zone where other MRs are present; and scenarios for route deletion: 94 timeout expiration of route entry, and explicit deletion of route 95 entry. 97 These RA extensions are intended for path establishment between LFNs 98 in separate moving networks. The Mobile Routers in charge of moving 99 networks exchange their prefixes (with RAs), and set up their routing 100 tables. The exchanged prefixes scopes are global [RFC4291] or local 101 [RFC4193]. In practice, applications may treat "Unique Local 102 Addresses" [RFC4193] as global scoped addresses. 104 The mechanism presented in this draft is an evolution of an earlier 105 work [I-D.petrescu-manemo-nano]. This document adds the behaviour 106 for MR arrival at a zone where other MRs are present, and the 107 behaviour for route deletion. 109 A similar mechanism is presented in "Routers auto-configuration using 110 Route Information Option from ICMPv6 Router Advertisements" 111 [I-D.pfister-moving-net-autoconf]. This draft uses a rather 112 different encoding mechanism in the Router Advertisement. It uses an 113 available bit in the Router Information Option (RIO) option - the bit 114 'M' - instead of using the IPv6 Router Advertisement Flags Option. 115 Additionally, it reserves 2 bits named 'R' for a future extension of 116 this mechanism, that may involve more than just one link. 118 A similar mechanism is presented in "Mobile Network Prefix 119 Provisioning" [I-D.jhlee-mext-mnpp]. The 'MNPP' draft addresses a 120 specific need of inter-connecting vehicular networks; it considers 121 use cases with or without fixed Access Point (infrastructure-based 122 and infrastructure-less scenarios). In this draft we do not consider 123 the use of an Access Point, neither the infrastructure-based 124 scenario. On another hand, this draft describes additional route 125 deletion scenarios, whereas the MNPP draft doesn't. 127 Communicating directly between two Mobile Routers, using their egress 128 interfaces, and without access to infrastructure can be considered as 129 Route Optimization: traffic between LFNs of different moving networks 130 is avoiding reaching the respective Home Agents (presumably placed in 131 the infrastructure). Whereas this RA-based work is not explicitely 132 addressing Route Optimization, the effect of updating routing tables 133 can be considered to be so; such an effect can be also achieved by 134 extensions to the Mobile IPv6 protocol, as is suggested, for example, 135 by a recent Internet Draft titled "Mobile IPv6 Route Optimization 136 without Home Agent", authored by G. Hampel and T. Klein, named 137 draft-hampel-mext-ro-without-ha-00, and posted on February 23rd, 138 2011. It proposes extensions to Mobile IPv6 protocol to conduct 139 Route Optimization without Home Agent, in particular by introducing a 140 concept of virtual home link and virtual home address. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 Mobile Router (MR) - a Mobile Router. 150 Mobile Network Prefix (MNP) - the Mobile Network Prefix is 151 topologically correct on the ingress interface of a Mobile Router. 153 Egress interface of MR - the interface sending the special Router 154 Advertisements to other egress interface of other Mobile Routers (by 155 this draft's recommendation). 157 Ingress interface of MR - the interface towards the Local Fixed Nodes 158 in the moving network and on which the Mobile Network Prefix (MNP) is 159 topologically correct. 161 3. Use-cases 163 Several use-cases in the context of a City public transportation may 164 take advantage of direct communications between vehicles (without 165 infrastructure), or between a vehicle and a bus stop. 167 3.1. Communication between Security Vehicle and RATP Vehicle 169 The environment consists of a Security Vehicle (such as public 170 safety) and a RATP Vehicle (a bus). The goal: during an incident 171 happenning within the bus, use a webcam to inform the security agents 172 (in the security vehicle) about the ongoing event developments. The 173 use-case: a bus is driven along a typical scheduled drive. A 174 passenger aggression incident is declared within bus. The driver 175 silently triggers the red-button alarm. The security vehicle 176 approaches bus and agents query the live video feed sent by the bus 177 webcam. This is illustrated in the following figure: 179 |wifi wifi\ 180 +------------+-+ \/--------\_ 181 | bus(webcam)| | car(agent)| 182 +-O-------O--+ +-o-------o-+ 184 3.2. RATP Vehicle (bus) Approaching a Bus Stop 186 The environment consists of an RATP vehicle (a typical public 187 transportation bus) and a bus stop equipped of a WiFi Access Point. 188 The goal: augment the precision of waiting time reporting to 189 passenger waiting at the bus stop. Currently, the waiting time is 190 reported on a display at the bus stop; its precision is in the order 191 of 1-2 minutes (i.e. it may happen that the display reports 2minute 192 wait time whereas the bus is actually at 30second distance). The bus 193 is equipped of a GPS receiver. Use-case: the passenger is waiting at 194 the bus stop. S/he scans the wait time reported on the display. 195 When the bus is within a range of 200 meter the display reports 196 "Approaching"; when the bus is within a 25 meter range the display 197 reports ("At the stop"). 199 |wifi wifi\ 200 +------------+-+ \/----------\ 201 | bus(webcam)| | bus stop | 202 +-O-------O--+ | (display) | 204 3.3. Visualizing Bus Stop Prior to Arrival 206 The environments consists of a RATP vehicle and a WiFi station at the 207 bus stop. Goal: ability to access a webcam deployed at the bus stop, 208 which allows the bus driver to see how crowded the stop is and the 209 type of potential passengers. It thus offers the driver the 210 opportunity to plan the fitting of the bus on the arrival ramp. Use- 211 case: the bus approaches the bus stop; the driver sees on the screen 212 the passengers waiting at the stop; the driver notices the presence 213 of a stroller and a wheelchair; the driver prepares the correct 214 arrival at the ramp and extension of the arm serving mobility. 216 |wifi wifi\ 217 +------------+-+ \/----------\ 218 |bus(display)| | bus stop | 219 +-O-------O--+ | (webcam) | 221 4. Protocol 223 4.1. Topology 225 These RA protocol extensions were conceived in a context of vehicular 226 networks. It was considered that a vehicle contains a moving 227 network. A moving network is composed of one Mobile Router (MR) and 228 several Local Fixed Nodes (LFNs). The MR has one egress interface 229 and one ingress interface. The egress interface is used to connect 230 to other vehicles whereas the ingress interface connects to the LFNs 231 in the vehicle. 233 For example, two moving networks connecting via their egress 234 interfaces are depicted below: 236 Vehicle 1 Vehicle 2 238 egress| |egress 239 ---- ---- ---- ---- ---- ---- 240 | LFN| |LFN | | MR | | MR | |LFN | |LFN | 241 ---- ---- ---- ---- ---- ---- 242 | | ingress| |ingress | | 243 --------------------- --------------------- 244 2001:db8:1::/40 2001:db8:2::/40 246 In this figure, the Mobile Network Prefix (MNP) deployed in vehicle 1 247 is 2001:db8:1::/40, for example. If ULA addresses are in use inside 248 the vehicles (convenient for communications between a limited set of 249 sites), the above figure prefixes could be, for example: FD78:ADC8: 250 857A::/48 and FDD3:48A5:2D72::/48 for vehicles 1 and 2, respectively. 251 For more information about ULA prefixes generation, please refer to 252 [RFC4193] It is also possible for a MR to generate ULA prefixes based 253 on its Vehicular Identification Number (VIN). The use of VIN numbers 254 to generate ULA prefixes will be detailed in a future draft. The 255 problem is how to establish IP paths between the LFNs between the two 256 vehicles; initially the MR in one vehicle only knows about the MNP in 257 its own vehicle. 259 4.2. Operation on a Mobile Router 261 We propose to use a special kind of prefixes in the Router 262 Advertisements. MR sends RA on its egress interface. A receiving MR 263 installs the pair MNP-LL in its forwarding information base (routing 264 table, destination cache, tbd). 266 Each Mobile Router maintains a forwarding information structure that 267 contains entries of the form: 269 o Mobile Network Prefix 271 o Gateway address 273 o Lifetime 275 o Name of outgoing interface 277 o Optionally link-layer address of Gateway 279 This data structure is managed mainly at the reception of the special 280 Router Advertisements, and when timers expire. This structure can be 281 implemented as part of the Destination Cache, Binding Cache, Routing 282 Table or Forwarding Information Base. 284 We present more details of the MR operation in the following section. 286 4.3. Message Exchange 288 The message exchange for the scenario of simultaneous power-up of 3 289 MRs is pictured in the diagram below: 291 MR1 MR2 MR3 292 | | | 293 | MLD REPORT (LL1) | | 294 |----------------->|----------------->|multicast 295 | |MLD REPORT (LL3) | 296 |<-----------------|<-----------------| 297 | MLD|REPORT (LL2) | 298 |<-----------------|----------------->| 299 | | | 300 | Special RA | | 301 |----------------->|----------------->| 302 | (MNP1-LL1) | | 303 | | Special RA | 304 |<-----------------|<-----------------| 305 | | (MNP3-LL3) | 306 | | | 307 | Special|RA | 308 |<-----------------|----------------->| 309 | (MNP2-LL2) | 311 o All Mobile Routers connect their egress interface with a wireless 312 MAC protocol, for example 802.11 MAC. We consider mainly the case 313 where the "ad-hoc" mode is used; we do not consider the presence 314 of an Access Point - the two moving networks should be able to 315 connect to each other without the use of fixed Access Points. 317 o Following link-layer successful connectivity, each Mobile Router 318 joins the all-routers multicast address on the egress interface 319 (typically using a link-local address, pictured as LL1). 321 o Each Mobile Router multicasts special RAs on the egress interface, 322 containing the Mobile Network Prefix that is assigned to its 323 moving network. A Mobile Router SHOULD wait for a random delay 324 [RFC4861] before sending the special RA. If the first special RA 325 contains a ULA prefix, the next special RAs sent should contain 326 ULA prefixes as well, if available. This is to avoid "mixing" ULA 327 addresses [RFC4193] and global addresses [RFC4291] in the same 328 packet. This is not forbidden though. 330 o When receiving the special RA from another MR, a MR parses the 331 packet for the link-local address of the sending MR, for the MNP 332 sent by that MR and for the lifetime. It then installs the 333 corresponding entry into the data structure mentioned earlier. 335 o Before leaving the Fixed Scene, a Mobile Router sends another 336 special RA to all routers this time informing them that the MNP- 337 linklocaladdress pair is no longer present at the scene (lifetime 338 0 as per [RFC4191]), so the other routers delete the corresponding 339 route. It could also courteously multicast a MLD REPORT to leave 340 the all-routers multicast group, if necessary. This Mobile Router 341 SHOULD wait for a random delay before sending the special RA 342 message. 344 o Operation of the Mobile Router when forwarding packets (after 345 installation of the MNP-ll route) is similar to that of any 346 router: for each packet not addressed to itself, longest-prefix 347 match the destination address of the packet to an entry in the 348 table, select the 'gateway' address, solicit that neighbour's MAC 349 address and put the received MAC address in the link-layer dst 350 address then send it. 352 With this mechanism, the various LFNs in the moving networks are 353 capable to exchange IP messages, routed by two Mobile Routers each 354 time. Longest-prefix match can still be used to take the next hop 355 forwarding decision regardless whether the destination address is 356 global scoped or Unique Local IPv6 address. 358 For faster discovery of the Mobile Network Prefixes of the other 359 Mobile Routers, a certain Mobile Router can send a special Router 360 Solicitation right after joining the scene. A random delay [RFC4861] 361 SHOULD be introduced before sending any RS/RA message in order to 362 prevent RS/RA storms when several Mobile Routers join or leave the 363 Fixed Scene. 365 For the scenario of arrival of an MR in a zone where other MRs are 366 present, the message exchange diagram is depicted below: 368 MR1 MR2 MR3 369 | | | 370 | RA3 (MNP3-LL3) | 371 |<-----------------o------------------| 372 | MLD "JOIN" | 373 |<-----------------o------------------| 374 | RS | | 375 |<-----------------o------------------| 376 | | | 377 | RA1 (MNP1-LL1) | 378 |------------------o----------------->| 379 | | | 380 | | RA2 (MNP2-LL2) | 381 | o----------------->| 382 | | | 384 The arriving MR is the one using the Mobile Router MR3. MR1 and MR2 385 have already exchanged their respective routes using the message 386 exchange presented in the previous scenario. The algorithm executed 387 by MR3 is the following: (1) Send an RA containing the prefix(es) 388 allocated to its subnets to which the ingress interfaces are 389 connected (2) "Join" the all-routers multicast address with link- 390 scope, on its egress interface (3) Send a Router Solicitation (RS) on 391 its egress interface requesting RAs from MR1 and MR2 (4) Receive 392 their special RAs: RA1 and RA2 (5) For each received RA, extract the 393 source address and the prefixes and insert the corresponding number 394 of routing table entries; these entries will help reach the LFNs in 395 the moving networks of MR1 and MR2. 397 For route deletion, we consider two scenarios: timeout expiration of 398 route entry, and explicit deletion of route entry. The following 399 diagram depicts timeout expiration of a route entry: 401 MR1 MR2 MR3 402 | | | \ 403 | | | | 404 | | | | 405 | | | > timeout 406 | | | | 407 | RS | | | 408 |<-----------------o------------------| / deletion 409 | | | \ 410 | RA1 (MNP1-LL1) | | 411 |------------------o----------------->| | 412 | | | > renewal 413 | | RA2 (MNP2-LL2) | |(eventually) 414 | o----------------->| | 415 | | | / 417 This first scenario for deleting a routing table entry consists in 418 associating a timeout value on each entry present in the routing 419 table. Such an entry typically contains the destination prefix, the 420 IP address of the next hop gateway and eventually the interface name. 421 The new timeout value is obtained from the "Lifetime" field of the 422 RA. With this value, each MR executes the following algorithm for 423 each entry present in its routing table: (1) Set variable lt to the 424 contents of the timeout value of the routing table entry (2) 425 Decrement lt (3) Wait 1 milisecond (4) If lt is different than 0 jump 426 to step 2, otherwise jump to step 5 (5) Delete this entry (6) Send an 427 RS to the next-hop IP address of this routing table entry (7) If an 428 RA is received then re-insert the routing table entry. 430 The second scenario for deleting routing table entries consists in an 431 explicit indication by a Mobile Router to other Mobile Routers about 432 its intention to quit the subnet, instructing them to remove the 433 routing table entries relative to its subnets (their MNPs: Mobile 434 Network Prefixes). The explicit indication is part of the same 435 special Router Advertisement. In practice, this effect could be 436 achieved in two different ways: either specify a 'D' flag for a 437 certain MNP, or alternatively use a lifetime '0' attached to same MNP 438 ('0' meaning that the deletion request is immediate). 440 The message exchange for explicit deletion is depicted in the figure 441 below. The Mobile Router MR1 sends RA1 containing the indication for 442 immediate deletion (flag 'D', or lifetime '0') and the mobile network 443 prefix MNP1. Upon receipt of this message, MR2 and MR3 search their 444 respective routing tables for the MNP1 and then delete these routing 445 table entries. 447 MR1 MR2 MR3 448 | | | 449 | RA1 (MNP1) | 450 |------------------o----------------->| 451 | ('D' flag or '0' lifetime) | 452 | | | 453 | | | 454 | | Upon reception of| 455 | |this RA, MR2 and 3| 456 | |delete their routes 457 | |for MNP1 from | 458 | |their routing | 459 | |tables. | 460 | | | 462 4.4. Message Formats 464 Router Advertisement is a message format defined in [RFC4861] as an 465 ICMPv6 message. The document [RFC5175] proposes an option for RA 466 extensibility: IPv6 Router Advertisement Flags Option. We propose to 467 reserve bit 16 for Mobile Network Prefixes. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Type | Length |M| Bit fields available ... 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 ... for assignment | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 'M' - Mobile Network Prefix present. Set to 1 if this Router 478 Advertisement contains a Mobile Network Prefix. 480 If the RA Flags Option contais the flag M, and set to 1, then the 481 Router Advertisement MUST contain a Route Information Option 482 [RFC4191] followed optionally by a Source-Link Layer Address Option 483 [RFC4861]. (If this SLLAO option is used then it avoids the 484 necessity of doing NS/NA exchange for the link-local address of the 485 Gateway entry in the data structure mentioned earlier.) 487 A complete diagram of the Router Advertisement is presented in the 488 figure below: 490 Base Header (RFC 2460) 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |Version| Traffic Class | Flow Label | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Payload Length | Next Header | Hop Limit | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | 497 + + 498 | | 499 + Source Address + 500 | | 501 + + 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | | 505 + + 506 | | 507 + Destination Address + 508 | | 509 + + 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 RA (RFC 4861) 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Code | Checksum | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Reachable Time | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Retrans Timer | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 IPv6 Router Advetisement Flags Option (RFC 5175) 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type | Length |M| Bit fields available ... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 ... for assignment | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Route Information Option (RFC 4191) 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Route Lifetime | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Prefix (Variable Length) | 535 . . 536 . . 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 SLLAO (RFC 4861) 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length | Link-Layer Address ... 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Source Address 545 IPv6 Link Layer Address of sending MR. To be installed as 546 the Gateway address in the manemo forwarding information 547 structure. 549 Destination Address 551 IPv6 all-routers multicast address with link-scope. 553 Prf 555 Preference, value 0x09; this route should not be preferred 556 over other default routes. 558 Prefix (in Router Information Option) 560 The Mobile Network Prefix of this Mobile Router. 562 Link-Layer Address (optional) 564 Link-layer address of the egress interface of the MR. The 565 receiving MR can use this address for sending packets to the 566 MR that advertises a certain MNP. 568 A Mobile Router MUST NOT include Prefix Information Options [RFC4861] 569 into the special Router Advertisements so that the receiving Mobile 570 Routers don't auto-configure addresses based on these prefixes. 572 A Mobile Router MUST NOT auto-configure an address derived from the 573 Mobile Network Prefix found within a received special Router 574 Advertisement. 576 5. Security Considerations 578 RA security. 580 It is of utmost importance that the Mobile Routers exchange the 581 special Router Advertisements securely. 583 SeND [RFC3971] permits to bind an address to a public key. But not a 584 prefix. This may involve concepts of the prefix-ownership problem 585 space. 587 It is necessary to build a threat model for this scenario and 588 mechanism, analyze the security tools offered by SeND and identify 589 the potential risks and their mitigation. 591 In some cases it is possible that a moving network is connected to 592 the Internet, in addition to being connected to other moving 593 networks. If so, it may be advantageous to update PKI certificates, 594 or similar operation, in order to ensure a more secure connectivity 595 to other moving networks. 597 Some kinds of link layers used for establishing the link connectivity 598 between the egress interfaces (e.g. IEEE 802.11b) offer several 599 means of authentication and confidentiality - at link-layer: e.g. 600 WEP, WPA, more. It may be advantageous to make use of these secure 601 link-layer mechanisms. 603 6. IANA Considerations 605 IANA no action. 607 7. Acknowledgements 609 The authors would like to thank people who contributed stimulating 610 discussion on the manemo@mobileip.jp list during November 2006 to 611 February 2007: Pascal Thubert, Ryuji Wakikawa, Jim Bound, Jari Arkko, 612 Roberto Baldessari, Ben McCarthy, Teco Boot, Nicolas Chevrollier, 613 Jean Lorchat, Fred Templin, Carlos Jesus Bernardos Cano, Thierry 614 Ernst, Bryan McLaughlin, Theo De Jongh, Thomas Heide Clausen, Lim 615 Hyung Jin, David Binet, Samita Chakrabarti, Shubhranshu, Richard 616 Bernhardt, Martin Dunmore, Emmanuel Baccelli. 618 The authors would like to acknowledge a number of co-workers at 619 Motorola who strongly supported work in this area several years ago. 620 Their names will appear when deemed necessary. 622 Authors would like to thank several interns during July 2009 to 623 September 2010 for their support in implementing, testing and 624 demonstrating the feasibility of the concepts presented in this 625 draft: Maxence Dalmais, Miljan Babovic and Nicolas Gressin. 627 Authors would like to thank Jong-Hyouk Lee for comments on the MEXT 628 WG email list about a similar idea implemented at INRIA. 630 The work presented in this draft was supported in part by the French 631 ANR ("Agence Nationale de la Recherche", fr.) project named SEAMLESS, 632 which lasted between September 2010 and January 2011. 634 8. References 636 8.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 642 More-Specific Routes", RFC 4191, November 2005. 644 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 645 Addresses", RFC 4193, October 2005. 647 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 648 Architecture", RFC 4291, February 2006. 650 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 651 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 652 September 2007. 654 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 655 Flags Option", RFC 5175, March 2008. 657 8.2. Informative References 659 [I-D.jhlee-mext-mnpp] 660 Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix 661 Provisioning", draft-jhlee-mext-mnpp-00 (work in 662 progress), October 2009. 664 [I-D.petrescu-manemo-nano] 665 Petrescu, A. and C. Janneteau, "The NANO Draft (Scene 666 Scenario for Mobile Routers and MNP in RA)", 667 draft-petrescu-manemo-nano-00 (work in progress), 668 March 2007. 670 [I-D.pfister-moving-net-autoconf] 671 Pfister, P. and A. Petrescu, "Routers auto-configuration 672 using Route Information Option from ICMPv6 Router 673 Advertisements", draft-pfister-moving-net-autoconf-00 674 (work in progress), July 2013. 676 Appendix A. ChangeLog 678 The changes are listed in reverse chronological order, most recent 679 changes appearing at the top of the list. 681 From draft-petrescu-autoconf-ra-based-routing-03.txt to 682 draft-petrescu-autoconf-ra-based-routing-04.txt: 684 o Added a reference to a new draft [I-D.pfister-moving-net-autoconf] 685 describing a similar idea, but with a different encoding and an 686 expansion possibility beyond a single link between vehicles. 688 From draft-petrescu-autoconf-ra-based-routing-02.txt to 689 draft-petrescu-autoconf-ra-based-routing-03.txt: 691 o Added explanatory text to the case where the ULA prefixes are 692 generated based on a Vehicular Identification Number (VIN). 694 From draft-petrescu-autoconf-ra-based-routing-01.txt to 695 draft-petrescu-autoconf-ra-based-routing-02.txt: 697 o Added explanatory text to the case where several vehicles are in a 698 Fixed Scene about the use of random delay before sending special 699 RAs. 701 o Added explanations about MNP exchange between vehicles in the case 702 ULA prefixes are used. 704 o Updated the authorship. 706 o Added a reference to RFC4193 and RFC4291. 708 o Updated the example IPv6 addresses to use the ULA prefixes. 710 From draft-petrescu-autoconf-ra-based-routing-00.txt to 711 draft-petrescu-autoconf-ra-based-routing-01.txt: 713 o Added a section with three Use-cases issued from a public 714 transportation setting: communications between a security vehicle 715 and a bus, between bus and bus stop and vice-versa. 717 o Updated the authorship. 719 o Added a reference to draft-hampel-mext-ro-without-ha-00 and short 720 explanatory text, in the Introduction. 722 o Updated the example IPv6 addresses to use the Documentation Prefix 723 2001:db8:: instead of the real 2001:1::. 725 From draft-petrescu-autoconf-ra-based-routing-00.txt to: 727 o changed. 729 Authors' Addresses 731 Alexandru Petrescu 732 CEA 733 CEA, LIST, Communicating Systems Laboratory, Point Courrier 173 734 Gif-sur-Yvette, Essonne F-91191 735 France 737 Phone: +33 0169089223 738 Email: alexandru.petrescu@cea.fr 739 Christophe Janneteau 740 CEA 741 CEA, LIST, Communicating Systems Laboratory, Point Courrier 173 742 Gif-sur-Yvette, Essonne F-91191 743 France 745 Phone: +33 0169089182 746 Email: christophe.janneteau@cea.fr 748 Nicolas Demailly 749 iXXi 750 1 Avenue Montaigne, Immeuble Central 4 751 Noisy-le-Grand F-93160 752 France 754 Email: nicolas.demailly@ixxi.biz 756 Sofiane Imadali 757 CEA 758 CEA, LIST, Communicating Systems Laboratory, Point Courrier 173 759 Gif-sur-Yvette, Essonne F-91191 760 France 762 Phone: +33 0169080727 763 Email: sofiane.imadali@cea.fr