idnits 2.17.1 draft-petrescu-nemo-mrha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 18) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7863 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) == Unused Reference: '15' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1421, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-01 ** Obsolete normative reference: RFC 2082 (ref. '3') (Obsoleted by RFC 4822) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2740 (ref. '5') (Obsoleted by RFC 5340) -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-01) exists of draft-ernst-nemo-terminology-00 -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '11') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 == Outdated reference: A later version (-03) exists of draft-kniveton-mobrtr-02 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 1723 (ref. '15') (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 2461 (ref. '19') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3344 (ref. '21') (Obsoleted by RFC 5944) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Petrescu, ed. 2 Document: draft-petrescu-nemo-mrha-00.txt M. Catalina-Gallego 3 Expires: April 2003 C. Janneteau 4 H. Y. Lach 5 A. Olivereau 6 Motorola 8 October 2002 10 Issues in Designing Mobile IPv6 Network Mobility 11 with the MR-HA Bidirectional Tunnel (MRHA) 12 14 Status of this Nemo 16 This document is an Internet-Draft and is in full conformance 17 with all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document presents various issues related to designing a 37 network mobility solution with Mobile IPv6 and the MRHA 38 bidirectional tunnel. Several scenarios are presented with the MR 39 at home and in a visited network, from which an argumentation is 40 made that all routing information is available in the HA (when BR 41 and HA are co-located) or can be communicated by ICMP Redirect 42 (when the BR and HA are separated). This raises questions on when 43 does the adding of more information than the 'R' bit into the 44 Mobile IPv6 BUs is necessary. Other generic issues with an MRHA 45 solution, like link-local addresses in Mobile IPv6, router 46 renumbering, or ND for the MR are presented. Route Optimization 47 and security aspects are only briefly touched. 49 Table of Contents 51 Status of this Memo................................................i 52 Abstract...........................................................i 53 Conventions used in this document..................................1 54 1. Introduction....................................................1 55 1.1 Prior descriptions...........................................3 56 2. Definitions.....................................................3 57 3. Data structures.................................................4 58 4. Description of a Home Network...................................5 59 5. Scenarios.......................................................6 60 5.0 Manual mobile networks.......................................6 61 5.1 Scenarios with co-located HA and BR..........................7 62 5.2 Scenarios with HA and BR separated..........................11 63 5.3 MR Redirects to BR..........................................15 64 6. Informing the HA about the route to MR.........................16 65 6.1 ICMP Redirect from BR to HA.................................16 66 6.2 Static route method.........................................17 67 6.3 Dynamic route method........................................18 68 7. Other Issues...................................................18 69 7.1 Link-local addresses........................................18 70 7.2 MR as an MN.................................................19 71 7.3 Prefix-based routing and host-based routing.................19 72 7.4 Multicast subscriptions of the MR...........................19 73 7.5 Neighbour Discovery for MR..................................19 74 7.6 Separation of routing and mobility for MR...................20 75 7.7 Router Renumbering..........................................20 76 8. Mobile Router behaviour........................................21 77 8.1 CoA Configuration...........................................21 78 8.2 Discovering HA..............................................21 79 8.3 Sending BUs to HA...........................................22 80 8.4 Search order in various tables..............................22 81 9. Home Agent behaviour...........................................22 82 10. Route Optimization............................................22 83 11. Security Considerations.......................................23 84 11.1 Security of the MRHA tunnel................................23 85 11.2 Security for Route Optimization............................23 86 Acknowledgements..................................................24 87 Changes...........................................................24 88 References........................................................24 89 Authors' Addresses................................................26 91 Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in RFC-2119 [1]. 97 1. Introduction 99 This document identifies issues when designing an enhancement of 100 the Mobile IPv6 protocol to support mobile networks. The 101 background is the extensive use of the bidirectional tunnel between 102 MR and HA. The HA acts on behalf of the link-local address of the 103 moving interface of the Mobile Router when the MR is in a foreign 104 network. 106 The Mobile Router is using BUs and BAcks with the Home Agent to 107 maintain the MRHA bidirectional tunnel. The modifications to 108 Mobile IPv6 HA and MN are minimal. The BU format contains, in 109 addition to all Mobile IPv6 fields, an additional bit 'R' that 110 informs the HA that this is a mobile router instead of a mobile 111 host. The 'R' bit is used by the HA to perform certain tasks 112 differently for this home address than if it were a host. 114 Traffic coming from outside the home link, or from other hosts on 115 the home link, and directed to hosts behind the mobile router 116 normally only need to go through the L2 address of the mobile 117 router's correspoinding to its L3 address. With Proxy ND [19], it 118 is the HA that pretends to own MR's L3 address by advertising new 119 associations of of the MR's L3 address to the HA's L2 address, thus 120 intercepting MR's home traffic and forwarding it to the current CoA 121 of the MR. 123 When the MR is in a foreign network, traffic coming from the mobile 124 network and towards anywhere to the Internet, is first forwarded by 125 the MR through the reverse tunnel MRHA to the HA. Then HA 126 decapsulates and forwards to the specific host on the home link or 127 outside the home link. 129 When the MR acts as a mobile host, vanilla Mobile IPv6 is used. MR 130 can send both BUs with the R bit set and without the R bit set. 131 Depending on what is decided for the home address to be like 132 (link-local or other), the HA could deduce both. 134 A nemo solution with the MRHA tunnel should allow for a clean 135 separation between routing maintenance and mobility bindings 136 maintenance. The route maintenance is done unmodified between MR 137 and BR, while the mobility bindings are done unmodified between MR 138 and HA. 140 Much of the argumentation made around routing can be considered as 141 operator, or administrative issues, which seen otherwise can 142 discard some of the conclusions, but not all. 144 The document is organized as follows: the next sections present a 145 description of the home network, where the HA could be co-located 146 with the BR, or separated. Then a set of simple scenarios are 147 presented describing the normal routing behaviour of the MR when it 148 is at home, and the desired behaviour of routing and of ND 149 messaging at home, when the MR is in a foreign network. These 150 scenarios are presented such that they expose the need for new 151 behaviours only in the case where the HA is separated from the BR; 152 otherwise (HA/BR co-located), all routing information is already 153 present in the HA. The following section presents possible 154 approaches for adding to HA routing information related to MR, one 155 based on ICMP Redirects, one based on static or dynamic routes 156 (from previous documents) and a third approach as a slight 157 modifications of dynamic routing where the HA "only listens" to 158 route updates but doesn't advertise. 160 Additional sections present other issues related to maintaining 161 normal MR behaviour when it is not at home (e.g. renumbering or 162 multicast subscriptions) and then detailed behaviour of the HA and 163 of the MR. The Route Optimization problem and the Security 164 Considerations are briefly touched at the end. 166 1.1 Prior descriptions of mobile network support with Mobile IPv6 168 A complete description of the previous proposals to support mobile 169 networks or mobile routers with Mobile IP bi-directional tunnel can 170 not be made here due to space constraints. 172 The closest description to mobile network support in Mobile IPv6 173 with the MRHA tunnel can be found in [13]. The approach described 174 in that document relies on the bidirectional tunnel between MR and 175 HA. The solution proposed is valid for Mobile IPv6 as for Mobile 176 IPv4. The MR and HA behaviours still represent a sensitive 177 departure from the Mobile IPv6 protocol in that MR informs its HA 178 directly about the tunnel interface and dynamically triggers 179 additions of routing table entries in the HA's routing table for 180 the MR's tunnel. In addition, the most recent version of the draft 181 proposes usage of the PSBUs in order to inform the HA about the 182 prefix of the mobile network (thus a combination with the PSBU 183 approach). Moreover, the considerations about dynamic routing in 184 this draft refer only to how dynamic routing would work with a MR, 185 but not about the necessity of running a routing protocol between 186 HA and MR. See sections 6.2 and 6.3 for an overview of the methods 187 presented in these documents. 189 Using PSBUs as proposed in [8] and [13] has many other side-effects 190 not considered until recently. When the mobile network is assigned 191 several prefixes instead of one, then it is not clear whether 192 several BUs are being sent or only one with several prefixes 193 inside. Remark that in the vanilla Mobile IPv6 case, only one CoA 194 can be sent with a BU (the alternative CoA is only an alternative 195 not a substitute). 197 In the Mobile IPv4 case, the network mobility support with the MRHA 198 tunnel has been reported at least by various teams at Cisco [4] and 199 NASA [14]. 201 2. Definitions 203 Many relevant definitions for network mobility with the MRHA (could 204 me spelled emra) tunnel can be found in [9]. In addition to those 205 definitions: 207 MRHA bidirectional tunnel, sometimes referred to as a reverse 208 tunnel. As described in [6], [12], [17], [20]. 210 MIMR: the Mobile Interface of the Mobile Router: the interface that 211 connects MR to the home link and that changes its Care-of Address 212 when away from home. 214 MR_HoA: mobile router's Home Address, or the home address of the 215 MIMR. 217 MNP: mobile network prefix, or the prefix of the link of the mobile 218 network that will move away. Note that in the most general case a 219 single MR may route multiple prefixes, in which case there would be 220 multiples MNPs per one mobile network. 222 FN: fixed node on the home link. It doesn't stand for fixed 223 network. 225 3. Data structures 227 A home agent that supports mobile networks maintains the following 228 structures: destination cache [19], binding cache [12] and routing 229 table [11]. The binding cache is modified from Mobile IPv6, such 230 that. The Home Agent also maintains the MRHA Tunnel Table. 232 A Mobile Router contains an on-link prefix list, a neighbour cache, 233 a destination cache, routing table, a binding update list, a home 234 agents list and so on. 236 Additionally, it contains an MRHA Tunnel Table with the following 237 fields: 238 -interface number 239 -address of the tunnel endpoint corresponding to the mobile 240 router. This is normally a CoA. 241 -address of the tunnel endpoint corresponding to the home 242 agent. This is normally the HA address. 243 -list of entries present in the neighbour cache. 244 -list of entries present in the destination cache. 245 -list of entries present in the prefix list. 246 -list of entries present in the default router list. 247 -list of entries present in every other structure. 249 The idea behind the MRHA tunnel table is to have as little 250 modifications as possible to the other ND and Mobile IPv6 tables 251 such that the MR acts as if it were at home, but across the MR-HA 252 tunnel. 254 All the mechanisms related to ND and classic routing are being 255 subjected to this tunnel table, such as to allow for mobility of 256 the mobile network. One example is to stop doing ND for the home 257 address of the MR's interface that acquired a new CoA. It also 258 prevents the MR to have routing interactions with the visited 259 domain, but it alows it to continue having "normal" routing 260 interactions with its home domain, including exchanging of normal 261 dynamic routing messages, multicast routing messages, ICMP 262 redirects and others. 264 4. Description of a Home Network 266 When designing a NEMO solution with the MRHA tunnel, the first 267 steps are to carefully consider the actual behaviour of the home 268 network when the mobile network is at home, employing normal 269 routing. Then this behaviour should be maintained as much as 270 possible when the MR is not at home (e.g. MR should be able to send 271 redirects through the MRHA tunnel); reciprocically, the normal 272 behaviour of an FR at home should change when that FR is an MR and 273 is at home (e.g. when MR at home, the MRHA tunnel should be torn 274 down). When the MR is in a foreign network, its presence at home 275 is simulated by the HA (as in Mobile IPv6 for hosts). 277 Let us consider a simple case of a home network that supports 278 movement of one of its links. The home network is made up of a 279 home link and a mobile network link, separated by the Mobile 280 Router. The home network is connected to the Internet via the 281 Border Router, as presented in the figure: 282 ---- 283 | FN | 284 ---- 285 | ------- 286 home link -------------------| HA/BR |---> Internet 287 | ------- 288 ---- ----- 289 | MR | | LFN | 290 ---- ----- 291 | | 292 mobile link --------- 294 Current specification for Mobile IPv6 implies that the HA can be 295 either co-located with the BR, or it can act as a separate 296 one-interface machine (this is advantageous for deploying Mobile 297 IPv6 without changing BRs). For mobile networks, the latter mode 298 can be pictured like this: 299 ---- ---- 300 | FN | | HA | 301 ---- ---- 302 | | ---- 303 home link -------------------| BR |------> Internet 304 | ---- 305 ---- ----- 306 | MR | | LFN | 307 ---- ----- 308 | | 309 mobile network link --------- 311 It is assumed that routes outside the home link are managed by BR 312 and MR, either in a static manner (operator fills in routing 313 tables) or dynamic manner (application software partially manages 314 routing tables). Remark that even when the dynamic style is used, 315 it is still true that operator fills initial routing configuration 316 files, where she/he puts the image of the network as being what the 317 operator believes it to be. The dynamic behaviour of routing 318 protocols intervenes when certain links come down or up due to 319 failures, the operator view is no longer true, and the routers 320 manage to find alternative paths. Also, the dynamic behaviour 321 helps obtaining shortest paths over large networks, relying on 322 several local operator's views of smaller sized networks. Addition 323 of mobility should not change this. 325 If static routing is used instead of dynamic routing, then static 326 routes are added manually both on MR and on the BR. When 327 considering adding *static* routes in a *dynamic* manner for 328 prefixes shorter than /128 by Mobile IP, authors of this document 329 realize (in truth, hopefully) that Mobile IP starts using semantics 330 that are traditionally belonging to routing protocols. 332 5. Scenarios 334 For the sake of completetess, we first describe a simple "manual" 335 scenario for mobile networks based on the MRHA tunnel, that exposes 336 relative simplicity, that uses static routing and doesn't use 337 Mobile IP. 339 Then, adding the Mobile IP behaviour, we present detailed scenarios 340 of communication between an FN on the home link and an LFN on the 341 mobile network link and a CN on the Internet, when the mobile 342 network is at home and away from home in a visited network, and 343 when the HA is co-located with the BR and separated from the BR. 344 All in all, 16 simple scenarios are presented. 346 The scenarios where HA is co-located with BR (1 up to 8) expose 347 that there is no need for MR to communicate prefixes to its HA via 348 BUs. In a normal routing function, when the MR is at home, it 349 exchanges routing information with the BR (co-located with the HA) 350 and thus those prefixes are communicated by e.g. RIP or OSPF. When 351 the MR is not at home, this behaviour continues, but through the 352 MRHA tunnel. 354 The scenarios where HA and BR are separated (9 up to 16) expose 355 that HA needs an entry in its routing table in order to be capable 356 of forwarding packets to the MR (when it is not at home). 358 An additional scenario is then presented where MR at home is using 359 ICMP Redirect, a functionality that might be needed even when the 360 MR is not at home. 362 5.0 Manual mobile networks 364 Authors of this draft have experimented with "manual" mobile 365 networks in IPv4, where the addition of routes and tunnels on the 366 MR and on the BR are done manually, by operators talking on the 367 phone. 369 A home network was used that contains about 10 routers and about 12 370 subnets. That home network is connected to the Internet with a BR. 371 All routers have static routes among them. 373 Then, one slice of that home network (the mobile network) 374 containing one "MR", one normal router and 6 subnets, was 375 disconnected from home, and moved across the Atlantic. Once the 376 "MR" was connected on the other side, it was manually configured 377 with a new IPv4 address, mask and default route. Then a tunnel 378 interface and a route were manually set up on the MR, a tunnel 379 interface and a route were manually set up on the BR. All other 380 routes on all other routers where not touched. Mobile IP software 381 was not used. 383 The entire network (the home and the mobile network) looked, and 384 acted, as if the mobile slice were at home. During this, several 385 applications were tested between hosts in the mobile network, hosts 386 in the home network and hosts on the Internet (incidentally, one of 387 the applications was relying on Mobile IPv4 for hosts, but in no 388 relation with the mobile network moving). 390 Again, this "manual" mobile networks scenario was not using any 391 dynamic routing protocol, and the tunnel was not supporting any 392 form of broadcast of multicast. 394 5.1 Scenarios with co-located HA and BR 396 1. FN sends packet to LFN, mobile network home, HA/BR colocated 397 ---- 398 | FN | 399 ---- 400 | ------- 401 home link -------------------| HA/BR |---> Internet 402 | ------- 403 ---- ----- 404 | MR | | LFN | 405 ---- ----- 406 | | 407 mobile link --------- 409 -FN scans its routing table for LFN's address, and finds default 410 route towards BR (if towards MR, see section 6.1). 411 -FN sends NS for L2 address of BR. 412 -BR replies NA. 413 -FN sends packet to BR. 414 -BR scans its routing table for LFN's address, and finds route 415 through MR; 416 -BR sends NS for MR. 417 -MR replies NA with its L2 address. 418 -BR forwards packet to MR and sends ICMP Redirect to FN such that 419 subsequent packets from FN to LFN go straight through MR and not 420 through BR. 421 -MR forwards packet to FN. 423 The sensitive issue exposed here is the way in which initially the 424 packet travels from FN to BR to MR, the dynamic addition of an 425 entry in the routing table of the FN (even if FN doesn't run a 426 routing protocol) and that subsequent packets will not go through 427 BR, but from FN to MR to LFN. 429 2. FN sends packet to LFN, mobile network visits, HA/BR colocated 430 ---- / 431 | FN | / 432 ---- ----------/ 433 | ------- | | 434 ----------------| HA/BR |---| Internet | 435 home link ------- | | 436 ----------\ 437 \ 438 \ ---- Visited link 439 --| AR |------ 440 ---- | 441 | 442 ---- ----- 443 | MR | | LFN | 444 ---- ----- 445 | | 446 --------- 447 mobile net 449 -FN scans its routing table for LFN's address, and finds default 450 route towards BR. 451 -FN sends NS for L2 address of BR. 452 -BR replies NA. 453 -FN sends packet to BR. 454 -BR scans its routing table for LFN's address, and finds route 455 through MR; 456 -BR (being an HA) scans its BC and its routing table and finds it 457 needs to encapsulate this packet towards MR's CoA. 458 -BR encapsulates through the MRHA tunnel to MR's CoA. 459 -MR decapsulates and forwards to LFN. 461 3. LFN sends packet to FN, mobile network home, HA/BR colocated 462 ---- 463 | FN | 464 ---- 465 | ------- 466 home link -------------------| HA/BR |---> Internet 467 | ------- 468 ---- ----- 469 | MR | | LFN | 470 ---- ----- 471 | | 472 mobile link --------- 474 -LFN scans its routing table for FN's address, and finds default 475 route towards MR. 476 -LFN sends NS for L2 address of MR. 477 -MR replies NA. 478 -LFN sends packet to MR. 479 -MR scans its routing table for LFN's address, and finds route 480 'on-link'; 481 -MR sends NS for FN. 482 -FN replies NA with its L2 address. 483 -MR forwards packet to FN. 485 4. LFN sends packet to FN, mobile network visits, HA/BR colocated 486 ---- / 487 | FN | / 488 ---- ----------/ 489 | ------- | | 490 ----------------| HA/BR |---| Internet | 491 home link ------- | | 492 ----------\ 493 \ 494 \ ---- Visited link 495 --| AR |------ 496 ---- | 497 | 498 ---- ----- 499 | MR | | LFN | 500 ---- ----- 501 | | 502 --------- 503 mobile net 505 -LFN scans its routing table for FN's address, and finds default 506 route towards MR. 507 -LFN sends NS for L2 address of MR. 508 -MR replies NA. 509 -LFN sends packet to MR. 510 -MR encapsulates this packet through the MRHA tunnel and sends to 511 HA. 512 -HA receives this packet and decapsulates. 513 -HA scans its routing table for FN's address, and finds route 514 'on-link'; 515 -HA sends NS for FN. 516 -FN replies NA with its L2 address. 517 -HA forwards packet to FN (on behalf of the MR). 519 5. CN sends packet to LFN, mobile network home, HA/BR co-located 520 ---- CN link 521 --| BR1|------ 522 / ---- | 523 / | 524 ----------/ ---- 525 ------- | | | CN | 526 ----------------| HA/BR |---| Internet | ---- 527 | home link ------- | | 528 ---- ----- ----------\ 529 | MR | | LFN | \ 530 ---- ----- \ 531 | | 532 --------- 533 mobile net link 535 -BR receives packet from CN towards LFN. 536 -BR scans its routing table and finds dest through MR. 537 -BR sends NS for L2 address of MR and MR replies NA. 538 -BR forwards packet to MR. 539 -MR forwards packet to LFN. 541 6. CN sends packet to LFN, mobile network visits, HA/BR colocated 543 ---- CN link 544 --| BR1|------ 545 / ---- | 546 / | 547 ----------/ ---- 548 ------- | | | CN | 549 ---| HA/BR |---| Internet | ---- 550 ------- | | 551 ----------\ 552 \ 553 \ ---- Visited link 554 --| AR |------ 555 ---- | 556 | 557 ---- ----- 558 | MR | | LFN | 559 ---- ----- 560 | | 561 --------- 562 mobile net 563 -BR receives packet from CN towards LFN. 564 -BR scans its routing table and finds dest through MR. 565 -BR scans its routing table and its BC and realizes it needs to 566 send this through the MRHA tunnel. 567 -BR sends the packet through the MRHA tunnel to MR. 568 -MR decapsulates and forwards to LFN. 570 (this is sometimes referred to as triangular routing, since the 571 packet from CN to LFN travels artificially through BR) 573 7. LFN sends packet to CN, mobile network home, HA/BR colocated 575 ---- CN link 576 --| BR1|------ 577 / ---- | 578 / | 579 ----------/ ---- 580 ------- | | | CN | 581 ----------------| HA/BR |---| Internet | ---- 582 | home link ------- | | 583 ---- ----- ----------\ 584 | MR | | LFN | \ 585 ---- ----- \ 586 | | 587 --------- 588 mobile net link 590 -MR receives packet from LFN towards CN. 591 -MR scans its routing table to and finds dest through BR. 592 -BR forwards packet to Internet towards CN. 593 -BR1 forwards packet to CN. 595 8. LFN sends packet to CN, mobile network visits, HA/BR colocated 596 ---- CN link 597 --| BR1|------ 598 / ---- | 599 / | 600 ----------/ ---- 601 ------- | | | CN | 602 ---| HA/BR |---| Internet | ---- 603 ------- | | 604 ----------\ 605 \ 606 \ ---- Visited link 607 --| AR |------ 608 ---- | 609 | 610 ---- ----- 611 | MR | | LFN | 612 ---- ----- 613 | | 614 --------- 615 mobile net 616 -MR receives packet from LFN towards CN. 617 -MR scans its tables and finds it needs to send it through the MRHA 618 tunnel. 619 -BR receives this packet, decapsulates and forwards to Internet. 620 -BR1 forwards this packet to CN. 622 (this is sometimes referred to as triangular routing, since the 623 packet from LFN to CN travels artificially through BR) 625 5.2 Scenarios with HA and BR separated 627 9. FN sends packet to LFN, mobile network home, HA separated BR 628 ---- ---- 629 | FN | | HA | 630 ---- ---- 631 | | ---- 632 home link -------------------| BR |------> Internet 633 | ---- 634 ---- ----- 635 | MR | | LFN | 636 ---- ----- 637 | | 638 mobile network link --------- 640 -FN scans its routing table for LFN's address, and finds default 641 route towards BR. 642 -FN sends NS for L2 address of BR. 643 -BR replies NA. 644 -FN sends packet to BR. 645 -BR scans its routing table for LFN's address, and finds route 646 through MR; 647 -BR sends NS for MR. 648 -MR replies NA with its L2 address. 650 -BR forwards packet to MR and sends ICMP Redirect to FN such that 651 subsequent packets from FN to LFN go straight through MR and not 652 through BR. 653 -MR forwards packet to FN. 655 10. FN sends packet to LFN, mobile network visits, HA separated BR 657 ---- ---- / 658 | FN | | HA | / 659 ---- ---- ----------/ 660 | | ---- | | 661 -------------------| BR |---| Internet | 662 home link ---- | | 663 ----------\ 664 \ 665 \ ---- Visited link 666 --| AR |------ 667 ---- | 668 | 669 ---- ----- 670 | MR | | LFN | 671 ---- ----- 672 | | 673 --------- 674 mobile net 676 -FN scans its routing table for LFN's address, and finds default 677 route towards BR. 678 -FN sends NS for L2 address of BR. 679 -BR replies NA. 680 -FN sends packet to BR. 681 -BR scans its routing table for LFN's address, and finds route 682 through MR; 683 -BR sends NS for MR. 684 -HA replies NA with its L2 address (on behalf of MR). 685 -BR forwards packet to HA and sends ICMP Redirect to FN such that 686 subsequent packets from FN to LFN go straight through MR and not 687 through BR. BR also sends ICMP Redirect to HA, such that HA knows 688 a route through MR. The logic of this last ICMP Redirect is 689 described in section 6.1. 690 -HA scans its routing table for LFN's address, and finds through MR; 691 -HA scans binding cache and finds 'through MRHA tunnel'; 692 -HA encapsulates and sends packet to MR. 693 -MR decapsulates and forwards to LFN. 695 The problem in the above case is how to inform the HA about the 696 route towards MR. When MR at home, and HA being a host, normally 697 HA doesn't have a route towards MR. See discussion in section 6.1. 699 11. LFN sends packet to FN, mobile network home, HA separated BR 700 ---- ---- 701 | FN | | HA | 702 ---- ---- 703 | | ---- 704 home link -------------------| BR |------> Internet 705 | ---- 706 ---- ----- 707 | MR | | LFN | 708 ---- ----- 709 | | 710 mobile network link --------- 712 -LFN scans its routing table for FN's address, and finds default 713 route towards MR. 714 -LFN sends NS for L2 address of MR. 715 -MR replies NA. 716 -LFN sends packet to MR. 717 -MR scans its routing table for LFN's address, and finds route 718 'on-link'; 719 -MR sends NS for FN. 720 -FN replies NA with its L2 address. 721 -MR forwards packet to FN. 723 12. LFN sends packet to FN, mobile network visits, HA separated BR 724 ---- ---- / 725 | FN | | HA | / 726 ---- ---- ----------/ 727 | | ---- | | 728 -------------------| BR |---| Internet | 729 home link ---- | | 730 ----------\ 731 \ 732 \ ---- Visited link 733 --| AR |------ 734 ---- | 735 | 736 ---- ----- 737 | MR | | LFN | 738 ---- ----- 739 | | 740 --------- 741 mobile net 743 -LFN scans its routing table for FN's address, and finds default 744 route towards MR. 745 -LFN sends NS for L2 address of MR. MR replies NA. 746 -LFN sends packet to MR. 747 -MR encapsulates this packet through the MRHA tunnel and sends to 748 HA. 749 -HA receives this packet and decapsulates. 750 -HA scans its routing table for FN's address, and finds route 751 'on-link'; 752 -HA sends NS for FN. FN replies NA with its L2 address. 753 -HA forwards packet to FN (on behalf of the MR). 755 13. CN sends packet to LFN, mobile network home, HA separated BR 757 ---- CN link 758 --| BR1|------ 759 ---- / ---- | 760 | HA | / | 761 ---- ----------/ ---- 762 | ---- | | | CN | 763 -----------------| BR |---| Internet | ---- 764 | home link ---- | | 765 ---- ----- ----------\ 766 | MR | | LFN | \ 767 ---- ----- \ 768 | | 769 --------- 770 mobile net link 772 -BR receives packet from CN towards LFN. 773 -BR scans its routing table to and finds dest through MR. 774 -BR sends NS for L2 address of MR. 775 -MR replies NA. 776 -BR forwards packet to MR. 777 -MR forwards packet to LFN. 779 14. CN sends packet to LFN, mobile network visits, HA separated BR 781 ---- CN link 782 --| BR1|------ 783 ---- / ---- | 784 | HA | / | 785 ---- ----------/ ---- 786 | ---- | | | CN | 787 ---------| BR |---| Internet | ---- 788 ---- | | 789 ----------\ 790 \ 791 \ ---- Visited link 792 --| AR |------ 793 ---- | 794 | 795 ---- ----- 796 | MR | | LFN | 797 ---- ----- 798 | | 799 --------- 800 mobile net 801 -BR receives packet from CN towards LFN. 802 -BR scans its routing table to and finds dest through MR. 803 -BR sends NS for L2 address of MR. HA replies NA on behalf of MR. 804 -BR sends Redirect to HA informing it about a route towards MR. 805 See section 6.1 on a discussion about this ICMP Redirect. 806 -Simultaneously with previous packet, BR forwards packet to HA. 807 -HA scans its routing table and finds an entry to MR (added as a 808 result to ICMP redirect), it also has a BC entry for MR, so it 809 sends the packet through the MRHA tunnel. 811 The problem in the above case is how to inform the HA about the 812 route towards MR. When MR at home, and HA being a host, normally 813 HA doesn't have a route towards MR. See discussion in section 6.1. 815 15. LFN sends packet to CN, mobile network home, HA separated BR 817 ---- CN link 818 --| BR1|------ 819 ---- / ---- | 820 | HA | / | 821 ---- ----------/ ---- 822 | ---- | | | CN | 823 -------------------| BR |---| Internet | ---- 824 | home link ---- | | 825 ---- ----- ----------\ 826 | MR | | LFN | \ 827 ---- ----- \ 828 | | 829 --------- 830 mobile net link 832 -MR receives packet from LFN towards CN. 833 -MR scans its routing table and finds dest through BR. 834 -BR sends packet to CN 836 16. LFN sends packet to CN, mobile network visits, HA separated BR 837 ---- CN link 838 --| BR1|------ 839 ---- / ---- | 840 | HA | / | 841 ---- ----------/ ---- 842 | ---- | | | CN | 843 ----------| BR |---| Internet | ---- 844 ---- | | 845 ----------\ 846 \ 847 \ ---- Visited link 848 --| AR |------ 849 ---- | 850 | 851 ---- ----- 852 | MR | | LFN | 853 ---- ----- 854 | | 855 --------- 856 mobile net 857 -MR receives packet from LFN towards CN. 858 -MR encapsulates this packet through the MRHA tunnel. 859 -HA receives this packet, decapsulates and sends to CN. 861 5.3 MR Redirects to BR 863 Also, consider the scenario where the FN has a default route 864 towards the MR instead of the BR, and sending packets to a CN on 865 the Internet. This might very well happen when the MR is at home 866 and sending RAs, in addition to the RAs sent by the BR. FN might 867 configure a default route through the MR instead of the BR. If MR 868 is at home, MR will redirect the FN towards the BR. So, even if 869 this looks like a wrong configuration on the FN (its default route 870 should point to BR and not MR), packets will still travel correctly 871 when MR is at home. This should be maintained when the MR is not 872 at home. There are two possibilities: either the HA (replacing the 873 MR) redirects the FN towards the BR, or it is the MR itself that 874 sends the respective ICMP redirect message to the FN (through the 875 MRHA tunnel). The first case supposes that HA maintains a routing 876 table, which contains routes towards the mobile network. This is 877 less desirable if the HA is not co-located with BR, and where we 878 prefer not to have routing interactions with the HA. The latter 879 case is more plausible, keeping the default routing behaviour to 880 the MR. 882 6. Informing the HA about the route to MR 884 In certain scenarios presented previously, with the HA dissociated 885 from the BR and the MR in the visited network, there is a need for 886 the HA to maintain in its routing table an entry towards the MR. A 887 scenario where packets from CN towards LFN are looping between MR 888 and HA has been described in detail in section 3.2.4 of [8]. 889 Several solutions exist to avoid this looping, described below. 891 6.1 ICMP Redirect from BR to HA 893 One alternative for avoiding the loop problem is by using ICMP 894 Redirects [19] sent by BR to HA in order to communicate to HA the 895 route it misses towards the MR. ICMP Redirects are deployed and 896 used in existing networks. The classic behaviour of ICMP Redirects 897 is presented in scenario 1. Scenarios 10 and 14 with 898 MR-not-at-home and BR dissociated from HA, present the fact that 899 classic ICMP Redirects are not triggered normally and thus 900 modifications are needed. 902 In addition to the normal behaviour with ICMP Redirects, described 903 in [19], it could be modified according to the following. The 904 decision by BR to send ICMP Redirect towards HA can be taken in at 905 least three ways: 907 -allow a number of iterations of a packet looping between HA and 908 BR and after this fixed number decide to send the Redirect to HA 909 such as the looping stops. This modifies the normal behaviour 910 of BR. 912 -another possibility is for BR to react at the moment it receives 913 the proxy NA from HA (on behalf of the MR), compare to the 914 current entry it has in the Neighbour Cache for MR, and then 915 decide that, because MR has moved away, send Redirect to HA to 916 inform HA about the route to MR. This is the route (or set of 917 routes) normally maintained by the BR with the MR, doesn't 918 contain any form of the new position (CoA) of the MR. This 919 route, or set of routes (in which case a set of Redirects are 920 sent), is copied from MR's routing table. All routes that have 921 destination the MR's home address need to be communicated to HA 922 with ICMP Redirects. This modifies the normal behaviour of BR. 924 -yet another possibility is to consider modifications on HA (from 925 vanilla Mobile IPv6), but don't touch BR, such that HA generates 926 a new packet, thus obtaining a classic ICMP Redirect from BR. 928 When the HA receives a packet that is not for itself, it 929 encapsulates it with an IP-in-IP tunnel, having the src address 930 its own address and the destination address copied from the dst 931 address of the original packet. Then try to route this packet 932 and find the default route towards BR. Then BR sends a normal 933 ICMP Redirect informing HA there is a better route for this 934 packet towards MR. Thus HA acquires the MR route dynamically. 935 The packet will be passed on by BR to HA again, and further 936 details are needed here. Remark that this is equivalent to one 937 iteration of the loop (a particular case of the fixed iterations 938 loop mentioned previously). 940 6.2 Static route method 942 This is proposed by [4] and [13], where operator statically 943 introduces a route in the HA, for MR's prefix, towards MR's 944 address, or towards the specific MRHA tunnel. 946 The first approach proposed in [4] suggests to configure a new 947 static tunnel on the MR's HA towards MR_HoA. This static tunnel, 948 that we call here MR_HoA_tunnel, is to be used as output interface 949 of a new static entry added in the routing table of HA for MR's 950 prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data 951 packet from CN addressed to a LFN, MR's HA will consult its routing 952 table and find a match for that packet for this static route since 953 LFN address matches MR's prefix. As a results it will encapsulate 954 the packet with an additional header that will have MR's HA as 955 source address and MR_HoA as destination address. In order to 956 forward this packet, now addressed to MR's Home Address, the MR 957 will first consult its binding cache and discover MR's Care-of 958 address. It will thus send the packet through the MRHA tunnel 959 towards MR's current location. It is worth mentionning that this 960 approach introduces a double encapsulation of an incoming packet to 961 be forwarded to the MR: the first is due to the MR_HoA_tunnel, the 962 second to the MRHA tunnel. 964 The second approach proposed in [13] suggests a similar method but 965 avoids the overhead introduced by the two tunnels. It consists in 966 configuring a static route in MR's HA routing table for MR's prefix 967 towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of 968 a data packet from CN addressed to a LFN, MR's HA will consult its 969 routing table and, again, find a match for that packet for this 970 static route since LFN address matches MR's prefix. This indicates 971 the MR's HA that the packet should be routed towards MR_HoA. From 972 its binding cache it discovers MR's CoA and as a consequence 973 forwards the incoming packet for CN directly through the MRHA 974 tunnel. This approach reduces the overhad of the MR_HoA_tunnel but 975 requires a suitable coordination of the routing table and binding 976 cache on the HA. 978 Analyzed from the perspective where HA is separated from BR, and 979 where MR doesn't normally maintain routes with HA, then this 980 addition might seem superfluous. Consider a situation where MR and 981 BR maintain routing information and where that manual route is 982 added on HA. When the MR is not at home, consider that 983 administrator decides to add a new fixed subnet at home, with its 984 own router neighbouring with BR on the home link. Consider the new 985 subnet's prefix being a longer prefix derived from the prefix 986 assigned to the MR's subnet. This is perfectly feasible by 987 changing configurations on the MR and BR. That can work perfectly 988 even if MR is not at home. But if HA doesn't participate in this 989 exchange (which is the case if HA separated from BR) then the 990 manual route added previously in the HA is no longer valid. Thus, 991 a potential issue. 993 Further explanation or simplification needed here. 995 6.3 Dynamic route method 997 It is possible for the HA, being either separated or co-located 998 with the BR, to run a specific routing protocol, participating in 999 the routing interactions between BR and all other neighbouring 1000 routers on the home link. Thus, the HA always has the necessary 1001 route it needs to join the MR's network. 1003 If the HA is a one-interface machine, and separated from the BR, it 1004 seems that it maintains information that is not always necessary to 1005 its well working as a HA. For example, it will maintain routes to 1006 all neighbouring routers, be it fixed or mobile. The routes to the 1007 fixed neighbouring routers are not necessary for its working as a 1008 host, since it suffices to only have a default route towards a BR, 1009 that will normally dynamically Redirect it towards the other fixed 1010 routers. Moreover, if HA runs a dynamic routing protocol, its 1011 route updates will never be taken into account by other routers, 1012 since they will always be one hop further than the routes already 1013 known by them. Thus it might be possible to have the HA as a 1014 silent routing, only receiving route updates from the neighbouring 1015 routers, but never sending route updates, since it does not have a 1016 network behind it (it is a "host") whose reachability it needs to 1017 advertise. 1019 RIP [11] supports having a silent host that only listens to update 1020 messages, but does not advertise new routes. With OSPF [18] the 1021 "listening only" requirement is complicated by the fact that the HA 1022 would needs to participate in OSPF's HELLO protocol. 1024 The advantage of using this solution is that it does not require 1025 additional changes to Mobile IPv6, and PSBUs are not needed. The 1026 disadvantage is that if the MR does not run a routing protocol then 1027 we still need some way of telling the HA the routes to the MNPs, 1028 which gets us back to sections 6.1 and 6.2. 1030 Further explanation or simplification needed here. 1032 7. Other Issues 1034 7.1 Link-local addresses 1036 When the MR is at home, and if it runs a dynamic routing protocol, 1037 it exchanges routing information with BR, by using its link-local 1038 address and BR's link-local address. When the MR is not at home, 1039 and HA defends the MR's home address, the HA is normally doing this 1040 for any type of addresses except link-locals. The immediate 1041 necessity would be for the HA to defend a link-local address of the 1042 MR, instead of a global-scoped home address. However, this is in 1043 conflict with the necessity of dynamic routing protocols to use 1044 link-local addresses only. 1046 If Mobile IPv6 spec is to be followed, then the HA will not allow 1047 re-direction of traffic of a Home Address towards a CoA, when that 1048 Home Address is link-local. 1050 Another issue concerning link local addresses: the MR has routes to 1051 the BR using BR's link local address. When the MR is away from 1052 home: how does the MR reach BR's link local address? 1053 How does it tell the difference between a link local address on the 1054 home link and a link local address on the visited link? 1056 7.2 MR as an MN 1058 If the MR is at home and it has an address configured on the moving 1059 interface other than a link-local address, then the MR can act as 1060 an MH too, and send normal Mobile IPv6 BUs, binding that Home 1061 Address to a newly configured CoA; thus allowing the MR to be an MH 1062 for itself only, ignoring the LFNs. If the MR at home doesn't have 1063 other addresses than link-local on the mobile interface then the MR 1064 can not send normal Mobile IPv6 BUs and can not be an MH. It can 1065 however be an MR for the hosts on the mobile network. 1067 7.3 Prefix-based routing and host-based routing 1069 Prefix-based hierarchical routing (where the mobile network link 1070 has a prefix that is a subset of the home-network link) is the 1071 preferred type of routing for IPv6. Practically though, it is 1072 possible for the BR to have a routing table entry containing the 1073 prefix of the mobile network, as well as a host-based entry that 1074 points to a certain LFN also in the mobile network. Those two 1075 entries might or might not have the same common sub-prefix. With a 1076 MR at home, being a normal router, BR will know how to forward to 1077 all hosts behind the MR as well as only to the specific LFN of the 1078 host-based route. This behaviour should be maintained when the MR 1079 is no longer at home and when it has a bidirectional tunnel MRHA. 1081 7.4 Multicast subscriptions of the MR 1083 When the MR is at home, it normally joins certain multicast groups 1084 related to routing (e.g. all-routers multicast group with site 1085 scope). This is assumed by dynamic routing protocols, or by 1086 renumbering mechanisms. When the MR is no longer at home, its 1087 multicast subscription should continue as if it were at home. This 1088 can be achieved by "home subscription" techniques considered in 1089 relation with Mobile IPv6. 1091 7.5 Neighbour Discovery for MR 1093 When MR is at home and sends RA towards the home link, it should 1094 not advertise itself as being capable of being a default router 1095 (Router Lifetime should be 0). 1097 When the MR is visiting, it should not respond to RSs sent on the 1098 visited link and it should not send RAs on the visited link. 1100 When the MR is at home, it doesn't normally use any information 1101 received from RAs sent by a neighbouring router, i.e. the BR. It 1102 has a link-local address and if it has a larger scope address 1103 configured on an interface, then that is normally done manually. 1104 Actually, routers are usually prohibited from using information 1105 received in RAs more than for logging and synchronization purposes. 1106 When the MR is in a foreign network, it needs a way to configure a 1107 Care-of Address. In the hosts case this is done by stateless or 1108 stateful autoconf. In the MR case, the stateful is possible, while 1109 the stateless is normally prohibited. A good way for address 1110 autococnfiguration for the MR should be identified, be it DHCP, or 1111 modified RAs, or modified router's behaviour to accept RAs. 1113 Assume the MR is at home and a non-link-local (site- or global) 1114 home address is configured on the interface connecting to the home 1115 link (supposedly the same interface that will change CoAqs when 1116 visiting). The MR-at-home will do periodic NAs for this home 1117 address; this behaviour should stop when MR is visiting. This 1118 modified behaviour is already taken into consideration by Mobile 1119 IPv6 MN. In the particular MR case, most ND operations of MR are 1120 delegated to the HA, and such most entries of Neighbour Cache, 1121 Destination Cache that are related to the home link will disappear. 1122 New entries that are relevant in the foreign network will populate 1123 those tables. When coming back home, all ND entries should be 1124 replaced back with the entries related to the home network. 1126 Another specific case in point is the default route. As already 1127 presented with the router behaviour with respect to RAs, a default 1128 route is not normally configured by MR from a received RA. When 1129 the MR is in a foreign network, it should have a default route that 1130 points to its BR (but through the MRHA tunnel) and another 1131 non-tunnelled default route towards the current AR. Moreover, all 1132 MR's routing table entries that pointed to BR when the MR was at 1133 home, should still continue to point to BR (through the MRHA 1134 tunnel). The same is true for all routing table entries of the BR. 1136 7.6 Separation of routing and mobility for MR 1138 The necessity of the separation between mobility vs. routing 1139 exchanges holds true irrespective to whether dynamic or static 1140 routing is used. If static routing is used, then BR has routes 1141 towards the mobile network through the MR, and MR has routes 1142 towards the Internet through the BR. If dynamic routing is used, 1143 then the MR and BR dynamically exchange routing information that is 1144 manually configured in the routing configuration files of MR and of 1145 BR, as well as routing information that is delivered by other 1146 routers external to the home network (be it beyond the BR or beyond 1147 the MR). The entities concerned with routing in the home network 1148 are only BR and MR. This behaviour should continue when network 1149 mobility is introduced, presumably by deploying an HA (but not 1150 touching the BR). MR and HA should exchange only the information 1151 related to mobility but not the information related to routing. 1153 7.7 Router Renumbering 1155 Router Renumbering for IPv6 [7] is a technique where routers of a 1156 home network are instructed to change the prefixes they advertise. 1157 In the context here, it should be possible for the MR to be 1158 re-numbered when it is at home as well as when it is visiting. 1160 The renumbering mechanisms provided by Mobile IPv6 (mobile prefix 1161 solicitations and advertisements) are not relevant for changing the 1162 prefixes advertised by the MR towards the mobile network; but these 1163 mechanisms should still be used for MR when MR is acting as an MH. 1164 In order for router renumbering to work for MR when acting as MR, 1165 the MR should at least be able to maintain its multicast 1166 subscription to all-routers group valid at home. 1168 8. Mobile Router behaviour 1170 The MR-HA tunnel is an IP-in-IP tunnel maintained by MR and HA. 1171 This is not a "tunnel" in the sense referred to sometimes by 1172 employing the IPv6 routing headers. 1174 The behaviour of the Mobile Router is the behaviour of a normal 1175 router with the main exception of the order of search in relevant 1176 routing tables, with the addition of a step to search in the MRHA 1177 tunnel table. The exact search steps will be detailed later. 1178 Various implementations do it in various ways. 1180 A generic behaviour of a router forwarding a packet having 1181 destination d, or the behaviour of MR when it is at home: 1182 -determine the packet is for itself or not, by comparing d to all 1183 addresses assigned to all interfaces. 1184 -if not for itself then search the routing table for a prefix that 1185 matches d under a prefix. Pick d2. 1186 -search the destination cache for an exact match for d2. If found, 1187 then send the packet to the L2 address in the DC entry. If not 1188 found, then create it by doing the ND exchange; then send it to 1189 what ND found. 1191 From that behaviour, here is the modified mobile router behaviour: 1192 -determine the packet is for itself or not, by comparing d to all 1193 addresses assigned to all interfaces. 1194 -if not for itself then search the routing table for a prefix that 1195 matches d under a prefix. Pick d2. 1196 +determine whether this entry in the routing table has a 1197 corresponding entry in the MRHA tunnel table. If yes, then 1198 encapsulate towards the HA marked there and create a new packet, 1199 with source s CoA and new destination d from the tunnel table 1200 (Home Agent address). 1201 -search the destination cache for an exact match for d2, and that 1202 is not linked to the tunnel table. If found, then send the packet 1203 to the L2 address in the DC entry. If not found, then create it 1204 by doing the ND game; then send it to what ND found. 1206 8.1 CoA Configuration 1208 This can be done by configuring an address based on a prefix 1209 received from the AR. However, routers don't take into account 1210 RAs, normally. It can be solved by saying that in this case MR is 1211 not quite a router but more of a host. 1213 It can also be done by means of DHCPv6 messaging, where there is no 1214 distinction between hosts and routers. 1216 8.2 Discovering HA 1217 Do it as a Mobile IPv6 MH, except that. Anycast. 1219 8.3 Sending BUs to HA 1221 Do the normal Mobile IPv6 signalling with its Home Agent. The BUs 1222 sent contain a distinguishing bit 'R'. 1224 8.4 Search order in various tables 1226 Further complicating the mobile routing issues, the Destination 1227 Cache is being specified with the option of being capable of being 1228 fusioned with the Routing Table. The same stands for the Binding 1229 Cache. It is then possible to have the DC, the BC and the routing 1230 table as a unique and only large routing table. With this kinds of 1231 unknowns, it is difficult for the authors, at present time, to 1232 specify a proper search order in the respective structures, even if 1233 we feel this is truly important. Or probably the behaviour of a MR 1234 and HA can be specified without going into the details of these 1235 structures, leaving implementations freedom of choice. 1237 9. Home Agent behaviour 1239 The MR-HA tunnel is an IP-in-IP encapsulation tunnel [20] 1240 maintained by MR and HA. This is not a "tunnel" in the sense 1241 referred to sometimes by employing the IPv6 routing headers. 1243 The behaviour of the Home Agent is the behaviour of a normal Mobile 1244 IPv6 HA with the main exception of the order of search in relevant 1245 routing tables, with the addition of a step to search in the MRHA 1246 tunnel table. The exact search steps will be detailed. 1248 The Home Agent uses proxy-ND to defend the link-local address of 1249 the MR when the MR is not at home. When the MR is at home, the HA 1250 stops defending MR's link-local address. 1252 When the MR is not at home, the L2 address of the link-local 1253 address of the MR is requested by neighbouring routers (such as BR) 1254 or by FNs that have entries in their routing tables or destination 1255 caches through MR's link-local address. HA should reply to these 1256 requests with its own L2 address and as such receive all packets 1257 that have dst address containing any address of all hosts and 1258 routers in the mobile network. Following this, the HA will search 1259 its BC as well as its routing table, then it will encapsulate those 1260 packets through the MRHA tunnel and sent according to the normal 1261 HA's destination cache and routing tables, towards the current 1262 Care-of Address of the Mobile Router. 1264 When HA is a host, HA doesn't need to have a routing table 1265 containing entries towards MR or hosts and routers behind MR. When 1266 HA is a host, HA's routing table should contain only entries 1267 related to the neighbouring fixed routers. For example HA has a 1268 default route towards BR. 1270 10. Route Optimization 1272 Route Optimization problem description is elsewhere. 1274 RO is an absolutely necessary need for mobile networks for Mobile 1275 IPv6. 1277 It might very well be that the need for RO might bring with it the 1278 need to put prefixes in the BUs towards CN. 1280 The previous scenarios allow for nested mobile networks as well. 1281 But the functioning suffers of drawbacks. 1283 The MRHA-enhanced Mobile IPv6 scenarios described previously suffer 1284 from important drawbacks, such as multiple nested tunnels, lack of 1285 route optimization with the CN. 1287 An example of an important inconvenient of using exclusively 1288 vanilla Mobile IPv6 with MRHA is when nesting: consider two mobile 1289 networks, each MR having its own HA in different domains. The 1290 first MR attaches to an AR and the second MR attaches under the 1291 first mobile network. In this case, two LFNs situated one on the 1292 first net and the second on the second net are capable to 1293 communicate with each other, but communication goes through both 1294 first MR's HA and through second's. In practice this exposes a 1295 paradox where if first MR loses connection to AR, then even if the 1296 two nets stay attached, the two LFNs can not communicate. 1298 11. Security Considerations 1300 Security threat analysis of Mobile IPv6 when a Mobile Router is 1301 used instead of a Mobile Host. Not a threat analysis of RO. 1303 The threat analysis of Mobile IPv6 for hosts is presented in [10]. 1304 When router moves instead of host, new threats appear. 1306 When MR at home and using secured RIP [3] or OSPF [18] (whose IPv6 1307 version [5] employs IPsec), then that level of security must be 1308 maintained when MR is away from home. 1310 11.1 Security of the MRHA tunnel 1312 The MRHA tunnel is protected as required by the Mobile IPv6 1313 specification for the MNHA tunnel [2]. 1315 MR and HA maintain a security association, share the same key. 1317 11.2 Security for Route Optimization 1319 Since RO is not treated in this document, then the return 1320 routability tests for MR are not described. 1322 MR could do CoTI for MR's CoA and HoTI for LFN's address. In that 1323 case LFN's address must be bound to MR, presumably by delegation 1324 mechanisms. 1326 MR if acting as an MN must do HoTI/CoTI for itself, if that MN 1327 needs RO. If MR acting as MN, then its LFNs must not take 1328 advantage of the results of having an SA MN-CN. Or if they do, 1329 then MR must have some form of delegation support. 1331 Acknowledgements 1333 Some of the issues presented in this document have not yet been 1334 discussed publicly, as far as the authors are aware, except for the 1335 places where specific references to prior drafts is explicitely 1336 made. Some of the issues have been discussed on the nemo mailing 1337 list, and proper acknowledgment will be given here. This document 1338 being submitted for public review, all comments are welcome and 1339 contributors will be properly acknowledged. 1341 Changes 1343 October 2002: revision 00 submitted. 1345 References 1347 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1348 Levels", BCP 14, RFC 2119, March 1997 1350 [2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using 1351 IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes 1352 and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, 1353 IETF Internet Draft, October 2002. (Work in Progress). 1355 [3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC 1356 2082, January 1997. 1358 [4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed 1359 October 25, 2002 at 1360 http://www.cisco.com/univercd/cc/td/doc/product/software/ 1361 ios122/122newft/122t/122t4/ftmbrout.pdf 1363 [5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 1364 2740, December 1999. 1366 [6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6 1367 Specification", RFC 2473, December 1998. 1369 [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 1370 2000. 1372 [8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic, 1373 Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks 1374 Support in Mobile IPv6", 1375 draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft, 1376 March 2002. (Work in Progress). 1378 [9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support 1379 Terminology", draft-ernst-nemo-terminology-00.txt, IETF 1380 Internet Draft, October 2002. (Work in Progress). 1382 [10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark, 1383 E., Patil, B. and Roberts, P., "Threat Models introduced by 1384 Mobile IPv6 and Requirements for Security", 1385 draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet 1386 Draft, November 2001. (Work in Progress). 1388 [11] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1389 1998. 1391 [12] Johnson, David B., Perkins, Charles E. and Arkko, Jari, 1392 "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, 1393 IETF Internet Draft, June 2002. (Work in Progress). 1395 [13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay, 1396 "Mobile Router Support with Mobile IP", 1397 draft-kniveton-mobrtr-02.txt, IETF Internet Draft, July 1398 2002. (Work in Progress). 1400 [14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart, 1401 D. H. and Bell, T. L. and Kachmar, B. A., "Application of 1402 Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs 1403 of the Aerospace Conference, 2001. 1405 [15] Malkin, G., "RIP Version 2, Carrying Additional Information", 1406 RFC 1723, November 1994. 1408 [16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997. 1410 [17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP, 1411 revised", RFC 3024, January 2001. 1413 [18] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1415 [19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery 1416 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1418 [20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1419 1996. 1421 [21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, 1422 August 2002. 1424 Authors' Addresses 1426 Alexandru Petrescu Miguel Catalina-Gallego 1427 Motorola Labs Motorola Labs 1428 Espace Technologique de St Aubin Espace Technologique de St Aubin 1429 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1430 France France 1431 Phone: +33 1 69354827 Phone: +33 1 69352541 1432 Alexandru.Petrescu@motorola.com Miguel.Catalina@motorola.com 1434 Christophe Janneteau Hong-Yon Lach 1435 Motorola Labs Motorola Labs 1436 Espace Technologique de St Aubin Espace Technologique de St Aubin 1437 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1438 France France 1439 Phone: +33 1 69352548 Phone: +33 1 69352536 1440 Christophe.Janneteau@motorola.com Hong-Yon.Lach@motorola.com 1442 Alexis Olivereau 1443 Motorola Labs 1444 Espace Technologique de St Aubin 1445 Gif-sur-Yvette 91193 1446 France 1447 Phone: +33 1 69352516 1448 Alexis@motorola.com 1450 Copyright (C) The Internet Society (2002). All Rights Reserved. 1452 This document and translations of it may be copied and furnished to 1453 others, and derivative works that comment on or otherwise explain it 1454 or assist in its implementation may be prepared, copied, published and 1455 distributed, in whole or in part, without restriction of any kind, 1456 provided that the above copyright notice and this paragraph are 1457 included on all such copies and derivative works. However, this 1458 document itself may not be modified in any way, such as by removing 1459 the copyright notice or references to the Internet Society or other 1460 Internet organizations, except as needed for the purpose of developing 1461 Internet standards in which case the procedures for copyrights defined 1462 in the Internet Standards process must be followed, or as required to 1463 translate it into languages other than English. 1465 The limited permissions granted above are perpetual and will not be 1466 revoked by the Internet Society or its successors or assigns. 1468 This document and the information contained herein is provided on an 1469 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1470 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1471 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1472 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1473 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1475 Funding for the RFC editor function is currently provided by the 1476 Internet Society.