idnits 2.17.00 (12 Aug 2021) /tmp/idnits55883/draft-perera-nemo-extended-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 76 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 470: '...rstand this flag MUST ignore it. We al...' RFC 2119 keyword, line 498: '...e Router (R) bit MUST be set to 1 in t...' RFC 2119 keyword, line 508: '... Receivers MUST ignore any optio...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 285 has weird spacing: '...hin the mobil...' == Line 467 has weird spacing: '...This is to...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '3' is mentioned on line 164, but not defined == Unused Reference: '7' is defined on line 667, but no explicit reference was found in the text == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-seamoby-mobility-terminology has been published as RFC 3753 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. '4') ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) == Outdated reference: draft-ietf-dhc-dhcpv6 has been published as RFC 3315 ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group Eranga Perera 2 INTERNET DRAFT UNSW 3 29th July 2003 Robert Hsieh 4 UNSW 5 Aruna Seneviratne 6 UNSW 8 Extended Network Mobility Support 9 draft-perera-nemo-extended-00.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. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html. 31 Abstract 32 This draft proposes a solution for extended network mobility support, 33 that is a mechanism to enable optimal routing between mobile network 34 nodes and its correspondent nodes. The proposed scheme not only 35 provides optimal routing for the mobility aware nodes but also 36 maintains the benefits of mobility transparency. Our solution 37 achieves route optimization by expecting the Mobile Router to take 38 the role of an Access Router thereby reducing the number of external 39 signaling messages a node behind the Mobile Router needs to perform. 40 In order to further reduce the number of signaling messages beyond 41 the scope of the mobile network we further propose the Mobile Router 42 to play the role of an Home Agent for NEMO-enabled nodes. 44 Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.1 Dual Roles of the Mobile Router. . . . . . . . . . . . . . 7 54 3.1.1 Mobile Router as an Access Router. . . . . . . . . . 7 56 3.1.2 Mobile Router as a Home Agent. . . . . . . . . . . . 8 58 3.2 Enabling Route Optimization for the Mobile Network Nodes . 9 60 3.2.1 Enabling Route Optimization for the Mobile Router. . 9 62 3.2.2 Enabling Route Optimization for Nodes behind the 63 Mobile Router. . . . . . . . . . . . . . . . . . . . 9 65 4. Mobile Router Operations . . . . . . . . . . . . . . . . . . . 10 67 4.1 Mobile Router Operations as an Access Router. . . . . . . . 10 69 4.2 Mobile Router operations as a Home Agent. . . . . . . . . . 11 71 4.2.1 Process of Discovering the Mobile Router . . . . . . 11 73 4.2.2 Establishment of a Bidirectional between the Mobile 74 Router and the NEMO-enabled nodes . . . . . . . . . 12 76 4.2.3 Establishment of a Bidirectional tunnel between the 77 Mobile Router and its Home Agent . . . . . . . . . . 12 79 5. Mobile Router's Home Agent Operations . . . . . . . . . . . . . 13 81 6. Mobile Network Nodes Route Optimization Operations . . . . . . 14 83 6.1 MIPv6-enabled Mobile Network Nodes Route Optimization 84 operations . . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.2 NEMO-enabled Local Mobile Node and Local Fixed Node 87 Operations . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 The basic NEMO protocol [1] provides session continuity to all the 94 nodes in the mobile network. This is achieved by creating a 95 bidirectional tunnel between the Mobile Router and its Home Agent. 96 Although this is achieved while providing complete mobility 97 transparency to the nodes within the network, the solution forces all 98 datagrams for a mobile node to be routed through the Home Agent. Our 99 solution proposes a mechanism in order to overcome this indirect 100 routing and provide route optimization for all MIPv6-enabled nodes of 101 a mobile network. 103 In MIPv6 [2] route optimization provide a means for mobile nodes to 104 send their current mobility bindings, in particular, the care-of 105 address to the correspondent nodes, enabling direct communication. It 106 is evident that in order for a mobile node to perform route 107 optimization, it should be aware of its current location. 108 If we were to provide network mobility transparency to all nodes 109 within the mobile network, as the mobile nodes within the mobile 110 network are unaware of their current location, would need to depend 111 on the Mobile Router to deal with all mobility management issues 112 including route optimization. We advocate on not adhering to the 113 design goal of network mobility transparency when providing extended 114 mobility support. We believe that allowing a mobile node to handle 115 sending Binding Updates to its correspondent nodes is a much secure 116 task than depending on another node to perform this task. Our scheme 117 preserves benefits of mobility transparency when providing optimal 118 routing for MIPv6-enabled nodes. This is achieved by extending the 119 Mobile Router's operations, in order to limit the signaling that a 120 mobile network node needs to perform beyond the scope of the mobile 121 network to a minimum. 123 Although our solution would only support MIPv6-enabled nodes in 124 optimal routing our solution does not inhibit in anyway the correct 125 operation of the NEMO basic protocol for mobility unaware nodes. Our 126 solution is backward compatible with MIPv6 and also compatible with 127 the solution for basic NEMO support. 129 2. Terminology 131 This document uses the mobility related terminology defined in [2], 132 [3] and [4]. 133 The following terms are used as defined in [2]. 135 - Home Agent 137 - Home Address 139 - Care-of Address 141 - Binding Update 143 The following terms defined in [3] specific to network mobility are 144 used in this draft. 146 - Local Mobile Node 148 - Local Fixed Node 150 - Visiting Mobile Node 152 - Mobile Network Node 154 - Correspondent Nodes 156 - Home Subnet Prefix 158 - MIPv6-enabled (MIPv6-node) 160 - Node behind the Mobile Router 162 Except for the definitions of the terms 'Mobile Router' and 163 'NEMO-enabled' the rest of the above terms are used as per 164 definitions in [3]. Before presenting our extensions to the 165 definition of a Mobile Router we state the definitions of a Home 166 Agent [2] and Access Router [4], since our definition relies on these 167 two terms. 169 Access Router - 171 An Access Network Router residing on the edge of an Access Network 172 and connected to one or more Access Points. The Access Points 173 maybe of different technology. An Access Router offers IP 174 connectivity to Mobile Nodes, acting as a default router to the 175 Mobile Nodes it is currently serving. The Access Router may 176 include intelligence beyond a simple forwarding service offered 177 by ordinary IP routers. 179 Home Agent - 181 A router on a mobile node's home link with which the mobile node 182 has registered its current care-of address. While the mobile 183 node is away from home, the Home Agent intercepts packets on the 184 home link destined to the mobile node's home address, 185 encapsulates them, and tunnels them to the mobile node's 186 registered care-of address. 188 Mobile Router - 190 A router capable of changing its point of attachment to the 191 network, moving from one link to another link. The Mobile Router 192 is capable of forwarding packets between two or more interfaces, 193 and possibly running a dynamic routing protocol modifying the 194 state by which to do packet forwarding. 196 The interface of a Mobile Router attached to a link inside the 197 mobile network is called the Ingress interface. The interface of a 198 Mobile Router attached to the home link if the Mobile Router is at 199 home, or attached to a foreign link if the Mobile Router is in a 200 foreign network is called the Egress interface. 202 A Mobile Router acting as a gateway between an entire mobile 203 network and the rest of the Internet has one or more Egress 204 interface(s) and one or more Ingress interface(s). Packets 205 forwarded upstream to the rest of the Internet are transmitted 206 through one of the Mobile Router's Egress interfaces; packets 207 forwarded downstream to the mobile network are transmitted through 208 one of the Mobile Router's Ingress interfaces. 210 Our extension to this definition - 212 A router capable of playing the role of a Home Agent for the 213 Local Mobile Nodes and Local Fixed Nodes belonging to its home 214 network link and playing the role of an Access Router for Local 215 Mobile Nodes, Local Fixed Nodes, Visiting Mobile Nodes. 217 NEMO-enabled - 219 A MIPv6-enabled Local Mobile Node or Local Fixed Node that is 220 capable of dynamically reconfiguring its Home Agent to be the 221 Mobile Router when the Mobile Network is attached to a foreign 222 link. 224 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in RFC 2119 []. 228 3. Overview 230 This scheme provides a mechanism to enable route optimization for the 231 mobile network nodes that are MIPv6-enabled. One might question the 232 need for the Mobile Router's participation in the mobility management 233 of these nodes when they are MIPv6-enabled. The reason for relying on 234 the Mobile Router to perform certain tasks for the nodes behind it, 235 is to preserve the benefits of mobility transparency. Consider a 236 mobile network scenario of an aircraft with potentially many Visiting 237 Mobile Nodes (passengers with mobile devices), Local Fixed Nodes 238 (fixed terminals on every seat for Internet access) and Local Mobile 239 Nodes (mobile devices that belong to aircraft personnel). In such a 240 scenario, as the aircraft moves each of the above mentioned devices 241 would need to communicate with an external Access Router in order to 242 get the prefix of the new access network. These mobile devices would 243 need to be technologically sophisticated to communicate with external 244 Access Routers potentially via satellite links. These devices can 245 overcome such technical difficulties and minimize the number of 246 signaling messages beyond the scope of the mobile network by relying 247 on the Mobile Router to perform the tasks of an Access Router for the 248 nodes sitting behind it. 250 Consider in the above aircraft scenario the need for each Local 251 Mobile Node and Local Fixed Node having to send a separate Binding 252 Update to their respective Home Agents. We advocate on making these 253 nodes to be NEMO-enabled in order to avoid the need for individual 254 Binding Updates to be sent to their Home Agents. The Mobile Router 255 can send one Binding Update to a Home Agent on the Home network 256 representing itself and the NEMO-enabled nodes behind it. This 257 mechanism reduces the number of external signaling messages a 258 NEMO-enabled node needs to perform, reduces the overall usage of 259 bandwidth beyond the scope of the mobile network and also reduces the 260 burden on the Home Agent residing on the home network. By requiring 261 the Mobile Router to play the role of a Home Agent for NEMO-enabled 262 nodes, our scheme introduces a hierarchical Home Agent structure for 263 network mobility which is depicted in figure 1. 264 __|_ 265 | | 266 | HA | <----- Mobile Router's Home Agent 267 |____| 268 ______|__ 269 _|__ 270 | | 271 | MR | <----- NEMO-enabled node's Home Agent 272 |____| 273 | 274 _____|_____________________________ 275 __|__ __|__ __|__ 276 | | | | | | 277 | LFN | | LMN | | LFN | . . . . . . . 278 |_____| |_____| |_____| 280 Figure 1: Hierarchical Home Agent Structure 281 3.1 Dual Roles of the Mobile Router 283 This section provides an overview of roles that the Mobile Router 284 performs in order to preserve the benefits of hiding mobility from 285 the nodes within the mobile network. 287 3.1.1 Mobile Router as an Access Router 289 The Mobile Router when attached to a foreign network will 290 obtain a prefix pertaining to the new network. Once this is 291 done the Mobile Router will act as an Access Router for the 292 nodes behind it and will send Router Advertisement messages 293 on its Ingress interface. Any MIPv6-enabled node sitting 294 behind the Mobile Router will be able to use the prefix 295 advertised by the Mobile Router and using stateless address 296 auto configuration [5] form a care-of address for itself. 297 Figure 2 depicts an instance of the Mobile Router playing the 298 role of an Access Router to MIPv6-enabled Local Mobile Nodes, 299 Local Fixed Nodes and Visiting Mobile Nodes. 301 ____ ____ 302 | | | | 303 | CN | | CN | 304 |____| |____| 305 ___|_______________|____ 306 | | 307 | | 308 | Internet | 309 | | 310 |________________________| 311 __|_ __|_ 312 | | Access | | 313 | AR | Router | AR | 314 |____| |____| 315 ______|__ Foreign 316 _|__ Link 317 | | 318 | MR | 319 |____| 320 |<------- Access Router Mode 321 _____|______________________ 322 __|__ __|__ __|__ 323 | | | | | | 324 | VMN | | LMN | | LFN | 325 |_____| |_____| |_____| 327 Figure 2: Instance of a Mobile Router playing the role of 328 an Access Router 329 3.1.2 Mobile Router as a Home Agent 331 NEMO-enabled nodes sitting behind the Mobile Router can 332 further reduce the number of external signaling messages by 333 relying on the Mobile Router to perform the role of a Home 334 Agent for them. Since a Home Agent is a router that resides in 335 a mobile nodes home network we can take the Mobile Router to 336 be a Home Agent for the Local Fixed Nodes and the Local Mobile 337 Nodes because with respect to the Mobile Router's topology 338 these nodes are at home. These nodes would obtain a prefix 339 from the Access Router that is the Mobile Router and auto 340 configure a care-of address. These operations will not differ 341 from a standard MIPv6 mobile node operations. The NEMO-enabled 342 nodes will register its current care-of address with the 343 Mobile Router by dynamically configuring the Mobile Router to 344 be their Home Agent if they belong to the Mobile Router's home 345 network. Mobile Router would send an aggregated Binding Update 346 to the Home Agent residing in the home network to which this 347 mobile network belongs, reducing the usage of bandwidth. The 348 Mobile Router on receiving any packets for the registered 349 nodes will tunnel these packets to the registered care-of 350 addresses of the NEMO-enabled nodes. Figure 3 depicts an 351 instance of a Mobile Router playing the role of a Home Agent 352 for NEMO-enabled nodes. 353 ____ ____ 354 | | | | 355 | CN | | CN | 356 |____| |____| 357 ___|_______________|____ 358 | | 359 | | 360 | Internet | 361 | | 362 |________________________| 363 __|_ 364 | | Access 365 | AR | Router 366 |____| 367 ______|__ Foreign 368 _|__ Link 369 | | 370 | MR | 371 |____| 372 |<------- Home Agent Mode 373 _____|______________________ 374 __|__ __|__ 375 | | | | 376 | LMN | | LFN | 377 |_____| |_____| 379 Figure 3: Mobile Router playing the role of a Home Agent 381 3.2 Enabling Route Optimization for the Mobile Network Nodes 383 This section provides an overview of the route optimization procedure 384 for MIPv6-enabled mobile network nodes. 386 3.2.1 Enabling Route Optimization for the Mobile Router 388 The Mobile Router acting as a Mobile Node can register its 389 care-of address with a Home Agent as well as its Correspondent 390 Nodes. This enables direct communication between the Mobile 391 Router and the MIPv6-enabled Correspondent Nodes. This operation 392 does not differ from standard MIPv6 route optimization procedure 393 for a Mobile node. If the Mobile Router is operating as a Home 394 Agent then the Mobile Router would send a Binding Update to its 395 Home Agent representing the nodes registered with it according 396 to the NEMO basic protocol. 398 3.2.2 Enabling Route Optimization for MIPv6-enabled nodes sitting 399 behind the Mobile Router 401 These nodes can obtain prefix information pertaining to the 402 current position of the Mobile Network from the Mobile Router, 403 now acting as an Access Router. This process will be described in 404 detail in Section 4. Once the prefix is obtained these nodes can 405 auto configure a care-of address and send Binding Updates to 406 their Home Agent as well as their Correspondent Nodes. Again it 407 is evident that route optimization is achieved by these nodes 408 using a reduced number of signaling messages with external 409 routers as the Mobile Router plays the role of an Access Router 410 for the nodes within the mobile network. It is also evident that 411 optimal routing for nodes behind the Mobile Router is achieved 412 without requiring any changes to the standard MIPv6 operation of 413 these nodes as well as their Correspondent Nodes. 415 The NEMO-enabled nodes can opt to dynamically configure the 416 Mobile Router to be their Home Agent. This process will be 417 explained in Section 5. In this case these nodes need only to 418 send a Binding Update to the Mobile Router and the Mobile Router 419 will perform the duties of a MIPv6 Home Agent for these nodes. 420 NEMO-enabled nodes can perform route optimization as a standard 421 MIPv6 node once they dynamically configure the Mobile Router to 422 be their Home Agent. 424 4. Mobile Router Operations 426 In Section 4.1 we provide the details of operations a Mobile Router 427 needs to perform when playing the role of an Access Router. This is 428 followed by a description of operations a Mobile Router performs as a 429 Home Agent in Section 4.2. 431 4.1 Mobile Router Operations as an Access Router 433 The Mobile Router would obtain a prefix from the Access Router in 434 the visited network operating as a standard MIPv6 node. This is 435 performed by running a prefix delegation protocol such as DHCPv6 436 [5]. (Details of this is beyond the scope of this document) After 437 obtaining the prefix the Mobile Router would advertise this prefix 438 to the nodes behind the Mobile Router. This can be done by using 439 Router Advertisements as described in RFC 2461 [6] with no 440 extensions. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | Code | Checksum | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Reachable Time | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Retrans Timer | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Options ... 454 +-+-+-+-+-+-+-+-+-+-+-+- 456 Figure 4: Router Advertisement Message Format 458 4.2 Mobile Router operations as a Home Agent 460 In this section we describe the operations a Mobile Router needs to 461 perform when it is capable of playing the role of an Home Agent. 463 4.2.1 Process of Discovering the Mobile Router 465 If the Mobile Router is capable of playing the role of a Home 466 Agent we propose to extend the above Router Advertisement 467 message format by introducing a new flag bit R. This is to 468 indicate to the NEMO-enabled nodes that the Router sending the 469 Advertisements is a Mobile Router. The receivers which do not 470 understand this flag MUST ignore it. We also introduce a new 471 option named 'Home Link' to specify the Mobile Router's home 472 link prefix. This option assists the NEMO-enabled nodes to 473 determine whether they belong to the same link as the Mobile 474 Router. If the prefix advertised on the 'Home Link' option 475 matches the home address prefix of any of the NEMO-enabled 476 nodes, these nodes can opt to reconfigure the Mobile Router as 477 their Home Agent. 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 | Type | Code | Checksum | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Cur Hop Limit |M|O|R| Reserved| Router Lifetime | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Reachable Time | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Retrans Timer | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Options ... 490 +-+-+-+-+-+-+-+-+-+-+-+- 492 Figure 5: Router Advertisement Message Format 494 This format represents the following changes over that 495 originally specified in RFC 2461 [6]: 497 Mobile Router Bit(R)- 498 The Mobile Router (R) bit MUST be set to 1 in the Router 499 Advertisement sent by the Mobile Router while the Mobile Router 500 is attached to a foreign link. 502 Reserved Field - 503 The Reserved Field changed from 6 bits to 5 bits. 505 Options - 506 Home Link : 507 This option specifies the Mobile Router's home link prefix. 508 Receivers MUST ignore any options they do not recognize and 509 continue processing the message [6]. 511 4.2.2 Establishment of a Bidirectional Tunnel between the Mobile 512 Router and the NEMO-enabled nodes 514 The nodes which opts to use the Mobile Router as the Home Agent 515 would send Binding Updates to the Mobile Router. If the Binding 516 update is valid that is if the message is from a node that 517 belongs to the Mobile Router's home network, the Mobile Router 518 would send a Binding Acknowledgement to the sending node. This 519 process would establish a bidirectional tunnel between the 520 Mobile Router and these nodes. The binding messages exchanged 521 here are in the same format as standard MIPv6. 523 4.2.3 Establishment of a Bidirectional Tunnel between the Mobile 524 Router and its Home Agent 526 The Mobile Router would send a Binding Update to its Home Agent 527 indicating that its behaving as a Mobile Router and not a 528 Mobile Node. This can be done by employing the Binding Update 529 format used in the NEMO basic protocol [1]. A new flag bit, 530 Mobile Router flag(R) is used in [1]. When this flag is set the 531 the Home Agent forwards packets destined to the mobile network 532 to the Mobile Router. We propose to use the new mobility 533 options defined in [1] in addition to what is defined in [2] in 534 order to adhere with the NEMO basic protocol. These options are 535 not described on this document, for details refer Section 4.1 536 in [1]. Figure 5 illustrates the new Binding Update format. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Sequence # | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |A|H|L|K|R| Reserved | Lifetime | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 . . 547 . Mobility options . 548 . . 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 6 : Format of Binding Update with new Mobile 552 Router Flag bit (R) 553 Mobile Router Flag (R) 555 The Mobile Router Flag is set to indicate to the Home Agent 556 that the Binding Update is from a Mobile Router. If the flag 557 is set to 0, the Home Agent assumes that the Mobile Router is 558 just behaving as a Mobile Node, and should not forward packets 559 destined for the mobile network to the Mobile Router. 561 5. Mobile Router's Home Agent Operations 563 On receiving a Binding Update with the Mobile Router flag bit (R) set 564 the Home Agent of the mobile network would place it in its binding 565 cache. When a packet arrives at the home network the Home Agent would 566 intercept the packet and would look up the binding cache with a 567 longest prefix matching algorithm. We advocate on the use of such an 568 algorithm at the Home Agent in order to accommodate Local Mobile 569 Nodes being away from the home network as well as not being in the 570 mobile network. Figure 6 below depicts such a scenario. Use of such 571 an algorithm would also accommodate nodes which are not NEMO-enabled 572 but are MIPv6 capable. If the Home Agent has a Binding Update for a 573 full address or a longer prefix than the mobile network's prefix it 574 would be routed to the care-of address on this Binding Update. 576 ____ ____ ____ ____ 577 | | | | | | | | 578 | CN | | CN | | CN | | CN | 579 |____| |____| |____| |____| 580 _____|_______________|____________|_____________|______ 581 | | 582 | | 583 | Internet | 584 | | 585 |_______________________________________________________| 586 __|_ __|_ __|_ 587 | | Access | | | | 588 | AR | Router | AR | | AR | 589 |____| |____| |____| 590 ______|__ Foreign _____|___ Home ______|___ Foreign 591 _|__ Link __|_ Link _|___ Link 592 | | | | | | 593 | MR | | HA | | LMN | 594 |____| |____| |_____| 595 | 596 _____|______________________ 597 __|__ __|__ __|__ 598 | | | | | | 599 | VMN | | LMN | | LFN | 600 |_____| |_____| |_____| 602 Figure 7: Local Mobile Node away from the Home Network and Mobile 603 Network 605 6. Mobile Network Nodes Route Optimization Operations 607 6.1 MIPv6-enabled Mobile Network Nodes Operations 609 These nodes would obtain the new access network prefix from the 610 Router Advertisement messages sent by the Mobile Router, which 611 enables them to auto configure a topologically correct address. 612 Each of them having their own care-of address can operate as 613 standard MIPv6 nodes and enable route optimization. 615 6.2 Operations specific to NEMO-enabled Nodes 617 We define any NEMO-enabled node to be capable of dynamically 618 reconfiguring its Home Agent to be the Mobile Router. These nodes 619 upon receiving Router Advertisements with the Mobile Router Flag 620 (R) set can choose to make the Mobile Router to be their Home 621 Agent. After reconfiguring the Mobile Router to be their Home Agent 622 these nodes need not perform any other network mobility related 623 operations. These nodes are then able to achieve route optimization 624 by following the standard MIPv6 protocol while needing to only 625 communicate with a Home Agent that resides locally. Since the 626 Mobile Router plays the role of a standard MIPv6 Home Agent for 627 these nodes this hierarchical Home Agent structure is hidden from 628 the NEMO-enabled nodes. 630 7. Security Considerations 632 The Mobile Network Nodes having their own care-of address can perform 633 the return routability procedure [2] as standard MIPv6 nodes. When 634 the Mobile Router is sending a Binding Update representing the 635 NEMO-enabled nodes sitting behind it, it is necessary that the Home 636 Agent verifies that these Binding Updates belong to the Mobile 637 Network. This does not add any security consideration other than what 638 is described in NEMO basic protocol [1]. 640 Acknowledgements 642 This work was carried out through an Australian Research Council Linkage 643 Postgraduate Research Award with Vodafone Australia Future Technologies. 645 References 647 [1] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert. Nemo 648 Basic Support Protocol (work in progress), Internet Draft, 649 IETF. draft-ietf-nemo-basic-support-00.txt, June 2003 651 [2] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work 652 in progress),Internet Draft, IETF, draft-ietf-mobileip-ipv6-22.txt. 653 May 2003 655 Internet Draft Extended Network Mobility Support 21 July 657 [4] J. Manner and M. Kojo, "Mobility Related Terminology", (work in 658 progress), draft-ietf-seamoby-mobility-terminology.txt, Internet 659 Draft, IETF, April 2003 661 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 662 Autoconfiguration", RFC 2462, December 1998 664 [6] Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 665 draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. 667 [7] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for IP 668 Version 6 (IPv6), RFC 2461, IETF, December 1998 670 Author's Addresses : 672 Eranga Perera 673 University of New South Wales 674 Department of Electrical Engineering and Telecommunications 675 Sydney, 676 NSW 2052, 677 Australia 678 Email : eranga@mobqos.ee.unsw.edu.au 680 Robert Hsieh 681 University of New South Wales 682 Department of Electrical Engineering and Telecommunications 683 Sydney, 684 NSW 2052, 685 Australia 686 Email : roberth@ee.unsw.edu.au 688 Aruna Seneviratne 689 University of New South Wales 690 Department of Electrical Engineering and Telecommunications 691 Sydney, 692 NSW 2052, 693 Australia 694 Email : a.seneviratne@unsw.edu.au