idnits 2.17.1 draft-petrescu-nemo-mrha-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 31) being 60 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 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 2003) is 7496 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: '2' is defined on line 455, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 460, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 471, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 487, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 523, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-03 ** 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' -- 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-20 -- 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' == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-01 Summary: 9 errors (**), 0 flaws (~~), 13 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-03.txt M. Catalina-Gallego 3 Expires: April 2004 C. Janneteau 4 H.-Y. Lach 5 A. Olivereau 6 Motorola 8 October 2003 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 describes several issues relevant to the design of a 37 network mobility support solution that relies on the bi-directional 38 tunnel between Mobile Router and Home Agent, with Mobile IP. 39 Examples of issues are: conflicting Mobile IP and RIPng/OSPF 40 requirements on link-local addresses, HA/BR co-location, 41 disconnected operation and "cross-over" tunnels. 43 Table of Contents 45 Status of this Nemo................................................i 46 Abstract...........................................................i 47 Conventions Used in this Document.................................ii 48 1. Introduction....................................................1 49 2. Definitions.....................................................1 50 3. NEMO "Basic" preliminary descriptions...........................1 51 4. Issues..........................................................2 52 4.1 Implementation-independent specification terms...............2 53 4.2 Allow for deployment flexibility.............................3 54 4.3 Dynamic routing protocol and the HA..........................3 55 4.4 Link-local addresses.........................................3 56 4.5 Mobile Router as a Mobile Host...............................4 57 4.6 Neighbour Discovery for MR's egress interface................4 58 4.7 Separation of routing and mobility for MR....................5 59 4.8 Prefix-based routing and host-based routing exceptions.......5 60 4.9 IPv4 Issues..................................................5 61 4.10 "Cross-over" tunnels........................................6 62 5. Security Considerations.........................................6 63 5.1 A tool: HA ingress filtering.................................6 64 Acknowledgements...................................................7 65 References.........................................................7 66 Changes............................................................9 67 A. Motivation for Full Addresses in Binding Updates................9 68 A.1 Description of a Home Network................................9 69 A.2 Scenarios...................................................11 70 A.2.1 Manual Mobile Networks..................................11 71 A.2.2 Scenarios with Co-located HA and BR.....................12 72 A.2.3 Scenarios with HA and BR Separated......................16 73 A.3 MR Redirects to BR..........................................21 74 A.4 Informing the HA about the Route to MR......................21 75 A.4.1 ICMP Redirect from BR to HA.............................22 76 A.4.2 Static Route Method.....................................22 77 A.4.3 Dynamic Route Method....................................24 78 B. Examples and Other Issues......................................24 79 B.1 Example of issue for Mobile Router as Mobile Host...........24 80 B.2 Multicast Subscriptions of the MR...........................25 81 B.3 Examples of issues for Neighbour Discovery for MR...........25 82 B.4 Router Renumbering..........................................26 83 B.5 Example of disconnected operation issue.....................26 84 B.6 Example for the "cross-over" tunnels issue..................26 85 B.7 Example of use of HA ingress filtering......................29 86 C. A Digression...................................................29 87 Intellectual Property Rights Considerations.......................29 88 Chairs' Addresses.................................................30 89 Authors' Addresses................................................30 90 Copyright Notice..................................................31 92 Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 96 this document are to be interpreted as described in RFC-2119 [1]. 98 1. Introduction 100 This document describes several issues relevant to the design of a 101 network mobility support solution that relies on the bi-directional 102 tunnel between Mobile Router and Home Agent, with Mobile IP. 103 Examples of issues are: conflicting Mobile IP and RIPng/OSPF 104 requirements on link-local addresses, HA/BR co-location and 105 "cross-over" tunnels. 107 The Mobile Router is using Binding Updates, Binding 108 Acknowledgments, Binding Requests and Binding Errors with the Home 109 Agent to maintain the MRHA bidirectional tunnel. 111 The document is organized as follows: the next section presents a 112 short perspective on three preliminary proposals for a NEMO "Basic" 113 type of solution; the following section lists the issues that 114 appear in this type of protocols. Two additional sections, or 115 appendices, give more detail of issues by way of motivations, 116 examples and other related issues. 118 2. Definitions 120 Complete NEMO terminology can be found in [9]. 122 MH: a mobile host, which is a mobile node (MN) as defined by Mobile 123 IPv6, except all router parts. In Mobile IPv6 terminology, MN 124 can be either a host or a router. An MH can only be a host. 126 MR_HoA: mobile router's Home Address, or the home address of the 127 mobile (egress) interface of the mobile router. 129 MNP: mobile network prefix, or the prefix of the link of the mobile 130 network that will move away. Note that in the most general 131 case a single MR may route multiple prefixes, in which case 132 there would be multiples MNPs per one mobile network. 134 FN: fixed node on the home link. It doesn't stand for fixed 135 network. 137 3. NEMO "Basic" preliminary descriptions 139 An exhaustive description of the proposals to support mobile 140 networks or mobile routers with Mobile IP bi-directional tunnel can 141 hardly fit in the usual space reserved for an Internet Draft, which 142 is traditionally a short document. We retain three main 143 descriptions: Cisco Mobile IPv4 for Mobile Routers [4], MRTP [13] 144 and the "Basic" approach [22]. 146 MRTP is a method of enabling mobile routers by using dynamic tunnel 147 registrations between the AR's point of attachment and its HA. 148 This tunnel allows the HA to tunnel all traffic for the mobile 149 network prefix to the MR, and also lets the MR forward all mobile 150 network traffic back to the home network, where it is topologically 151 correct, and can avoid ingress routing in the visited network. 152 MRTP does not suffer from the authorization problem of how to show 153 that the MR owns the routing authority for the Mobile Network. 155 The approach relies on the bidirectional tunnel between MR and HA. 156 The solution proposed is valid for Mobile IPv6 as for Mobile IPv4. 157 The MR and HA behaviours still represent a sensitive departure from 158 the Mobile IPv6 protocol in that MR informs its HA directly about 159 the tunnel interface and dynamically triggers additions of routing 160 table entries in the HA's routing table for the MR's tunnel. In 161 addition, the most recent version of the draft proposes usage of 162 the PSBUs in order to inform the HA about the prefix of the mobile 163 network (thus a combination with the PSBU approach). Moreover, the 164 considerations about dynamic routing in this draft refer only to 165 how dynamic routing would work with a MR, but not about the 166 necessity of running a routing protocol between HA and MR. 168 In the Mobile IPv4 case, the network mobility support with the MRHA 169 tunnel has been reported at least by various teams at Cisco [4] and 170 NASA [14]. 172 The Basic protocol proposed in [22] takes a different tack at 173 assigning the home addresses: it assigns it to the MR's ingress 174 interface, instead of the egress interface. In addition, it 175 proposes a two step approach for the search algorithm in the HA's 176 binding cache: the first step is a search based on a key that is a 177 full /128 address, while the second step is a search based on 178 longest-prefix match. A new aspect is that this proposals relies 179 also on a (yet to be developped) prefix delegation scheme where the 180 HA assigns the mobile network prefix to MR, in a dynamic manner. 182 For a more detailed analysis on the first two approaches (MRTP and 183 Cisco Mobile Routers) see sections A.4.2 and A.4.3. 185 4. Issues 187 The following is a list of issues that we believe might be relevant 188 when designing a Basic type of solution by the NEMO WG. Some of 189 the issues are exemplified in the Appendices. 191 4.1 Implementation-independent specification terms 193 The specification of the basic network mobility support should be 194 expressed with implementation-independent terms. In other words, 195 clear distinction should be made between the specification of the 196 protocol and a description of a possible implementation of this 197 protocol. Especially, since it is to be based on Mobile IP(v6), the 198 basic NEMO support specification should not make any assumption on 199 how Mobile IP(v6) is implemented but instead re-use (and possibly 200 extend) data structures from the Mobile IP(v6) specification 201 (e.g. Binding Cache), and eventually introduce new ones if 202 needed. Below are two examples of how attention should be payed in 203 the specification of the protocol. 205 The bi-directional approach requires MR's HA to configure a 206 "forwarding information" for the mobile network prefix towards the 207 mobile router. Since the Mobile IP(v6) specification introduces a 208 dedicated structure, so-called Binding Cache, to store 209 mobility-related "forwading information" on the HA, the 210 specification of basic NEMO support should re-use/extend the 211 Binding Cache to include the new mobility-related "forwarding 212 information" for a mobile network. Even though a Binding Cache may 213 be implemented as an extension of a routing table, the 214 specification should relate to the Binding Cache and not the 215 routing table. For instance, the specification should relate to 216 the "forwading information" to be configured on MR's HA for the 217 mobile network prefix in terms of a prefix entry in the Binding 218 Cache instead of an entry in the routing table of MR's HA. 219 Especially, Mobile IP(v6) specification does not specify any 220 routing table for a HA. 222 Similarly, the specification should not assume that a tunnel, 223 e.g. the MRHA bi-directionnal tunnel, is visible as a virtual 224 network interface on the MR or HA. This is an 225 implementation-related consideration that may not be true for all 226 IP(v6)/MobileIP(v6) stacks. 228 Such considerations will allow to clearly draw the line between the 229 specification and a description of a possible implementation, and 230 as a result ease any future implementation of the basic NEMO 231 support as an extention of an existing Mobile IPv6 implementation. 233 4.2 Allow for deployment flexibility 235 The basic NEMO support specification should not assume MR's HA to 236 be co-located with the Border Router (BR) of MR's home network. The 237 HA should be allowed to be a one-interface machine, separated from 238 BR, that does only NEMO HA functionalities (as a Mobile IP(v6) HA 239 can be). This way, HA can be deployed in a home domain without the 240 need to upgrade deployed BRs offering an easy deployment path. 242 4.3 Dynamic routing protocol and the HA 244 Considering the case of a HA deployed as a one-interface machine 245 not co-located with BR, the basic NEMO support specification should 246 not mandate the HA to run a routing protocol, even in situation 247 when MR runs a routing protocol. On the other hand, such HA should 248 allow MR and BR to continue running the dynamic routing protocol as 249 if MR was at home. Suffices it for the HA to: (1) join the 250 corresponding multicast address, intercept all packets addressed to 251 the link-local address of MR and encapsulate towards current MR CoA 252 and (2) relay, or forward, towards BR all dynamic routing message 253 exchanges coming from MR. 255 4.4 Link-local addresses 257 According to section 10.4.2 of Mobile IPv6 spec [12] the HA will 258 not allow re-direction of traffic of a Home Address towards a CoA, 259 when that Home Address is link-local. Two relevant paragraphs: 261 "However, packets addressed to the mobile node's link-local 262 address MUST NOT be tunneled to the mobile node." 264 "Multicast packets addressed to a multicast address with 265 link-local scope [], to which the mobile node is subscribed, 266 MUST NOT be tunneled to the mobile node;" 268 which exposes, of course, the very nature of link-local addresses: 269 they are local, not going anywhere. 271 On another hand, OSPF for IPv6 [5] requires that: 273 "On all OSPF interfaces except virtual links, OSPF packets are 274 sent using the interface's associated link-local unicast address 275 as source." 277 Moreover, RIPng [16] requires that: (1) next hop addresses in 278 routing tables managed by RIPng be link-local and (2) a large part 279 of RIPng messages be originated and adressed to link-local 280 addresses: 282 "An address specified as a next hop must be a link-local 283 address." 285 or 287 "Response Messages: [...] the source of the datagram must be a 288 link-local address." 290 or 292 "Generating Response messages: [...] The IPv6 source address 293 must be a link-local address of the possible addresses of the 294 sending router's interface, except when replying to a unicast 295 Request Message from a port other than the RIPng port." 297 Overall, keeping in mind that Mobile IPv6 is not dealing with 298 link-local home addresses and that routing protocols and forwarding 299 process make substantial use of link-local addresses, the issue is 300 clearly how to make the routing protocols work together with Mobile 301 IPv6. Basic NEMO support specification should enable redirection of 302 traffic destined to MR's link-local addresses. 304 4.5 Mobile Router as a Mobile Host 306 There are several scenarios that involve an MR that needs to act as 307 a MH too, that is, send normal BUs and use existing Mobile IPv6. 308 Applications running on the MR should take advantage of MR's 309 session continuity and universal reachability at its home address. 310 For more example issues see section B. 312 4.6 Neighbour Discovery for MR's egress interface 314 Neighbour Discover on the MR's egress interface is particularly 315 delicate in that Neighbour Discovery should act differently when MR 316 is at home and when MR is in a foreign network. A simple example 317 is that when MR is at home, it has little reason to listen to RAs. 318 However, when MR is in a foreign network, receiving RAs is very 319 important in order to have a good working of Mobile IPv6. For more 320 example issues see section B. 322 4.7 Separation of routing and mobility for MR 324 The necessity of the distinction between mobility vs. routing 325 exchanges holds true irrespective to whether dynamic or static 326 routing is used. If static routing is used, then BR has routes 327 towards the mobile network through the MR, and MR has routes 328 towards the Internet through the BR. If dynamic routing is used, 329 then the MR and BR dynamically exchange routing information that is 330 manually configured in the routing configuration files of MR and of 331 BR, as well as routing information that is delivered by other 332 routers external to the home network (be it beyond the BR or beyond 333 the MR). The entities concerned with routing in the home network 334 are only BR and MR. This behaviour should continue when network 335 mobility is introduced, presumably by deploying an HA (but not 336 touching the BR). MR and HA should exchange only the information 337 related to mobility but not the information related to routing. 339 4.8 Prefix-based routing and host-based routing exceptions 341 Prefix-based hierarchical routing (where the mobile network link 342 has a prefix that is a subset of the home-network link) is the 343 preferred type of routing for IPv6. Practically though, it is 344 possible for the BR to have a routing table entry containing the 345 prefix of the mobile network, as well as a host-based entry that 346 points to a certain LFN also in the mobile network. Those two 347 entries might or might not have the same common sub-prefix. With a 348 MR at home, being a normal router, BR will know how to forward to 349 all hosts behind the MR as well as only to the specific LFN of the 350 host-based route. This behaviour should be maintained when the MR 351 is no longer at home and when it has a bidirectional tunnel MRHA. 353 4.9 IPv4 Issues 355 The mechanisms and issues described in this draft for IPv6 mobile 356 networks can be applied for IPv4 network mobility as well. RFC 357 3344 [21] provides important intuititve support for IPv4 network 358 mobility through the 'R' bit in Registration Requests/Replies. 359 Some solutions have already been successfully tested in [4] and 360 [14]. The support provided in RFC 3344 [21] as well as those 361 solutions keep the HA co-located with the BR. In a general case in 362 which the BR and HA are kept on separate machines (scenarios 9 to 363 16 in section A.2.3) the same issues as in IPv6 apply to the IPv4 364 case. 366 Additionally, in Mobile IPv4 there is a distinction between the MN 367 and FA functionality, and it is possible to have the FA separated 368 from the MN, whereas in IPv6 MN and FA are always co-located. This 369 gets us to the following additional cases: 371 -When the MR is in a visited network it can send BU's using a 372 co-located care-of address or a Foreing Agent care-of address 373 if an FA is available. In the latter case, two reverse 374 tunneling modes are possible: direct delivery style and 375 encapsulated delivery style [17]. 377 -The MR may be itself a FA for Leaf Mobile Nodes (LMNs), or the 378 mobile network may contain a FA for LMNs. 380 4.10 "Cross-over" tunnels 382 Two MR-HA tunnels are "crossing over" each other when the path 383 between one tunnel's endpoints includes only one of the other 384 tunnel's endpoints. 386 Support of nested mobile networks is possible only when the path 387 from MR2 to MR1's HA does not go through MR1 (path considered when 388 both mobile routers are at home and no tunnels are in place). 390 An example of the dynamics of two MR-HA crossing tunnels is given 391 in section B.6. 393 5. Security Considerations 395 A detailed threat analysis is to be performed for a NEMO "Basic" 396 type of solution. But that's what the Charter says anyways. 398 One issue is related to when the MR runs a dynamic routing 399 protocol. In that case, MR is able to inform the routers in the 400 home domain about new routes (or "inject" routes in the home 401 domain). Considering that MR might be a small device, not locked 402 in a highly secured room, not a tamper-proof device, potentially 403 being stolen, then it is clear that the ability to introduce routes 404 in the home domain, and worse, propagating upper to backbones, is 405 inducing serious risks. 407 It is possible that HA and MR belong to a same administrative 408 domain. It is also possible that HA and MR belong to different 409 administrative domains. In the latter case, there might be 410 important security risks, and routing instability risks. For one, 411 if MR advertises a prefix towards HA, HA accepts it and propagates 412 it upper stream then an important instability in the Internet at 413 large might appear (because MR's prefix is administratively 414 assigned somewhere else, in MR's administrative domain). Second, 415 if HA advertises prefixes towards the mobile network, then routing 416 instability in the mobile network might appear. Because of those 417 two reasons, it might be recommended for MR and HA to forbid the 418 exchange of any routing information (other than Mobile IPv6) when 419 MR and HA belong to different administrative domains. 421 5.1 A tool: HA ingress filtering 423 Home Agents supporting mobile networks are normally able to perform 424 ingress filtering, so that only topologically correct packets leave 425 the HA. See section B.7 on how HA could do ingress filtering. 427 Acknowledgements 429 Authors of this document acknowledge the following WG members and 430 non-members for their remarks, improvements to this draft and 431 fruitful discussions: 433 Tim Leinumeller for many insightful remarks and implementation 434 aspects. 436 Mattias Petterson. 438 Vijay Devarapalli. 440 TJ Kniveton. 442 Pekka P��kk�nen. 444 Mooi Choo Chuah. 446 Erik Nordmark. 448 Takeshi Tanaka. 450 References 452 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 453 Levels", BCP 14, RFC 2119, March 1997 455 [2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using 456 IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes 457 and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-03.txt, 458 IETF Internet Draft, February 2003. (Work in Progress). 460 [3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC 461 2082, January 1997. 463 [4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed 464 March 3rd, 2003 at 465 http://www.cisco.com/univercd/cc/td/doc/product/software/ 466 ios122/122newft/122t/122t4/ftmbrout.pdf 468 [5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 469 2740, December 1999. 471 [6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6 472 Specification", RFC 2473, December 1998. 474 [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 475 2000. 477 [8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic, 478 Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks 479 Support in Mobile IPv6", 480 draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft, 481 March 2002. (Work in Progress). 483 [9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support 484 Terminology", draft-ernst-nemo-terminology-01.txt, IETF 485 Internet Draft, November 2002. (Work in Progress). 487 [10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark, 488 E., Patil, B. and Roberts, P., "Threat Models introduced by 489 Mobile IPv6 and Requirements for Security", 490 draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet 491 Draft, November 2001. (Work in Progress). 493 [11] Hedrick, C., "Routing Information Protocol", RFC 1058, June 494 1998. 496 [12] Johnson, David B., Perkins, Charles E. and Arkko, Jari, 497 "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-20.txt, 498 IETF Internet Draft, January 2003. (Work in Progress). 500 [13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay, 501 "Mobile Router Tunneling Protocol", 502 draft-kniveton-mobrtr-03.txt, IETF Internet Draft, November 503 2003. (Work in Progress). 505 [14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart, 506 D. H. and Bell, T. L. and Kachmar, B. A., "Application of 507 Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs 508 of the Aerospace Conference, 2001. 510 [15] Malkin, G., "RIP Version 2, Carrying Additional Information", 511 RFC 1723, November 1994. 513 [16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997. 515 [17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP, 516 revised", RFC 3024, January 2001. 518 [18] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 520 [19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery 521 for IP Version 6 (IPv6)", RFC 2461, December 1998. 523 [20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 524 1996. 526 [21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, 527 August 2002. 529 [22] Wakikawa, R., Uehara, K., Mitsuya, K. and Ernst, T., "Basic 530 Network Mobility Support", draft-wakikawa-nemo-basic-00.txt, 531 IETF Internet Draft, February 2003. (Work in Progress). 533 [23] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., 534 "Nemo Basic Support Protocol" (work in progress). Internet 535 Draft, IETF. draft-ietf-nemo-basic-support-01.txt. September 536 2003. 538 Changes 540 October 2002: revision 00 submitted. 541 November 2002: revision 01: 542 -added discussion on multicast addresses with link-local scope. 543 -added Chairs' addresses. 544 -modified the abstract to better express the fact that /128s are 545 probably sufficient. 546 -added section on v4 issues, and Mobile IPv4 issues. 547 -added an empty IPR section. 548 March 2003: revision 02: 549 -major overhaul from revision 01: shorter, focused on main 550 issues, integrated some ml discussions, moved large "Motivation" 551 parts to appendices. 552 -added MH definition and used MH instead of MN when MR acts as an 553 MH. 554 -added more detailed acknowledgements. 555 -added "cross-over" tunnels discussion. 556 -added HA ingress filtering. 557 October 2003: revision 03: 558 -extended the security section with cases when MR and HA not in 559 the same admin domain. 560 -added reference to NEMO Basic Support draft. 561 -refined the sections B.5 on disconnected operation and B.6 on 562 cross-over tunnels. 564 Appendix A: Motivation for Full Addresses in Binding Updates 566 An initial remark is that traffic coming from outside the home 567 link, or from other hosts on the home link, and directed to hosts 568 in the mobile network (or behind the mobile router) only need to go 569 through the L2 address of the mobile router (corresponding to its 570 L3 address). With Proxy ND [19], it is the HA that pretends to own 571 MR's L3 address by advertising new associations of the MR's L3 572 address to the its own L2 address, thus intercepting MR's home 573 traffic and forwarding it to the current CoA of the MR. 575 With this in mind, it can be stated that when the MR is in a 576 foreign network, traffic coming from hosts in the mobile network 577 and towards anywhere to the Internet, is first forwarded by the MR 578 through the reverse tunnel MRHA to the HA. Then HA decapsulates 579 and forwards to the address specified in the inner packet. 581 A.1 Description of a Home Network 583 When designing a NEMO solution with the MRHA tunnel, the first 584 steps are to carefully consider the actual behaviour of the home 585 network when the mobile network is at home, employing normal 586 routing. Then this behaviour should be maintained as much as 587 possible when the MR is not at home (e.g. MR should be able to send 588 redirects through the MRHA tunnel); reciprocically, the normal 589 behaviour of an FR at home should change when that FR is an MR and 590 is at home (e.g. when MR at home, the MRHA tunnel should be torn 591 down). When the MR is in a foreign network, its presence at home 592 is simulated by the HA (as in Mobile IPv6 for hosts). 594 Let us consider a simple case of a home network that supports 595 movement of one of its links. The home network is made up of a 596 home link and a mobile network link, separated by the Mobile 597 Router. The home network is connected to the Internet via the 598 Border Router, as presented in the figure: 599 ---- 600 | FN | 601 ---- 602 | ------- 603 home link -------------------| HA/BR |---> Internet 604 | ------- 605 ---- ----- 606 | MR | | LFN | 607 ---- ----- 608 | | 609 mobile link --------- 611 Current specification for Mobile IPv6 implies that the HA can be 612 either co-located with the BR, or it can act as a separate 613 one-interface machine (this is advantageous for deploying Mobile 614 IPv6 without changing BRs). For mobile networks, the latter mode 615 can be pictured like this: 616 ---- ---- 617 | FN | | HA | 618 ---- ---- 619 | | ---- 620 home link -------------------| BR |------> Internet 621 | ---- 622 ---- ----- 623 | MR | | LFN | 624 ---- ----- 625 | | 626 mobile network link --------- 628 It is assumed that routes outside the home link are managed by BR 629 and MR, either in a static manner (operator fills in routing 630 tables) or dynamic manner (application software partially manages 631 routing tables). Remark that even when the dynamic style is used, 632 it is still true that operator fills initial routing configuration 633 files, where she/he puts the image of the network as being what the 634 operator believes it to be. The dynamic behaviour of routing 635 protocols intervenes when certain links come down or up due to 636 failures, the operator view is no longer true, and the routers 637 manage to find alternative paths. Also, the dynamic behaviour 638 helps obtaining shortest paths over large networks, relying on 639 several local operator's views of smaller sized networks. Addition 640 of mobility should not change this. 642 If static routing is used instead of dynamic routing, then static 643 routes are added manually both on MR and on the BR. When 644 considering adding *static* routes in a *dynamic* manner for 645 prefixes shorter than /128 by Mobile IP, authors of this document 646 realize (in truth, hopefully) that Mobile IP starts using semantics 647 that are traditionally belonging to routing protocols. 649 A.2 Scenarios 651 For the sake of completetess, we first describe a simple "manual" 652 scenario for mobile networks based on the MRHA tunnel, that exposes 653 relative simplicity, that uses static routing and doesn't use 654 Mobile IP. 656 Then, adding the Mobile IP behaviour, we present detailed scenarios 657 of communication between an FN on the home link and an LFN on the 658 mobile network link and a CN on the Internet, when the mobile 659 network is at home and away from home in a visited network, and 660 when the HA is co-located with the BR and separated from the BR. 661 All in all, 16 simple scenarios are presented. 663 The scenarios where HA is co-located with BR (1 up to 8) expose 664 that there is no need for MR to communicate prefixes to its HA via 665 BUs. In a normal routing function, when the MR is at home, it 666 exchanges routing information with the BR (co-located with the HA) 667 and thus those prefixes are communicated by e.g. RIP or OSPF. When 668 the MR is not at home, this behaviour continues, but through the 669 MRHA tunnel. 671 The scenarios where HA and BR are separated (9 up to 16) expose 672 that HA needs an entry in its routing table in order to be capable 673 of forwarding packets to the MR (when it is not at home). 675 An additional scenario is then presented where MR at home is using 676 ICMP Redirect, a functionality that might be needed even when the 677 MR is not at home. 679 A.2.1 Manual Mobile Networks 681 Authors of this draft have experimented with "manual" mobile 682 networks in IPv4, where the addition of routes and tunnels on the 683 MR and on the BR are done manually, by operators talking on the 684 phone. 686 A home network was used that contains about 10 routers and about 12 687 subnets. That home network is connected to the Internet with a BR. 688 All routers have static routes among them. 690 Then, one slice of that home network (the mobile network) 691 containing one "MR", one normal router and 6 subnets, was 692 disconnected from home, and moved across the Atlantic. Once the 693 "MR" was connected on the other side, it was manually configured 694 with a new IPv4 address, mask and default route. Then a tunnel 695 interface and a route were manually set up on the MR, a tunnel 696 interface and a route were manually set up on the BR. All other 697 routes on all other routers where not touched. Mobile IP software 698 was not used. 700 The entire network (the home and the mobile network) looked, and 701 acted, as if the mobile slice were at home. During this, several 702 applications were tested between hosts in the mobile network, hosts 703 in the home network and hosts on the Internet (incidentally, one of 704 the applications was relying on Mobile IPv4 for hosts, but in no 705 relation with the mobile network moving). 707 Again, this "manual" mobile networks scenario was not using any 708 dynamic routing protocol, and the tunnel was not supporting any 709 form of broadcast of multicast. 711 A.2.2 Scenarios with Co-located HA and BR 713 1. FN sends packet to LFN, mobile network home, HA/BR colocated 714 ---- 715 | FN | 716 ---- 717 | ------- 718 home link -------------------| HA/BR |---> Internet 719 | ------- 720 ---- ----- 721 | MR | | LFN | 722 ---- ----- 723 | | 724 mobile link --------- 726 -FN scans its routing table for LFN's address, and finds default 727 route towards BR. 728 -FN sends NS for L2 address of BR. 729 -BR replies NA. 730 -FN sends packet to BR. 731 -HA scans its BC to find out whether MR is at home; BR scans its 732 routing table for LFN's address, and finds route through MR; 733 -BR sends NS for MR. 734 -MR replies NA with its L2 address. 735 -BR forwards packet to MR and sends ICMP Redirect to FN such that 736 subsequent packets from FN to LFN go straight through MR and not 737 through BR. 738 -MR forwards packet to FN. 740 The sensitive issue exposed here is the way in which initially the 741 packet travels from FN to BR to MR, the dynamic addition of an 742 entry in the routing table of the FN (even if FN doesn't run a 743 routing protocol) and that subsequent packets will not go through 744 BR, but from FN to MR to LFN. 746 2. FN sends packet to LFN, mobile network visits, HA/BR colocated 747 ---- / 748 | FN | / 749 ---- ----------/ 750 | ------- | | 751 ----------------| HA/BR |---| Internet | 752 home link ------- | | 753 ----------\ 754 \ 755 \ ---- Visited link 756 --| AR |------ 757 ---- | 758 | 759 ---- ----- 760 | MR | | LFN | 761 ---- ----- 762 | | 763 --------- 764 mobile net 766 -FN scans its routing table for LFN's address, and finds default 767 route towards BR. 768 -FN sends NS for L2 address of BR. 769 -BR replies NA. 770 -FN sends packet to BR. 771 -BR scans its routing table for LFN's address, and finds route 772 through MR; 773 -BR (being an HA) scans its BC and its routing table and finds it 774 needs to encapsulate this packet towards MR's CoA. 775 -BR encapsulates through the MRHA tunnel to MR's CoA. 776 -MR decapsulates and forwards to LFN. 778 3. LFN sends packet to FN, mobile network home, HA/BR colocated 779 ---- 780 | FN | 781 ---- 782 | ------- 783 home link -------------------| HA/BR |---> Internet 784 | ------- 785 ---- ----- 786 | MR | | LFN | 787 ---- ----- 788 | | 789 mobile link --------- 791 -LFN scans its routing table for FN's address, and finds default 792 route towards MR. 793 -LFN sends NS for L2 address of MR. 794 -MR replies NA. 795 -LFN sends packet to MR. 796 -MR scans its routing table for LFN's address, and finds route 797 'on-link'; 798 -MR sends NS for FN. 799 -FN replies NA with its L2 address. 800 -MR forwards packet to FN. 802 4. LFN sends packet to FN, mobile network visits, HA/BR colocated 803 ---- / 804 | FN | / 805 ---- ----------/ 806 | ------- | | 807 ----------------| HA/BR |---| Internet | 808 home link ------- | | 809 ----------\ 810 \ 811 \ ---- Visited link 812 --| AR |------ 813 ---- | 814 | 815 ---- ----- 816 | MR | | LFN | 817 ---- ----- 818 | | 819 --------- 820 mobile net 822 -LFN scans its routing table for FN's address, and finds default 823 route towards MR. 824 -LFN sends NS for L2 address of MR. 825 -MR replies NA. 826 -LFN sends packet to MR. 827 -MR encapsulates this packet through the MRHA tunnel and sends to 828 HA. 829 -HA receives this packet and decapsulates. 830 -HA scans its routing table for FN's address, and finds route 831 'on-link'; 832 -HA sends NS for FN. 833 -FN replies NA with its L2 address. 834 -HA forwards packet to FN (on behalf of the MR). 836 5. CN sends packet to LFN, mobile network home, HA/BR co-located 837 ---- CN link 838 --| BR1|------ 839 / ---- | 840 / | 841 ----------/ ---- 842 ------- | | | CN | 843 ----------------| HA/BR |---| Internet | ---- 844 | home link ------- | | 845 ---- ----- ----------\ 846 | MR | | LFN | \ 847 ---- ----- \ 848 | | 849 --------- 850 mobile net link 852 -BR receives packet from CN towards LFN. 853 -HA scans its BC to see whether MR is at home; BR scans its routing 854 table and finds dest through MR. 855 -BR sends NS for L2 address of MR and MR replies NA. 856 -BR forwards packet to MR. 858 -MR forwards packet to LFN. 860 6. CN sends packet to LFN, mobile network visits, HA/BR colocated 862 ---- CN link 863 --| BR1|------ 864 / ---- | 865 / | 866 ----------/ ---- 867 ------- | | | CN | 868 ---| HA/BR |---| Internet | ---- 869 ------- | | 870 ----------\ 871 \ 872 \ ---- Visited link 873 --| AR |------ 874 ---- | 875 | 876 ---- ----- 877 | MR | | LFN | 878 ---- ----- 879 | | 880 --------- 881 mobile net 882 -BR receives packet from CN towards LFN. 883 -BR scans its routing table and finds dest through MR. 884 -BR scans its routing table and its BC and realizes it needs to 885 send this through the MRHA tunnel. 886 -BR sends the packet through the MRHA tunnel to MR. 887 -MR decapsulates and forwards to LFN. 889 (this is sometimes referred to as triangular routing, since the 890 packet from CN to LFN travels artificially through BR) 892 7. LFN sends packet to CN, mobile network home, HA/BR colocated 894 ---- CN link 895 --| BR1|------ 896 / ---- | 897 / | 898 ----------/ ---- 899 ------- | | | CN | 900 ----------------| HA/BR |---| Internet | ---- 901 | home link ------- | | 902 ---- ----- ----------\ 903 | MR | | LFN | \ 904 ---- ----- \ 905 | | 906 --------- 907 mobile net link 909 -MR receives packet from LFN towards CN. 910 -MR scans its routing table to and finds dest through BR. 912 -BR forwards packet to Internet towards CN. 913 -BR1 forwards packet to CN. 915 8. LFN sends packet to CN, mobile network visits, HA/BR colocated 916 ---- CN link 917 --| BR1|------ 918 / ---- | 919 / | 920 ----------/ ---- 921 ------- | | | CN | 922 ---| HA/BR |---| Internet | ---- 923 ------- | | 924 ----------\ 925 \ 926 \ ---- Visited link 927 --| AR |------ 928 ---- | 929 | 930 ---- ----- 931 | MR | | LFN | 932 ---- ----- 933 | | 934 --------- 935 mobile net 936 -MR receives packet from LFN towards CN. 937 -MR scans its tables and finds it needs to send it through the MRHA 938 tunnel. 939 -BR receives this packet, decapsulates and forwards to Internet. 940 -BR1 forwards this packet to CN. 942 (this is sometimes referred to as triangular routing, since the 943 packet from LFN to CN travels artificially through BR) 945 A.2.3 Scenarios with HA and BR Separated 947 9. FN sends packet to LFN, mobile network home, HA separated BR 948 ---- ---- 949 | FN | | HA | 950 ---- ---- 951 | | ---- 952 home link -------------------| BR |------> Internet 953 | ---- 954 ---- ----- 955 | MR | | LFN | 956 ---- ----- 957 | | 958 mobile network link --------- 960 -FN scans its routing table for LFN's address, and finds default 961 route towards BR. 962 -FN sends NS for L2 address of BR. 963 -BR replies NA. 964 -FN sends packet to BR. 966 -BR scans its routing table for LFN's address, and finds route 967 through MR; 968 -BR sends NS for MR. 969 -MR replies NA with its L2 address. 970 -BR forwards packet to MR and sends ICMP Redirect to FN such that 971 subsequent packets from FN to LFN go straight through MR and not 972 through BR. 973 -MR forwards packet to FN. 975 10. FN sends packet to LFN, mobile network visits, HA separated BR 977 ---- ---- / 978 | FN | | HA | / 979 ---- ---- ----------/ 980 | | ---- | | 981 -------------------| BR |---| Internet | 982 home link ---- | | 983 ----------\ 984 \ 985 \ ---- Visited link 986 --| AR |------ 987 ---- | 988 | 989 ---- ----- 990 | MR | | LFN | 991 ---- ----- 992 | | 993 --------- 994 mobile net 996 -FN scans its routing table for LFN's address, and finds default 997 route towards BR. 998 -FN sends NS for L2 address of BR. 999 -BR replies NA. 1000 -FN sends packet to BR. 1001 -BR scans its routing table for LFN's address, and finds route 1002 through MR; 1003 -BR sends NS for MR. 1004 -HA replies NA with its L2 address (on behalf of MR). 1005 -BR forwards packet to HA and sends ICMP Redirect to FN such that 1006 subsequent packets from FN to LFN go straight through MR and not 1007 through BR. BR also sends ICMP Redirect to HA, such that HA knows 1008 a route through MR. The logic of this last ICMP Redirect is 1009 described in section 6.1. 1010 -HA scans its routing table for LFN's address, and finds through MR; 1011 -HA scans binding cache and finds 'through MRHA tunnel'; 1012 -HA encapsulates and sends packet to MR. 1013 -MR decapsulates and forwards to LFN. 1015 The problem in the above case is how to inform the HA about the 1016 route towards MR. When MR at home, and HA being a host, normally 1017 HA doesn't have a route towards MR. 1019 11. LFN sends packet to FN, mobile network home, HA separated BR 1020 ---- ---- 1021 | FN | | HA | 1022 ---- ---- 1023 | | ---- 1024 home link -------------------| BR |------> Internet 1025 | ---- 1026 ---- ----- 1027 | MR | | LFN | 1028 ---- ----- 1029 | | 1030 mobile network link --------- 1032 -LFN scans its routing table for FN's address, and finds default 1033 route towards MR. 1034 -LFN sends NS for L2 address of MR. 1035 -MR replies NA. 1036 -LFN sends packet to MR. 1037 -MR scans its routing table for LFN's address, and finds route 1038 'on-link'; 1039 -MR sends NS for FN. 1040 -FN replies NA with its L2 address. 1041 -MR forwards packet to FN. 1043 12. LFN sends packet to FN, mobile network visits, HA separated BR 1044 ---- ---- / 1045 | FN | | HA | / 1046 ---- ---- ----------/ 1047 | | ---- | | 1048 -------------------| BR |---| Internet | 1049 home link ---- | | 1050 ----------\ 1051 \ 1052 \ ---- Visited link 1053 --| AR |------ 1054 ---- | 1055 | 1056 ---- ----- 1057 | MR | | LFN | 1058 ---- ----- 1059 | | 1060 --------- 1061 mobile net 1063 -LFN scans its routing table for FN's address, and finds default 1064 route towards MR. 1065 -LFN sends NS for L2 address of MR. MR replies NA. 1066 -LFN sends packet to MR. 1067 -MR encapsulates this packet through the MRHA tunnel and sends to 1068 HA. 1069 -HA receives this packet and decapsulates. 1070 -HA scans its routing table for FN's address, and finds route 1071 'on-link'; 1072 -HA sends NS for FN. FN replies NA with its L2 address. 1073 -HA forwards packet to FN (on behalf of the MR). 1075 13. CN sends packet to LFN, mobile network home, HA separated BR 1077 ---- CN link 1078 --| BR1|------ 1079 ---- / ---- | 1080 | HA | / | 1081 ---- ----------/ ---- 1082 | ---- | | | CN | 1083 -----------------| BR |---| Internet | ---- 1084 | home link ---- | | 1085 ---- ----- ----------\ 1086 | MR | | LFN | \ 1087 ---- ----- \ 1088 | | 1089 --------- 1090 mobile net link 1092 -BR receives packet from CN towards LFN. 1093 -BR scans its routing table to and finds dest through MR. 1094 -BR sends NS for L2 address of MR. 1095 -MR replies NA. 1096 -BR forwards packet to MR. 1097 -MR forwards packet to LFN. 1099 14. CN sends packet to LFN, mobile network visits, HA separated BR 1101 ---- CN link 1102 --| BR1|------ 1103 ---- / ---- | 1104 | HA | / | 1105 ---- ----------/ ---- 1106 | ---- | | | CN | 1107 ---------| BR |---| Internet | ---- 1108 ---- | | 1109 ----------\ 1110 \ 1111 \ ---- Visited link 1112 --| AR |------ 1113 ---- | 1114 | 1115 ---- ----- 1116 | MR | | LFN | 1117 ---- ----- 1118 | | 1119 --------- 1120 mobile net 1121 -BR receives packet from CN towards LFN. 1122 -BR scans its routing table to and finds dest through MR. 1123 -BR sends NS for L2 address of MR. HA replies NA on behalf of MR. 1124 -BR sends Redirect to HA informing it about a route towards MR. 1125 -Simultaneously with previous packet, BR forwards packet to HA. 1126 -HA scans its routing table and finds an entry to MR (added as a 1127 result to ICMP redirect), it also has a BC entry for MR, so it 1128 sends the packet through the MRHA tunnel. 1130 The problem in the above case is how to inform the HA about the 1131 route towards MR. When MR at home, and HA being a host, normally 1132 HA doesn't have a route towards MR. 1134 15. LFN sends packet to CN, mobile network home, HA separated BR 1136 ---- CN link 1137 --| BR1|------ 1138 ---- / ---- | 1139 | HA | / | 1140 ---- ----------/ ---- 1141 | ---- | | | CN | 1142 -------------------| BR |---| Internet | ---- 1143 | home link ---- | | 1144 ---- ----- ----------\ 1145 | MR | | LFN | \ 1146 ---- ----- \ 1147 | | 1148 --------- 1149 mobile net link 1151 -MR receives packet from LFN towards CN. 1152 -MR scans its routing table and finds dest through BR. 1153 -BR sends packet to CN 1154 16. LFN sends packet to CN, mobile network visits, HA separated BR 1155 ---- CN link 1156 --| BR1|------ 1157 ---- / ---- | 1158 | HA | / | 1159 ---- ----------/ ---- 1160 | ---- | | | CN | 1161 ----------| BR |---| Internet | ---- 1162 ---- | | 1163 ----------\ 1164 \ 1165 \ ---- Visited link 1166 --| AR |------ 1167 ---- | 1168 | 1169 ---- ----- 1170 | MR | | LFN | 1171 ---- ----- 1172 | | 1173 --------- 1174 mobile net 1175 -MR receives packet from LFN towards CN. 1176 -MR encapsulates this packet through the MRHA tunnel. 1177 -HA receives this packet, decapsulates and sends to CN. 1179 A.3 MR Redirects to BR 1181 Also, consider the scenario where the FN has a default route 1182 towards the MR instead of the BR, and sending packets to a CN on 1183 the Internet. This might very well happen when the MR is at home 1184 and sending RAs, in addition to the RAs sent by the BR. FN might 1185 configure a default route through the MR instead of the BR. If MR 1186 is at home, MR will redirect the FN towards the BR. So, even if 1187 this looks like a wrong configuration on the FN (its default route 1188 should point to BR and not MR), packets will still travel correctly 1189 when MR is at home. This should be maintained when the MR is not 1190 at home. There are two possibilities: either the HA (replacing the 1191 MR) redirects the FN towards the BR, or it is the MR itself that 1192 sends the respective ICMP redirect message to the FN (through the 1193 MRHA tunnel). The first case supposes that HA maintains a routing 1194 table, which contains routes towards the mobile network. This is 1195 less desirable if the HA is not co-located with BR, and where we 1196 prefer not to have routing interactions with the HA. The latter 1197 case is more plausible, keeping the default routing behaviour to 1198 the MR. 1200 A.4 Informing the HA about the Route to MR 1202 In certain scenarios presented previously, with the HA dissociated 1203 from the BR and the MR in the visited network, there is a need for 1204 the HA to maintain in its routing table an entry towards the MR. A 1205 scenario where packets from CN towards LFN are looping between BR 1206 and HA has been described in detail in section 3.2.4 of [8]. 1207 Several solutions exist to avoid this looping, described below. 1209 A.4.1 ICMP Redirect from BR to HA 1211 One alternative for avoiding the loop problem is by using ICMP 1212 Redirects [19] sent by BR to HA in order to communicate to HA the 1213 route it misses towards the MR. ICMP Redirects are deployed and 1214 used in existing networks. The classic behaviour of ICMP Redirects 1215 is presented in scenario 1. Scenarios 10 and 14 with 1216 MR-not-at-home and BR dissociated from HA, present the fact that 1217 classic ICMP Redirects are not triggered normally and thus 1218 modifications are needed. 1220 In addition to the normal behaviour with ICMP Redirects, described 1221 in [19], it could be modified according to the following. The 1222 decision by BR to send ICMP Redirect towards HA can be taken in at 1223 least three ways: 1225 -allow a number of iterations of a packet looping between HA and 1226 BR and after this fixed number decide to send the Redirect to HA 1227 such as the looping stops. This modifies the normal behaviour 1228 of BR. 1230 -another possibility is for BR to react at the moment it receives 1231 the proxy NA from HA (on behalf of the MR), compare to the 1232 current entry it has in the Neighbour Cache for MR, and then 1233 decide that, because MR has moved away, send Redirect to HA to 1234 inform HA about the route to MR. This is the route (or set of 1235 routes) normally maintained by the BR with the MR, doesn't 1236 contain any form of the new position (CoA) of the MR. This 1237 route, or set of routes (in which case a set of Redirects are 1238 sent), is copied from BR's routing table. All routes that have 1239 destination the MR's home address need to be communicated to HA 1240 with ICMP Redirects. This modifies the normal behaviour of BR. 1242 -yet another possibility is to consider modifications on HA (from 1243 vanilla Mobile IPv6), but don't touch BR, such that HA generates 1244 a new packet, thus obtaining a classic ICMP Redirect from BR. 1246 When the HA receives a packet that is not for itself, it 1247 encapsulates it with an IP-in-IP tunnel, having the src address 1248 its own address and the destination address copied from the dst 1249 address of the original packet. Then try to route this packet 1250 and find the default route towards BR. Then BR sends a normal 1251 ICMP Redirect informing HA there is a better route for this 1252 packet towards MR. Thus HA acquires the MR route dynamically. 1253 The packet will be passed on by BR to HA again, and further 1254 details are needed here. Remark that this is equivalent to one 1255 iteration of the loop (a particular case of the fixed iterations 1256 loop mentioned previously). 1258 A.4.2 Static Route Method 1260 This is proposed by [4] and [13], where a route is statically 1261 introduced in the HA upon receiption of a Binding Update from 1262 MR. This route for MR's prefix may point towards MR's home address 1263 (next hop), towards a specific tunnel to MR's home address(output 1264 interface), or towards a specific tunnel to MR's care-of address 1265 (output interface). 1267 The first approach proposed in [4] suggests to configure a new 1268 static tunnel on the MR's HA towards MR_HoA. This static tunnel, 1269 that we call here MR_HoA_tunnel, is to be used as output interface 1270 of a new static entry added in the routing table of HA for MR's 1271 prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data 1272 packet from CN addressed to a LFN, MR's HA will consult its routing 1273 table and find a match for that packet for this static route since 1274 LFN address matches MR's prefix. As a results it will encapsulate 1275 the packet with an additional header that will have MR's HA as 1276 source address and MR_HoA as destination address. In order to 1277 forward this packet, now addressed to MR's Home Address, the MR 1278 will first consult its binding cache and discover MR's Care-of 1279 address. It will thus send the packet through the MRHA tunnel 1280 towards MR's current location. It is worth mentionning that this 1281 approach introduces a double encapsulation of an incoming packet to 1282 be forwarded to the MR: the first is due to the MR_HoA_tunnel, the 1283 second to the MRHA tunnel. 1285 The second approach proposed in [13] suggests a similar method but 1286 avoids the overhead introduced by the two tunnels. It consists in 1287 configuring a static route in MR's HA routing table for MR's prefix 1288 towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of 1289 a data packet from CN addressed to a LFN, MR's HA will consult its 1290 routing table and, again, find a match for that packet for this 1291 static route since LFN address matches MR's prefix. This indicates 1292 the MR's HA that the packet should be routed towards MR_HoA. From 1293 its binding cache it discovers MR's CoA and as a consequence 1294 forwards the incoming packet from the CN directly through the MRHA 1295 tunnel. This approach reduces the overhead of the MR_HoA_tunnel but 1296 requires a suitable coordination of the routing table and binding 1297 cache on the HA. 1299 A third possible approach is similar to the previous one but 1300 directly uses the MR's care-of address as the tunnel termination 1301 point instead of MR's home address. As such the new static entry 1302 added in the routing table of HA for MR's prefix is then MR prefix 1303 -> MRHA_tunnel. 1305 Analyzed from the perspective where HA is separated from BR, and 1306 where MR doesn't normally maintain routes with HA, then this 1307 addition might seem superfluous. Consider a situation where MR and 1308 BR maintain routing information and where that manual route is 1309 added on HA. When the MR is not at home, consider that 1310 administrator decides to add a new fixed subnet at home, with its 1311 own router neighbouring with BR on the home link. Consider the new 1312 subnet's prefix being a longer prefix derived from the prefix 1313 assigned to the MR's subnet. This is perfectly feasible by 1314 changing configurations on the MR and BR. That can work perfectly 1315 even if MR is not at home. But if HA doesn't participate in this 1316 exchange (which is the case if HA separated from BR) then the 1317 manual route added previously in the HA is no longer valid. Thus, 1318 a potential issue. 1320 Using PSBUs as proposed in [8] and [13] has many side-effects not 1321 clearly considered. When the mobile network is assigned several 1322 prefixes instead of one, then it is not clear whether several BUs 1323 are being sent or only one with several prefixes inside. Remark 1324 that in the vanilla Mobile IPv6 case, only one CoA can be sent with 1325 a BU (the alternative CoA is only an alternative not a substitute). 1327 A.4.3 Dynamic Route Method 1329 It is possible for the HA, being either separated or co-located 1330 with the BR, to run a specific routing protocol, participating in 1331 the routing interactions between BR and all other neighbouring 1332 routers on the home link. Thus, the HA always has the necessary 1333 route it needs to join the MR's network. 1335 If the HA is a one-interface machine, and separated from the BR, it 1336 seems that it maintains information that is not always necessary to 1337 its well working as a HA. For example, it will maintain routes to 1338 all neighbouring routers, be it fixed or mobile. The routes to the 1339 fixed neighbouring routers are not necessary for its working as a 1340 host, since it suffices to only have a default route towards a BR, 1341 that will normally dynamically Redirect it towards the other fixed 1342 routers. Moreover, if HA runs a dynamic routing protocol, its 1343 route updates will never be taken into account by other routers, 1344 since they will always be one hop further than the routes already 1345 known by them. Thus it might be possible to have the HA as a 1346 silent routing, only receiving route updates from the neighbouring 1347 routers, but never sending route updates, since it does not have a 1348 network behind it (it is a "host") whose reachability it needs to 1349 advertise. 1351 RIP [11] supports having a silent host that only listens to update 1352 messages, but does not advertise new routes. With OSPF [18] the 1353 "listening only" requirement is complicated by the fact that the HA 1354 would needs to participate in OSPF's HELLO protocol. 1356 The advantage of using this solution is that it does not require 1357 additional changes to Mobile IPv6, and PSBUs are not needed. The 1358 disadvantage is that if the MR does not run a routing protocol then 1359 we still need some way of telling the HA the routes to the MNPs. 1361 Appendix B: Examples and Other Issues 1363 B.1 Example of issue for Mobile Router as Mobile Host 1365 If the MR is at home and it has an address configured on the moving 1366 interface other than a link-local address, then the MR can act as 1367 an MH too, and send normal Mobile IPv6 BUs, binding that Home 1368 Address to a newly configured CoA; thus allowing the MR to be an MH 1369 for itself only, ignoring the LFNs. If the MR at home doesn't have 1370 other addresses than link-local on the mobile interface then the MR 1371 can not send normal Mobile IPv6 BUs and can not be an MH. It can 1372 however be an MR for the hosts on the mobile network. 1374 B.2 Multicast Subscriptions of the MR 1376 When the MR is at home, it normally joins certain multicast groups 1377 related to routing (e.g. all-routers multicast group with site 1378 scope). This is assumed by dynamic routing protocols, or by 1379 renumbering mechanisms. When the MR is no longer at home, its 1380 multicast subscription should continue as if it were at home. This 1381 can be achieved by "home subscription" techniques considered in 1382 relation with Mobile IPv6. 1384 B.3 Examples of issues for Neighbour Discovery for MR 1386 When MR is at home and sends RA towards the home link, it should 1387 not advertise itself as being capable of being a default router 1388 (Router Lifetime should be 0). 1390 When the MR is visiting, it should not respond to RSs sent on the 1391 visited link and it should not send RAs on the visited link. 1393 When the MR is at home, it doesn't normally use any information 1394 received from RAs sent by a neighbouring router, i.e. the BR. It 1395 has a link-local address and if it has a larger scope address 1396 configured on an interface, then that is normally done manually. 1397 Actually, routers are usually prohibited from using information 1398 received in RAs more than for logging and synchronization purposes. 1399 When the MR is in a foreign network, it needs a way to configure a 1400 Care-of Address. In the hosts case this is done by stateless or 1401 stateful autoconf. In the MR case, the stateful is possible, while 1402 the stateless is normally prohibited. A good way for address 1403 autococnfiguration for the MR should be identified, be it DHCP, or 1404 modified RAs, or modified router's behaviour to accept RAs. 1406 Assume the MR is at home and a non-link-local (site- or global) 1407 home address is configured on the interface connecting to the home 1408 link (supposedly the same interface that will change CoAs when 1409 visiting). The MR-at-home will do periodic NAs for this home 1410 address; this behaviour should stop when MR is visiting. This 1411 modified behaviour is already taken into consideration by Mobile 1412 IPv6 MN. In the particular MR case, most ND operations of MR are 1413 delegated to the HA, and such most entries of Neighbour Cache, 1414 Destination Cache that are related to the home link will disappear. 1415 New entries that are relevant in the foreign network will populate 1416 those tables. When coming back home, all ND entries should be 1417 replaced back with the entries related to the home network. 1419 Another specific case in point is the default route. As already 1420 presented with the router behaviour with respect to RAs, a default 1421 route is not normally configured by MR from a received RA. When 1422 the MR is in a foreign network, it should have a default route that 1423 points to its BR (but through the MRHA tunnel) and another 1424 non-tunnelled default route towards the current AR. Moreover, all 1425 MR's routing table entries that pointed to BR when the MR was at 1426 home, should still continue to point to BR (through the MRHA 1427 tunnel). The same is true for all routing table entries of the BR. 1429 B.4 Router Renumbering 1431 Router Renumbering for IPv6 [7] is a technique where routers of a 1432 home network are instructed to change the prefixes they advertise. 1433 In the context here, it should be possible for the MR to be 1434 re-numbered when it is at home as well as when it is visiting. 1436 The renumbering mechanisms provided by Mobile IPv6 (mobile prefix 1437 solicitations and advertisements) are not relevant for changing the 1438 prefixes advertised by the MR towards the mobile network; but these 1439 mechanisms should still be used for MR when MR is acting as an MH. 1440 In order for router renumbering to work for MR when acting as MR, 1441 the MR should at least be able to maintain its multicast 1442 subscription to all-routers group valid at home. 1444 B.5 Example of disconnected operation issue 1446 With the NEMO basic support protocol as described in [23], it is 1447 possible to accomodate a wide range of simple and nested mobile 1448 networks. However, the communication between two entities inside a 1449 nested aggregation of two mobile networks is not possible if the 1450 aggregation is not connected to the Internet. Consider two mobile 1451 networks, each MR having its own HA in different domains. The 1452 first MR attaches to an AR and the second MR attaches under the 1453 first mobile network. In this case, the communication between two 1454 LFNs situated one on the first mobile net and the second on the 1455 second mobile net is encapsulated by both HA's. If the first MR 1456 looses connectivity to AR ("disconnects"), the LFN's are unable to 1457 communicate, even though the two mobile networks are attached to 1458 each other. 1460 B.6 Example for the "cross-over" tunnels issue 1462 With the NEMO basic support protocol as described in [23], it is 1463 possible to accomodate a wide range of simple and nested mobile 1464 networks. However, certain cases of nested network mobility are not 1465 possible with this protocol, as exemplified by the "cross-over" 1466 tunnels issue described in this section. 1468 Consider a mobility configuration depicted below. MR1 is served by 1469 HA1/BR and MR2 is served by HA2. Both MR1 and MR2 are at home in 1470 the initial step. HA2 is placed inside the first mobile network, 1471 thus representing a "mobile" Home Agent. 1473 /-----CN 1474 ----------/ 1475 home link1 ------- | | 1476 -----------------------| HA1/BR|---| Internet | 1477 | ------- | | 1478 | ---------- 1479 ----- ----- 1480 | MR1 | | HA2 | 1481 ----- ----- 1482 | | 1483 -------------mobile network 1 / home link2 1484 | 1485 ----- ----- 1486 | MR2 | | LFN | 1487 ----- ----- 1488 | | 1489 ------------mobile network 2 1491 In the picture above, communication between CN and LFN follows a 1492 direct path as lons as both MR1 and MR2 are positioned at home. No 1493 encapsulation intervenes. 1495 In the next step, consider that the MR2's mobile network leaves home 1496 and visits a foreign network, under Access Router (AR) like in the 1497 figure below: 1499 /-----CN 1500 ----------/ 1501 home link 1 ------- | | 1502 ---------------| HA1/BR|---| Internet | 1503 | ------- | | 1504 ----- ----- ----------\ 1505 | MR1 | | HA2 | \ 1506 ----- ----- ----- 1507 | | | AR | 1508 ------------mobile net 1 ----- 1509 home link2 | 1510 ----- ----- 1511 | MR2 | | LFN | 1512 ----- ----- 1513 | | 1514 mobile net 2------------ 1516 Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs 1517 between MR2 and HA2. MR2 sends BU to HA2 and HA2 replies BAck to 1518 MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. 1519 After the tunnel MR2HA2 has been set up, the path taken by a packet 1520 from CN towards LFN can be summarized as: 1521 CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. Non-encapsulated packets 1522 are marked "->" while encapsulated packets are marked "=>". 1524 Consider next the attachment of the first mobile network under the 1525 second mobile network, like in the figure below: 1527 /-----CN 1528 ----------/ 1529 ------- | | 1530 | HA1/BR|---| Internet | 1531 ------- | | 1532 ----------\ 1533 \ 1534 ----- 1535 | AR | 1536 ----- 1537 | 1538 ----- ----- 1539 | MR2 | | LFN | 1540 ----- ----- 1541 | | 1542 mobile net 2------------ 1543 | 1544 ----- ----- 1545 | MR1 | | HA2 | 1546 ----- ----- 1547 | | 1548 mobile net 1------------ 1550 After this movement, MR1 acquires a CoA valid in the second mobile 1551 network. Subsequently, it sends a BU message addressed to HA1. 1552 This BU is encapsulated by MR2 and sent towards HA2, which is 1553 expected to be placed in mobile net 1 and expected to be at home. 1554 Once HA1/BR receives this encapsulated BU, it tries to deliver to 1555 MR1. Since MR1 is not at home, and a tunnel has not yet been set up 1556 between MR1 and HA1, HA1 is not able to route this packet and drops 1557 it. Thus, the tunnel establishment procedure between MR1 and HA1 is 1558 not possible, due to the fact that the tunnel between MR2 and HA2 1559 has been previously torn down (when the mobile net 1 has moved from 1560 home). The communication between CN and LFN stops, even though both 1561 mobile networks are connected to the Internet. 1563 If both the tunnels between MR1 and HA1, and between MR2 and HA2 1564 were up simultaneously, they would have "crossed over" each other. 1565 If the tunnels MR1-HA1 and MR2-HA2 were drawn in the above picture, 1566 it could be noticed that the path of the tunnel MR1-HA1 includes 1567 only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two 1568 MR-HA tunnels are crossing over each other if the IP path between 1569 two endpoints of one tunnel includes one and only one endpoint of 1570 the other tunnel (assuming that both tunnels are up). When both 1571 endpoints of one tunnel are included in the path of the other 1572 tunnel, then tunnels are simply encapsulating each other. 1574 B.7 Example of use of HA ingress filtering 1576 HA should verify that packets it receives from the MRHA tunnel have 1577 a source address that matches what's in HA's routing table. HA 1578 should have a route for the mobile prefix pointing into the MRHA 1579 tunnel, and the LFN should have use a source address derived from 1580 that prefix when sending its packets. Other packets will be 1581 dropped. 1583 Appendix C: A Digression 1585 Two types of approaches have been distinguished in designing a 1586 network mobility support with Mobile IPv6 and the bidirectional 1587 tunnel. 1589 Clean-slate Mobile IP-centric approach 1591 In this approach, it is assumed that a home network is in fact a 1592 new 1-link network. This home network connects to the Internet 1593 with one or more BRs. The BRs have HA functionality with Mobile IP 1594 for hosts. There are no other routers or hosts in the home network 1595 than the BRs and the MRs. MRs are seldom at home. MRs and BRs 1596 would presumably have little need to run a dynamic routing 1597 protocol. Most, if not all, routing information exhanges happen 1598 with Mobile IP BUs. 1600 Nodes in the mobile networks communicate with CNs. Those CNs are 1601 anywhere in the Internet, but not in the home network (there's no 1602 node in the home network than BRs and/or other MRs). 1604 Evolutionary approach 1606 In this type of approach, it is assumed that a home network is 1607 already deployed. The home network has several routers that run 1608 dynamic routing protocols (non-Mobile IP) to maintain connectivity 1609 between various endpoints. The home network is connected to the 1610 Internet with one or more BRs. 1612 From this, it is possible to "mobilize" some slices (or chunks of 1613 this network), maintaining session continuity and reachability at a 1614 permanent home address for fixed nodes of that slice. Consider 1615 that the slice that needs to be physically disconnected from the 1616 home network uses a router (called "MR") that connects the slice to 1617 the home network. A minimal deployment effort could be the 1618 following: (1) modify software on MR and (2) place a new box with 1619 new software on the link where MR was connecting the slice to the 1620 home network (this entity called "HA"). MR and the slice move away 1621 and HA stays in place. 1623 Intellectual Property Rights Considerations 1625 Consult Motorola on IPR (authors believe no IPR here, but depends 1626 who asks; the complete and authoritative answers can be found from 1627 IPD or Public Relations of Motorola, corelated with IPD of ECRL). 1629 Chairs' Addresses 1631 Thierry Ernst, Timothy J. Kniveton 1632 French National Institute for Communication Systems Lab 1633 Research in Computer Science and Nokia Research Center 1634 Control 313 Fairchild Drive 1635 Visiting Researcher at WIDE Mountain View, California 94043 1636 Project USA 1637 Jun Murai lab. Faculty of Phone: +1 650 625-2025 1638 Environmental Information, EMail: timothy.kniveton@nokia.com 1639 Keio University. Fax: +1 650 625-2502 1640 5322 Endo, Fujisawa-shi, Kanagawa 1641 252-8520, Japan. 1642 Phone : +81-466-49-1100 1643 Fax : +81-466-49-1395 1644 E-mail: ernst@sfc.wide.ad.jp 1645 Web: 1646 http://www.sfc.wide.ad.jp/~ernst/ 1648 Authors' Addresses 1650 Alexandru Petrescu Miguel Catalina-Gallego 1651 Motorola Labs Motorola Labs 1652 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin 1653 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1654 France France 1655 Phone: +33 1 69354827 Phone: +33 1 69352541 1656 Alexandru.Petrescu@motorola.com Miguel.Catalina@motorola.com 1658 Christophe Janneteau Hong-Yon Lach 1659 Motorola Labs Motorola Labs 1660 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin 1661 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1662 France France 1663 Phone: +33 1 69352548 Phone: +33 1 69352536 1664 Christophe.Janneteau@motorola.com Hong-Yon.Lach@motorola.com 1666 Alexis Olivereau 1667 Motorola Labs 1668 Parc les Algorithmes St Aubin 1669 Gif-sur-Yvette 91193 1670 France 1671 Phone: +33 1 69352516 1672 Alexis@motorola.com 1674 Copyright (C) The Internet Society (2002). All Rights Reserved. 1676 This document and translations of it may be copied and furnished to 1677 others, and derivative works that comment on or otherwise explain it 1678 or assist in its implementation may be prepared, copied, published and 1679 distributed, in whole or in part, without restriction of any kind, 1680 provided that the above copyright notice and this paragraph are 1681 included on all such copies and derivative works. However, this 1682 document itself may not be modified in any way, such as by removing 1683 the copyright notice or references to the Internet Society or other 1684 Internet organizations, except as needed for the purpose of developing 1685 Internet standards in which case the procedures for copyrights defined 1686 in the Internet Standards process must be followed, or as required to 1687 translate it into languages other than English. 1689 The limited permissions granted above are perpetual and will not be 1690 revoked by the Internet Society or its successors or assigns. 1692 This document and the information contained herein is provided on an 1693 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1694 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1695 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1696 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1697 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1699 Funding for the RFC editor function is currently provided by the 1700 Internet Society.