idnits 2.17.1 draft-kniveton-mobrtr-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 31 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1, 2002) is 7847 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '7') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2002 (ref. '9') (Obsoleted by RFC 3220) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group T. J. Kniveton 2 Internet Draft Jari T. Malinen 3 Expires: May 1, 2003 Vijay Devarapalli 4 Charles E. Perkins 5 Nokia 6 November 1, 2002 8 Mobile Router Tunneling Protocol 9 draft-kniveton-mobrtr-03.txt 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html. 29 This document is a submission by the NEMO Working Group of the Internet 30 Engineering Task Force (IETF). Comments should be submitted to the 31 nemo@nal.motlabs.com mailing list. 33 Distribution of this memo is unlimited. 35 Abstract 37 This document describes how to support mobile networks with Mobile 38 IP or Mobile IPv6 using reverse tunneling. It provides this support 39 capability with no modifications to Mobile IP or routing protocol 40 signaling, but also defines new extensions to ease in the implementation 41 of network mobility. There are two described scenarios of mobile router 42 support, consumer mode, and fully enabled mode. In the former, the 43 mobile router is not allowed to use routing protocol signaling with the 44 home agent, but performs routing for subnet(s) assigned to it. In the 45 latter mode, both the home agent and the mobile router use a routing 46 protocol in the same manner as fixed routers. 48 Contents 50 Status of This Memo 1 52 Abstract 1 54 1. Introduction 2 56 2. Terms 4 58 3. Solution Overview 5 59 3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 8 60 3.2. Mapping to requirements . . . . . . . . . . . . . . . . . 8 62 4. Protocol Messages and Signaling 9 63 4.1. Explicit Signaling for IPv6 nodes . . . . . . . . . . . . 9 64 4.1.1. R-bit . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1.2. Mobile Network Option . . . . . . . . . . . . . . 10 66 4.2. Implicit Signaling . . . . . . . . . . . . . . . . . . . 12 68 5. Alternate Solutions 12 70 6. Support for Dynamic Routing Protocol 13 71 6.1. Processing the Tunneled Routing Messages . . . . . . . . 14 72 6.2. Forwarding Packets to MR's subnet . . . . . . . . . . . . 14 74 7. Security Considerations 14 76 8. IANA Considerations 15 78 9. Intellectual Property Right Considerations 15 80 10. Acknowledgements 15 82 Authors' Addresses 16 84 Full Copyright Statement 16 86 1. Introduction 88 This document describes the problem of mobile router support and 89 requirements for solving this problem. It then shows how to solve 90 this problem and support mobile networks with Mobile IP [9] or Mobile 91 IPv6 [5]. The document describes two categorical scenarios, static 92 (``consumer'') and dynamic (``fully enabled'') mobile routers, and 93 outlines how these scenarios are possible using unmodified Mobile IP or 94 Mobile IPv6, with or without a dynamic routing protocol. 96 Within the context of this document, a Mobile Router is defined as a 97 node which operates as a Mobile Node as detailed in Mobile IP or Mobile 98 IPv6, but has the additional capability of routing between its point 99 of attachment (Care-of Address), and a network fragment (subnet) which 100 moves with the mobile router. 102 An architecture to enable mobile routers is required to: 104 1 support unmodified Mobile IP or Mobile IPv6 signaling. 106 2 support communication to or from nodes on subnetwork(s) connected 107 to and moving with the mobile router. 109 3 support both fixed and mobile nodes in the network moving with 110 the mobile router. Fixed nodes are unmodified IP or IPv6 hosts 111 or routers which do not necessarily have any mobility support 112 nor any knowledge of the mechanisms described in this document. 113 Mobile nodes are nodes supporting Mobile IP or Mobile IPv6 with 114 no knowledge of the mechanisms described in this document. 116 4 support arbitrary nesting level of mobile routers; i.e., support 117 connection (into the mobile router's moving network) of another 118 mobile router and its associated network. 120 5 support static configuration; that is, the mobile router need not 121 have a dynamic routing protocol running on it. 123 6 support dynamic configuration; that is, the mobile router may run 124 a dynamic routing protocol and communicate with such a routing 125 protocol to signal its home agent. 127 7 allow routing entities such as the home agent and mobile router 128 to be able to run these dynamic routing protocols with no 129 modifications to their signaling. 131 8 support an end-to-end security model for mobility where no 132 intermediate node or router alters mobility state in mobile 133 nodes, routers, or their respective home agents and correspondent 134 nodes. 136 Mobile router support described here is NOT assumed to: 138 - solve the problems resulting from excessively fast relative 139 topology changes. The outcome of implementing a mobile network 140 as described here will inherit the characteristics of Mobile IP 141 and the routing protocol chosen, and thus be able to support 142 movement and topology changes to the same extent as those 143 protocols. Hence, any routing protocol which would be used to 144 support mobile routers is assumed to be suitable for the rate of 145 change to topology in anticipated usage scenarios. 147 - solve the problem of scalability resulting from fixed 148 network connectivity of a cascaded mesh of routers (and their 149 subnetworks) that contain non-aggregable, host-based routes. 151 2. Terms 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [1]. 157 In addition, this document uses the following terms: 159 Fixed Node 160 A host not capable moving from its home link to other 161 links. A fixed node is capable of sending and receiving 162 packets, that is, being a source or destination of 163 traffic, but not a forwarder of it. 165 Fixed Router 166 A router not capable of moving from its home link to 167 other links. A fixed router is capable of forwarding 168 packets between two or more interfaces, and possibly 169 running a dynamic routing protocol modifying the state by 170 which to do packet forwarding. 172 Mobile Node 173 A host moving from its home link to other links. A 174 mobile node is capable of sending and receiving packets, 175 that is, being a source or destination of traffic, but 176 not a forwarder of it. 178 Mobile Router 179 A router moving from its home link to other links. A 180 mobile router is capable of forwarding packets between 181 two or more interfaces, and possibly running a dynamic 182 routing protocol modifying the state by which to do 183 packet forwarding. 185 This terminology is intended to conform to those that have been used in 186 IPv6, Mobile IPv6, and other Internet protocols [3, 5]. 188 3. Solution Overview 190 This document outlines a solution which satisfies the above 191 requirements. The one-digit prefixes are assumed to be legal prefixes 192 for globally routable links, e.g,. with prefix length 64. 194 +----+ +-------+ 195 | MN | | HA_MN | 196 +--+-+ 1:: +---+---+ 197 2+-------------+3 198 | 199 +-------+2 2:: +-------------------+ 3:: 2+-------+ 200 | CN_MN |------| Internet |------| CN_MR | 201 +-------+ +------------ GW ---+ +-------+ 202 4:: | 203 2+-------------+3 204 +--+-+ +---+---+ 205 | MR | | HA_MR | 206 +--+-+ +-------+ 207 5:: |1 208 ---------- 209 2| |3 210 +--+-+ +--+-+ 211 | FN | | FR | 212 +--+-+ +--+-+ 213 6:: |1 214 ---------- 216 Figure 1: Mobile node and mobile router at home. 218 In Figure 1, a mobile node (MN) 1::2 is at home on its home link where 219 we have its home agent 1::3 (HA_MN). A mobile router (MR) 4::2 is at 220 its home. It also provides routing for an access link 5::, on which 221 there is a fixed node (FN). MR also provides access for access link 6::, 222 which is behind a fixed fouter (FR). MR, GW, and HA are supposed to be 223 routers, so that they at least forward packets. They may also run the 224 same dynamic routing protocol. 226 In Figure 2 we see the bindings when MN moves away from its home to link 227 6::, after MN has signaled its home agent (HA_MN) and its correspondent 228 node (CN_MN), assuming mobile nodes or routers get the same host number 229 as in their home addresses. 231 In Figure 3 we see the bindings when MR moves away from its home 232 link, to link 7::, and it has updated its home agent (HA_MR), and its 233 correspondent node (CN_MR) on its new location. 235 +-------+ 236 | HA_MN | 1::2->6::2 237 1:: +---+---+ 238 -------------|3 239 | 240 +-------+2 2:: +-------------------+ 3:: 2+-------+ 241 | CN_MN |------| Internet |------| CN_MR | 242 +-------+ +------------ GW ---+ +-------+ 243 1::2->6::2 4:: | 244 2+-------------+3 245 +--+-+ +---+---+ 246 | MR | | HA_MR | 247 +--+-+ +-------+ 248 5:: |1 249 ---------- 250 2| |3 251 +--+-+ +--+-+ 252 | FN | | FR | 253 +--+-+ +--+-+ 254 6:: |1 255 --------+- 256 |2 257 +--+-+ 258 | MN | 259 +----+ 261 Figure 2: Mobile node not at home. 263 Both MN and MR hence use unmodified Mobile IPv6, except that there are 264 minor implications to the packet forwarding implementation of MR and 265 HA_MR. Basically, MR and HA_MR have a bidirectional tunnel between them. 266 These rules are simply that 268 - MR locally knows it is a mobile router and when not at home it 269 installs an encapsulation interface towards its home agent. 270 Through this interface, MR forwards (reverse-tunnels) all packets 271 not originated from MR towards its HA. For packets originated 272 from MR the behavior is as if MR were a normal MN; they get 273 forwarded on the visited link, except if the packets are targeted 274 to the home link; then they get reverse-tunneled to HA. Hence, 275 when arriving at a visited link, MR injects a default route and 276 a network route of its home link, towards the reverse tunnel it 277 creates pointing to its home agent, in addition to a default 278 route to MR's default router on the visited link. 280 +-------+ 281 | HA_MN | 1::2->6::2 282 1:: +---+---+ 283 -------------|3 284 | 285 +-------+2 2:: +-------------------+ 3:: 2+-------+ 286 | CN_MN |------| Internet |------| CN_MR | 287 +-------+ ++----------- GW ---+ +-------+ 288 3::2->6::2 | 7:: 4:: | 4::2->7::2 289 2+---- ------+3 290 +--+-+ +---+---+ 291 | MR | | HA_MR | 4::2->7::2 292 +--+-+ +-------+ 293 5:: |1 294 ---------- 295 2| |3 296 +--+-+ +--+-+ 297 | FN | | FR | 298 +--+-+ +--+-+ 299 6:: |1 300 --------+- 301 |2 302 +--+-+ 303 | MN | 304 +----+ 306 Figure 3: Mobile node and mobile router both on a visited link. 308 - If MR, HA_MR, and GW were running a dynamic routing protocol, 309 MR redirects control traffic of this protocol towards HA_MR, 310 tunneling these packets through the reverse tunnel pointing to 311 HA_MR. The dynamic routing protocol updates the routing state 312 between GW, HA_MR, and MR, so that next hops between GW and MR 313 now go through intermediate router HA_MR. There MAY be expedition 314 of routing state update, triggered by registration of MR with its 315 home agent. 317 - If it is not desired that MR runs a dynamic routing protocol, 318 HA_MR MUST inject routing entries for all mobile links behind 319 MR, using MR's home address as the next hop. That is, in our 320 example, HA_MR would inject network routes for 5:: and 6:: with 321 next hop 4::2. 323 - When HA_MR captures a data packet forwarded towards MR, its 324 forwarding engine then does a route lookup for this packet. If 325 the returned route has MR's home address as the next hop, it then 326 does a binding cache lookup for this next hop, and tunnels the 327 packet to the registered care-of-address of MR. 329 3.1. Application Scenarios 331 There are two application scenarios for this proposal, one for 332 restricted ``consumer'' mobile router support, and one for ``fully 333 enabled'' mobile router support. In the former, HA_MR injects static 334 routes for a restricted set of links behind each MR, when MR registers 335 with its HA. These are statically configured for each MR in its HA. In 336 this mode, MR cannot run dynamic routing protocol and arbitrarily modify 337 provider's routing cloud state. In the latter scenario, MR is a genuine 338 router running dynamic routing protocol. This provides support e.g. for 339 the case when provider's router moves to a visited link, or there is 340 exterior routing protocol running between MR and its GW, that is, when 341 the mobile router support is ``fully enabled''. 343 3.2. Mapping to requirements 345 With the simple scenario presented above, we can support the 346 requirements stated above. The solution 348 1 supports unmodified Mobile IP or Mobile IPv6 signaling. 350 2 supports communication to or from nodes on subnetwork(s) 351 connected to and moving with the mobile router. 353 3 supports both fixed and mobile nodes in the network moving with 354 the mobile router. Since links moving with MR do not change as 355 a result of movement, and their traffic get forwarded via MR's 356 home address, these nodes do not need separate binding updates 357 to any nodes. Binding-triggered route updates, as stated above, 358 keep them connected in a timely manner as a result of standard 359 routing. 361 4 supports arbitrary nesting level of mobile routers. MR support 362 provides transparency where second-level MR only sets up a tunnel 363 to its HA, this tunnel going inside tunnel set up by first-level 364 MR. This can then applied to subsequent levels, inductively. 366 5 supports static configuration; that is, the mobile router need 367 not have a dynamic routing protocol running on it. This is 368 provided by the ``consumer'' scenario. 370 6 supports dynamic configuration; This is provided by the 371 ``fully-enabled'' scenario. 373 7 allows routing entities to run the dynamic routing protocols 374 with no modifications to their signaling. Routing protocols are 375 not affected, though there can be route injections triggered by 376 binding updates from MR. 378 8 supports the end-to-end security model for mobility. No 379 intermediate node or router alters mobility state in mobile 380 nodes, routers, or their respective home agents and correspondent 381 nodes, since nodes do not send any additional binding updates on 382 behalf of other nodes. 384 However, this solution has one drawback: it has less than full route 385 optimization for the packets as they get forwarded through two-way 386 tunneling via MR's home agent. Route optimization is available for MN 387 in that it can let its CNs know its CoA. However, these packets pass 388 through the tunnel between MR and HA_MR. Route optimization is, however, 389 fully available for communication between MR and its CNs. With this 390 restriction, however, we can support arbitrary links behind MRs, nested 391 MNs, MRs, stub- and transit networks. 393 4. Protocol Messages and Signaling 395 This Mobile Router solution requires support in Home Agents and Mobile 396 Routers, since both entities must understand that a tunnel is to be 397 established, and packets for the mobile network must be routed through 398 that tunnel. Part of the support includes signaling, which can be 399 implicit (meaning that no changes to Mobile IP are necessary), or 400 explicit (allowing greater communication of status conditions and 401 specificity of prefix mappings). 403 In general, it is preferable to explicitly signal the intention to 404 change location of mobile network route segments. However, it may not 405 always be possible to specify changes to other protocols. Therefore, 406 both modes of signaling will be included. It is possible to support 407 both modes on a home agent and mobile router. 409 4.1. Explicit Signaling for IPv6 nodes 411 For IPv6 implementations, the following messages are suggested to be 412 used in signaling the intention to establish a Mobile Tunnel. These 413 messages are new protocol messages that are included in Mobile IPv6 414 Binding Updates and Binding Acknowledgements. 416 4.1.1. R-bit 418 This draft extends Mobile IPv6 to include a Mobile Router bit (R) in the 419 Binding Update message. 421 0 1 2 3 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |A|H|S|D|L|R| Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Sequence # | Reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Lifetime | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 + + 432 | | 433 + Home Address + 434 | | 435 + + 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 . . 440 . Mobility options . 441 . . 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 R-bit The R-bit is located at the 21st bit of the binding update 446 as depicted. It should be set to 1 only in BUs sent to the 447 HA. 449 The R-bit indicates that the home agent should create a 450 route to tunnel the mobile network packets to the CoA 451 included in the Binding Update. 453 If the R-bit is set to 0 and a previous static route 454 existed, the HA should delete it and cease forwarding 455 packets to the mobile network. The MR can use R=0 to cease 456 routing functionality and, in effect, become a MN. 458 4.1.2. Mobile Network Option 460 The Mobile Network Option is a mobility option included in the mobile 461 router's Binding Update message to specify the prefix(es) associated 462 with the MR. The Mobile Network Option is also used as a mobility option 463 in Binding Acknowledgement messages returned by the home agent to 464 specify the prefix(es) which have routing established. Mobile Network 465 Options are only used in Binding Update messages with R=1 from a mobile 466 router to its home agent, and Binding Acknowledgements from the home 467 agent to the mobile router. These two messages are distinguished by the 468 value of the Action field. 470 The mobile router may request specific prefixes for which the HA to 471 establish tunnel routes. Alternatively, if the HA is configured with 472 a list of MRs and their mobile network prefixes, the MR may omit the 473 Mobile Network Options and ``all prefixes'' is implied -- the HA will 474 start forwarding packets for all appropriate mobile network prefixes as 475 if Mobile Network Options for all usable prefixes were included in the 476 BU. 478 0 1 2 3 479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Option Type | Option Length | Action | Prefix Len | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 + + 485 | | 486 + Mobile Network Prefix + 487 | | 488 + + 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Option Type 6 (TBD by IANA) 494 Option Length 18 496 Action (in BU) 0 = No Action (remove routes) 498 1 = Forward (route through tunnel) 500 2 = Verify (Send ACK if this prefix is mine) 502 Action (in BA) 100 = OK (Route successfully created) 504 101 = Mobile Network Option sent from non-MR 506 102 = Invalid prefix (not part of valid address space) 508 103 = Prefix not owned by this domain/link 510 104 = Prefix not owned by MR which sent this MNO 511 105 = Could not create route / insufficient resources 513 Prefix Length Length of prefix, in bits (valid range is 1..128) 515 Mobile Network Prefix Prefix to route. Any bits after should be set 516 to 0. 518 Alignment requirement: This message must be aligned to 8n + 4. 520 Mobile Network Options should be sent by the home agent in 521 response to a binding update which establishes a binding for 522 the first time. It is not necessary to send them when the MR 523 is updating a binding with a new CoA, or when deregistering a 524 binding / removing a route. 526 4.2. Implicit Signaling 528 In general, implicit signaling means that signaling is not necessary 529 because of the implication of other factors. When a mobile router sends 530 a binding update to its home agent, the home agent knows which prefixes 531 are assigned to the router, and it sets up the static route and begins 532 forwarding traffic to the mobile network. The mobile router can test 533 that the tunnel is properly established by sending an echo request from 534 its CoA to its address on the mobile network. 536 With implicit signaling, the home agent keeps a list of mobile routers 537 and their associated prefixes. When a mobile router establishes a 538 binding, the home agent goes through all the same steps as in explicit 539 signaling (static route setup, and rules for packet forwarding), but 540 does not relay any status information to the mobile router. Thus, the 541 effects of routing changes must be learned using existing protocol 542 messages, i.e. ICMP echo request/reply. 544 5. Alternate Solutions 546 Another solution [4] was previously proposed, and follows a slightly 547 different set of requirements. It includes support for route 548 optimization, and requires changes to Mobile IP signaling. Providing 549 a generic scalable solution for the address ownership problem may 550 prove to be complicated. A problem is, how can a mobile router or an 551 intermediate agent efficiently authorize multiple fixed and mobile nodes 552 to communicate with their peers, when all these may be from multiple 553 different domains, and the mobile router is not and end node for their 554 communication. However, if this issue can be solved, or if a controlled 555 security environment is feasible, this alternate may provide additional 556 benefits when compared to this proposal. 558 Other solutions using inter-domain routing protocols may be possible, 559 depend on the willingness of the routing infrastructure to trust mobile 560 routers. 562 6. Support for Dynamic Routing Protocol 564 In the fully enabled mode, the mobile router (MR) runs a dynamic routing 565 protocol with its home agent (assumed to be a router) to exchange 566 up-to-date routing information. The mobile router continues running 567 this intra-domain routing protocol even when it moves away from home 568 and attaches to a visited domain. One of the requirements listed in 569 section 1 is to avoid any modifications to the routing protocol. This 570 can be done by dynamically modifying the list of interfaces on which 571 the routing protocol is active. For example, let us assume a mobile 572 router used interface 'A' when it was connected to its home network 573 and was exchanging routing updates through that interface. When the 574 mobile router moves and attaches to a visited network with the same 575 interface, the routing protocol is turned off for that interface. This 576 is to prevent the mobile router from advertising the routes in its 577 mobile subnet to the visited network. The mobile router then sets up 578 a encapsulating tunnel to its home agent (HA_MR). This encapsulating 579 tunnel is then added as a virtual interface to the list of interfaces 580 on which the routing protocol is active. The mobile router then 581 starts sending routing information through this tunnel to the HA_MR. 582 Most IPv6 intra-domain routing protocols assume link local address to 583 appear as the source address for routing information messages. The 584 encapsulating tunnel takes care of this, by encapsulating the routing 585 messages in a IP header whose source address is the mobile router's CoA 586 and the destination address is HA_MR's address. When HA_MR receives the 587 tunneled routing message, it decapsulates it and processes the inner 588 routing message. The inner routing message appears as if the packet was 589 sent from a node on the link. 591 The HA_MR also sets up a similar tunnel to the MR and adds the tunnel to 592 the list of interfaces on which the routing protocol is active. HA_MR 593 then tunnels the routing information it has towards the mobile router. 594 The mobile router now learns about HA_MR's routing information. 596 The tunneled packets are sent through a secured channel between the 597 mobile router and HA_MR. This secured channel is made possible by a 598 static or a pre-negotiated security association between the mobile 599 router and its HA_MR. The tunneled routing messages MUST be protected by 600 Authentication Header [6]. If data confidentiality is required, ESP [7] 601 SHOULD be used. 603 Certain routing protocols like OSPFv2 [8]or OSPF for IPv6 [2] exchange 604 periodic HELLO messages between adjacent routers. In our case these 605 periodic messages from the mobile router are sent through this tunnel to 606 its HA_MR. 608 6.1. Processing the Tunneled Routing Messages 610 When the HA_MR receives the routing information from the mobile router 611 through the bidirectional tunnel, it adds the corresponding routes to 612 its routing table with the next hop set to the mobile router's address, 613 in case of IPv6 MR's link local address. This next hop address is 614 obtained from the source address of the inner packet. The HA_MR in 615 turn propagates this information when it sends routing updates to other 616 routers on the mobile router's home link. 618 The HA_MR also needs a binding cache entry for that address which is 619 the next hop address for the MR's subnet. In the case of IPv4 this 620 is created when the MR sends a registration request [?] for its home 621 address when it moves away from its home link. In the case of IPv6 622 HA_MR needs a binding cache entry to the mobile router's link local 623 address. This is because the next hop address in the routing table 624 entry returns the mobile router's link local address. And to forward 625 packets to the mobile router's link local address, a binding cache entry 626 is needed. A binding cache entry is not created unless HA_MR receives a 627 binding update from the mobile router. Therefore the mobile router MUST 628 send a binding update for its link local address in addition to its home 629 address. This is optional in the current Mobile IPv6 [5] specification. 631 6.2. Forwarding Packets to MR's subnet 633 Since HA_MR advertised routing reachability information for MR's 634 subnet, it receives the packets meant for the nodes in the MR's subnet. 635 Route lookup on HA_MR returns the address of the mobile router as the 636 next hop address. By making use of the binding cache entry for the 637 mobile router's address (link local address in case of IPv6) and the 638 bi-directional tunnel with the mobile router, HA_MR starts forwarding 639 packets throught the tunnel to the mobile router. The mobile router in 640 turn decapsulates the packet and fowards it on its subnet. 642 7. Security Considerations 644 The mechanism described in this draft requires routing messages 645 exchanged between a mobile router and its home agent to be secured when 646 the mobile router is not on its home link. This is done by creaating 647 a static security association between the mobile router and its home 648 agent. This document does not require changes to either Mobile IP or 649 any routing protocol. Therefore, it does not introduce any additional 650 security requirements. 652 8. IANA Considerations 654 The following protocol numbers may require allocation from IANA: 656 - The Mobile Network Option is a mobility option in the Mobile IPv6 657 mobility header. The Option Type should be allocated within this 658 namespace. 660 9. Intellectual Property Right Considerations 662 On IPR related issues, Nokia refers to its statement on patent 663 licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA. 665 10. Acknowledgements 667 The authors would like to thank the following individuals who have made 668 suggestions to improve the text of this draft which were incorporated: 670 Marco Molteni (Cisco) Tapio Suihko (Technical Research Centre of 671 Finland) 673 References 675 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 676 Levels. Request for Comments (Best Current Practice) 2119, 677 Internet Engineering Task Force, March 1997. 679 [2] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. Request for 680 comments (proposed standard), Internet Engineering Task Force, 681 December 1999. 683 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) 684 Specification. Request for Comments (Draft Standard) 2460, 685 Internet Engineering Task Force, December 1998. 687 [4] et al. Ernst, T. Mobile networks support in mobile ipv6. 688 Internet Draft, Internet Engineering Task Force, June 2001. 690 [5] D. Johnson and C. Perkins. Mobility support in IPv6 (work in 691 progress). Internet Draft, Internet Engineering Task Force, 692 November 1998. 694 [6] S. Kent and R. Atkinson. IP Authentication Header. Request for 695 Comments (Proposed Standard) 2402, Internet Engineering Task 696 Force, November 1998. 698 [7] S. Kent and R. Atkinson. IP Encapsulating Security Payload 699 (ESP). Request for Comments (Proposed Standard) 2406, Internet 700 Engineering Task Force, November 1998. 702 [8] J. Moy. OSPF Version 2. Request for Comments (Standard) 2328, 703 Internet Engineering Task Force, April 1998. 705 [9] C. Perkins. IP Mobility Support. Request for Comments (Proposed 706 Standard) 2002, Internet Engineering Task Force, October 1996. 708 Authors' Addresses 710 T. J. Kniveton Vijay Devarapalli 711 Communication Systems Lab Communication Systems Lab 712 Nokia Research Center Nokia Research Center 713 313 Fairchild Drive 313 Fairchild Drive 714 Mountain View, California 94043 Mountain View, California 94043 715 USA USA 716 Phone: +1 650 625-2025 Phone: +1 650 625-2320 717 EMail: timothy.kniveton@nokia.com EMail: vijayd@iprg.nokia.com 718 Fax: +1 650 625-2502 Fax: +1 650 625-2502 720 Jari T. Malinen Charles Perkins 721 Communication Systems Lab Communication Systems Lab 722 Nokia Research Center Nokia Research Center 723 313 Fairchild Drive 313 Fairchild Drive 724 Mountain View, California 94043 Mountain View, California 94043 725 USA USA 726 Phone: +1 650 625-2355 Phone: +1 650 625-2986 727 EMail: jmalinen@iprg.nokia.com EMail: charliep@iprg.nokia.com 728 Fax: +1 650 625-2502 Fax: +1 650 625-2502 730 Full Copyright Statement 732 Copyright (C) The Internet Society (2001-2002). All Rights Reserved. 734 This document and translations of it may be copied and furnished to 735 others, and derivative works that comment on or otherwise explain it 736 or assist in its implementation may be prepared, copied, published and 737 distributed, in whole or in part, without restriction of any kind, 738 provided that the above copyright notice and this paragraph are included 739 on all such copies and derivative works. However, this document itself 740 may not be modified in any way, such as by removing the copyright notice 741 or references to the Internet Society or other Internet organizations, 742 except as needed for the purpose of developing Internet standards 743 in which case the procedures for copyrights defined in the Internet 744 Standards process must be followed, or as required to translate it into 745 languages other than English. 747 The limited permissions granted above are perpetual and will not be 748 revoked by the Internet Society or its successors or assigns. 750 This document and the information contained herein is provided on an 751 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 752 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 753 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 754 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 755 FITNESS FOR A PARTICULAR PURPOSE. 757 Acknowledgement 759 Funding for the RFC editor function is currently provided by the 760 Internet Society.