idnits 2.17.1 draft-petrescu-nemo-mrha-01.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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-petrescu-nemo-mrha-00', but the file name used is 'draft-petrescu-nemo-mrha-01' == 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 17) 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. ** There are 7 instances of lines with control characters in the document. 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 (November 2002) is 7826 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 1463, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1466, 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) -- Possible downref: Normative reference to a draft: ref. '22' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 9 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: May 2003 C. Janneteau 4 H. Y. Lach 5 A. Olivereau 6 Motorola 8 November 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. Scenarios are presented with the MR at home 39 and in a visited network, from which an argumentation is made that 40 all routing information is available in the HA (when BR and HA are 41 co-located) or can be communicated by ICMP Redirect (when the BR 42 and HA are separated). This raises questions on the necessity of 43 more information than the 'R' bit into the Mobile IPv6 BUs 44 (i.e. /128 prefixes are sufficient). Other generic issues with an 45 MRHA 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.................................ii 54 1. Introduction....................................................1 55 1.1 Prior descriptions...........................................2 56 2. Definitions.....................................................2 57 3. Data structures.................................................3 58 4. Description of a Home Network...................................3 59 5. Scenarios.......................................................5 60 5.0 Manual mobile networks.......................................5 61 5.1 Scenarios with co-located HA and BR..........................6 62 5.2 Scenarios with HA and BR separated..........................10 63 5.3 MR Redirects to BR..........................................15 64 6. Informing the HA about the route to MR.........................15 65 6.1 ICMP Redirect from BR to HA.................................15 66 6.2 Static route method.........................................16 67 6.3 Dynamic route method........................................17 68 7. Other Issues...................................................17 69 7.1 Link-local addresses........................................17 70 7.2 MR as an MN.................................................18 71 7.3 Prefix-based routing and host-based routing.................18 72 7.4 Multicast subscriptions of the MR...........................18 73 7.5 Neighbour Discovery for MR..................................19 74 7.6 Separation of routing and mobility for MR...................19 75 7.7 Router Renumbering..........................................20 76 7.8 IPv4 issues.................................................20 77 8. Mobile Router behaviour........................................20 78 8.1 CoA Configuration...........................................21 79 8.2 Discovering HA..............................................21 80 8.3 Sending BUs to HA...........................................21 81 8.4 Search order in various tables..............................22 82 9. Home Agent behaviour...........................................22 83 10. Route Optimization............................................22 84 11. Security Considerations.......................................23 85 11.1 Security of the MRHA tunnel................................23 86 11.2 Security for Route Optimization............................23 87 Acknowledgements..................................................24 88 Intellectual Property Rights Considerations.......................24 89 Changes...........................................................24 90 References........................................................24 91 Chairs' Addresses.................................................26 92 Authors' Addresses................................................26 93 Copyright Notice..................................................27 95 Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in RFC-2119 [1]. 101 1. Introduction 103 This document identifies issues when designing an enhancement of 104 the Mobile IPv6 protocol to support mobile networks. The 105 background is the extensive use of the bidirectional tunnel between 106 MR and HA. The HA acts on behalf of the link-local address of the 107 moving interface of the Mobile Router when the MR is in a foreign 108 network. 110 The Mobile Router is using BUs and BAcks with the Home Agent to 111 maintain the MRHA bidirectional tunnel. The modifications to 112 Mobile IPv6 HA and MN are minimal. The BU format contains, in 113 addition to all Mobile IPv6 fields, an additional bit 'R' that 114 informs the HA that this is a mobile router instead of a mobile 115 host. The 'R' bit is used by the HA to perform certain tasks 116 differently for this home address than if it were a host. 118 Traffic coming from outside the home link, or from other hosts on 119 the home link, and directed to hosts behind the mobile router 120 normally only need to go through the L2 address of the mobile 121 router's correspoinding to its L3 address. With Proxy ND [19], it 122 is the HA that pretends to own MR's L3 address by advertising new 123 associations of of the MR's L3 address to the HA's L2 address, thus 124 intercepting MR's home traffic and forwarding it to the current CoA 125 of the MR. 127 When the MR is in a foreign network, traffic coming from the mobile 128 network and towards anywhere to the Internet, is first forwarded by 129 the MR through the reverse tunnel MRHA to the HA. Then HA 130 decapsulates and forwards to the specific host on the home link or 131 outside the home link. 133 When the MR acts as a mobile host, vanilla Mobile IPv6 is used. MR 134 can send both BUs with the R bit set and without the R bit set. 135 Depending on what is decided for the home address to be like 136 (link-local or other), the HA could deduce both. 138 A nemo solution with the MRHA tunnel should allow for a clean 139 separation between routing maintenance and mobility bindings 140 maintenance. The route maintenance is done unmodified between MR 141 and BR, while the mobility bindings are done unmodified between MR 142 and HA. 144 Much of the argumentation made around routing can be considered as 145 operator, or administrative issues, which seen otherwise can 146 discard some of the conclusions, but not all. 148 The document is organized as follows: the next sections present a 149 description of the home network, where the HA could be co-located 150 with the BR, or separated. Then a set of simple scenarios are 151 presented describing the normal routing behaviour of the MR when it 152 is at home, and the desired behaviour of routing and of ND 153 messaging at home, when the MR is in a foreign network. These 154 scenarios are presented such that they expose the need for new 155 behaviours only in the case where the HA is separated from the BR; 156 otherwise (HA/BR co-located), all routing information is already 157 present in the HA. The following section presents possible 158 approaches for adding to HA routing information related to MR, one 159 based on ICMP Redirects, one based on static or dynamic routes 160 (from previous documents) and a third approach as a slight 161 modifications of dynamic routing where the HA "only listens" to 162 route updates but doesn't advertise. 164 Additional sections present other issues related to maintaining 165 normal MR behaviour when it is not at home (e.g. renumbering or 166 multicast subscriptions) and then detailed behaviour of the HA and 167 of the MR. The Route Optimization problem and the Security 168 Considerations are briefly touched at the end. 170 1.1 Prior descriptions of mobile network support with Mobile IPv6 172 A complete description of the previous proposals to support mobile 173 networks or mobile routers with Mobile IP bi-directional tunnel can 174 not be made here due to space constraints. 176 The closest description to mobile network support in Mobile IPv6 177 with the MRHA tunnel can be found in [13]. The approach described 178 in that document relies on the bidirectional tunnel between MR and 179 HA. The solution proposed is valid for Mobile IPv6 as for Mobile 180 IPv4. The MR and HA behaviours still represent a sensitive 181 departure from the Mobile IPv6 protocol in that MR informs its HA 182 directly about the tunnel interface and dynamically triggers 183 additions of routing table entries in the HA's routing table for 184 the MR's tunnel. In addition, the most recent version of the draft 185 proposes usage of the PSBUs in order to inform the HA about the 186 prefix of the mobile network (thus a combination with the PSBU 187 approach). Moreover, the considerations about dynamic routing in 188 this draft refer only to how dynamic routing would work with a MR, 189 but not about the necessity of running a routing protocol between 190 HA and MR. See sections 6.2 and 6.3 for an overview of the methods 191 presented in these documents. 193 Using PSBUs as proposed in [8] and [13] has many other side-effects 194 not considered until recently. When the mobile network is assigned 195 several prefixes instead of one, then it is not clear whether 196 several BUs are being sent or only one with several prefixes 197 inside. Remark that in the vanilla Mobile IPv6 case, only one CoA 198 can be sent with a BU (the alternative CoA is only an alternative 199 not a substitute). 201 In the Mobile IPv4 case, the network mobility support with the MRHA 202 tunnel has been reported at least by various teams at Cisco [4] and 203 NASA [14]. 205 2. Definitions 207 Many relevant definitions for network mobility with the MRHA (could 208 me spelled emra) tunnel can be found in [9]. In addition to those 209 definitions: 211 MRHA bidirectional tunnel, sometimes referred to as a reverse 212 tunnel. As described in [6], [12], [17], [20]. 214 MIMR: the Mobile Interface of the Mobile Router: the interface that 215 connects MR to the home link and that changes its Care-of Address 216 when away from home. 218 MR_HoA: mobile router's Home Address, or the home address of the 219 MIMR. 221 MNP: mobile network prefix, or the prefix of the link of the mobile 222 network that will move away. Note that in the most general case a 223 single MR may route multiple prefixes, in which case there would be 224 multiples MNPs per one mobile network. 226 FN: fixed node on the home link. It doesn't stand for fixed 227 network. 229 3. Data structures 231 A home agent that supports mobile networks maintains the following 232 structures: destination cache [19], binding cache [12] and routing 233 table [11]. The binding cache is modified from Mobile IPv6, such 234 that. The Home Agent also maintains the MRHA Tunnel Table. 236 A Mobile Router contains an on-link prefix list, a neighbour cache, 237 a destination cache, routing table, a binding update list, a home 238 agents list and so on. 240 Additionally, it contains an MRHA Tunnel Table with the following 241 fields: 242 -interface number 243 -address of the tunnel endpoint corresponding to the mobile 244 router. This is normally a CoA. 245 -address of the tunnel endpoint corresponding to the home 246 agent. This is normally the HA address. 247 -list of entries present in the neighbour cache. 248 -list of entries present in the destination cache. 249 -list of entries present in the prefix list. 250 -list of entries present in the default router list. 251 -list of entries present in every other structure. 253 The idea behind the MRHA tunnel table is to have as little 254 modifications as possible to the other ND and Mobile IPv6 tables 255 such that the MR acts as if it were at home, but across the MR-HA 256 tunnel. 258 All the mechanisms related to ND and classic routing are being 259 subjected to this tunnel table, such as to allow for mobility of 260 the mobile network. One example is to stop doing ND for the home 261 address of the MR's interface that acquired a new CoA. It also 262 prevents the MR to have routing interactions with the visited 263 domain, but it alows it to continue having "normal" routing 264 interactions with its home domain, including exchanging of normal 265 dynamic routing messages, multicast routing messages, ICMP 266 redirects and others. 268 4. Description of a Home Network 270 When designing a NEMO solution with the MRHA tunnel, the first 271 steps are to carefully consider the actual behaviour of the home 272 network when the mobile network is at home, employing normal 273 routing. Then this behaviour should be maintained as much as 274 possible when the MR is not at home (e.g. MR should be able to send 275 redirects through the MRHA tunnel); reciprocically, the normal 276 behaviour of an FR at home should change when that FR is an MR and 277 is at home (e.g. when MR at home, the MRHA tunnel should be torn 278 down). When the MR is in a foreign network, its presence at home 279 is simulated by the HA (as in Mobile IPv6 for hosts). 281 Let us consider a simple case of a home network that supports 282 movement of one of its links. The home network is made up of a 283 home link and a mobile network link, separated by the Mobile 284 Router. The home network is connected to the Internet via the 285 Border Router, as presented in the figure: 286 ---- 287 | FN | 288 ---- 289 | ------- 290 home link -------------------| HA/BR |---> Internet 291 | ------- 292 ---- ----- 293 | MR | | LFN | 294 ---- ----- 295 | | 296 mobile link --------- 298 Current specification for Mobile IPv6 implies that the HA can be 299 either co-located with the BR, or it can act as a separate 300 one-interface machine (this is advantageous for deploying Mobile 301 IPv6 without changing BRs). For mobile networks, the latter mode 302 can be pictured like this: 303 ---- ---- 304 | FN | | HA | 305 ---- ---- 306 | | ---- 307 home link -------------------| BR |------> Internet 308 | ---- 309 ---- ----- 310 | MR | | LFN | 311 ---- ----- 312 | | 313 mobile network link --------- 315 It is assumed that routes outside the home link are managed by BR 316 and MR, either in a static manner (operator fills in routing 317 tables) or dynamic manner (application software partially manages 318 routing tables). Remark that even when the dynamic style is used, 319 it is still true that operator fills initial routing configuration 320 files, where she/he puts the image of the network as being what the 321 operator believes it to be. The dynamic behaviour of routing 322 protocols intervenes when certain links come down or up due to 323 failures, the operator view is no longer true, and the routers 324 manage to find alternative paths. Also, the dynamic behaviour 325 helps obtaining shortest paths over large networks, relying on 326 several local operator's views of smaller sized networks. Addition 327 of mobility should not change this. 329 If static routing is used instead of dynamic routing, then static 330 routes are added manually both on MR and on the BR. When 331 considering adding *static* routes in a *dynamic* manner for 332 prefixes shorter than /128 by Mobile IP, authors of this document 333 realize (in truth, hopefully) that Mobile IP starts using semantics 334 that are traditionally belonging to routing protocols. 336 5. Scenarios 338 For the sake of completetess, we first describe a simple "manual" 339 scenario for mobile networks based on the MRHA tunnel, that exposes 340 relative simplicity, that uses static routing and doesn't use 341 Mobile IP. 343 Then, adding the Mobile IP behaviour, we present detailed scenarios 344 of communication between an FN on the home link and an LFN on the 345 mobile network link and a CN on the Internet, when the mobile 346 network is at home and away from home in a visited network, and 347 when the HA is co-located with the BR and separated from the BR. 348 All in all, 16 simple scenarios are presented. 350 The scenarios where HA is co-located with BR (1 up to 8) expose 351 that there is no need for MR to communicate prefixes to its HA via 352 BUs. In a normal routing function, when the MR is at home, it 353 exchanges routing information with the BR (co-located with the HA) 354 and thus those prefixes are communicated by e.g. RIP or OSPF. When 355 the MR is not at home, this behaviour continues, but through the 356 MRHA tunnel. 358 The scenarios where HA and BR are separated (9 up to 16) expose 359 that HA needs an entry in its routing table in order to be capable 360 of forwarding packets to the MR (when it is not at home). 362 An additional scenario is then presented where MR at home is using 363 ICMP Redirect, a functionality that might be needed even when the 364 MR is not at home. 366 5.0 Manual mobile networks 368 Authors of this draft have experimented with "manual" mobile 369 networks in IPv4, where the addition of routes and tunnels on the 370 MR and on the BR are done manually, by operators talking on the 371 phone. 373 A home network was used that contains about 10 routers and about 12 374 subnets. That home network is connected to the Internet with a BR. 376 All routers have static routes among them. 378 Then, one slice of that home network (the mobile network) 379 containing one "MR", one normal router and 6 subnets, was 380 disconnected from home, and moved across the Atlantic. Once the 381 "MR" was connected on the other side, it was manually configured 382 with a new IPv4 address, mask and default route. Then a tunnel 383 interface and a route were manually set up on the MR, a tunnel 384 interface and a route were manually set up on the BR. All other 385 routes on all other routers where not touched. Mobile IP software 386 was not used. 388 The entire network (the home and the mobile network) looked, and 389 acted, as if the mobile slice were at home. During this, several 390 applications were tested between hosts in the mobile network, hosts 391 in the home network and hosts on the Internet (incidentally, one of 392 the applications was relying on Mobile IPv4 for hosts, but in no 393 relation with the mobile network moving). 395 Again, this "manual" mobile networks scenario was not using any 396 dynamic routing protocol, and the tunnel was not supporting any 397 form of broadcast of multicast. 399 5.1 Scenarios with co-located HA and BR 401 1. FN sends packet to LFN, mobile network home, HA/BR colocated 402 ---- 403 | FN | 404 ---- 405 | ------- 406 home link -------------------| HA/BR |---> Internet 407 | ------- 408 ---- ----- 409 | MR | | LFN | 410 ---- ----- 411 | | 412 mobile link --------- 414 -FN scans its routing table for LFN's address, and finds default 415 route towards BR (if towards MR, see section 6.1). 416 -FN sends NS for L2 address of BR. 417 -BR replies NA. 418 -FN sends packet to BR. 419 -BR scans its routing table for LFN's address, and finds route 420 through MR; 421 -BR sends NS for MR. 422 -MR replies NA with its L2 address. 423 -BR forwards packet to MR and sends ICMP Redirect to FN such that 424 subsequent packets from FN to LFN go straight through MR and not 425 through BR. 426 -MR forwards packet to FN. 428 The sensitive issue exposed here is the way in which initially the 429 packet travels from FN to BR to MR, the dynamic addition of an 430 entry in the routing table of the FN (even if FN doesn't run a 431 routing protocol) and that subsequent packets will not go through 432 BR, but from FN to MR to LFN. 434 2. FN sends packet to LFN, mobile network visits, HA/BR colocated 435 ---- / 436 | FN | / 437 ---- ----------/ 438 | ------- | | 439 ----------------| HA/BR |---| Internet | 440 home link ------- | | 441 ----------\ 442 \ 443 \ ---- Visited link 444 --| AR |------ 445 ---- | 446 | 447 ---- ----- 448 | MR | | LFN | 449 ---- ----- 450 | | 451 --------- 452 mobile net 454 -FN scans its routing table for LFN's address, and finds default 455 route towards BR. 456 -FN sends NS for L2 address of BR. 457 -BR replies NA. 458 -FN sends packet to BR. 459 -BR scans its routing table for LFN's address, and finds route 460 through MR; 461 -BR (being an HA) scans its BC and its routing table and finds it 462 needs to encapsulate this packet towards MR's CoA. 463 -BR encapsulates through the MRHA tunnel to MR's CoA. 464 -MR decapsulates and forwards to LFN. 466 3. LFN sends packet to FN, mobile network home, HA/BR colocated 467 ---- 468 | FN | 469 ---- 470 | ------- 471 home link -------------------| HA/BR |---> Internet 472 | ------- 473 ---- ----- 474 | MR | | LFN | 475 ---- ----- 476 | | 477 mobile link --------- 479 -LFN scans its routing table for FN's address, and finds default 480 route towards MR. 481 -LFN sends NS for L2 address of MR. 482 -MR replies NA. 483 -LFN sends packet to MR. 484 -MR scans its routing table for LFN's address, and finds route 485 'on-link'; 487 -MR sends NS for FN. 488 -FN replies NA with its L2 address. 489 -MR forwards packet to FN. 491 4. LFN sends packet to FN, mobile network visits, HA/BR colocated 492 ---- / 493 | FN | / 494 ---- ----------/ 495 | ------- | | 496 ----------------| HA/BR |---| Internet | 497 home link ------- | | 498 ----------\ 499 \ 500 \ ---- Visited link 501 --| AR |------ 502 ---- | 503 | 504 ---- ----- 505 | MR | | LFN | 506 ---- ----- 507 | | 508 --------- 509 mobile net 511 -LFN scans its routing table for FN's address, and finds default 512 route towards MR. 513 -LFN sends NS for L2 address of MR. 514 -MR replies NA. 515 -LFN sends packet to MR. 516 -MR encapsulates this packet through the MRHA tunnel and sends to 517 HA. 518 -HA receives this packet and decapsulates. 519 -HA scans its routing table for FN's address, and finds route 520 'on-link'; 521 -HA sends NS for FN. 522 -FN replies NA with its L2 address. 523 -HA forwards packet to FN (on behalf of the MR). 525 5. CN sends packet to LFN, mobile network home, HA/BR co-located 526 ---- CN link 527 --| BR1|------ 528 / ---- | 529 / | 530 ----------/ ---- 531 ------- | | | CN | 532 ----------------| HA/BR |---| Internet | ---- 533 | home link ------- | | 534 ---- ----- ----------\ 535 | MR | | LFN | \ 536 ---- ----- \ 537 | | 538 --------- 539 mobile net link 541 -BR receives packet from CN towards LFN. 543 -BR scans its routing table and finds dest through MR. 544 -BR sends NS for L2 address of MR and MR replies NA. 545 -BR forwards packet to MR. 546 -MR forwards packet to LFN. 548 6. CN sends packet to LFN, mobile network visits, HA/BR colocated 550 ---- CN link 551 --| BR1|------ 552 / ---- | 553 / | 554 ----------/ ---- 555 ------- | | | CN | 556 ---| HA/BR |---| Internet | ---- 557 ------- | | 558 ----------\ 559 \ 560 \ ---- Visited link 561 --| AR |------ 562 ---- | 563 | 564 ---- ----- 565 | MR | | LFN | 566 ---- ----- 567 | | 568 --------- 569 mobile net 570 -BR receives packet from CN towards LFN. 571 -BR scans its routing table and finds dest through MR. 572 -BR scans its routing table and its BC and realizes it needs to 573 send this through the MRHA tunnel. 574 -BR sends the packet through the MRHA tunnel to MR. 575 -MR decapsulates and forwards to LFN. 577 (this is sometimes referred to as triangular routing, since the 578 packet from CN to LFN travels artificially through BR) 580 7. LFN sends packet to CN, mobile network home, HA/BR colocated 582 ---- CN link 583 --| BR1|------ 584 / ---- | 585 / | 586 ----------/ ---- 587 ------- | | | CN | 588 ----------------| HA/BR |---| Internet | ---- 589 | home link ------- | | 590 ---- ----- ----------\ 591 | MR | | LFN | \ 592 ---- ----- \ 593 | | 594 --------- 595 mobile net link 597 -MR receives packet from LFN towards CN. 598 -MR scans its routing table to and finds dest through BR. 599 -BR forwards packet to Internet towards CN. 600 -BR1 forwards packet to CN. 602 8. LFN sends packet to CN, mobile network visits, HA/BR colocated 603 ---- CN link 604 --| BR1|------ 605 / ---- | 606 / | 607 ----------/ ---- 608 ------- | | | CN | 609 ---| HA/BR |---| Internet | ---- 610 ------- | | 611 ----------\ 612 \ 613 \ ---- Visited link 614 --| AR |------ 615 ---- | 616 | 617 ---- ----- 618 | MR | | LFN | 619 ---- ----- 620 | | 621 --------- 622 mobile net 623 -MR receives packet from LFN towards CN. 624 -MR scans its tables and finds it needs to send it through the MRHA 625 tunnel. 626 -BR receives this packet, decapsulates and forwards to Internet. 627 -BR1 forwards this packet to CN. 629 (this is sometimes referred to as triangular routing, since the 630 packet from LFN to CN travels artificially through BR) 632 5.2 Scenarios with HA and BR separated 634 9. FN sends packet to LFN, mobile network home, HA separated BR 635 ---- ---- 636 | FN | | HA | 637 ---- ---- 638 | | ---- 639 home link -------------------| BR |------> Internet 640 | ---- 641 ---- ----- 642 | MR | | LFN | 643 ---- ----- 644 | | 645 mobile network link --------- 647 -FN scans its routing table for LFN's address, and finds default 648 route towards BR. 649 -FN sends NS for L2 address of BR. 650 -BR replies NA. 652 -FN sends packet to BR. 653 -BR scans its routing table for LFN's address, and finds route 654 through MR; 655 -BR sends NS for MR. 656 -MR replies NA with its L2 address. 657 -BR forwards packet to MR and sends ICMP Redirect to FN such that 658 subsequent packets from FN to LFN go straight through MR and not 659 through BR. 660 -MR forwards packet to FN. 662 10. FN sends packet to LFN, mobile network visits, HA separated BR 664 ---- ---- / 665 | FN | | HA | / 666 ---- ---- ----------/ 667 | | ---- | | 668 -------------------| BR |---| Internet | 669 home link ---- | | 670 ----------\ 671 \ 672 \ ---- Visited link 673 --| AR |------ 674 ---- | 675 | 676 ---- ----- 677 | MR | | LFN | 678 ---- ----- 679 | | 680 --------- 681 mobile net 683 -FN scans its routing table for LFN's address, and finds default 684 route towards BR. 685 -FN sends NS for L2 address of BR. 686 -BR replies NA. 687 -FN sends packet to BR. 688 -BR scans its routing table for LFN's address, and finds route 689 through MR; 690 -BR sends NS for MR. 691 -HA replies NA with its L2 address (on behalf of MR). 692 -BR forwards packet to HA and sends ICMP Redirect to FN such that 693 subsequent packets from FN to LFN go straight through MR and not 694 through BR. BR also sends ICMP Redirect to HA, such that HA knows 695 a route through MR. The logic of this last ICMP Redirect is 696 described in section 6.1. 697 -HA scans its routing table for LFN's address, and finds through MR; 698 -HA scans binding cache and finds 'through MRHA tunnel'; 699 -HA encapsulates and sends packet to MR. 700 -MR decapsulates and forwards to LFN. 702 The problem in the above case is how to inform the HA about the 703 route towards MR. When MR at home, and HA being a host, normally 704 HA doesn't have a route towards MR. See discussion in section 6.1. 706 11. LFN sends packet to FN, mobile network home, HA separated BR 707 ---- ---- 708 | FN | | HA | 709 ---- ---- 710 | | ---- 711 home link -------------------| BR |------> Internet 712 | ---- 713 ---- ----- 714 | MR | | LFN | 715 ---- ----- 716 | | 717 mobile network link --------- 719 -LFN scans its routing table for FN's address, and finds default 720 route towards MR. 721 -LFN sends NS for L2 address of MR. 722 -MR replies NA. 723 -LFN sends packet to MR. 724 -MR scans its routing table for LFN's address, and finds route 725 'on-link'; 726 -MR sends NS for FN. 727 -FN replies NA with its L2 address. 728 -MR forwards packet to FN. 730 12. LFN sends packet to FN, mobile network visits, HA separated BR 731 ---- ---- / 732 | FN | | HA | / 733 ---- ---- ----------/ 734 | | ---- | | 735 -------------------| BR |---| Internet | 736 home link ---- | | 737 ----------\ 738 \ 739 \ ---- Visited link 740 --| AR |------ 741 ---- | 742 | 743 ---- ----- 744 | MR | | LFN | 745 ---- ----- 746 | | 747 --------- 748 mobile net 750 -LFN scans its routing table for FN's address, and finds default 751 route towards MR. 752 -LFN sends NS for L2 address of MR. MR replies NA. 753 -LFN sends packet to MR. 754 -MR encapsulates this packet through the MRHA tunnel and sends to 755 HA. 756 -HA receives this packet and decapsulates. 757 -HA scans its routing table for FN's address, and finds route 758 'on-link'; 760 -HA sends NS for FN. FN replies NA with its L2 address. 761 -HA forwards packet to FN (on behalf of the MR). 763 13. CN sends packet to LFN, mobile network home, HA separated BR 765 ---- CN link 766 --| BR1|------ 767 ---- / ---- | 768 | HA | / | 769 ---- ----------/ ---- 770 | ---- | | | CN | 771 -----------------| BR |---| Internet | ---- 772 | home link ---- | | 773 ---- ----- ----------\ 774 | MR | | LFN | \ 775 ---- ----- \ 776 | | 777 --------- 778 mobile net link 780 -BR receives packet from CN towards LFN. 781 -BR scans its routing table to and finds dest through MR. 782 -BR sends NS for L2 address of MR. 783 -MR replies NA. 784 -BR forwards packet to MR. 785 -MR forwards packet to LFN. 787 14. CN sends packet to LFN, mobile network visits, HA separated BR 789 ---- CN link 790 --| BR1|------ 791 ---- / ---- | 792 | HA | / | 793 ---- ----------/ ---- 794 | ---- | | | CN | 795 ---------| BR |---| Internet | ---- 796 ---- | | 797 ----------\ 798 \ 799 \ ---- Visited link 800 --| AR |------ 801 ---- | 802 | 803 ---- ----- 804 | MR | | LFN | 805 ---- ----- 806 | | 807 --------- 808 mobile net 809 -BR receives packet from CN towards LFN. 810 -BR scans its routing table to and finds dest through MR. 811 -BR sends NS for L2 address of MR. HA replies NA on behalf of MR. 812 -BR sends Redirect to HA informing it about a route towards MR. 813 See section 6.1 on a discussion about this ICMP Redirect. 814 -Simultaneously with previous packet, BR forwards packet to HA. 816 -HA scans its routing table and finds an entry to MR (added as a 817 result to ICMP redirect), it also has a BC entry for MR, so it 818 sends the packet through the MRHA tunnel. 820 The problem in the above case is how to inform the HA about the 821 route towards MR. When MR at home, and HA being a host, normally 822 HA doesn't have a route towards MR. See discussion in section 6.1. 824 15. LFN sends packet to CN, mobile network home, HA separated BR 826 ---- CN link 827 --| BR1|------ 828 ---- / ---- | 829 | HA | / | 830 ---- ----------/ ---- 831 | ---- | | | CN | 832 -------------------| BR |---| Internet | ---- 833 | home link ---- | | 834 ---- ----- ----------\ 835 | MR | | LFN | \ 836 ---- ----- \ 837 | | 838 --------- 839 mobile net link 841 -MR receives packet from LFN towards CN. 842 -MR scans its routing table and finds dest through BR. 843 -BR sends packet to CN 845 16. LFN sends packet to CN, mobile network visits, HA separated BR 846 ---- CN link 847 --| BR1|------ 848 ---- / ---- | 849 | HA | / | 850 ---- ----------/ ---- 851 | ---- | | | CN | 852 ----------| BR |---| Internet | ---- 853 ---- | | 854 ----------\ 855 \ 856 \ ---- Visited link 857 --| AR |------ 858 ---- | 859 | 860 ---- ----- 861 | MR | | LFN | 862 ---- ----- 863 | | 864 --------- 865 mobile net 866 -MR receives packet from LFN towards CN. 867 -MR encapsulates this packet through the MRHA tunnel. 868 -HA receives this packet, decapsulates and sends to CN. 870 5.3 MR Redirects to BR 872 Also, consider the scenario where the FN has a default route 873 towards the MR instead of the BR, and sending packets to a CN on 874 the Internet. This might very well happen when the MR is at home 875 and sending RAs, in addition to the RAs sent by the BR. FN might 876 configure a default route through the MR instead of the BR. If MR 877 is at home, MR will redirect the FN towards the BR. So, even if 878 this looks like a wrong configuration on the FN (its default route 879 should point to BR and not MR), packets will still travel correctly 880 when MR is at home. This should be maintained when the MR is not 881 at home. There are two possibilities: either the HA (replacing the 882 MR) redirects the FN towards the BR, or it is the MR itself that 883 sends the respective ICMP redirect message to the FN (through the 884 MRHA tunnel). The first case supposes that HA maintains a routing 885 table, which contains routes towards the mobile network. This is 886 less desirable if the HA is not co-located with BR, and where we 887 prefer not to have routing interactions with the HA. The latter 888 case is more plausible, keeping the default routing behaviour to 889 the MR. 891 6. Informing the HA about the route to MR 893 In certain scenarios presented previously, with the HA dissociated 894 from the BR and the MR in the visited network, there is a need for 895 the HA to maintain in its routing table an entry towards the MR. A 896 scenario where packets from CN towards LFN are looping between MR 897 and HA has been described in detail in section 3.2.4 of [8]. 898 Several solutions exist to avoid this looping, described below. 900 6.1 ICMP Redirect from BR to HA 902 One alternative for avoiding the loop problem is by using ICMP 903 Redirects [19] sent by BR to HA in order to communicate to HA the 904 route it misses towards the MR. ICMP Redirects are deployed and 905 used in existing networks. The classic behaviour of ICMP Redirects 906 is presented in scenario 1. Scenarios 10 and 14 with 907 MR-not-at-home and BR dissociated from HA, present the fact that 908 classic ICMP Redirects are not triggered normally and thus 909 modifications are needed. 911 In addition to the normal behaviour with ICMP Redirects, described 912 in [19], it could be modified according to the following. The 913 decision by BR to send ICMP Redirect towards HA can be taken in at 914 least three ways: 916 -allow a number of iterations of a packet looping between HA and 917 BR and after this fixed number decide to send the Redirect to HA 918 such as the looping stops. This modifies the normal behaviour 919 of BR. 921 -another possibility is for BR to react at the moment it receives 922 the proxy NA from HA (on behalf of the MR), compare to the 923 current entry it has in the Neighbour Cache for MR, and then 924 decide that, because MR has moved away, send Redirect to HA to 925 inform HA about the route to MR. This is the route (or set of 926 routes) normally maintained by the BR with the MR, doesn't 927 contain any form of the new position (CoA) of the MR. This 928 route, or set of routes (in which case a set of Redirects are 929 sent), is copied from MR's routing table. All routes that have 930 destination the MR's home address need to be communicated to HA 931 with ICMP Redirects. This modifies the normal behaviour of BR. 933 -yet another possibility is to consider modifications on HA (from 934 vanilla Mobile IPv6), but don't touch BR, such that HA generates 935 a new packet, thus obtaining a classic ICMP Redirect from BR. 937 When the HA receives a packet that is not for itself, it 938 encapsulates it with an IP-in-IP tunnel, having the src address 939 its own address and the destination address copied from the dst 940 address of the original packet. Then try to route this packet 941 and find the default route towards BR. Then BR sends a normal 942 ICMP Redirect informing HA there is a better route for this 943 packet towards MR. Thus HA acquires the MR route dynamically. 944 The packet will be passed on by BR to HA again, and further 945 details are needed here. Remark that this is equivalent to one 946 iteration of the loop (a particular case of the fixed iterations 947 loop mentioned previously). 949 6.2 Static route method 951 This is proposed by [4] and [13], where operator statically 952 introduces a route in the HA, for MR's prefix, towards MR's 953 address, or towards the specific MRHA tunnel. 955 The first approach proposed in [4] suggests to configure a new 956 static tunnel on the MR's HA towards MR_HoA. This static tunnel, 957 that we call here MR_HoA_tunnel, is to be used as output interface 958 of a new static entry added in the routing table of HA for MR's 959 prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data 960 packet from CN addressed to a LFN, MR's HA will consult its routing 961 table and find a match for that packet for this static route since 962 LFN address matches MR's prefix. As a results it will encapsulate 963 the packet with an additional header that will have MR's HA as 964 source address and MR_HoA as destination address. In order to 965 forward this packet, now addressed to MR's Home Address, the MR 966 will first consult its binding cache and discover MR's Care-of 967 address. It will thus send the packet through the MRHA tunnel 968 towards MR's current location. It is worth mentionning that this 969 approach introduces a double encapsulation of an incoming packet to 970 be forwarded to the MR: the first is due to the MR_HoA_tunnel, the 971 second to the MRHA tunnel. 973 The second approach proposed in [13] suggests a similar method but 974 avoids the overhead introduced by the two tunnels. It consists in 975 configuring a static route in MR's HA routing table for MR's prefix 976 towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of 977 a data packet from CN addressed to a LFN, MR's HA will consult its 978 routing table and, again, find a match for that packet for this 979 static route since LFN address matches MR's prefix. This indicates 980 the MR's HA that the packet should be routed towards MR_HoA. From 981 its binding cache it discovers MR's CoA and as a consequence 982 forwards the incoming packet for CN directly through the MRHA 983 tunnel. This approach reduces the overhad of the MR_HoA_tunnel but 984 requires a suitable coordination of the routing table and binding 985 cache on the HA. 987 Analyzed from the perspective where HA is separated from BR, and 988 where MR doesn't normally maintain routes with HA, then this 989 addition might seem superfluous. Consider a situation where MR and 990 BR maintain routing information and where that manual route is 991 added on HA. When the MR is not at home, consider that 992 administrator decides to add a new fixed subnet at home, with its 993 own router neighbouring with BR on the home link. Consider the new 994 subnet's prefix being a longer prefix derived from the prefix 995 assigned to the MR's subnet. This is perfectly feasible by 996 changing configurations on the MR and BR. That can work perfectly 997 even if MR is not at home. But if HA doesn't participate in this 998 exchange (which is the case if HA separated from BR) then the 999 manual route added previously in the HA is no longer valid. Thus, 1000 a potential issue. 1002 Further explanation or simplification needed here. 1004 6.3 Dynamic route method 1006 It is possible for the HA, being either separated or co-located 1007 with the BR, to run a specific routing protocol, participating in 1008 the routing interactions between BR and all other neighbouring 1009 routers on the home link. Thus, the HA always has the necessary 1010 route it needs to join the MR's network. 1012 If the HA is a one-interface machine, and separated from the BR, it 1013 seems that it maintains information that is not always necessary to 1014 its well working as a HA. For example, it will maintain routes to 1015 all neighbouring routers, be it fixed or mobile. The routes to the 1016 fixed neighbouring routers are not necessary for its working as a 1017 host, since it suffices to only have a default route towards a BR, 1018 that will normally dynamically Redirect it towards the other fixed 1019 routers. Moreover, if HA runs a dynamic routing protocol, its 1020 route updates will never be taken into account by other routers, 1021 since they will always be one hop further than the routes already 1022 known by them. Thus it might be possible to have the HA as a 1023 silent routing, only receiving route updates from the neighbouring 1024 routers, but never sending route updates, since it does not have a 1025 network behind it (it is a "host") whose reachability it needs to 1026 advertise. 1028 RIP [11] supports having a silent host that only listens to update 1029 messages, but does not advertise new routes. With OSPF [18] the 1030 "listening only" requirement is complicated by the fact that the HA 1031 would needs to participate in OSPF's HELLO protocol. 1033 The advantage of using this solution is that it does not require 1034 additional changes to Mobile IPv6, and PSBUs are not needed. The 1035 disadvantage is that if the MR does not run a routing protocol then 1036 we still need some way of telling the HA the routes to the MNPs, 1037 which gets us back to sections 6.1 and 6.2. 1039 Further explanation or simplification needed here. 1041 7. Other Issues 1043 7.1 Link-local addresses 1045 When the MR is at home, and if it runs a dynamic routing protocol, 1046 it exchanges routing information with BR, by using its link-local 1047 address and BR's link-local address. When the MR is not at home, 1048 and HA defends the MR's home address, the HA is normally doing this 1049 for any type of addresses except link-locals. The immediate 1050 necessity would be for the HA to defend a link-local address of the 1051 MR, instead of a global-scoped home address. However, this is in 1052 conflict with the necessity of dynamic routing protocols to use 1053 link-local addresses only. 1055 According to section 6.3 of Mobile IPv6 spec [] the HA will not 1056 allow re-direction of traffic of a Home Address towards a CoA, when 1057 that Home Address is link-local. 1059 Even more concrete, section 6.3 of MIPv6 says that it is not 1060 possible to put a ll-address in a HA option. Of course this is 1061 equivalent. 1063 Another issue concerning link local addresses: the MR has routes to 1064 the BR using BR's link local address. When the MR is away from 1065 home: how does the MR reach BR's link local address? How does it 1066 tell the difference between a link local address on the home link 1067 and a link local address on the visited link? 1069 Moreover, Mobile IPv6 forbids re-directing (through the MHHA 1070 tunnel) of packets addressed to a multicast address with 1071 link-scope. RIP uses this extensively. 1073 7.2 MR as an MN 1075 If the MR is at home and it has an address configured on the moving 1076 interface other than a link-local address, then the MR can act as 1077 an MH too, and send normal Mobile IPv6 BUs, binding that Home 1078 Address to a newly configured CoA; thus allowing the MR to be an MH 1079 for itself only, ignoring the LFNs. If the MR at home doesn't have 1080 other addresses than link-local on the mobile interface then the MR 1081 can not send normal Mobile IPv6 BUs and can not be an MH. It can 1082 however be an MR for the hosts on the mobile network. 1084 7.3 Prefix-based routing and host-based routing 1086 Prefix-based hierarchical routing (where the mobile network link 1087 has a prefix that is a subset of the home-network link) is the 1088 preferred type of routing for IPv6. Practically though, it is 1089 possible for the BR to have a routing table entry containing the 1090 prefix of the mobile network, as well as a host-based entry that 1091 points to a certain LFN also in the mobile network. Those two 1092 entries might or might not have the same common sub-prefix. With a 1093 MR at home, being a normal router, BR will know how to forward to 1094 all hosts behind the MR as well as only to the specific LFN of the 1095 host-based route. This behaviour should be maintained when the MR 1096 is no longer at home and when it has a bidirectional tunnel MRHA. 1098 7.4 Multicast subscriptions of the MR 1100 When the MR is at home, it normally joins certain multicast groups 1101 related to routing (e.g. all-routers multicast group with site 1102 scope). This is assumed by dynamic routing protocols, or by 1103 renumbering mechanisms. When the MR is no longer at home, its 1104 multicast subscription should continue as if it were at home. This 1105 can be achieved by "home subscription" techniques considered in 1106 relation with Mobile IPv6. 1108 7.5 Neighbour Discovery for MR 1110 When MR is at home and sends RA towards the home link, it should 1111 not advertise itself as being capable of being a default router 1112 (Router Lifetime should be 0). 1114 When the MR is visiting, it should not respond to RSs sent on the 1115 visited link and it should not send RAs on the visited link. 1117 When the MR is at home, it doesn't normally use any information 1118 received from RAs sent by a neighbouring router, i.e. the BR. It 1119 has a link-local address and if it has a larger scope address 1120 configured on an interface, then that is normally done manually. 1121 Actually, routers are usually prohibited from using information 1122 received in RAs more than for logging and synchronization purposes. 1123 When the MR is in a foreign network, it needs a way to configure a 1124 Care-of Address. In the hosts case this is done by stateless or 1125 stateful autoconf. In the MR case, the stateful is possible, while 1126 the stateless is normally prohibited. A good way for address 1127 autococnfiguration for the MR should be identified, be it DHCP, or 1128 modified RAs, or modified router's behaviour to accept RAs. 1130 Assume the MR is at home and a non-link-local (site- or global) 1131 home address is configured on the interface connecting to the home 1132 link (supposedly the same interface that will change CoAqs when 1133 visiting). The MR-at-home will do periodic NAs for this home 1134 address; this behaviour should stop when MR is visiting. This 1135 modified behaviour is already taken into consideration by Mobile 1136 IPv6 MN. In the particular MR case, most ND operations of MR are 1137 delegated to the HA, and such most entries of Neighbour Cache, 1138 Destination Cache that are related to the home link will disappear. 1139 New entries that are relevant in the foreign network will populate 1140 those tables. When coming back home, all ND entries should be 1141 replaced back with the entries related to the home network. 1143 Another specific case in point is the default route. As already 1144 presented with the router behaviour with respect to RAs, a default 1145 route is not normally configured by MR from a received RA. When 1146 the MR is in a foreign network, it should have a default route that 1147 points to its BR (but through the MRHA tunnel) and another 1148 non-tunnelled default route towards the current AR. Moreover, all 1149 MR's routing table entries that pointed to BR when the MR was at 1150 home, should still continue to point to BR (through the MRHA 1151 tunnel). The same is true for all routing table entries of the BR. 1153 7.6 Separation of routing and mobility for MR 1155 The necessity of the separation between mobility vs. routing 1156 exchanges holds true irrespective to whether dynamic or static 1157 routing is used. If static routing is used, then BR has routes 1158 towards the mobile network through the MR, and MR has routes 1159 towards the Internet through the BR. If dynamic routing is used, 1160 then the MR and BR dynamically exchange routing information that is 1161 manually configured in the routing configuration files of MR and of 1162 BR, as well as routing information that is delivered by other 1163 routers external to the home network (be it beyond the BR or beyond 1164 the MR). The entities concerned with routing in the home network 1165 are only BR and MR. This behaviour should continue when network 1166 mobility is introduced, presumably by deploying an HA (but not 1167 touching the BR). MR and HA should exchange only the information 1168 related to mobility but not the information related to routing. 1170 7.7 Router Renumbering 1172 Router Renumbering for IPv6 [7] is a technique where routers of a 1173 home network are instructed to change the prefixes they advertise. 1174 In the context here, it should be possible for the MR to be 1175 re-numbered when it is at home as well as when it is visiting. 1177 The renumbering mechanisms provided by Mobile IPv6 (mobile prefix 1178 solicitations and advertisements) are not relevant for changing the 1179 prefixes advertised by the MR towards the mobile network; but these 1180 mechanisms should still be used for MR when MR is acting as an MH. 1181 In order for router renumbering to work for MR when acting as MR, 1182 the MR should at least be able to maintain its multicast 1183 subscription to all-routers group valid at home. 1185 7.8 IPv4 issues 1187 The mechanisms and issues described in this draft for IPv6 mobile 1188 networks can be applied for IPv4 network mobility as well. RFC 1189 3344 [21] provides important intuititve support for IPv4 network 1190 mobility through the 'R' bit in Registration Requests/Replies. 1191 Some solutions have already been successfully tested in [4] and 1192 [14]. The support provided in RFC 3344 [21] as well as those 1193 solutions keep the HA co-located with the BR. In a general case in 1194 which the BR and HA are kept on separate machines (scenarios 9 to 1195 16 in Section 5.2) the same issues as in IPv6 apply to the IPv4 1196 case. 1198 Additionally, in Mobile IPv4 there is a distinction between the MN 1199 and FA functionality, and it is possible to have the FA separated 1200 from the MN, whereas in IPv6 MN and FA are always co-located. This 1201 gets us to the following additional cases: 1203 -When the MR is in a visited network it can send BU's using a 1204 co-located care-of address or a Foreing Agent care-of address 1205 if an FA is available. In the latter case, two reverse 1206 tunneling modes are possible: direct delivery style and 1207 encapsulated delivery style [17]. 1209 -The MR may be itself a FA for Leaf Mobile Nodes (LMNs), or the 1210 mobile network may contain a FA for LMNs. 1212 Some of these issues have been identified in [22]. 1214 8. Mobile Router behaviour 1216 The MR-HA tunnel is an IP-in-IP tunnel maintained by MR and HA. 1217 This is not a "tunnel" in the sense referred to sometimes by 1218 employing the IPv6 routing headers. 1220 The behaviour of the Mobile Router is the behaviour of a normal 1221 router with the main exception of the order of search in relevant 1222 routing tables, with the addition of a step to search in the MRHA 1223 tunnel table. The exact search steps will be detailed later. 1224 Various implementations do it in various ways. 1226 A generic behaviour of a router forwarding a packet having 1227 destination d, or the behaviour of MR when it is at home: 1228 -determine the packet is for itself or not, by comparing d to all 1229 addresses assigned to all interfaces. 1230 -if not for itself then search the routing table for a prefix that 1231 matches d under a prefix. Pick d2. 1232 -search the destination cache for an exact match for d2. If found, 1233 then send the packet to the L2 address in the DC entry. If not 1234 found, then create it by doing the ND exchange; then send it to 1235 what ND found. 1237 From that behaviour, here is the modified mobile router behaviour: 1238 -determine the packet is for itself or not, by comparing d to all 1239 addresses assigned to all interfaces. 1240 -if not for itself then search the routing table for a prefix that 1241 matches d under a prefix. Pick d2. 1242 +determine whether this entry in the routing table has a 1243 corresponding entry in the MRHA tunnel table. If yes, then 1244 encapsulate towards the HA marked there and create a new packet, 1245 with source s CoA and new destination d from the tunnel table 1246 (Home Agent address). 1247 -search the destination cache for an exact match for d2, and that 1248 is not linked to the tunnel table. If found, then send the packet 1249 to the L2 address in the DC entry. If not found, then create it 1250 by doing the ND game; then send it to what ND found. 1252 8.1 CoA Configuration 1254 This can be done by configuring an address based on a prefix 1255 received from the AR. However, routers don't take into account 1256 RAs, normally. It can be solved by saying that in this case MR is 1257 not quite a router but more of a host. 1259 It can also be done by means of DHCPv6 messaging, where there is no 1260 distinction between hosts and routers. 1262 8.2 Discovering HA 1264 Do it as a Mobile IPv6 MH, except that. Anycast. 1266 8.3 Sending BUs to HA 1268 Do the normal Mobile IPv6 signalling with its Home Agent. The BUs 1269 sent contain a distinguishing bit 'R'. 1271 8.4 Search order in various tables 1273 Further complicating the mobile routing issues, the Destination 1274 Cache is being specified with the option of being capable of being 1275 fusioned with the Routing Table. The same stands for the Binding 1276 Cache. It is then possible to have the DC, the BC and the routing 1277 table as a unique and only large routing table. With this kinds of 1278 unknowns, it is difficult for the authors, at present time, to 1279 specify a proper search order in the respective structures, even if 1280 we feel this is truly important. Or probably the behaviour of a MR 1281 and HA can be specified without going into the details of these 1282 structures, leaving implementations freedom of choice. 1284 9. Home Agent behaviour 1286 The MR-HA tunnel is an IP-in-IP encapsulation tunnel [20] 1287 maintained by MR and HA. This is not a "tunnel" in the sense 1288 referred to sometimes by employing the IPv6 routing headers. 1290 The behaviour of the Home Agent is the behaviour of a normal Mobile 1291 IPv6 HA with the main exception of the order of search in relevant 1292 routing tables, with the addition of a step to search in the MRHA 1293 tunnel table. The exact search steps will be detailed. 1295 The Home Agent uses proxy-ND to defend the link-local address of 1296 the MR when the MR is not at home. When the MR is at home, the HA 1297 stops defending MR's link-local address. 1299 When the MR is not at home, the L2 address of the link-local 1300 address of the MR is requested by neighbouring routers (such as BR) 1301 or by FNs that have entries in their routing tables or destination 1302 caches through MR's link-local address. HA should reply to these 1303 requests with its own L2 address and as such receive all packets 1304 that have dst address containing any address of all hosts and 1305 routers in the mobile network. Following this, the HA will search 1306 its BC as well as its routing table, then it will encapsulate those 1307 packets through the MRHA tunnel and sent according to the normal 1308 HA's destination cache and routing tables, towards the current 1309 Care-of Address of the Mobile Router. 1311 When HA is a host, HA doesn't need to have a routing table 1312 containing entries towards MR or hosts and routers behind MR. When 1313 HA is a host, HA's routing table should contain only entries 1314 related to the neighbouring fixed routers. For example HA has a 1315 default route towards BR. 1317 10. Route Optimization 1319 Route Optimization problem description is elsewhere. 1321 RO is an absolutely necessary need for mobile networks for Mobile 1322 IPv6. 1324 It might very well be that the need for RO might bring with it the 1325 need to put prefixes in the BUs towards CN. 1327 The previous scenarios allow for nested mobile networks as well. 1328 But the functioning suffers of drawbacks. 1330 The MRHA-enhanced Mobile IPv6 scenarios described previously suffer 1331 from important drawbacks, such as multiple nested tunnels, lack of 1332 route optimization with the CN. 1334 An example of an important inconvenient of using exclusively 1335 vanilla Mobile IPv6 with MRHA is when nesting: consider two mobile 1336 networks, each MR having its own HA in different domains. The 1337 first MR attaches to an AR and the second MR attaches under the 1338 first mobile network. In this case, two LFNs situated one on the 1339 first net and the second on the second net are capable to 1340 communicate with each other, but communication goes through both 1341 first MR's HA and through second's. In practice this exposes a 1342 paradox where if first MR loses connection to AR, then even if the 1343 two nets stay attached, the two LFNs can not communicate. 1345 11. Security Considerations 1347 Security threat analysis of Mobile IPv6 when a Mobile Router is 1348 used instead of a Mobile Host. Not a threat analysis of RO. 1350 The threat analysis of Mobile IPv6 for hosts is presented in [10]. 1351 When router moves instead of host, new threats appear. 1353 When MR at home and using secured RIP [3] or OSPF [18] (whose IPv6 1354 version [5] employs IPsec), then that level of security must be 1355 maintained when MR is away from home. 1357 11.1 Security of the MRHA tunnel 1359 The MRHA tunnel is protected as required by the Mobile IPv6 1360 specification for the MNHA tunnel [2]. 1362 MR and HA maintain a security association, share the same key. 1364 11.2 Security for Route Optimization 1366 Since RO is not treated in this document, then the return 1367 routability tests for MR are not described. 1369 MR could do CoTI for MR's CoA and HoTI for LFN's address. In that 1370 case LFN's address must be bound to MR, presumably by delegation 1371 mechanisms. 1373 MR if acting as an MN must do HoTI/CoTI for itself, if that MN 1374 needs RO. If MR acting as MN, then its LFNs must not take 1375 advantage of the results of having an SA MN-CN. Or if they do, 1376 then MR must have some form of delegation support. 1378 Acknowledgements 1380 Some of the issues presented in this document have not yet been 1381 discussed publicly, as far as the authors are aware, except for the 1382 places where specific references to prior drafts is explicitely 1383 made. Some of the issues have been discussed on the nemo mailing 1384 list, and proper acknowledgment will be given here. This document 1385 being submitted for public review, all comments are welcome and 1386 contributors will be properly acknowledged. 1388 Intellectual Property Rights Considerations 1390 Consult Motorola on IPRs. Put the url here. 1392 Changes 1394 October 2002: revision 00 submitted. 1395 November 2002: revision 01: 1396 -added discussion on multicast addresses with link-local scope. 1397 -added Chairs' addresses. 1398 -modified the abstract to better express the fact that /128s are 1399 probably sufficient. 1400 -added section on v4 issues, and Mobile IPv4 issues. 1401 -added an empty IPR section. 1403 References 1405 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1406 Levels", BCP 14, RFC 2119, March 1997 1408 [2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using 1409 IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes 1410 and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, 1411 IETF Internet Draft, October 2002. (Work in Progress). 1413 [3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC 1414 2082, January 1997. 1416 [4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed 1417 October 25, 2002 at 1418 http://www.cisco.com/univercd/cc/td/doc/product/software/ 1419 ios122/122newft/122t/122t4/ftmbrout.pdf 1421 [5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 1422 2740, December 1999. 1424 [6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6 1425 Specification", RFC 2473, December 1998. 1427 [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 1428 2000. 1430 [8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic, 1431 Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks 1432 Support in Mobile IPv6", 1433 draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft, 1434 March 2002. (Work in Progress). 1436 [9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support 1437 Terminology", draft-ernst-nemo-terminology-00.txt, IETF 1438 Internet Draft, October 2002. (Work in Progress). 1440 [10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark, 1441 E., Patil, B. and Roberts, P., "Threat Models introduced by 1442 Mobile IPv6 and Requirements for Security", 1443 draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet 1444 Draft, November 2001. (Work in Progress). 1446 [11] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1447 1998. 1449 [12] Johnson, David B., Perkins, Charles E. and Arkko, Jari, 1450 "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, 1451 IETF Internet Draft, June 2002. (Work in Progress). 1453 [13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay, 1454 "Mobile Router Support with Mobile IP", 1455 draft-kniveton-mobrtr-02.txt, IETF Internet Draft, July 1456 2002. (Work in Progress). 1458 [14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart, 1459 D. H. and Bell, T. L. and Kachmar, B. A., "Application of 1460 Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs 1461 of the Aerospace Conference, 2001. 1463 [15] Malkin, G., "RIP Version 2, Carrying Additional Information", 1464 RFC 1723, November 1994. 1466 [16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997. 1468 [17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP, 1469 revised", RFC 3024, January 2001. 1471 [18] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1473 [19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery 1474 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1476 [20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1477 1996. 1479 [21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, 1480 August 2002. 1482 [22] Sarikaya, B., "Architectural Requirements for Base Network 1483 Mobility Using Bidirectional Tunneling", 1484 draft-sarikaya-nemo-archreqs-00.txt, IETF Internet Draft, 1485 October 2002. (Work in Progress). 1487 Chairs' Addresses 1489 Thierry Ernst, Timothy J. Kniveton 1490 French National Institute for Communication Systems Lab 1491 Research in Computer Science and Nokia Research Center 1492 Control 313 Fairchild Drive 1493 Visiting Researcher at WIDE Mountain View, California 94043 1494 Project USA 1495 Jun Murai lab. Faculty of Phone: +1 650 625-2025 1496 Environmental Information, EMail: timothy.kniveton@nokia.com 1497 Keio University. Fax: +1 650 625-2502 1498 5322 Endo, Fujisawa-shi, Kanagawa 1499 252-8520, Japan. 1500 Phone : +81-466-49-1100 1501 Fax : +81-466-49-1395 1502 E-mail: ernst@sfc.wide.ad.jp 1503 Web: 1504 http://www.sfc.wide.ad.jp/~ernst/ 1506 Authors' Addresses 1508 Alexandru Petrescu Miguel Catalina-Gallego 1509 Motorola Labs Motorola Labs 1510 Espace Technologique de St Aubin Espace Technologique de St Aubin 1511 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1512 France France 1513 Phone: +33 1 69354827 Phone: +33 1 69352541 1514 Alexandru.Petrescu@motorola.com Miguel.Catalina@motorola.com 1516 Christophe Janneteau Hong-Yon Lach 1517 Motorola Labs Motorola Labs 1518 Espace Technologique de St Aubin Espace Technologique de St Aubin 1519 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1520 France France 1521 Phone: +33 1 69352548 Phone: +33 1 69352536 1522 Christophe.Janneteau@motorola.com Hong-Yon.Lach@motorola.com 1524 Alexis Olivereau 1525 Motorola Labs 1526 Espace Technologique de St Aubin 1527 Gif-sur-Yvette 91193 1528 France 1529 Phone: +33 1 69352516 1530 Alexis@motorola.com 1532 Copyright (C) The Internet Society (2002). All Rights Reserved. 1534 This document and translations of it may be copied and furnished to 1535 others, and derivative works that comment on or otherwise explain it 1536 or assist in its implementation may be prepared, copied, published and 1537 distributed, in whole or in part, without restriction of any kind, 1538 provided that the above copyright notice and this paragraph are 1539 included on all such copies and derivative works. However, this 1540 document itself may not be modified in any way, such as by removing 1541 the copyright notice or references to the Internet Society or other 1542 Internet organizations, except as needed for the purpose of developing 1543 Internet standards in which case the procedures for copyrights defined 1544 in the Internet Standards process must be followed, or as required to 1545 translate it into languages other than English. 1547 The limited permissions granted above are perpetual and will not be 1548 revoked by the Internet Society or its successors or assigns. 1550 This document and the information contained herein is provided on an 1551 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1552 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1553 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1554 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1555 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1557 Funding for the RFC editor function is currently provided by the 1558 Internet Society.