idnits 2.17.1 draft-ietf-nemo-ro-space-analysis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1851. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 15, 2006) is 6426 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-05 == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-05 -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '13') (Obsoleted by RFC 5380) == Outdated reference: A later version (-02) exists of draft-thubert-nemo-global-haha-01 -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '15') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '17') (Obsoleted by RFC 5268) == Outdated reference: A later version (-01) exists of draft-bernardos-nemo-miron-00 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '28') (Obsoleted by RFC 4861) == Outdated reference: A later version (-01) exists of draft-ming-nemo-sipnemo-00 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-04 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Intended status: Informational F. Zhao 5 Expires: March 19, 2007 UC Davis 6 M. Watari 7 KDDI R&D Labs 8 P. Thubert 9 Cisco Systems 10 September 15, 2006 12 Network Mobility Route Optimization Solution Space Analysis 13 draft-ietf-nemo-ro-space-analysis-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 19, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 With current Network Mobility (NEMO) Basic Support, all 47 communications to and from Mobile Network Nodes must go through the 48 MRHA tunnel when the mobile network is away. This results in 49 increased length of packet route and increased packet delay in most 50 cases. To overcome these limitations, one might have to turn to 51 Route Optimization (RO) for NEMO. This memo documents various types 52 of Route Optimization in NEMO, and explores the benefits and 53 tradeoffs in different aspects of NEMO Route Optimization. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Benefits of NEMO Route Optimization . . . . . . . . . . . . . 5 60 3. Different Scenarios of NEMO Route Optimization . . . . . . . . 7 61 3.1. Non-Nested NEMO Route Optimization . . . . . . . . . . . . 7 62 3.2. Nested Mobility Optimization . . . . . . . . . . . . . . . 9 63 3.2.1. Decreasing the Number of Home Agents on the Path . . . 9 64 3.2.2. Decreasing the Number of Tunnels . . . . . . . . . . . 10 65 3.3. Infrastructure based Optimization . . . . . . . . . . . . 10 66 3.4. Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 11 67 4. Issues of NEMO Route Optimization . . . . . . . . . . . . . . 13 68 4.1. Additional Signaling Overhead . . . . . . . . . . . . . . 13 69 4.2. Increased Protocol Complexity and Processing Load . . . . 14 70 4.3. Increased Delay during Handoff . . . . . . . . . . . . . . 14 71 4.4. Extending Nodes with New Functionalities . . . . . . . . . 14 72 4.5. Detection of New Functionalities . . . . . . . . . . . . . 16 73 4.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.7. Mobility Transparency . . . . . . . . . . . . . . . . . . 16 75 4.8. Location Privacy . . . . . . . . . . . . . . . . . . . . . 16 76 4.9. Security Consideration . . . . . . . . . . . . . . . . . . 17 77 4.10. Support of Legacy Nodes . . . . . . . . . . . . . . . . . 17 78 5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 18 79 5.1. Which Entities are Involved? . . . . . . . . . . . . . . . 18 80 5.1.1. Mobile Network Node and Correspondent Node . . . . . . 18 81 5.1.2. Mobile Router and Correspondent Node . . . . . . . . . 19 82 5.1.3. Mobile Router and Correspondent Router . . . . . . . . 19 83 5.1.4. Entities in the Infrastructure . . . . . . . . . . . . 20 84 5.2. Who and When to Initiate Route Optimization? . . . . . . . 20 85 5.3. How to Detect Route Optimization Capability? . . . . . . . 21 86 5.4. How is the Address of Mobile Network Node Represented? . . 22 87 5.5. How is Mobile Network Node's Address Bound to Location? . 22 88 5.5.1. Binding to the Location of Parent Mobile Router . . . 23 89 5.5.2. Binding to a Sequence of Locations of Upstream 90 Mobile Routers . . . . . . . . . . . . . . . . . . . . 25 92 5.5.3. Binding to the Location of Root Mobile Router . . . . 26 93 5.6. How is Signaling Performed? . . . . . . . . . . . . . . . 28 94 5.7. How is Data Transmitted? . . . . . . . . . . . . . . . . . 29 95 5.8. What are the Security Considerations? . . . . . . . . . . 30 96 5.8.1. Security Considerations of Address Binding . . . . . . 30 97 5.8.2. End-to-End Integrity . . . . . . . . . . . . . . . . . 32 98 5.8.3. Location Privacy . . . . . . . . . . . . . . . . . . . 32 99 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 102 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 104 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 105 10.2. Informative References . . . . . . . . . . . . . . . . . . 35 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 108 Intellectual Property and Copyright Statements . . . . . . . . . . 43 110 1. Introduction 112 Network Mobility Route Optimization Problem Statement [1] describes 113 operational limitations and overheads incurred in a deployment of 114 Network Mobility (NEMO) Basic Support [2], which could be alleviated 115 by a set of NEMO Route Optimization techniques to be defined. For 116 this purpose of NEMO, the term "Route Optimization" is accepted in a 117 broader sense than already defined for IPv6 Host Mobility in [3], to 118 loosely refer to any approach that optimizes the transmission of 119 packets between a Mobile Network Node and a Correspondent Node. 121 Solutions that would fit that general description were continuously 122 proposed since the early days of NEMO, even before the Working Group 123 was formed. Based on that long standing stream of innovation, this 124 document classifies, at a generic level, the solution space of the 125 possible approaches that could be taken to solve the Route 126 Optimization related problems for NEMO. The scope of the solutions, 127 the benefits, and the impacts to the existing implementations and 128 deployments are analyzed. This work should serve as a foundation for 129 the NEMO WG to decide where to focus its Route Optimization effort, 130 with a deeper understanding of the relative strength and weaknesses 131 of each approach. 133 It should be beneficial for readers to keep in mind the design 134 requirements of NEMO [4]. A point to note is that since this 135 document discusses aspects of Route Optimization, the reader may 136 assume that a mobile network or a mobile host is away when they are 137 mentioned throughout this document, unless it is explicitly specified 138 that they are at home. 140 1.1. Terminology 142 It is expected for readers to be familiar with terminologies related 143 to mobility in [3] and [5], and NEMO related terms defined in [6]. 144 In addition, the following Route Optimization specific terms are used 145 in this document: 147 Correspondent Router (CR) 149 This refers to the router which is capable of terminating a Route 150 Optimization session on behalf of a Correspondent Node. 152 Correspondent Entity (CE) 154 This refers to the entity which a Mobile Router or Mobile Network 155 Node attempts to establish a Route Optimization session with. 156 Depending on the Route Optimization approach, the Correspondent 157 Entity maybe a Correspondent Node or Correspondent Router. 159 2. Benefits of NEMO Route Optimization 161 NEMO Route Optimization addresses the problems discussed in [1]. 162 Although a standardized NEMO Route Optimization solution has yet to 163 materialize, one can expect it to show some of the following 164 benefits: 166 o Shorter Delay 168 Route Optimization involves the selection and utilization of a 169 lesser cost (thus generally shorter and faster) route to be taken 170 for traffic between a Mobile Network Node and its Correspondent 171 Node. Hence, Route Optimization should improve the latency of the 172 data traffic between the two end nodes. This may possibly in turn 173 lead to better overall Quality of Service characteristics, such as 174 reduced jitter and packet loss. 176 o Reduced Consumption of Overall Network Resources 178 Through the selection of a shorter route, the total link 179 utilization for all links used by traffic between the two end 180 nodes should be much lower than that used if Route Optimization is 181 not carried out. This would result in a lighter network load with 182 reduced congestion. 184 o Reduced Susceptibility to Link Failure 186 If a link along the bi-directional tunnel is disrupted, all 187 traffic to and from the mobile network will be affected until IP 188 routing recovers from the failure. An optimized route would 189 conceivably utilize a smaller number of links between the two end 190 nodes. Hence, the probability of a loss of connectivity due to a 191 single point of failure at a link should be lower as compared to 192 the longer non-optimized route. 194 o Greater Data Efficiency 196 Depending on the actual solution for NEMO Route Optimization, the 197 data packets exchanged between two end nodes may not require as 198 many levels of encapsulation as that in NEMO Basic Support. This 199 would mean less packet overheads, and higher data efficiency. In 200 particular, avoiding packet fragmentation that may be induced by 201 the multiple levels of tunneling is critical for end-to-end 202 efficiency from the viewpoints of buffering and transport 203 protocols. 205 o Reduced Processing Delay 207 In a nested mobile network, the application of Route Optimization 208 may eliminate the need of multiple encapsulations required by NEMO 209 Basic Support, which may result in less processing delay at the 210 points of encapsulation and decapsulation. 212 o Avoiding Bottleneck in the Home Network 214 NEMO Route Optimization allows traffic to by-pass the Home Agents. 215 Apart from having a more direct route, this also avoids routing 216 traffic via the home network, which may be a potential bottleneck 217 otherwise. 219 o Avoid the Security Policy Issue 221 Security policy may forbid a Mobile Router from tunneling traffic 222 of Visiting Mobile Nodes into the home network of the Mobile 223 Router. Route Optimization can be used to avoid this issue by 224 forwarding traffic from Visiting Mobile Nodes directly to their 225 destinations without going through the home network of the Mobile 226 Router. 228 It should however be taken into consideration that a Route 229 Optimization mechanism may not be an appropriate solution since 230 the Mobile Router may still be held responsible for illegal 231 traffic sent from its Mobile Network Nodes even when Route 232 Optimization is used. In addition, there can be a variety of 233 different policies which might conflict with the deployment of 234 Route Optimization for Visiting Mobile Nodes. Being a policy 235 issue, solving this with a protocol at the policy plane might be 236 more appropriate. 238 o Avoid the Instability and Stalemate 240 [1] described a potential stalemate situation when a Home Agent is 241 nested within a Mobile Network. Route Optimization may circumvent 242 such stalemate situations by directly forwarding traffic upstream. 243 However, it should be noted that certain Route Optimization 244 schemes may require signaling packets to be first routed via the 245 Home Agent before an optimized route can be established. In such 246 cases, a Route Optimization solution cannot avoid the stalemate. 248 3. Different Scenarios of NEMO Route Optimization 250 There are multiple proposals for providing various forms of Route 251 Optimization in the NEMO context. In the following sub-sections, we 252 describe the different scenarios which would require a Route 253 Optimization mechanism and list the potential solutions which have 254 been proposed in that area. 256 3.1. Non-Nested NEMO Route Optimization 258 The Non-Nested NEMO Route Optimization involves a Mobile Router 259 sending binding information to a Correspondent Entity. It does not 260 involve nesting of Mobile Routers nor Visiting Mobile Nodes. The 261 Correspondent Entity can be a Correspondent Node or a Correspondent 262 Router. The interesting case is when the Correspondent Entity is a 263 Correspondent Router. With the use of Correspondent Router, Route 264 Optimization session is terminated at the Correspondent Router on 265 behalf of the Correspondent Node. As long as the Correspondent 266 Router is located "closer" to the Correspondent Node than the Home 267 Agent of the Mobile Router, the route between Mobile Network Node and 268 the Correspondent Node can be said to be optimized. For this 269 purpose, Correspondent Routers may be deployed to provide an optimal 270 route as illustrated in Figure 1. 272 ************************** HAofMR 273 * #*# 274 * #*# +---------------------+ 275 CN #*# | LEGEND | 276 o #*# +---------------------+ 277 o ############### #*# | #: Tunnel | 278 CR ooooooooooooooo MR | *: NEMO Basic route | 279 ############### | | o: Optimized route | 280 MNN +---------------------+ 282 Figure 1: MR-CR Optimization 284 This form of optimization can carry traffic in both directions or 285 independently for the 2 directions of traffic: 287 o From MNN to CN 289 The Mobile Router locates the Correspondent Router, establishes a 290 tunnel with that Correspondent Router and sets up a route to the 291 Correspondent Node via the Correspondent Router over the tunnel. 292 Traffic to the Correspondent Node would no longer flow through the 293 Home Agent anymore. 295 o From CN to MNN 297 The Correspondent Router is on the path of the traffic from the 298 Correspondent Node to the Home Agent. In addition, it has an 299 established tunnel with the current care-of address of the Mobile 300 Router and is aware of the mobile network prefix(es) managed by 301 the Mobile Router. The Correspondent Router can thus intercept 302 packets going to the mobile network, and forward them to the 303 Mobile Router over the established tunnel. 305 A straight-forward approach to Route Optimization in NEMO is for the 306 Mobile Router to attempt Route Optimization with a Correspondent 307 Entity. This can be viewed as a logical extension to NEMO Basic 308 Support, where the Mobile Router would send binding updates 309 containing one or more Mobile Network Prefix options to the 310 Correspondent Entity. The Correspondent Entity having received the 311 binding update, can then set up a bi-directional tunnel with the 312 Mobile Router at the current care-of address of the Mobile Router, 313 and inject a route to its routing table so that packets destined for 314 addresses in the mobile network prefix will be routed through the bi- 315 directional tunnel. 317 The definition of Correspondent Router does not limit it to be a 318 fixed router. Here we consider the case where the Correspondent 319 Router is a Mobile Router. Thus Route Optimization is initiated and 320 performed between a Mobile Router and its peer Mobile Router. Such 321 solutions are often posed with a requirement to leave the Mobile 322 Network Nodes untouched, as with the NEMO Basic Support protocol, and 323 therefore Mobile Routers handle the optimization management on behalf 324 of the Mobile Network Nodes. Thus, providing Route Optimization for 325 Visiting Mobile Node is often out of scope for such scenario because 326 such interaction would require extensions to the Mobile IPv6 327 protocol. This scenario is illustrated in Figure 2. 329 HAofCR ********************************** HAofMR 330 #*# #*# 331 #*# #*# +---------------------+ 332 #*# #*# | LEGEND | 333 #*# #*# +---------------------+ 334 #*# ############### #*# | #: Tunnel | 335 CR ooooooooooooooo MR | *: NEMO Basic route | 336 | ############### | | o: Optimized route | 337 MNN2 MNN1 +---------------------+ 339 Figure 2: MR-CR Optimization 341 This form of optimization can carry traffic for both directions 342 identically: 344 o MNN1 to/from MNN2 346 The Mobile Router locates the Correspondent Router, establishes a 347 tunnel with that Correspondent Router and sets up a route to the 348 Mobile Network Node via the Correspondent Router over the tunnel. 349 Traffic to the Mobile Networks Nodes would no longer flow through 350 the Home Agents. 352 Examples of this approach include Optimized Route Cache (ORC) [7][8] 353 and Path Control Header (PCH) [9]. 355 3.2. Nested Mobility Optimization 357 Optimization in Nested Mobility targets scenarios where a nesting of 358 mobility management protocols is created (i.e. Mobile IPv6 enabled 359 host inside a mobile network or multiple Mobile Routers that attach 360 behind one another creating a nested mobile network). Note that 361 because Mobile IPv6 defines its own Route Optimization mechanism in 362 its base protocol suite as a standard, collaboration between this and 363 NEMO protocols brings various complexities. 365 There are two main aspects in providing optimization for Nested 366 Mobility and they are discussed in the following sub-sections. 368 3.2.1. Decreasing the Number of Home Agents on the Path 370 The aim is to remove the sub-optimality of paths caused by multiple 371 tunnels established between multiple Mobile Nodes and their Home 372 Agents. Such a solution will seek to minimize the number of Home 373 Agents along the path, by bypassing some of the Home Agent(s) from 374 the original path. Unlike the scenario where no nesting is formed 375 and only a single Home Agent exists along the path, bypassing one of 376 the many Home Agents can still be effective. 378 Solutions for Nested Mobility scenarios can usually be divided into 379 two cases based on whether the nesting involves Mobile IPv6 hosts or 380 only involves Mobile Routers. Since Mobile IPv6 defines its own 381 Route Optimization mechanism, providing optimal path for such hosts 382 will require interaction with the protocol and may require an 383 altering of the messages exchanged during the Return Routability 384 procedure with the Correspondent Node. 386 Example of this approach include Reverse Routing Header (RRH) [10]. 388 3.2.2. Decreasing the Number of Tunnels 390 The aim is to reduce the amplification effect of nested tunnels due 391 to the nesting of tunnels between the Visiting Mobile Node and its 392 Home Agent within the tunnel between the parent Mobile Router and the 393 parent Mobile Router's Home Agent. Such a solution will seek to 394 minimize the number of tunnels possibly by collapsing the amount of 395 tunnels required through some form of signaling between Mobile Nodes, 396 or between Mobile Nodes and their Home Agents, or by using routing 397 headers to route packets through a discovered path. These limit the 398 consequences of the amplification effect of nested tunnels, and at 399 best, the performance of a nested mobile network will be the same as 400 though there were no nesting at all. 402 Examples of this approach include the Reverse Routing Header (RRH) 403 [10], Access Router Option (ARO) [11], and Nested Path Info (NPI) 404 [12]. 406 3.3. Infrastructure based Optimization 408 An infrastructure based optimization is an approach where 409 optimization is carried out fully in the infrastructure. One example 410 is to make use of Mobility Anchor Points (MAP) such as defined in 411 HMIPv6 [13] to optimize routes between themselves. Another example 412 is to make use of proxy Home Agent such as defined in the global HAHA 413 protocol [14]. A proxy Home Agent acts as a Home Agent for the 414 Mobile Node, and acts as a Mobile Node for the Home Agent, 415 Correspondent Node, Correspondent Router, and other proxies. In 416 particular, the proxy Home Agent terminates the MRHA tunnel and the 417 associated encryption, extracts the packets, and re-encapsulates them 418 to the destination. In this case, proxy Home Agents are distributed 419 in the infrastructure and each Mobile Router binds to the closest 420 proxy. The proxy, in turn, performs a primary binding with a real 421 Home Agent for that Mobile Router. Then, the proxy might establish 422 secondary bindings with other Home Agents or proxies in the 423 infrastructure, in order to improve the end-to-end path. In this 424 case, the proxies discover each other using some form of Next Hop 425 Resolution Protocol, establish a tunnel and exchange the relevant 426 mobile network prefix information in the form of explicit prefix 427 routes. 429 Alternatively, another approach is to use prefix delegation. Here, 430 each Mobile Router in a nested mobile network is delegated a mobile 431 network prefix from the access router using DHCP Prefix Delegation 432 [15]. Each Mobile Router also autoconfigures its care-of address 433 from this delegated prefix. In this way, the care-of addresses of 434 each Mobile Router are all formed from an aggregatable address space 435 starting from the access router. This may be used to eliminate the 436 multiple tunnels caused by nesting of Mobile Nodes. 438 3.4. Intra-NEMO Optimization 440 A Route Optimization solution may seek to improve the communications 441 between two Mobile Network Nodes within a nested mobile network. 442 This would avoid traffic being injected out of the nested mobile 443 network and route them within the nested mobile network. An example 444 will be the optimized route taken between MNN1 and MNN2 of Figure 3 445 below. 447 +--------+ +--------+ +--------+ +--------+ 448 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 449 +------+-+ +---+----+ +---+----+ +-+------+ 450 \ | | / 451 +--------+ +------------------------------+ 452 | MR1_HA |----| Internet |-----CN 453 +--------+ +--------------+---------------+ 454 | 455 +----+----+ 456 | MR1 | 457 +----+----+ 458 | 459 ---+-----------+-----------+--- 460 | | | 461 +---+---+ +---+---+ +---+---+ 462 | MR5 | | MR2 | | MR4 | 463 +---+---+ +---+---+ +---+---+ 464 | | | 465 ---+--- +---+---+ ---+--- 466 MNN2 | MR3 | MNN3 467 +---+---+ 468 | 469 ----+---- 470 MNN1 472 Figure 3: An example of nested Mobile Network 474 One may be able to extend a well-designed NEMO Route Optimization for 475 "Nested Mobility Optimization" (see Section 3.2) to provide for such 476 kind of Intra-NEMO optimization, where, for example in Figure 3, MNN1 477 is treated as a Correspondent Node by MR5/MNN2, and MNN2 is treated 478 as a Correspondent Node by MR3/MNN1. 480 Another possibility is for the "Non-Nested NEMO Route Optimization" 481 technique (see Section 3.1) to be applied here. Using the same 482 example of communication between MNN1 and MNN2, both MR3 and MR2 can 483 treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and 484 MR2 as Correspondent Routers for MNN1. An example of this approach 485 is [16] which has the Mobile Routers announce their Mobile Network 486 Prefixes to other Mobile Routers in the same nested Mobile Network. 488 Yet another approach is to flatten any nested Mobile Network so that 489 all nested Mobile Network Nodes appear to be virtually on the same 490 link. Examples of such approaches include delegating a single prefix 491 to the nested Mobile Network, having Mobile Routers to perform 492 Neighbor Discovery on behalf of their Mobile Network Nodes, and 493 exposing a single prefix over the entire mobile network using a 494 Mobile Ad-Hoc (MANET) protocol. In particular, it might prove useful 495 to develop a new type of MANET, specialized for the NEMO problem, a 496 MANET for NEMO (MANEMO). The MANEMO will optimize the formation of 497 the nested NEMO and maintain inner connectivity, whether a connection 498 to the infrastructure can be established or not. 500 4. Issues of NEMO Route Optimization 502 Although Route Optimization can bring benefits as described in 503 Section 2, the scenarios described in Section 3 do so with some 504 tradeoffs. This section explores some general issues that may impact 505 a NEMO Route Optimization mechanism. 507 4.1. Additional Signaling Overhead 509 The nodes involved in performing Route Optimization would be expected 510 to exchange additional signaling messages in order to establish Route 511 Optimization. The required amount of signaling depends on the 512 solution, but is likely to exceed the amount required in the home 513 binding update procedure defined in NEMO Basic Support. The amount 514 of signaling is likely to increase with the increasing number of 515 Mobile Network Nodes and/or Correspondent Nodes, and may be amplified 516 with nesting of mobile networks. It may scale to unacceptable height 517 especially to the resource-scarce mobile node which typically has 518 limited power, memory and processing capacity. 520 This may lead to an issue that impacts NEMO Route Optimization, known 521 as the phenomenon of "Binding Update Storm", or more generally, 522 "Signaling Storm". This occurs when a change in point of attachment 523 of the mobile network is accompanied with a sudden burst of signaling 524 messages, resulting in temporary congestion, packet delays or even 525 packet loss. This effect will be especially significant for wireless 526 environment where bandwidth is relatively limited. 528 It is possible to moderate the effect of Signaling Storm by 529 incorporating mechanisms such as spreading the transmissions burst of 530 signaling messages over a longer period of time, or aggregating the 531 signaling messages. 533 Even so, the amount of signaling required might be overwhelming, 534 since a large mobile network (such as those deployed on a train or 535 plane) may potentially have a large number of flows with a large 536 number of Correspondent Nodes. This might suggest a need to have 537 some adaptive behavior that depends on the amount of signaling 538 required versus the effort needed to tunnel home. 540 4.2. Increased Protocol Complexity and Processing Load 542 It is expected for NEMO Route Optimization to be more complicated 543 than NEMO Basic Support. Thus, complexity of nodes that are required 544 to incorporate new functionalities to support NEMO Route Optimization 545 would be higher than those required to provide NEMO Basic Support. 547 Coupled with the increased complexity, nodes that are involved in the 548 establishment and maintenance of Route Optimization will have to bear 549 the increased processing load. If such nodes are mobile, this may 550 prove to be a significant cost due to the limited power and 551 processing resources such devices usually have. 553 4.3. Increased Delay during Handoff 555 Due to the diversity of locations of different nodes that Mobile 556 Network Node may signal with and the complexity of NEMO Route 557 Optimization procedure that may cause several rounds of signaling 558 messages, a NEMO Route Optimization procedure may take a longer time 559 to finish its handoff than that in NEMO Basic Support. This may 560 exacerbate the overall delay during handoffs and further cause 561 performance degradation of the applications running on Mobile Network 562 Nodes. 564 Another NEMO specific delay during handoff is that in a nested mobile 565 network, a child Mobile Network Node may need to detect or be 566 notified of the handoff of its parent Mobile Router so that it can 567 begin signaling its own Correspondent Entities. Apart from the 568 compromise of mobility transparency and location privacy (see 569 Section 4.7 and Section 4.8), this mechanism also increases the delay 570 during handoffs. 572 Some of the solutions for Mobile IPv6, such as Fast Handoff for 573 Mobile IPv6 [17], may be able to alleviate the increase in handoff 574 delay. 576 4.4. Extending Nodes with New Functionalities 578 In order to support NEMO Route Optimization, some nodes need to be 579 changed or upgraded. Smaller number of nodes required to be changed 580 will allow for easier adoption of NEMO Route Optimization solution in 581 the Internet and create less impact on existing Internet 582 infrastructure. The number and the types of nodes involved with new 583 functionalities also affect how much of the route is optimized. In 584 addition, it may also be beneficial to reuse existing protocols (such 585 as Mobile IPv6) as much as possible. 587 Possible nodes that may be required to change include: 589 o Local Fixed Nodes 591 It may prove to be difficult to introduce new functionalities at 592 Local Fixed Nodes, since by definition, any IPv6 node can be a 593 Local Fixed Node. This might mean that only those Local Fixed 594 Nodes that are modified can enjoy the benefits of Route 595 Optimization. 597 o Visiting Mobile Nodes 599 Visiting Mobile Nodes in general should already implement Mobile 600 IPv6 functionalities, and since Mobile IPv6 is a relatively new 601 standard, there is still a considerable window to allow mobile 602 devices to implement new functionalities. 604 o Mobile Routers 606 It is expected for Mobile Routers to implement new functionalities 607 in order to support route optimization. 609 o Access Routers 611 Some approaches require access routers, or nodes in the access 612 network, to implement some new functionalities. It may prove to 613 be difficult to do so, since access routers, are in general, 614 standard IPv6 routers. 616 o Home Agents 618 It is relatively easier for new functionalities to be implemented 619 in Home Agents. 621 o Correspondent Nodes 623 It may prove to be difficult to introduce new functionalities at 624 Correspondent Nodes, since by definition, any IPv6 node can be a 625 Correspondent Node. This might mean that only those Correspondent 626 Nodes that are modified can enjoy the benefits of Route 627 Optimization. 629 o Correspondent Routers 631 Correspondent Routers are new entities introduced for the purpose 632 of Route Optimization, and therefore new functionalities can be 633 defined as needed. 635 4.5. Detection of New Functionalities 637 One issue that is related to the need for new functionalities as 638 described in Section 4.4 is the need to detect the existence of such 639 functionalities. In these cases, a detection mechanism might be 640 helpful to allow the initiator of Route Optimization to detect if 641 support of the new functionalities are available. Furthermore, it 642 might be advantageous to have a graceful fall back procedure if the 643 required functionalities are unavailable. 645 4.6. Scalability 647 Given the same number of nodes, the number of route optimization 648 sessions would usually be more than the number of NEMO Basic Support 649 tunnels. If all route optimization sessions of a mobile network are 650 maintained by a single node (such as the Mobile Router), this would 651 means that the single node has to keep track of the states of all 652 route optimization sessions. This may leads to scalability issues 653 especially when that single node is a mobile device with limited 654 memory and processing resources. 656 A similar scalability issue may be faced by Correspondent Entity as 657 well if it maintains many route optimized sessions on behalf of 658 Correspondent Node(s) with a large number of Mobile Routers. 660 4.7. Mobility Transparency 662 One advantage of NEMO Basic Support is that the Mobile Network Nodes 663 need not be aware of the actual location and mobility of the mobile 664 network. With some approaches for Route Optimization, it might be 665 necessary to reveal the point of attachment of the Mobile Router to 666 the Mobile Network Nodes. This may mean a tradeoff between mobility 667 transparency and Route Optimization. 669 4.8. Location Privacy 671 Without Route Optimization, the Correspondent Nodes are not aware of 672 the actual location and mobility of the mobile network and its Mobile 673 Network Nodes. To achieve Route Optimization, it might be necessary 674 to reveal the point of attachment of the Mobile Router to the 675 Correspondent Nodes. This may mean a tradeoff between location 676 privacy [18] and Route Optimization. 678 In Mobile IPv6, a mobile node can decide whether or not to perform 679 Route Optimization with a given Correspondent Node. Thus, the mobile 680 node is in control of whether to trade location privacy for an 681 optimized route. In NEMO Route Optimization, if the decision to 682 perform Router Optimization is made by the Mobile Router, it will be 683 difficult for Mobile Network Nodes to control the decision of having 684 this tradeoff. 686 4.9. Security Consideration 688 As Mobile Router and Home Agent usually belong to the same 689 administration domain, it is likely that there exists a security 690 association between them, which is leveraged by NEMO Basic Support to 691 conduct the home binding update in a secure way. However, NEMO Route 692 Optimization usually involves nodes from different domains (for 693 example, Mobile Router and Correspondent Entity), thus the existence 694 of such a security association is not a valid assumption in many 695 deployment scenarios. Thus the security protection of NEMO Route 696 Optimization signaling message is considered as "weaker" than that in 697 NEMO Basic Support. It is expected that some additional security 698 mechanisms are needed to achieve the same or similar level of 699 security as in NEMO Basic Support. 701 When considering security issues of NEMO Route Optimization, it might 702 be useful to keep in mind some of the security issues considered when 703 Mobile IPv6 Route Optimization was designed as documented in [19]. 705 4.10. Support of Legacy Nodes 707 NEMO Basic Support is designed so that all legacy Mobile Network 708 Nodes (such as those who are not aware of the mobility of the network 709 they are in, and those that do not understand any mobility protocols) 710 can still reach and be reached from the Internet. Some Route 711 Optimization schemes, however, require that all Mobile Routers to 712 implement the same Route Optimization scheme in order for them to 713 operate. Thus, a nested Mobile Router may not be able to achieve 714 Route Optimization if it is attached to a legacy Local Fixed Router. 716 5. Analysis of Solution Space 718 As described in Section 3, there are various different approaches to 719 achieve Route Optimization in Network Mobility Support. In this 720 section, we attempt to analyze the vast solution space of NEMO Route 721 optimization by asking the following questions: 723 1. Which entities are involved? 725 2. Who and when to initiate signaling? 727 3. How to detect Route Optimization capabilities? 729 4. How is the address of Mobile Network Node represented? 731 5. How is the address of Mobile Network Node bound to location of 732 mobile network? 734 6. How is signaling performed? 736 7. How is data transmitted? 738 8. What are the security considerations? 740 5.1. Which Entities are Involved? 742 There are many combinations of entities involved in Route 743 Optimization. When considering the role each entity plays in Route 744 Optimization, one has to bear in mind the considerations described in 745 Section 4.4 and Section 4.5. Below is a list of combinations to be 746 discussed in the following subsections: 748 o Mobile Network Node and Correspondent Node 750 o Mobile Router and Correspondent Node 752 o Mobile Router and Correspondent Router 754 o Entities in the Infrastructure 756 5.1.1. Mobile Network Node and Correspondent Node 758 A Mobile Network Node can establish Route Optimization with its 759 Correspondent Node, possibly the same way as a Mobile Node 760 establishes Route Optimization with its Correspondent Node in Mobile 761 IPv6. This would achieve the most optimal route, since the entire 762 end-to-end path is optimized. However, there might be scalability 763 issues since both the Mobile Network Node and the Correspondent Node 764 may need to maintain many Route Optimization sessions. In addition, 765 new functionalities would be required for both the Mobile Network 766 Node and Correspondent Node. For the Mobile Network Node, it needs 767 to be able to manage its mobility, and possibly be aware of the 768 mobility of its upstream Mobile Router(s). For the Correspondent 769 Node, it needs to be able to maintain the bindings sent by the Mobile 770 Network Nodes. 772 5.1.2. Mobile Router and Correspondent Node 774 Alternatively, the Mobile Router can establish Route Optimization 775 with a Correspondent Node on behalf of the Mobile Network Node. 776 Since all packets to and from the Mobile Network Node must transit 777 the Mobile Router, this effectively achieves an optimal route for the 778 entire end-to-end path as well. Compared with Section 5.1.1, the 779 scalability issue here may be remedied since it is possible for 780 Correspondent Node to maintain only one session with the Mobile 781 Router if it communicates with many Mobile Network Nodes associated 782 with the same Mobile Router. Furthermore, with the Mobile Router 783 handling Route Optimization, there is no need for Mobile Network 784 Nodes to implement new functionalities. However, new functionality 785 is likely to be required on the Correspondent Node. An additional 786 point of consideration is the amount of state information the Mobile 787 Router is required to maintain. Traditionally, it has been generally 788 avoided to have state information in the routers to increase 789 proportionally with the number of pairs of communicating peers. 791 5.1.3. Mobile Router and Correspondent Router 793 Approaches involving Mobile Routers and Correspondent Routers are 794 described in Section 3.1. The advantage of this approach is that no 795 additional functionality is required for the Correspondent Node and 796 Mobile Network Nodes. In addition, location privacy is relatively 797 preserved, since the current location of the mobile network is only 798 revealed to the Correspondent Router and not to the Correspondent 799 Node (please refer to Section 5.8.3 for more discussions). 800 Furthermore, if the Mobile Router and Correspondent Router exchange 801 prefix information, this approach may scale well since a single Route 802 Optimization session between the Mobile Router and Correspondent 803 Router can achieve Route Optimization between any Mobile Network Node 804 in the mobile network, and any Correspondent Node managed by the 805 Correspondent Router. 807 The main concern with this approach is the need for a mechanism to 808 allow the Mobile Router to detect the presence of the Correspondent 809 Router (see Section 5.3 for details), and its security impact. Both 810 the Mobile Router and the Correspondent Router need some means to 811 verify the validity of each other. This is discussed in greater 812 detail in Section 5.8. 814 A deployment consideration with respect to the use of Correspondent 815 Router is the location of the Correspondent Router relative to the 816 Correspondent Node. On one hand, deploying the Correspondent Router 817 nearer to the Correspondent Node would result in a more optimal path. 818 On the other hand, a Correspondent Router that is placed further away 819 from the Correspondent Node can perform Route Optimization on behalf 820 of more Correspondent Nodes. 822 5.1.4. Entities in the Infrastructure 824 Approaches using entities in the infrastructure are described in 825 Section 3.3. The advantages of this approach include firstly not 826 requiring new functionalities to be implemented on the Mobile Network 827 Nodes and Correspondent Nodes, and secondly having most of the 828 complexity shifted to nodes in the infrastructure. However, one main 829 issue with this approach is how the Mobile Router can detect the 830 presence of such entities, and why the Mobile Router should trust 831 these entities. This may be easily addressed if such entity is a 832 Home Agent of the Mobile Router (such as in global HAHA [14]). 833 Another concern is that the resulting path may not be a true 834 optimized one, since it depends on the relative positions of the 835 infrastructure entities with respect to the mobile network and the 836 Correspondent Node. 838 5.2. Who and When to Initiate Route Optimization? 840 Having determined the entities involved in the Route Optimization in 841 the previous sub-section, the next question is which of these 842 entities should initiate the Route Optimization session. Usually, 843 the node that is moving (i.e. Mobile Network Node or Mobile Router) 844 is in the best position to detect its mobility. Thus, in general, it 845 is better for the mobile node to initiate the Route Optimization 846 session in order to handle the topology changes in any kind of 847 mobility pattern and achieve the optimized route promptly. However, 848 when the mobile node is within a nested mobile network, the detection 849 of the mobility of upstream Mobile Routers may need to be conveyed to 850 the nested Mobile Network Node. This might incur longer signaling 851 delay as discussed in Section 4.3. 853 Some solution may enable the node on the correspondent side to 854 initiate Route Optimization session in certain situations. For 855 instance, when the Route Optimization state that is already 856 established on the Correspondent Entity is about to expire but the 857 communication is still active, depending on the policy, the 858 Correspondent Entity may initiate a Route Optimization request with 859 the mobile node side. 861 There is also the question of when Route Optimization should be 862 initiated. Because route optimization would certainly incur 863 tradeoffs of various forms, it might not be desirable for Route 864 Optimization to be performed for any kind of traffic. This is, 865 however, implementation specific and policy driven. 867 A related question is how often signaling messages should be sent to 868 maintain the Route Optimization session. Typically, signaling 869 messages is likely to be sent whenever there is topological changes. 870 The discussion in Section 4.1 should be considered. In addition, a 871 Lifetime value is often used to indicate the period of validity for 872 the Route Optimization session. Signaling messages would have to be 873 sent before the Lifetime value expires in order to maintain the Route 874 Optimization session. The choice of Lifetime value needs to balance 875 between different considerations. On one hand, a short Lifetime 876 value would increase the amount of signaling overhead. On the other 877 hand, a long Lifetime value may expose the Correspondent Entity to 878 the risk of having an obsolete binding cache entry, which creates an 879 opportunity for an attacker to exploit. 881 5.3. How to Detect Route Optimization Capability? 883 The question here is how the initiator of Route Optimization knows if 884 the Correspondent Entity supports the functionality required to 885 established a Route Optimization session. The usual method is for 886 the initiator to attempt Route Optimization with the Correspondent 887 Entity. Depending on the protocol specifics, the initiator may 888 receive (i) a reply from the Correspondent Entity indicating its 889 capability, (ii) an error message from the Correspondent Entity, or 890 (iii) no response from the Correspondent Entity within a certain time 891 period. This serves as an indication of whether the Correspondent 892 Entity supports the required functionality to establish Route 893 Optimization or not. This form of detection may incur additional 894 delay as a penalty when the Correspondent Entity does not have Route 895 Optimization capability, especially when the Route Optimization 896 mechanism is using in-band-signaling. 898 When the Correspondent Entity is not the Correspondent Node but a 899 Correspondent Router, an immediate question is how its presence can 900 be detected. One approach is for the initiator to send an Internet 901 Control Message Protocol (ICMP) message containing the address of the 902 Correspondent Node to a well-known anycast address reserved for all 903 Correspondent Routers [7][8]. Only the Correspondent Router that is 904 capable of terminating Route Optimization session on behalf of the 905 Correspondent Node will respond. Another way is to insert a Router 906 Alert Option (RAO) to a packet sent to the Correspondent Node [9]. 907 Any Correspondent Router en route will process the Router Alert 908 Option, and send a response to the Mobile Router. 910 Both approaches need to consider the possibility of multiple 911 Correspondent Routers responding to the initiator, and both 912 approaches will generate additional traffic or processing load to 913 other routers. Furthermore, both approaches have yet to consider how 914 the initiator can verify the authenticity of the Correspondent 915 Routers that responded. 917 5.4. How is the Address of Mobile Network Node Represented? 919 Normally, Route Optimization would mean that a binding between the 920 address of a Mobile Network Node and the location of the mobile 921 network is registered at the Correspondent Entity. Before exploring 922 into different ways of binding (see Section 5.5), one must first ask 923 how the address of the Mobile Network Node is represented. 924 Basically, there are two ways to represent the Mobile Network Node's 925 address: 927 o inferred by the use of the Mobile Network Prefix, or 929 o explicitly specifying the address of the Mobile Network Node. 931 Using the Mobile Network Prefix would usually mean that the initiator 932 is the Mobile Router, and has the benefit of binding numerous Mobile 933 Network Nodes with one signaling. However, it also means that if 934 location privacy is compromised, the location privacy of an entire 935 Mobile Network Prefix would be compromised. 937 On the other hand, using the Mobile Network Node's address would mean 938 that the initiator is either the Mobile Network Node itself, or the 939 Mobile Router is initiating Route Optimization on behalf of the 940 Mobile Network Node. Initiation by the Mobile Network Node itself 941 means that the Mobile Network Node must have new functionalities 942 implemented, while initiation by the Mobile Router means that the 943 Mobile Router must maintain some Route Optimization states for each 944 Mobile Network Node. 946 5.5. How is Mobile Network Node's Address Bound to Location? 948 In order for route to be optimized, it is generally necessary for the 949 Correspondent Entity to create a binding between the address and the 950 location of the Mobile Network Node. This can be done in the 951 following ways: 953 o binding the address to the location of the parent Mobile Router; 955 o binding the address to a sequence of locations of upstream Mobile 956 Routers; and 958 o binding the address to the location of the root Mobile Router 960 These are described in the following sub-sections. 962 5.5.1. Binding to the Location of Parent Mobile Router 964 By binding the address of Mobile Network Node to the location of its 965 parent Mobile Router, the Correspondent Entity would know how to 966 reach the Mobile Network Node via the current location of the parent 967 Mobile Router. This can be done by: 969 o Binding Update with Mobile Network Prefix 971 This can be viewed as a logical extension to NEMO Basic Support, 972 where the Mobile Router would send binding updates containing one 973 or more Mobile Network Prefix options to the Correspondent Entity. 974 The Correspondent Entity having received the Binding Update, can 975 then set up a bi-directional tunnel with the Mobile Router at the 976 current care-of address of the Mobile Router, and inject a route 977 to its routing table so that packets destined for addresses in the 978 mobile network prefix would be routed through the bi-directional 979 tunnel. 981 Note that in this case, the address of the Mobile Network Node is 982 implied by the Mobile Network Prefix (see Section 5.4). 984 o Sending Information of Parent Mobile Router 986 This involves the Mobile Network Node sending the information of 987 its Mobile Router to the Correspondent Entity, thus allowing the 988 Correspondent Entity to establish a binding between the address of 989 the Mobile Network Node to the location of the parent Mobile 990 Router. An example of such an approach would be [11]. 992 o Mobile Router as a Proxy 994 Another approach is for the parent Mobile Router to act as a 995 "proxy" for its Mobile Network Nodes. In this case, the Mobile 996 Router uses standard Mobile IPv6 Route Optimization procedure to 997 bind the address of a Mobile Network Node to the Mobile Router's 998 care-of address. For instance, when the Mobile Network Node is a 999 Local Fixed Node without Mobile IPv6 Route Optimization 1000 functionality, the Mobile Router may initiate the Return 1001 Routability procedure with a Correspondent Node on behalf of the 1002 Local Fixed Node. An example of such an approach would be 1003 [20][21]. 1005 On the other hand, if the Mobile Network Node is a Visiting Mobile 1006 Node, it might be necessary for the Visiting Mobile Node to 1007 delegate the rights of Route Optimization signaling to the Mobile 1008 Router (see [22] for an example of such delegation). With this 1009 delegation, either the Visiting Mobile Network Node or the Mobile 1010 Router can initiate the Return Routability procedure with the 1011 Correspondent Node. For the case where the Return Routability 1012 procedure is initiated by the Visiting Mobile Node, the Mobile 1013 Router will have to transparently alters content of the Return 1014 Routability signaling messages so that packets sent from the 1015 Correspondent Node to the Visiting Node will be routed to the 1016 care-of address of the Mobile Router once Route Optimization is 1017 established. The case where the Return Routability procedure is 1018 initiated by the Mobile Router is similar to the case where the 1019 Mobile Network Node is a Local Fixed Node. 1021 For all of the approaches listed above, when the Mobile Network Node 1022 is deeply nested within a Mobile Network, the Correspondent Entity 1023 would need to gather Binding Updates from all the upstream Mobile 1024 Routers in order to build the complete route to reach the Mobile 1025 Network Node. This increases the complexity of the Correspondent 1026 Entity, as the Correspondent Entity may need to perform multiple 1027 binding cache look-ups before it can construct the complete route. 1029 Other than increasing the complexity of the Correspondent Entity, 1030 these approaches may incur extra signaling overhead and delay for a 1031 nested Mobile Network Node. For instance, every Mobile Router on the 1032 upstream of the Mobile Network Node needs to send Binding Updates to 1033 the Correspondent Entity. If this is done by the upstream Mobile 1034 Routers independently, it may incur additional signaling overhead. 1035 Also, since each Binding Update takes a finite amount of time to 1036 reach and be processed by the Correspondent Entity, the delay from 1037 the time an optimized route is changed till the time the change is 1038 registered on the Correspondent Entity will increase proportionally 1039 with the number of Mobile Routers on the upstream of the Mobile 1040 Network Node (i.e. the level of nesting of the Mobile Network Node). 1042 For "Binding Update with Mobile Network Prefix" and "Sending 1043 Information of Upstream Mobile Router", new functionality is required 1044 at the Correspondent Entity, whereas "Mobile Router as a Proxy" keeps 1045 the functionality of the Correspondent Entity to be the same as a 1046 Mobile IPv6 Correspondent Node. However, this is done at an expense 1047 of the Mobile Routers, since in "Mobile Router as a Proxy", the 1048 Mobile Router must maintain state information for every Route 1049 Optimization session its Mobile Network Nodes have. Furthermore, in 1050 some cases, the Mobile Router needs to look beyond the standard IPv6 1051 headers for ingress and egress packets, and alter the packet contents 1052 appropriately. 1054 One advantage shared by all the approaches listed here is that only 1055 mobility protocol is affected. In other words, no modification is 1056 required on other existing protocols (such as Neighbor Discovery). 1057 There is also no additional requirements on existing infrastructure 1058 (such as the access network). 1060 In addition, having upstream Mobile Routers send Binding Updates 1061 independently means that the Correspondent Entity can use the same 1062 binding cache entries of upstream Mobile Routers to construct the 1063 complete route to two Mobile Network Nodes that have common upstream 1064 Mobile Routers. This may translate to lower memory consumption since 1065 the Correspondent Entity need not store one complete route per Mobile 1066 Network Node when it is having Route Optimizations sessions with 1067 multiple Mobile Network Nodes from the same mobile network. 1069 5.5.2. Binding to a Sequence of Locations of Upstream Mobile Routers 1071 For a nested Mobile Network Node, it might be more worthwhile to bind 1072 its address to the sequence of points of attachment of upstream 1073 Mobile Routers. In this way, the Correspondent Entity can build a 1074 complete sequence of points of attachment from a single transmission 1075 of the binding information. Examples using this approach are [10] 1076 and [12]. 1078 Different from Section 5.5.1, this approach constructs the complete 1079 route to a specific Mobile Network Node at the mobile network side, 1080 thus offering the opportunity to reduce the signaling overhead. 1081 Since the complete route is conveyed to the Correspondent Entity in a 1082 single transmission, it is possible to reduce the delay from the time 1083 an optimized route is changed till the time the change is registered 1084 on the Correspondent Entity to its minimum. 1086 One question that immediately comes to mind is how the Mobile Network 1087 Node gets hold of the sequence of locations of its upstream Mobile 1088 Routers. This is usually achieved by having such information 1089 inserted as special options in the Router Advertisement messages 1090 advertised by upstream Mobile Routers. To do so, not only must a 1091 Mobile Router advertise its current location to its Mobile Network 1092 Nodes, it must also relay information embedded in Router 1093 Advertisement messages it has received from its upstream Mobile 1094 Routers. This might imply a compromise of the mobility transparency 1095 of a mobile network (see Section 4.7). In addition, it also means 1096 that whenever an upstream Mobile Router changes its point of 1097 attachment, all downstream Mobile Network Nodes must perform Route 1098 Optimization signaling again, possibly leading to a "signaling storm" 1099 (see Section 4.1). 1101 A different method of conveying locations of upstream Mobile Routers 1102 is used in [10] where upstream Mobile Routers insert their current 1103 point of attachment into a Reverse Routing Header embedded within a 1104 packet sent by the Mobile Network Node. This may raise security 1105 concerns that will be discussed later in Section 5.8.2. 1107 In order for a Correspondent Entity to bind the address of a Mobile 1108 Network Node to a sequence of locations of upstream Mobile Routers, 1109 new functionalities need to be implemented on the Correspondent 1110 Entity. The Correspondent Entity also needs to store the complete 1111 sequence of locations of upstream Mobile Routers for every Mobile 1112 Network Node. This may demand more memory compared to Section 5.5.1 1113 if the same Correspondent Entity has a lot of Route Optimization 1114 sessions with Mobile Network Nodes from the same nested Mobile 1115 Network. In addition, some amount of modifications or extension to 1116 existing protocols is also required, such as a new type of IPv6 1117 routing header, or a new option in Router Advertisement message. 1119 5.5.3. Binding to the Location of Root Mobile Router 1121 A third approach is to bind the address of the Mobile Network Node to 1122 the location of the root Mobile Router, regardless of how deeply 1123 nested the Mobile Network Node is within a nested Mobile Network. 1124 Whenever the Correspondent Entity needs to forward packet to the 1125 Mobile Network Node, it only needs to forward the packet to this 1126 point of attachment. The mobile network will figure out how to 1127 forward the packet to the Mobile Network Node by itself. This kind 1128 of approach can be viewed as flattening the structure of a nested 1129 Mobile Network, so that it seems to the Correspondent Entity that 1130 every node in the Mobile Network is attached to the Internet at the 1131 same network segment. 1133 There are various approaches to achieve this: 1135 o Prefix Delegation 1137 Here, each Mobile Router in a nested mobile network is delegated a 1138 Mobile Network Prefix from the access router (such as using DHCP 1139 Prefix Delegation [15]). Each Mobile Router also autoconfigures 1140 its care-of address from this delegated prefix. In this way, the 1141 care-of addresses of Mobile Routers are all from an aggregatable 1142 address space starting from the access router. Mobile Network 1143 Nodes with Mobile IPv6 functionality may also autoconfigure its 1144 care-of address from this delegated prefix, and use standard 1145 Mobile IPv6 mechanism to bind its home address to this care-of 1146 address. 1148 Examples of this approach includes [23] and [24][25]. 1150 This approach has the advantage of keeping the implementations of 1151 Correspondent Nodes unchanged. However, it requires the access 1152 router (or some other entity within the access network) and Mobile 1153 Router to possess prefix delegation functionality, and also 1154 maintain information on what prefix is delegated to which node. 1155 How to efficiently assign a subset of Mobile Network Prefix to 1156 child Mobile Routers could be an issue because Mobile Network 1157 Nodes may dynamically join and leave with an unpredictable 1158 pattern. In addition, a change in the point of attachment of the 1159 root Mobile Router will also require every nested Mobile Router 1160 (and possibly Visiting Mobile Nodes) to change their care-of 1161 addresses and delegated prefixes. These will cause a burst of 1162 Binding Updates and prefix delegation activities where every 1163 Mobile Router and every Visiting Mobile Node start sending Binding 1164 Updates to their Correspondent Entities. 1166 o Neighbor Discovery Proxy 1168 This approach (such as [26][27]) achieves Route Optimization by 1169 having Mobile Router to act as a Neighbor Discovery [28] proxy for 1170 its Mobile Network Nodes. The Mobile Router will configure a 1171 care-of address from the network prefix advertised by its access 1172 router, and also relay this prefix to its subnets. When a Mobile 1173 Network Node configures an address from this prefix, the Mobile 1174 Router will act as a Neighbor Discovery proxy on its behalf. In 1175 this way, the entire mobile network and its access network form a 1176 logical multilink subnet, thus eliminating any nesting. 1178 This approach has the advantage of keeping the implementations of 1179 Correspondent Nodes unchanged. However, it requires the root 1180 Mobile Router to act as a Neighbor Discovery proxy for all the 1181 Mobile Network Nodes that are directly or indirectly attached to 1182 it. This increases the processing load of the root Mobile Router. 1183 In addition, a change in the point of attachment of the root 1184 Mobile Router will require every nested Mobile Router (and 1185 possibly Visiting Mobile Nodes) to change their care-of addresses. 1186 Not only will this cause a burst of Binding Updates where every 1187 Mobile Router and every Visiting Mobile Node start sending Binding 1188 Updates to their Correspondent Entities, it will also cause a 1189 burst of Duplicate Address Discovery messages to be exchanged 1190 between the mobile network and the access network. Furthermore, 1191 route optimization for Local Fixed Nodes is not possible without 1192 new functionalities implemented on the Local Fixed Nodes. 1194 o Hierarchical Registrations 1196 Hierarchical Registration involves Mobile Network Nodes (including 1197 nested Mobile Routers) to register themselves with either their 1198 parent Mobile Routers, or the root Mobile Router itself. After 1199 registrations, Mobile Network Nodes would tunnel packets directly 1200 to the upstream Mobile Router they register with. At the root 1201 Mobile Router, packets tunneled from sub-Mobile Routers or Mobile 1202 Network Nodes are tunneled directly to the Correspondent Entities, 1203 thus avoiding nested tunneling. 1205 One form of such approach uses the principle of Hierarchical 1206 Mobile IPv6 [13], where the root Mobile Router acts as a Mobility 1207 Anchor Point. It is also possible for each parent Mobile Router 1208 to act as Mobility Anchor Points for their child Mobile Routers, 1209 thus forming a hierarchy of Mobility Anchor Points. One can also 1210 view these Mobility Anchor Points as local Home Agents, thus 1211 forming a cascade of mobile Home Agents. In this way, each Mobile 1212 Router terminates its tunnel at its parent Mobile Router. Hence, 1213 although there are equal number of tunnels as the level of 1214 nestings, there is no tunnel encapsulated within another. 1216 Examples of this approach includes [29], [30] and [31][32]. 1218 An advantage of this approach is that the functionalities of the 1219 Correspondent Nodes are unchanged. 1221 o Mobile Ad-Hoc Routing 1223 It is possible for nodes within a mobile network to use Mobile Ad- 1224 hoc routing for packet-forwarding between nodes in the same mobile 1225 network. An approach of doing so might involve a router acting as 1226 a gateway for connecting nodes in the mobile network to the global 1227 Internet. All nodes in the mobile network would configure their 1228 care-of addresses from one or more prefixes advertised by that 1229 gateway, while their parent Mobile Routers use Mobile Ad-hoc 1230 routing to forward packets to that gateway or other destinations 1231 inside the mobile network. 1233 One advantage that is common to all the approaches listed above is 1234 that local mobility of a Mobile Network Node within a nested Mobile 1235 Network is hidden from the Correspondent Entity. 1237 5.6. How is Signaling Performed? 1239 In general, Route Optimization signaling can be done either in-plane, 1240 off-plane, or both. In-plane signaling involves embedding signaling 1241 information into headers of data packets. A good example of in-plane 1242 signaling would be Reverse Routing Header [10]. Off-plane signaling 1243 uses dedicated signaling packets rather than embedding signaling 1244 information into headers of data packets. Proposals involving the 1245 sending of Binding Updates fall into this category. 1247 The advantage of in-plane signaling is that any change in the mobile 1248 network topology can be rapidly propagated to the Correspondent 1249 Entity as long as there is a continuous stream of data to be 1250 transmitted. However, this might incur a substantial overhead on the 1251 data packets. Off-plane signaling, on the other hand, sends 1252 signaling messages independently from the data packet. This has the 1253 advantage of reducing the signaling overhead in situations where 1254 there are relatively less topological changes to the mobile network. 1255 However, data packets transmission may be disrupted while off-plane 1256 signaling takes place. 1258 An entirely different method of signaling makes use of upper layer 1259 protocols to establish the bindings between the address of a Mobile 1260 Network Node and the location of the mobile network. Such binding 1261 information can then be passed down to the IP layer to insert the 1262 appropriate entry in the Binding Cache or routing table. An example 1263 of such mechanism is [33] which uses the Session Initiation Protocol 1264 (SIP) to relay binding information. 1266 5.7. How is Data Transmitted? 1268 With Route Optimization established, one remaining question to be 1269 answered is how data packets can be routed to follow the optimized 1270 route. There are the following possible approaches: 1272 o Encapsulations 1274 One way to route packets through the optimized path is to use IP- 1275 in-IP encapsulations [34]. In this way, the original packet can 1276 be tunneled to the location bound to the address of the Mobile 1277 Network Node using the normal routing infrastructure. Depending 1278 on how the location is bound to the address of Mobile Network 1279 Node, the number of encapsulations required might vary. 1281 For instance, if the Correspondent Entity knows the full sequence 1282 of points of attachment, it might be necessary for there to be 1283 multiple encapsulations in order to forward the data packet 1284 through each point of attachment. This may lead to the need for 1285 multiple tunnels and extra packet header overhead. It is possible 1286 to alleviate this by using Robust Header Compression techniques 1287 [35][36] [37] to compress the multiple tunnel packet headers. 1289 o Routing Headers 1291 A second way to route packets through the optimized path is to use 1292 routing headers. This is useful especially for the case where the 1293 Correspondent Entity knows the sequence of locations of upstream 1294 Mobile Routers, (see Section 5.5.2), since a routing header can 1295 contain multiple intermediate destinations. Each intermediate 1296 destination corresponds to a point of attachment bound to the 1297 address of the Mobile Network Node. 1299 This requires the use of a new Routing Header type, or possibly an 1300 extension of the Type 2 Routing Header as defined by Mobile IPv6 1301 to contain multiple addresses instead of only one. 1303 o Routing Entries in Parent Mobile Routers 1305 Yet another way is for parent Mobile Routers to install routing 1306 entries in their routing table that will route Route Optimized 1307 packets differently, most likely based on source address routing. 1308 This usually applies to approaches described in Section 5.5.3. 1309 For instance, the Prefix Delegation approach [23][24][25] would 1310 require parent Mobile Routers to route packets differently if the 1311 source address belongs to the prefix delegated from the access 1312 network. 1314 5.8. What are the Security Considerations? 1316 5.8.1. Security Considerations of Address Binding 1318 The most important security consideration in Route Optimization is 1319 certainly the security risks a Correspondent Entity is exposed to by 1320 creating a binding between the address of a Mobile Network Node and 1321 the specified location(s) of the Mobile Network. Generally, it is 1322 assumed that Correspondent Entity and Mobile Network Node do not 1323 share any pre-existing security association. However, the 1324 Correspondent Entity must have some ways of verifying the 1325 authenticity of the binding specified, else it will be susceptible to 1326 various attacks described in [19], such as snooping (sending packets 1327 meant for a Mobile Network Node to an attacker) or denial-of-service 1328 (flooding a victim with packets meant for a Mobile Network Node) 1329 attacks. 1331 When the binding is performed between the address of the Mobile 1332 Network Node and one care-of address (possibly of the Mobile Router, 1333 see Section 5.5.1 and Section 5.5.3), the standard Return Routability 1334 procedure specified in Mobile IPv6 might be sufficient to provide a 1335 reasonable degree of assurance to the Correspondent Entity. This 1336 also allows the Correspondent Entity to re-use existing 1337 implementations. But in other situations, an extension to the Return 1338 Routability procedure might be necessary. 1340 For instance, consider the case where the Mobile Router sends Binding 1341 Update containing Mobile Network Prefix information to Correspondent 1342 Entity (see Section 5.5.1). Although the Return Routability 1343 procedure allows the Correspondent Entity to verify that the care-of 1344 and home addresses of the Mobile Router are indeed collocated, it 1345 does not allow the Correspondent Entity to verify the validity of the 1346 Mobile Network Prefix. If the Correspondent Entity accepts the 1347 binding without verification, it will be exposed to attacks where the 1348 attacker tricks the Correspondent Entity into forwarding packets 1349 destined for a mobile network to the attacker (snooping) or victim 1350 (DoS). [38] discusses this security threat further. 1352 The need to verify the validity of network prefixes is not 1353 constrained to Correspondent Entities. In approaches that involve 1354 the Correspondent Routers (see Section 5.1.3), there have been 1355 suggestions for the Correspondent Router to advertise the network 1356 prefix(es) of Correspondent Nodes the Correspondent Router is capable 1357 of terminating Route Optimization on behalf of to Mobile Network 1358 Nodes. In such cases, the Mobile Network Nodes also need a mechanism 1359 to check the authenticity of such claims. Even if the Correspondent 1360 Routers do not advertise the network prefix, the Mobile Network Nodes 1361 also have the need to verify that the Correspondent Router is indeed 1362 a valid Correspondent Router for a given Correspondent Node. 1364 In Section 5.5.2, the signaling of Route Optimization involves 1365 sending the location of one or more upstream Mobile Routers. The 1366 Correspondent Entity must also have the means to verify such 1367 information. Again, the standard Return Routability procedure is 1368 inadequate here. An extension such as attaching a routing header to 1369 the Care-of Test (CoT) message to verify the authenticity of the 1370 locations of upstream Mobile Routers is likely to be needed. The 1371 risk, however, is not confined to the Correspondent Entities. The 1372 Mobile Network Nodes are also under the threat of receiving false 1373 information from their upstream Mobile Routers, which they might pass 1374 to the Correspondent Entities. There are some considerations that 1375 this kind of on-path threat exists in the current Internet anyway 1376 especially when no (or weak) end-to-end protection is used. 1378 All these concerns over the authenticity of addresses might suggest 1379 that perhaps a more radical and robust approach is necessary. This 1380 is currently under extensive study in various Working Groups of the 1381 IETF, and many related documents might be of interest here. For 1382 instance, in Securing Neighbor Discovery (SEND) [39], the use of 1383 Cryptographically Generated Addresses (CGA) [40] could be used to 1384 establish the ownership of care-of addresses and network prefixes. 1385 [41] employs the Home Agent to check the signaling messages sent by 1386 Mobile Routers to provide a way for Correspondent Entities to verify 1387 the authenticity of Mobile Network Prefixes specified. [42] documents 1388 various proposed enhancements to the Mobile IPv6 Route Optimization 1389 mechanism which might be applied to NEMO Route Optimization as well, 1390 such as [43] which allows the Correspondent Entity to authenticate a 1391 certain operator's Home Agent by verifying the associated 1392 certificate. The Host Identity Protocol (HIP) [44] with end-host 1393 mobility considerations [45] may also be extended for NEMO Route 1394 Optimization as well. 1396 In addition, interested readers might want to refer to [46] that 1397 discussed the general problem of making Route Optimization in NEMO 1398 secure and explored some possible solution schemes. There is also a 1399 proposed mechanism for Mobile Network Node to delegate some rights to 1400 their Mobile Routers in [22], which may be used to allow the Mobile 1401 Routers to prove their authenticities to Correspondent Entities when 1402 establishing Route Optimization sessions on behalf of the Mobile 1403 Network Nodes. 1405 5.8.2. End-to-End Integrity 1407 In some of the approaches, such as "Mobile Router as a Proxy" in 1408 Section 5.5.1, the Mobile Router sends messages using the Mobile 1409 Network Node's address as the source address. This is done mainly to 1410 achieve zero new functionalities required at the Correspondent 1411 Entities and the Mobile Network Nodes. However, adopting such a 1412 strategy may interfere with existing or future protocols, most 1413 particularly security-related protocols. This is especially true 1414 when the Mobile Router needs to make changes to packets sent by 1415 Mobile Network Nodes. In a sense, these approaches break the end-to- 1416 end integrity of packets. A related concern is that this kind of 1417 approach may also require the Mobile Router to inspect into packet 1418 contents sent to/by Mobile Network Nodes. This may prove to be 1419 difficult or impossible if such contents are encrypted. 1421 The concern over end-to-end integrity arises for the use of Reverse 1422 Routing Header (see Section 5.5.2) too, since Mobile Routers would 1423 insert new contents to the header of packets sent by downstream 1424 Mobile Network Nodes. This makes it difficult for Mobile Network 1425 Nodes to protect the end-to-end integrity of such information with 1426 security associations. 1428 5.8.3. Location Privacy 1430 Another security related concern is the issue of location privacy. 1431 This draft currently does not consider the location privacy threats 1432 caused by an on path eavesdropper. For more information on that 1433 aspect, please refer to [18]. Instead, we consider the following 1434 three aspects to location privacy: 1436 o Revelation of Location to Correspondent Entity 1438 Route optimization is achieved by creating a binding between the 1439 address of the Mobile Network Node and the current location of the 1440 Mobile Network. It is thus inevitable that the location of Mobile 1441 Network Node be revealed to the Correspondent Entity. The concern 1442 may be alleviated if the Correspondent Entity is not the 1443 Correspondent Node, since this implies that the actual traffic 1444 end-point (i.e. the Correspondent Node) would remain ignorant of 1445 the current location of the Mobile Network Node. 1447 o Degree of Revelation 1449 With network mobility, the degree of location exposure varies, 1450 especially when one considers nested mobile networks. For 1451 instance, for approaches that bind the address of the Mobile 1452 Network Node to the location of the root Mobile Router (see 1453 Section 5.5.3), only the topmost point of attachment of the mobile 1454 network is revealed to the Correspondent Entity. Whereas for 1455 approaches such as those described in Section 5.5.1 and 1456 Section 5.5.2, more information (such as Mobile Network Prefixes 1457 and current locations of upstream Mobile Routers) is revealed. 1459 o Control of the Revelation 1461 When Route Optimization is initiated by the Mobile Network Node 1462 itself, it is in control of whether or not to sacrifice location 1463 privacy for an optimized route. However, if it is the Mobile 1464 Router that initiates Route Optimization (e.g. "Binding Update 1465 with Mobile Network Prefix" and "Mobile Router as a Proxy" in 1466 Section 5.5.1), then control is taken away from the Mobile Network 1467 Node. Additional signaling mechanism between the Mobile Network 1468 Node and its Mobile Router can be used in this case to prevent the 1469 Mobile Router from attempting Route Optimization for a given 1470 traffic stream. 1472 6. Conclusion 1474 The problem space of Route Optimization in the NEMO context is 1475 multifold and can be split into several work areas. It will be 1476 critical, though, that the solution to a given piece of the puzzle be 1477 compatible and integrated smoothly with others. With this in mind, 1478 this document attempts to present a detailed and in depth analysis of 1479 the NEMO Route Optimization solution space by first describing the 1480 benefits a Route Optimization solution is expected to bring, then 1481 illustrating the different scenarios in which a Route Optimization 1482 solution applies to, and next presenting some issues a Route 1483 Optimization solution might face. We have also asked ourselves some 1484 of the basic questions about a Route Optimization solution. By 1485 investigating different possible answers to these questions, we have 1486 explored different aspects to a Route Optimization solution. The 1487 intent of this work is to enhance our common understanding of the 1488 Route Optimization problem and solution space. 1490 7. IANA Considerations 1492 This is an informational document and does not require any IANA 1493 action. 1495 8. Security Considerations 1497 This is an informational document that analyzes the solution space of 1498 NEMO Route Optimization. Security considerations of different 1499 approaches are described in the relevant sections throughout this 1500 document. Particularly, please refer to Section 4.9 for a brief 1501 discussion of the security concern with respect to Route Optimization 1502 in general, and Section 5.8 for a more detailed analysis of the 1503 various Route Optimization approaches. 1505 9. Acknowledgments 1507 The authors wish to thank the co-authors of previous drafts from 1508 which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki 1509 Ohnishi, Felix Wu, and Souhwan Jung. In addition, sincere 1510 appreciation is also extended to Jari Arkko, Carlos Jesus Bernardos, 1511 Greg Daley, Thierry Ernst, T.J. Kniveton, Erik Nordmark, Alexandru 1512 Petrescu, Hesham Soliman, Ryuji Wakikawa and Patrick Wetterwald for 1513 their various contributions. 1515 10. References 1517 10.1. Normative References 1519 [1] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 1520 Route Optimization Problem Statement", 1521 draft-ietf-nemo-ro-problem-statement-03 (work in progress), 1522 September 2006. 1524 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1525 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1526 January 2005. 1528 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1529 IPv6", RFC 3775, June 2004. 1531 [4] Ernst, T., "Network Mobility Support Goals and Requirements", 1532 draft-ietf-nemo-requirements-05 (work in progress), 1533 October 2005. 1535 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 1536 RFC 3753, June 2004. 1538 [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1539 draft-ietf-nemo-terminology-05 (work in progress), March 2006. 1541 10.2. Informative References 1543 [7] Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, "ORC: 1544 Optimized Route Cache Management Protocol for Network 1545 Mobility", 10th International Conference on Telecommunications, 1546 vol 2, pp 1194-1200, February 2003. 1548 [8] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol 1549 (ORC)", draft-wakikawa-nemo-orc-01 (work in progress), 1550 November 2004. 1552 [9] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Route 1553 Optimization Scheme based on Path Control Header", 1554 draft-na-nemo-path-control-header-00 (work in progress), 1555 April 2004. 1557 [10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 1558 its application to Mobile Networks", 1559 draft-thubert-nemo-reverse-routing-header-05 (work in 1560 progress), June 2004. 1562 [11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization 1563 with Access Router Option", 1564 draft-ng-nemo-access-router-option-01 (work in progress), 1565 July 2004. 1567 [12] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, 1568 "Secure Nested Tunnels Optimization using Nested Path 1569 Information", draft-na-nemo-nested-path-info-00 (work in 1570 progress), September 2003. 1572 [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 1573 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1574 RFC 4140, August 2005. 1576 [14] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA 1577 protocol", draft-thubert-nemo-global-haha-01 (work in 1578 progress), October 2005. 1580 [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1581 Configuration Protocol (DHCP) version 6", RFC 3633, 1582 December 2003. 1584 [16] Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing 1585 Optimization in the same nested mobile network", 1586 draft-baek-nemo-nested-ro-00 (work in progress), October 2005. 1588 [17] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1589 July 2005. 1591 [18] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 1592 Problem Statement", draft-irtf-mobopts-location-privacy-ps-00 1593 (work in progress), July 2005. 1595 [19] Nikander, P., "Mobile IP version 6 Route Optimization Security 1596 Design Background", draft-ietf-mip6-ro-sec-03 (work in 1597 progress), May 2005. 1599 [20] Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: MIPv6 1600 Route Optimization for NEMO", 4th Workshop on Applications and 1601 Services in Wireless Network, 1602 Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf, 1603 August 2004. 1605 [21] Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile 1606 IPv6 Route Optimisation for Network Mobility (MIRON)", 1607 draft-bernardos-nemo-miron-00 (work in progress), July 2005. 1609 [22] Ylitalo, J., "Securing Route Optimization in NEMO", Workshop 1610 of 12th Network and Distributed System Security Syposuim, NDSS 1611 Workshop 2005, online: http://www.isoc.org/isoc/conferences/ 1612 ndss/05/workshop/ylitalo.pdf, February 2005. 1614 [23] Perera, E., Hsieh, R., and A. Seneviratne, "Extended Network 1615 Mobility Support", draft-perera-nemo-extended-00 (work in 1616 progress), July 2003. 1618 [24] Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile 1619 Nodes in Mobile Network based on Prefix Delegation", 58th IEEE 1620 Vehicular Technology Conference, vol 3, pp 2035-2038, 1621 October 2003. 1623 [25] Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization 1624 for Mobile Nodes in Mobile Network based on Prefix 1625 Delegation", draft-leekj-nemo-ro-pd-02 (work in progress), 1626 February 2004. 1628 [26] Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization 1629 based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network", 1630 59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465, 1631 May 2004. 1633 [27] Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route 1634 Optimization for Mobile Nodes in Mobile Network", 1635 draft-jeong-nemo-ro-ndproxy-02 (work in progress), 1636 February 2004. 1638 [28] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1639 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1641 [29] Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route 1642 Optimization for Mobile Network by Using Bi-directional Between 1643 Home Agent and Top Level Mobile Router", 1644 draft-hkang-nemo-ro-tlmr-00 (work in progress), June 2003. 1646 [30] Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization 1647 for Nested Mobile Network", 18th Int'l Conf on Advance 1648 Information Networking and Applications, vol 1, pp 225-229, 1649 2004. 1651 [31] Takagi, Y., Ohnishi, H., Sakitani, K., Baba, K., and S. 1652 Shimojo, "Route Optimization Methods for Network Mobility with 1653 Mobile IPv6", IEICE Trans. on Comms, vol E87-B, no 3, pp 480- 1654 489, March 2004. 1656 [32] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route 1657 optimization method in a mobile network", 1658 draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003. 1660 [33] Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility 1661 (SIP-NEMO) Route Optimization", draft-ming-nemo-sipnemo-00 1662 (work in progress), October 2005. 1664 [34] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1665 Specification", RFC 2473, December 1998. 1667 [35] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1668 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 1669 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 1670 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 1671 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 1672 RFC 3095, July 2001. 1674 [36] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology 1675 and Channel Mapping Examples", RFC 3759, April 2004. 1677 [37] Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC 1678 (Robust Header Compression) in NEMO network", 1679 draft-minaburo-rohc-nemo-01 (work in progress), July 2005. 1681 [38] Ng, C. and J. Hirano, "Extending Return Routability Procedure 1682 for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in 1683 progress), October 2004. 1685 [39] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1686 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1688 [40] Aura, T., "Cryptographically Generated Addresses (CGA)", 1689 RFC 3972, March 2005. 1691 [41] Zhao, F., "Extensions to Return Routability Test in MIP6", 1692 draft-zhao-mip6-rr-ext-01 (work in progress), February 2005. 1694 [42] Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements 1695 to Mobile IPv6 Route Optimization", 1696 draft-irtf-mobopts-ro-enhancements-08 (work in progress), 1697 May 2006. 1699 [43] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based 1700 Binding Update Protocol (CBU)", 1701 draft-qiu-mip6-certificated-binding-update-03 (work in 1702 progress), March 2005. 1704 [44] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 1705 (work in progress), June 2006. 1707 [45] Nikander, P., "End-Host Mobility and Multihoming with the Host 1708 Identity Protocol", draft-ietf-hip-mm-04 (work in progress), 1709 June 2006. 1711 [46] Calderon, M., Bernardos, C., Bagnulo, M., and I. Soto, 1712 "Securing Route Optimization in NEMO", Third International 1713 Symposium on Modeling and Optimization in Mobile, Ad Hoc, and 1714 Wireless Networks, WIOPT 2005, pages 248-254, April 2005. 1716 Appendix A. Change Log 1718 o draft-ietf-nemo-ro-space-analysis-03: 1720 * Keepalive release 1722 o draft-ietf-nemo-ro-space-analysis-02: 1724 * Changed title of Sect 3.1 from "Basic NEMO Route Optimization" 1725 to "Non-Nested NEMO Route Optimization" 1727 * Added "Terminology" Sub-section [Issue #17] 1729 * Modifications to Sect 3.1 and 5.1.1 [Issues #18, #20] 1731 * Break "Mobility Transparency and Location Privacy" into Sect 1732 4.7 and 4.8 [Issue #19] 1734 * Updated References [Issue #21] 1736 o draft-ietf-nemo-ro-space-analysis-01: 1738 * Changed the term "Correspondent Agent" to "Correspondent 1739 Entity" [Issue #13] 1741 * Added clarifying text to some benefits listed in Sect 2 [Issue 1742 #14] 1744 * Added clarifying text to Sect 4.1, 4.3 and 4.4 [Issues #5, #6, 1745 #16] 1747 * Added Section 4.9 [Issue #3] 1749 * Added clarifying text to various parts of Sect 5 [Issues #7, 1750 #8, #9, #11, and #16] 1752 * Combined "MR as a Proxy" and "MR as a Transparent Proxy" in 1753 Sect 5.5.1 [Issue #11] 1755 * Changed the term "identity of MNN" to "address of MNN" in Sect 1756 5.5 [Issue #12] 1758 * Added text on signaling using upper layer protocols in Sect 5.6 1760 * Added more security consideration to Sect 5.8 [Issue #15] 1762 o draft-ietf-nemo-ro-space-analysis-00: 1764 * Adapted from Sections 3, 4 & 5 of 1765 'draft-thubert-nemo-ro-taxonomy-04.txt' into: 1767 + Section 3 - "Different Scenarios of NEMO Route Optimization" 1769 + Section 4 - "Issues of NEMO Route Optimization" 1771 * Included various parts from 'draft-zhao-nemo-ro-ps-01.txt' 1773 * Re-vamped Section 5 - "Analysis of Solution Space" 1775 Authors' Addresses 1777 Chan-Wah Ng 1778 Panasonic Singapore Laboratories Pte Ltd 1779 Blk 1022 Tai Seng Ave #06-3530 1780 Tai Seng Industrial Estate 1781 Singapore 534415 1782 SG 1784 Phone: +65 65505420 1785 Email: chanwah.ng@sg.panasonic.com 1787 Fan Zhao 1788 University of California Davis 1789 One Shields Avenue 1790 Davis, CA 95616 1791 US 1793 Phone: +1 530 752 3128 1794 Email: fanzhao@ucdavis.edu 1796 Masafumi Watari 1797 KDDI R&D Laboratories Inc. 1798 2-1-15 Ohara 1799 Fujimino, Saitama 356-8502 1800 JAPAN 1802 Email: watari@kddilabs.jp 1804 Pascal Thubert 1805 Cisco Systems Technology Center 1806 Village d'Entreprises Green Side 1807 400, Avenue Roumanille 1808 Biot - Sophia Antipolis 06410 1809 FRANCE 1811 Email: pthubert@cisco.com 1813 Full Copyright Statement 1815 Copyright (C) The Internet Society (2006). 1817 This document is subject to the rights, licenses and restrictions 1818 contained in BCP 78, and except as set forth therein, the authors 1819 retain all their rights. 1821 This document and the information contained herein are provided on an 1822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1824 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1825 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1826 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1829 Intellectual Property 1831 The IETF takes no position regarding the validity or scope of any 1832 Intellectual Property Rights or other rights that might be claimed to 1833 pertain to the implementation or use of the technology described in 1834 this document or the extent to which any license under such rights 1835 might or might not be available; nor does it represent that it has 1836 made any independent effort to identify any such rights. Information 1837 on the procedures with respect to rights in RFC documents can be 1838 found in BCP 78 and BCP 79. 1840 Copies of IPR disclosures made to the IETF Secretariat and any 1841 assurances of licenses to be made available, or the result of an 1842 attempt made to obtain a general license or permission for the use of 1843 such proprietary rights by implementers or users of this 1844 specification can be obtained from the IETF on-line IPR repository at 1845 http://www.ietf.org/ipr. 1847 The IETF invites any interested party to bring to its attention any 1848 copyrights, patents or patent applications, or other proprietary 1849 rights that may cover technology that may be required to implement 1850 this standard. Please address the information to the IETF at 1851 ietf-ipr@ietf.org. 1853 Acknowledgment 1855 Funding for the RFC Editor function is provided by the IETF 1856 Administrative Support Activity (IASA).