idnits 2.17.1 draft-ietf-nemo-ro-space-analysis-00.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 1610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1600. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (August 31, 2005) is 6813 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-nemo-ro-problem-statement-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-ro-problem-statement (ref. '1') ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '4') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '6') == Outdated reference: A later version (-01) exists of draft-bernardos-nemo-miron-00 == 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-00 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '21') (Obsoleted by RFC 4861) == Outdated reference: A later version (-08) exists of draft-irtf-mobopts-ro-enhancements-01 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-02 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 10 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 Expires: March 4, 2006 F. Zhao 5 UC Davis 6 M. Watari 7 KDDI R&D Labs 8 P. Thubert 9 Cisco Systems 10 August 31, 2005 12 Network Mobility Route Optimization Solution Space Analysis 13 draft-ietf-nemo-ro-space-analysis-00 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 4, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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 Basic 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 . . . . . . . . . . . 9 65 3.3 Infrastructure based Optimization . . . . . . . . . . . . 10 66 3.4 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 10 67 4. Issues of NEMO Route Optimization . . . . . . . . . . . . . . 12 68 4.1 Additional Signaling Overhead . . . . . . . . . . . . . . 12 69 4.2 Increased Protocol Complexity and Processing Load . . . . 12 70 4.3 Increased Delay during Handoff . . . . . . . . . . . . . . 13 71 4.4 New Functionalities . . . . . . . . . . . . . . . . . . . 13 72 4.5 Detection of New Functionalities . . . . . . . . . . . . . 14 73 4.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.7 Mobility Transparency and Location Privacy . . . . . . . . 15 75 4.8 Security Consideration . . . . . . . . . . . . . . . . . . 15 76 5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 16 77 5.1 Which Entities are Involved? . . . . . . . . . . . . . . . 16 78 5.1.1 Mobile Network Node and Correspondent Node . . . . . . 16 79 5.1.2 Mobile Router and Correspondent Node . . . . . . . . . 17 80 5.1.3 Mobile Router and Correspondent Router . . . . . . . . 17 81 5.1.4 Entities in the Infrastructure . . . . . . . . . . . . 17 82 5.2 Who and When to Initiate Route Optimization? . . . . . . . 18 83 5.3 How to Detect Route Optimization Capability? . . . . . . . 19 84 5.4 How is Identity Represented? . . . . . . . . . . . . . . . 19 85 5.5 How is Identity Bound to Location? . . . . . . . . . . . . 20 86 5.5.1 Binding to the Location of Parent Mobile Router . . . 20 87 5.5.2 Binding to a Sequence of Locations of Upstream 88 Mobile Routers . . . . . . . . . . . . . . . . . . . . 23 89 5.5.3 Binding to the Location of Root Mobile Router . . . . 24 90 5.6 How is Signaling Performed? . . . . . . . . . . . . . . . 26 91 5.7 How is Data Transmitted? . . . . . . . . . . . . . . . . . 27 92 5.8 What are the Security Considerations? . . . . . . . . . . 28 93 5.8.1 Security Considerations of Identity-Location 94 Binding . . . . . . . . . . . . . . . . . . . . . . . 28 95 5.8.2 End-to-End Integrity . . . . . . . . . . . . . . . . . 29 96 5.8.3 Location Privacy . . . . . . . . . . . . . . . . . . . 30 98 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 10.1 Normative References . . . . . . . . . . . . . . . . . . . 32 104 10.2 Informative References . . . . . . . . . . . . . . . . . . 32 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 106 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 Intellectual Property and Copyright Statements . . . . . . . . 37 109 1. Introduction 111 Network Mobility Route Optimization Problem Statement [1] describes 112 operational limitations and overheads incurred in a deployment of 113 Network Mobility (NEMO) Basic Support [2], which could be alleviated 114 by a set of NEMO Route Optimization techniques to be defined. For 115 this purpose of NEMO, the term "Route Optimization" is accepted in a 116 broader sense than already defined for IPv6 Host Mobility in [3], to 117 loosely refer to any approach that optimizes the transmission of 118 packets between a Mobile Network Node and a Correspondent Node. 120 Solutions that would fit that general description were continuously 121 proposed since the early days of NEMO, even before the Working Group 122 was formed. Based on that long standing stream of innovation, this 123 document classifies, at a generic level, the solution space of the 124 possible approaches that could be taken to solve the Route 125 Optimization related problems for NEMO. 127 The scope of the solutions, the benefits, and the impacts to the 128 existing implementations and deployments are analyzed. This work 129 should serve as a foundation for the NEMO WG to decide where to focus 130 its Route Optimization effort, with a deeper understanding of the 131 relative strength and weaknesses of each approach. 133 It is expected for readers to be familiar with general terminologies 134 related to mobility in [3] and [4], and NEMO related terms defined in 135 [5]. In addition, it is beneficial to keep in mind the design 136 requirements of NEMO [6]. A point to note is that since this 137 document discusses aspects of Route Optimization, the readers may 138 assume that a mobile network or a mobile host is away when they are 139 mentioned throughout this document, unless it is explicitly specified 140 that they are at home. 142 1.1 Terminology 144 Correspondent Router (CR) 146 This refers to the entity which is capable of terminating a Route 147 Optimization session on behalf of a Correspondent Node. 149 Correspondent Agent (CA) 151 This refers to the entity which a Mobile Router or Mobile Network 152 Node attempts to establish a Route Optimization session with. 153 Depending on the Route Optimization approach, the Correspondent 154 Agent maybe a Correspondent Node or Correspondent Router. 156 2. Benefits of NEMO Route Optimization 158 To address the problems discussed in [1], one can incorporate Route 159 Optimization into NEMO. Although a standardized NEMO Route 160 Optimization solution has yet to materialize, one can expect it to 161 show some of the following benefits: 163 o Shorter Delay 165 Route Optimization involves the selection and utilization of a 166 least cost (thus generally shorter and faster) route to be taken 167 for traffic between a Mobile Network Node and its Correspondent 168 Node. Hence, Route Optimization should improve the latency of the 169 data traffic between the two end nodes. This may possibly in turn 170 lead to better overall Quality of Services characteristics, such 171 as reduced jitter and packet loss. 173 o Reduced Consumption of Overall Network Resources 175 Through the selection of a shorter route, the total link 176 utilization for all links used by traffic between the two end 177 nodes should be much lower than that used if Route Optimization is 178 not carried out. This would result in a lighter network load with 179 reduced congestion. 181 o Reduced Susceptibility to Link Failure 183 If a link along the bi-directional tunnel is disrupted, all 184 traffic to and from the mobile network will be affected until IP 185 routing recovers from the failure. An optimized route would 186 conceivably utilize a smaller number of links between the two end 187 nodes. Hence, the probability of a loss of connectivity due to a 188 single point of failure at a link should be lower as compared to 189 the longer non-optimized route. 191 o Greater Data Efficiency 193 Depending on the actual solution for NEMO Route Optimization, the 194 data packets exchanged between two end nodes may not require as 195 many levels of encapsulation as that in NEMO Basic Support. This 196 would mean less packet overheads, and higher data efficiency. In 197 particular, avoiding packet fragmentation that may be induced by 198 the multiple levels of tunneling is critical for end-to-end 199 efficiency from the viewpoints of buffering and transport 200 protocols. 202 o Reduced Processing Delay 204 In a nested mobile network, the application of Route Optimization 205 may eliminate the need of multiple encapsulations required by NEMO 206 Basic Support, which may result in less processing delay at the 207 points of encapsulation and decapsulation. 209 o Avoiding the Bottleneck in Home Network 211 NEMO Route Optimization allows traffic to by-pass the Home Agents. 212 Apart from having a more direct route, this also avoids routing 213 traffic via the home network, which may be a potential bottleneck 214 otherwise. 216 o Avoid the Security Policy Issue 218 Security policy may forbid Mobile Routers from tunneling traffic 219 of Visiting Mobile Nodes into the home network of Mobile Router. 220 Route Optimization can be used to avoid this issue by forwarding 221 traffic from Visiting Mobile Nodes directly to their destination 222 without going through the home network of the Mobile Router. 224 o Avoid the Instability and Deadlock 226 [1] described a potential deadlock situation when a Home Agent is 227 nested within a Mobile Network. Route Optimization may circumvent 228 such deadlock situations by directly forwarding traffic upstream. 230 3. Different Scenarios of NEMO Route Optimization 232 There are multiple proposals for providing various forms of Route 233 Optimization in the NEMO context. In the following sub-sections, we 234 describe the different scenarios which would require a Route 235 Optimization mechanism and list the potential solutions which have 236 been proposed in that area. 238 3.1 Basic NEMO Route Optimization 240 We start off with a scenario where nesting of Mobile Routers is not 241 considered, and Route Optimization is initiated and performed between 242 a Mobile Router and its peer Mobile Router, also known as a 243 Correspondent Router. Such solutions are often posed with a 244 requirement to leave the Mobile Network Nodes untouched, as with the 245 NEMO Basic Support protocol, and therefore Mobile Routers handle the 246 optimization management on behalf of the Mobile Network Nodes. Thus, 247 providing Route Optimization for Visiting Mobile Node is often out of 248 scope for such scenario because such interaction would require 249 extensions to the Mobile IPv6 protocol. This scenario is illustrated 250 in Figure 1. 252 HAofCR ********************************** HAofMR 253 #*# #*# 254 #*# #*# +---------------------+ 255 #*# #*# | LEGEND | 256 #*# #*# +---------------------+ 257 #*# ############### #*# | #: Tunnel | 258 CR ooooooooooooooo MR | *: NEMO Basic route | 259 | ############### | | o: Optimized route | 260 MNN2 MNN1 +---------------------+ 262 Figure 1: MR-CR Optimization 264 This form of optimization can carry traffic for both directions 265 identically: 267 o MNN1 to/from MNN2 269 The Mobile Router locates the Correspondent Router, establishes a 270 tunnel with that Correspondent Router and sets up a route to the 271 Mobile Network Node via the Correspondent Router over the tunnel. 272 Traffic to the Mobile Networks Nodes would no longer flow through 273 the Home Agents. 275 From the definition of Correspondent Router, it does not limit itself 276 to be mobile, but can also be an entity within the fixed 277 infrastructure with similar functionalities. As long as the 278 Correspondent Router is located "closer" to the Correspondent Node 279 than the Home Agent of the Mobile Router, the route between Mobile 280 Network Node and the Correspondent Node can be said to be optimized. 281 For this purpose, Correspondent Routers may be deployed to provide an 282 optimal route as illustrated in Figure 2. 284 ************************** HAofMR 285 * #*# 286 * #*# +---------------------+ 287 CN #*# | LEGEND | 288 o #*# +---------------------+ 289 o ############### #*# | #: Tunnel | 290 CR ooooooooooooooo MR | *: NEMO Basic route | 291 ############### | | o: Optimized route | 292 MNN +---------------------+ 294 Figure 2: MR-CR Optimization 296 This form of optimization can carry traffic both directions identical 297 to the previous example in Figure 1, or independently for the 2 298 directions of traffic: 300 o From MNN to CN 302 The Mobile Router locates the Correspondent Router, establishes a 303 tunnel with that Correspondent Router and sets up a route to the 304 Correspondent Node via the Correspondent Router over the tunnel. 305 Traffic to the Correspondent Node would no longer flow through the 306 Home Agent anymore. 308 o From CN to MNN 310 The Correspondent Router is on the path of the traffic from the 311 Correspondent Node to the Home Agent. In addition, it has an 312 established tunnel with the current care-of address of the Mobile 313 Router and is aware of the mobile network prefix(es) managed by 314 the Mobile Router. The Correspondent Router can thus intercept 315 packets going to the mobile network, and forward them to the 316 Mobile Router over the established tunnel. 318 A straight-forward approach to Route Optimization in NEMO is for the 319 Mobile Router to attempt Route Optimization with a Correspondent 320 Agent. This can be viewed as a logical extension to NEMO Basic 321 Support, where the Mobile Router would send binding updates 322 containing one or more Mobile Network Prefix options to the 323 Correspondent Agent. The Correspondent Agent having received the 324 binding update, can then set up a bi-directional tunnel with the 325 Mobile Router at the current care-of address of the Mobile Router, 326 and inject a route to its routing table so that packets destined for 327 addresses in the mobile network prefix will be routed through the bi- 328 directional tunnel. 330 Examples of this approach include Optimized Route Cache (ORC) [7] and 331 Path Control Header (PCH) [8]. 333 3.2 Nested Mobility Optimization 335 Optimization in Nested Mobility targets scenarios where a nesting of 336 mobility management protocols is created (i.e. Mobile IPv6 enabled 337 host inside a mobile network or multiple Mobile Routers that attach 338 behind one another creating a nested mobile network). Note that 339 because Mobile IPv6 defines its own Route Optimization mechanism in 340 its base protocol suite as a standard, collaboration with this and 341 NEMO brings various complexity. 343 There are two main aspects in providing optimization for Nested 344 Mobility and they are discussed in the following sub-sections. 346 3.2.1 Decreasing the number of Home Agents on the path 348 The aim is to remove the sub-optimality of paths caused by multiple 349 tunnels established between multiple Mobile Nodes and their Home 350 Agents. Such a solution will seek to minimize the number of Home 351 Agents along the path, possibly by bypassing some of the Home 352 Agent(s) from the original path. Unlike the scenario where no 353 nesting is formed and only a single Home Agent exists along the path, 354 bypassing one of the many Home Agents can still be effective. 356 Solutions for Nested Mobility scenarios can usually be divided into 357 two cases based on whether the nesting involves Mobile IPv6 hosts or 358 only involves Mobile Routers. Since Mobile IPv6 defines its own 359 Route Optimization mechanism, providing optimal path for such hosts 360 will require interaction with the protocol and may require an 361 altering of the messages exchanged during the Return Routability 362 procedure with the Correspondent Node. 364 Examples of this approach include MIRON [9] and Reverse Routing 365 Header (RRH) [10]. 367 3.2.2 Decreasing the number of tunnels 369 The aim is to reduce the amplification effect of nested tunnels due 370 to the nesting of tunnels between the Visiting Mobile Node and its 371 Home Agent within the tunnel between the parent Mobile Router and the 372 parent Mobile Router's Home Agent. Such a solution will seek to 373 minimize the number of tunnels possibly by collapsing the amount of 374 tunnels required through some form of signaling between Mobile Nodes, 375 or between Mobile Nodes and their Home Agents, or by using routing 376 headers to route packets through a discovered path. These limit the 377 consequences of the amplification effect of nested tunnels, and at 378 best, the performance of a nested mobile network will be the same as 379 though there were no nesting at all. 381 Example includes the Reverse Routing Header (RRH) [10], Access Router 382 Option (ARO) [11], and Nested Path Info (NPI) [12]. 384 3.3 Infrastructure based Optimization 386 An infrastructure based optimization is an approach where 387 optimization is carried out fully in the infrastructure. One example 388 is to make use of mobile anchor points (MAP) in HMIPv6 [13] to 389 optimize routes between themselves. Another example is to make use 390 of the global HAHA protocol [14]. In this case, proxy Home Agents 391 are distributed in the infrastructure and Mobile Routers bind to the 392 closest proxy. The proxy, in turn, performs a primary binding with a 393 real Home Agent for that Mobile Router. Then, the proxy might 394 establish secondary bindings with other Home Agents or proxies in the 395 infrastructure, in order to improve the end-to-end path. In this 396 case, the proxies discover each other, establish a tunnel and 397 exchange the relevant mobile network prefix information in the form 398 of explicit prefix routes. 400 Alternatively, another approach is to use prefix delegation. Here, 401 each Mobile Router in a nested mobile network is delegated a mobile 402 network prefix from the access router using DHCP Prefix Delegation 403 [15]). Each Mobile Router also autoconfigures its care-of address 404 from this delegated prefix. In this way, the care-of addresses of 405 each Mobile Router are all from an aggregatable address space 406 starting from the access router. This may be used to eliminate the 407 multiple tunnels caused by nesting of Mobile Nodes. 409 3.4 Intra-NEMO Optimization 411 A Route Optimization solution may seek to improve the communications 412 between two Mobile Network Nodes within a nested mobile network. 413 This would avoid traffic being injected out of the nested mobile 414 network and route them within the nested mobile network. An example 415 will be the optimized route taken between MNN1 and MNN2 of Figure 3 416 below. 418 +--------+ +--------+ +--------+ +--------+ 419 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 420 +------+-+ +---+----+ +---+----+ +-+------+ 421 \ | | / 422 +--------+ +------------------------------+ 423 | MR1_HA |----| Internet |-----CN 424 +--------+ +--------------+---------------+ 425 | 426 +----+----+ 427 | MR1 | 428 +----+----+ 429 | 430 ---+-----------+-----------+--- 431 | | | 432 +---+---+ +---+---+ +---+---+ 433 | MR5 | | MR2 | | MR4 | 434 +---+---+ +---+---+ +---+---+ 435 | | | 436 ---+--- +---+---+ ---+--- 437 MNN2 | MR3 | MNN3 438 +---+---+ 439 | 440 ----+---- 441 MNN1 443 Figure 3: An example of nested Mobile Network 445 One may be able to extend a well-designed NEMO Route Optimization for 446 "Nested Mobility Optimization" (see Section 3.2) to provide for such 447 kind of Intra-NEMO optimization, where, for example in Figure 3, 448 MNN1 is treated as a Correspondent Node from the perspective of MR5/ 449 MNN2, and MNN2 is treated as a Correspondent Node from the view of 450 MR3/MNN1. 452 Another possibility is for the "Basic NEMO Route Optimization" 453 technique (see Section 3.1) to be applied here. Using the same 454 example of communication between MNN1 and MNN2, both MR3 and MR2 can 455 treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and 456 MR2 as Correspondent Routers for MNN1. 458 Yet another approach is to flatten any nested Mobile Network so that 459 all nested Mobile Network Nodes appear to be virtually on the same 460 link. Examples of such approaches include delegating a single prefix 461 to the nested Mobile Network, having Mobile Routers to perform 462 Neighbor Discovery on behalf of their Mobile Network Nodes, and 463 exposing a single prefix over the entire mobile network using a 464 Mobile Ad-Hoc (MANET) protocol. 466 4. Issues of NEMO Route Optimization 468 Although Route Optimization can bring benefits as described in 469 Section 2, the scenarios described in Section 3 does so with some 470 tradeoffs. This section explores some general issues that may impact 471 a NEMO Route Optimization mechanism. 473 4.1 Additional Signaling Overhead 475 The nodes involved in performing Route Optimization would be expected 476 to exchange additional signaling messages in order to establish Route 477 Optimization. The required amount of signaling depends on the 478 solution, but is likely to exceed the amount required in the home 479 binding update procedure defined in NEMO Basic Support. The amount 480 of signaling is likely to increase with the increasing number of 481 Mobile Network Nodes and/or Correspondent Nodes, and may be amplified 482 with nesting of mobile networks. It may scale to unacceptable height 483 especially to the resource-scarce mobile node which typically has 484 limited power, memory and processing capacity. 486 This may lead to an issue that impacts NEMO Route Optimization, known 487 as the phenomenon of "Binding Update Storm", or more generally, 488 "Signaling Storm". This occurs when a change in point of attachment 489 of the mobile network is accompanied with a sudden burst of signaling 490 messages, resulting in temporary congestion, packet delays or even 491 packet loss. This effect will be especially significant for wireless 492 environment where bandwidth is relatively limited. 494 It is possible to moderate the effect of Signaling Storm by 495 incorporating mechanisms such as spreading the transmissions burst of 496 signaling messages over a longer period of time, or aggregating the 497 signaling messages. 499 4.2 Increased Protocol Complexity and Processing Load 501 It is expected for NEMO Route Optimization to be more complicated 502 than NEMO Basic Support. Thus, complexity of nodes that are required 503 to incorporate new functionalities to support NEMO Route Optimization 504 would be higher than those required to provide NEMO Basic Support. 506 Coupled with the increased complexity, nodes that are involved in the 507 establishment and maintenance of Route Optimization will have to bear 508 the increased processing load. If such nodes are mobile, this may 509 prove to be a significant cost due to the limited power and 510 processing resources such devices usually have. 512 4.3 Increased Delay during Handoff 514 Due to the diversity of locations of different nodes that Mobile 515 Network Node may signal with and the complexity of NEMO Route 516 Optimization procedure that may cause several rounds of signaling 517 messages, a NEMO Route Optimization procedure may take a longer time 518 to finish its handoff than that in NEMO Basic Support. This may 519 exacerbate the overall delay during handoffs and further cause 520 performance degradation of the applications running on Mobile Network 521 Nodes. 523 Another NEMO specific delay during handoff is that in a nested mobile 524 network, a child Mobile Network Node may need to detect or be 525 notified of the handoff of its parent Mobile Router so that it can 526 begin signaling its own Correspondent Agents. Apart from the 527 compromise of mobility awareness and location privacy, this mechanism 528 also increases the delay during handoffs. 530 4.4 New Functionalities 532 In order to support NEMO Route Optimization, some nodes need to be 533 changed or upgraded. Smaller number of nodes required to be changed 534 will allow for easier adoption of NEMO Route Optimization solution in 535 the Internet and create less impact on existing Internet 536 infrastructure. The number and the types of nodes involved with new 537 functionalities also affect how much of the route is optimized. 539 Possible nodes that may be required to change include: 541 o Local Fixed Nodes 543 It may prove to be difficult to introduce new functionalities at 544 Local Fixed Nodes, since by definition, any IPv6 node can be a 545 Local Fixed Node. This might mean that only those Local Fixed 546 Nodes that are modified can enjoy the benefits of Route 547 Optimization. 549 o Visiting Mobile Nodes 551 Visiting Mobile Nodes in general should already implement Mobile 552 IPv6 functionalities, and since Mobile IPv6 is a relatively new 553 standard, there is still a considerable window to allow mobile 554 devices to implement new functionalities. 556 o Mobile Routers 558 It is expected for Mobile Routers to implement new functionalities 559 in order to support route optimization. 561 o Access Routers 563 Some approaches require access routers, or nodes in the access 564 network, to implement some new functionalities. It may prove to 565 be difficult to do so, since access routers, are in general, 566 standard IPv6 routers. 568 o Home Agents 570 It is relatively easier for new functionalities to be implemented 571 in Home Agents. 573 o Correspondent Nodes 575 It may prove to be difficult to introduce new functionalities at 576 Correspondent Nodes, since by definition, any IPv6 node can be a 577 Correspondent Node. This might mean that only those Correspondent 578 Nodes that are modified can enjoy the benefits of Route 579 Optimization. 581 o Correspondent Routers 583 Correspondent Routers are new entities introduced for the purpose 584 of Route Optimization, and therefore new functionalities can be 585 defined as needed. 587 4.5 Detection of New Functionalities 589 One issue that is related to the need for new functionalities as 590 described in Section 4.4 is the need to detect the existence of such 591 functionalities. In these cases, a detection mechanism might be 592 helpful to allow the initiator of Route Optimization to detect if 593 support of the new functionalities are available. Furthermore, it 594 might be advantageous to have a graceful fall back procedure if the 595 required functionalities are unavailable. 597 4.6 Scalability 599 Given the same number of nodes, the number of route optimization 600 sessions would usually be more than the number of NEMO Basic Support 601 tunnels. If all route optimization sessions of a mobile network are 602 maintained by a single node (such as the Mobile Router), this would 603 means that the single node has to keep track of the states of all 604 route optimization sessions. This may leads to scalability issues 605 especially when that single node is a mobile device with limited 606 memory and processing resources. 608 A similar scalability issue may be faced by Correspondent Agent as 609 well if it maintains many route optimized sessions on behalf of 610 Correspondent Node(s) with a large number of Mobile Routers. 612 4.7 Mobility Transparency and Location Privacy 614 One advantage of NEMO Basic Support is that the Correspondent Nodes 615 and Mobile Network Nodes need not be aware of the actual location and 616 mobility of the mobile network. With Route Optimization, it might be 617 necessary to reveal the point of attachment of the Mobile Router to 618 other nodes, such as the Mobile Network Nodes or their Correspondent 619 Nodes. This may mean a tradeoff between location privacy [16] (and 620 mobility transparency) and Route Optimization. 622 In Mobile IPv6, a mobile node can decide whether or not to perform 623 Route Optimization with a given Correspondent Node. Thus, the mobile 624 node is in control of whether to trade location privacy for an 625 optimized route. In NEMO Route Optimization, if the decision to 626 perform Router Optimization is made by the Mobile Router, it will be 627 difficult for Mobile Network Nodes to control the decision of having 628 this tradeoff. 630 4.8 Security Consideration 632 As Mobile Router and Home Agent usually belong to the same 633 administration domain, it is likely that there exists a security 634 association between them, which is leveraged by NEMO Basic Support to 635 conduct the home binding update in a secure way. However, NEMO Route 636 Optimization usually involves nodes from different domains (for 637 example, Mobile Router and Correspondent Agent), thus the existence 638 of such a security association is not a valid assumption in many 639 deployment scenarios. Thus the security protection of NEMO Route 640 Optimization signaling message is considered as "weaker" than that in 641 NEMO Basic Support. It is expected that some additional security 642 mechanisms are needed to achieve the same or similar level of 643 security as in NEMO Basic Support. 645 When considering security issues of NEMO Route Optimization, it might 646 be useful to keep in mind some of the security issues considered when 647 Mobile IPv6 Route Optimization was designed as documented in [17]. 649 5. Analysis of Solution Space 651 As described in Section 3, there are various different approaches to 652 achieve Route Optimization in Network Mobility Support. In this 653 section, we attempt to analyze the vast solution space of NEMO Route 654 optimization by asking the following questions: 656 1. Which entities are involved? 658 2. Who and when to initiate signaling? 660 3. How to detect Route Optimization capabilities? 662 4. How is identity represented? 664 5. How is identity bound to location? 666 6. How is signaling done? 668 7. How is data transmitted? 670 8. What are the security considerations? 672 5.1 Which Entities are Involved? 674 There are many combinations of entities involved in Route 675 Optimization. When considering the role each entity plays in Route 676 Optimization, one has to bear in mind the considerations described in 677 Section 4.4 and Section 4.5. Below is a list of combinations to be 678 discussed in the following subsections: 680 o Mobile Network Node and Correspondent Node 682 o Mobile Router and Correspondent Node 684 o Mobile Router and Correspondent Router 686 o Entities in the Infrastructure 688 5.1.1 Mobile Network Node and Correspondent Node 690 A Mobile Network Node can establish Route Optimization with its 691 Correspondent Node, possibly the same way as a Mobile Node 692 establishes Route Optimization with its Correspondent Node in Mobile 693 IPv6. This would achieve the most optimal route, since the entire 694 end-to-end path is optimized. However, there might be scalability 695 issues since both the Mobile Network Node and the Correspondent Node 696 may need to maintain many Route Optimization sessions. In addition, 697 new functionalities are required for both the Mobile Network Node and 698 Correspondent Node. 700 5.1.2 Mobile Router and Correspondent Node 702 Alternatively, Mobile Router can establish Route Optimization with a 703 Correspondent Node on behalf of the Mobile Network Node. Since the 704 Mobile Router is merely one hop away from the Mobile Network Node, 705 this effectively achieves an optimal route for the entire end-to-end 706 path as well. Compared with Section 5.1.1, the scalability issue 707 here may be remedied since it is possible for Correspondent Node to 708 maintain only one session with Mobile Router if it communicates with 709 many Mobile Network Nodes associated with Mobile Router. 710 Furthermore, with Mobile Router handling Route Optimization, there is 711 no need for Mobile Network Nodes to implement new functionalities. 712 However, new functionality is likely to be required on the 713 Correspondent Node. 715 5.1.3 Mobile Router and Correspondent Router 717 Approaches involving Mobile Routers and Correspondent Routers are 718 described in Section 3.1. The advantage of this approach is that no 719 additional functionality is required for the Correspondent Node and 720 Mobile Network Nodes. In addition, location privacy is relatively 721 preserved, since the current location of the mobile network is only 722 revealed to the Correspondent Router and not to the Correspondent 723 Node (please refer to Section 5.8.3 for more discussions). 724 Furthermore, if the Mobile Router and Correspondent Router exchange 725 prefix information, this approach may scale well since a single Route 726 Optimization session between the Mobile Router and Correspondent 727 Router can achieve Route Optimization between any Mobile Network Node 728 in the mobile network, and any Correspondent Node managed by the 729 Correspondent Router. 731 The main concern with this approach is the need for a mechanism to 732 allow the Mobile Router to detect the presence of the Correspondent 733 Router (see Section 5.3 for details), and its security impact. Both 734 the Mobile Router and the Correspondent Router need some means to 735 verify the validity of each other. This is discussed in greater 736 detail in Section 5.8. 738 5.1.4 Entities in the Infrastructure 740 Approaches using entities in the infrastructure are described in 741 Section 3.3. The advantages of this approach include firstly not 742 requiring new functionalities to be implemented on the Mobile Network 743 Nodes and Correspondent Nodes, and secondly having most of the 744 complexity shifted to nodes in the infrastructure. However, one main 745 issue with this approach is how the Mobile Router can detect the 746 presence of such entities, and why the Mobile Router should trust 747 these entities. This may be easily addressed if such entity is a 748 Home Agent of the Mobile Router (such as in global HAHA). Another 749 concern is that the resulting path may not be a true optimized one, 750 since it depends on the relative positions of the infrastructure 751 entities with respect to the mobile network and the Correspondent 752 Node. 754 5.2 Who and When to Initiate Route Optimization? 756 Usually, the node that is mobile (i.e. Mobile Network Node or Mobile 757 Router) is in the best position to detect its mobility. Thus, in 758 general, it is better for the mobile node to initiate the Route 759 Optimization session in order to handle the topology changes in any 760 kind of mobility pattern and achieve the optimized route promptly. 761 However, when the mobile node is within a nested mobile network, the 762 detection of the mobility may need to be conveyed to the nested 763 Mobile Network Node. This might incur longer signaling delay as 764 discussed in Section 4.3. 766 Some solution may enable the node on the correspondent side to 767 initiate Route Optimization session in certain situations. For 768 instance, when the Route Optimization state that is already 769 established on the Correspondent Agent is about to expire but the 770 communication is still active, depending on the policy, the 771 Correspondent Agent may initiate a Route Optimization request with 772 the mobile node side. 774 There is also the question of when Route Optimization should be 775 initiated. Because route optimization would certainly incur 776 tradeoffs of various forms, it might not be desirable for Route 777 Optimization to be performed for any kind of traffic. This is, 778 however, implementation specific and policy driven. 780 A related question is how often signaling messages should be sent to 781 maintain the Route Optimization session. Typically, signaling 782 messages is likely to be sent whenever there is topological changes. 783 The discussion in Section 4.1 should be considered. In addition, a 784 Lifetime value is often used to indicate the period of validity for 785 the Route Optimization session. Signaling messages would have to be 786 sent before the Lifetime value expires in order to maintain the Route 787 Optimization session. The choice of Lifetime value needs to balance 788 between different considerations. On one hand, a short Lifetime 789 value would increase the amount of signaling overhead. On the other 790 hand, a long Lifetime value may expose the Correspondent Agent to the 791 risk of having an obsolete binding cache entry, which creates an 792 opportunity for an attacker to exploit. 794 5.3 How to Detect Route Optimization Capability? 796 The question here is how the initiator of Route Optimization knows if 797 the Correspondent Agent supports the functionality required to 798 established a Route Optimization session. The usual method is for 799 the initiator to attempt Route Optimization with the Correspondent 800 Agent. Depending on the protocol specifics, the initiator may 801 receive (i) a reply from the Correspondent Agent indicating its 802 capability, (ii) an error message from the Correspondent Agent, or 803 (iii) no response from the Correspondent Agent within a certain time 804 period. This serves as an indication of whether the Correspondent 805 Agent supports the required functionality to establish Route 806 Optimization or not. This form of detection may incur additional 807 delay as a penalty when the Correspondent Agent does not have Route 808 Optimization capability. 810 When the Correspondent Agent is not the Correspondent Node but a 811 Correspondent Router, a more immediate question is how to detect its 812 presence. One way to approach this is for the initiator to send an 813 Internet Control Message Protocol (ICMP) message containing the 814 address of the Correspondent Node to a well-known anycast address 815 reserved for all Correspondent Routers [7]. Only the Correspondent 816 Router that is capable of terminating Route Optimization session on 817 behalf of the Correspondent Node will respond. Another way is to 818 insert a Router Alert Option (RAO) to a packet sent to the 819 Correspondent Node [8]. Any Correspondent Router en route will 820 process the Router Alert Option, and send a response to the Mobile 821 Router. 823 Both approaches need to consider the possibility of multiple 824 Correspondent Routers responding to the initiator, and both 825 approaches will generate additional traffic or processing load to 826 other routers. Furthermore, both approaches have yet to consider how 827 the initiator can verify the authenticity of the Correspondent 828 Routers that responded. 830 5.4 How is Identity Represented? 832 Normally, Route Optimization would mean that a binding between the 833 Mobile Network Node's identity and location is registered at the 834 Correspondent Agent. Before exploring into different ways of binding 835 location to identity (see Section 5.5), one must first ask how the 836 identity of the Mobile Network Node is represented. Basically, there 837 are two ways to represent the Mobile Network Node's identity: 839 o implicitly, by the use of Mobile Network Prefix, or 841 o explicitly, by the use of the address of Mobile Network Node. 843 Using the Mobile Network Prefix would usually mean the initiator is 844 the Mobile Router, and has the benefit of binding numerous Mobile 845 Network Nodes with one signaling. However, it also means that if 846 location privacy is compromised, the location privacy of an entire 847 Mobile Network Prefix will be compromised. 849 On the other hand, using the Mobile Network Node's address would mean 850 that the initiator is either the Mobile Network Node itself, or the 851 Mobile Router is initiating Route Optimization on behalf of the 852 Mobile Network Node. Initiation by the Mobile Network Node itself 853 means that the Mobile Network Node must have new functionalities 854 implemented, while initiation by the Mobile Router means that the 855 Mobile Router must maintain some Route Optimization states for each 856 Mobile Network Node. 858 5.5 How is Identity Bound to Location? 860 In order for route to be optimized, it is generally necessary for the 861 Correspondent Agent to create a binding between the identity and the 862 location of the Mobile Network Node. This can be done in the 863 following ways: 865 o binding the identity to the location of the parent Mobile Router; 867 o binding the identity to a sequence of locations of upstream Mobile 868 Routers; and 870 o binding the identity to the location of the root Mobile Router 872 These will be described in the following sub-sections. 874 5.5.1 Binding to the Location of Parent Mobile Router 876 By binding the identity of Mobile Network Node to the location of its 877 parent Mobile Router, the Correspondent Agent would know how to reach 878 the Mobile Network Node via the current location of the parent Mobile 879 Router. This can be done by: 881 o Binding Update with Mobile Network Prefix 883 This can be viewed as a logical extension to NEMO Basic Support, 884 where the Mobile Router would send binding updates containing one 885 or more Mobile Network Prefix options to the Correspondent Agent. 886 The Correspondent Agent having received the Binding Update, can 887 then set up a bi-directional tunnel with the Mobile Router at the 888 current care-of address of the Mobile Router, and inject a route 889 to its routing table so that packets destined for addresses in the 890 mobile network prefix will be routed through the bi-directional 891 tunnel. 893 Note that in this case, the identity of the Mobile Network Node is 894 implied by the Mobile Network Prefix (see Section 5.4). 896 o Sending Information of Parent Mobile Router 898 This involves the Mobile Network Node sending the information of 899 its Mobile Router to the Correspondent Agent, thus allowing the 900 Correspondent Agent to establish a binding between the identity of 901 the Mobile Network Node to the location of the parent Mobile 902 Router. An example of such an approach would be [11]. 904 o Mobile Router as a Proxy 906 Another approach is for the parent Mobile Router to act as a 907 "proxy" for its Mobile Network Nodes. In this case, the Mobile 908 Router uses standard Mobile IPv6 Route Optimization procedure to 909 bind the address of a Mobile Network Node to the Mobile Router's 910 care-of address. 912 o Mobile Router as a Transparent Proxy 914 A somewhat similar approach involves the Mobile Router 915 transparently altering packets transmitted with Mobile IPv6 Route 916 Optimization (such as altering messages exchanged during the 917 return routability procedure between a Visiting Mobile Node and 918 its Correspondent Node), so that packets sent from Correspondent 919 Node to the Visiting Mobile Node will be routed to the care-of 920 address of the Mobile Router once Route Optimization is 921 established (such as [9]). This should be contrasted against 922 "Mobile Router as a Proxy". Here, the Mobile Router relies on the 923 Visiting Mobile Node to start the Return Routability procedure, 924 and alters the contents of the messages in Return Routability 925 procedure to achieve Route Optimization. Whereas in "Mobile 926 Router as a Proxy", the Mobile Router initiates the Return 927 Routability procedure on its own. 929 For all of the approaches listed above, when the Mobile Network Node 930 is deeply nested within a Mobile Network, the Correspondent Agent 931 would need to gather Binding Updates from all the upstream Mobile 932 Routers in order to build the complete route to reach the Mobile 933 Network Node. This increases the complexity of the Correspondent 934 Agent, as the Correspondent Agent may need to perform multiple 935 binding cache look-ups before it can construct the complete route. 937 Other than increasing the complexity of the Correspondent Agent, 938 these approaches may incur extra signaling overhead and delay for a 939 nested Mobile Network Node. For instance, every Mobile Router on the 940 upstream of the Mobile Network Node needs to send Binding Updates to 941 the Correspondent Agent. If this is done by the upstream Mobile 942 Routers independently, it may incur additional signaling overhead. 943 Also, since each Binding Update takes a finite amount of time to 944 reach and be processed by the Correspondent Agent, the delay from the 945 time an optimized route is changed till the time the change is 946 registered on the Correspondent Agent will increase proportionally 947 with the number of Mobile Routers on the upstream of the Mobile 948 Network Node (i.e. the level of nesting of the Mobile Network Node). 950 For "Binding Update with Mobile Network Prefix" and "Sending 951 Information of Upstream Mobile Router", new functionality is required 952 at the Correspondent Agent, whereas "Mobile Router as a Proxy" and 953 "Mobile Router as a Transparent Proxy" keeps the functionality of the 954 Correspondent Agent to be the same as a Mobile IPv6 Correspondent 955 Node. However, this is done at an expense of the Mobile Routers, 956 since in "Mobile Router as a Proxy" and "Mobile Router as a 957 Transparent Proxy", the Mobile Router must maintain state information 958 for every Route Optimization session its Mobile Network Nodes have. 959 Furthermore, for "Mobile Router as a Transparent Proxy", the Mobile 960 Router needs to look beyond the standard IPv6 headers for ingress and 961 egress packets, and alter the packet contents appropriately. 963 One advantage shared by all the approaches listed here is that only 964 mobility protocol is affected. In other words, no modification is 965 required on other existing protocols (such as Neighbor Discovery). 966 There is also no additional requirements on existing infrastructure 967 (such as the access network). 969 In addition, having upstream Mobile Routers send Binding Updates 970 independently means that the Correspondent Agent can use the same 971 binding cache entries of upstream Mobile Routers to construct the 972 complete route to two Mobile Network Nodes that have common upstream 973 Mobile Routers. This may translate to lower memory consumption since 974 the Correspondent Agent need not store one complete route per Mobile 975 Network Node when it is having Route Optimizations sessions with 976 multiple Mobile Network Nodes from the same mobile network. 978 5.5.2 Binding to a Sequence of Locations of Upstream Mobile Routers 980 For a nested Mobile Network Node, it might be more worth while to 981 bind its identity to the sequence of points of attachment of upstream 982 Mobile Routers. In this way, the Correspondent Agent can build a 983 complete sequence of points of attachment from a single transmission 984 of the binding information. Examples using this approach are [10] 985 and [12]. 987 Different from Section 5.5.1, this approach constructs the complete 988 route to a specific Mobile Network Node at the mobile network side, 989 thus offering the opportunity to reduce the signaling overhead. 990 Since the complete route is conveyed to the Correspondent Agent in a 991 single transmission, it is possible to reduce the delay from the time 992 an optimized route is changed till the time the change is registered 993 on the Correspondent Agent to its minimum. 995 One question that immediately comes to the mind is how the Mobile 996 Network Node gets hold of the sequence of locations of its upstream 997 Mobile Routers. This is usually achieved by having such information 998 inserted as special options in the Router Advertisement messages 999 advertised by upstream Mobile Routers. To do so, not only must a 1000 Mobile Router advertise its current location to its Mobile Network 1001 Nodes, it must also relay information embedded in Router 1002 Advertisement messages it has received from its upstream Mobile 1003 Routers. This might imply a compromise of the mobility transparency 1004 of a mobile network (see Section 4.7). In addition, it also means 1005 that whenever an upstream Mobile Router changes its point of 1006 attachment, all downstream Mobile Network Nodes must perform Route 1007 Optimization signaling again, possibly leading to a "signaling storm" 1008 (see Section 4.1). 1010 A different method of conveying locations of upstream Mobile Routers 1011 is used in [10] where upstream Mobile Routers insert their current 1012 point of attachment into a Reverse Routing Header embedded within a 1013 packet sent by the Mobile Network Node. This may raise security 1014 concerns that will be discussed later in Section 5.8.2. 1016 In order for a Correspondent Agent to bind the identity of a Mobile 1017 Network Node to a sequence of locations of upstream Mobile Routers, 1018 new functionalities need to be implemented on the Correspondent 1019 Agent. The Correspondent Agent also needs to store the complete 1020 sequence of locations of upstream Mobile Routers for every Mobile 1021 Network Node. This may demand more memory compared to Section 5.5.1 1022 if the same Correspondent Agent has a lot of Route Optimization 1023 sessions with Mobile Network Nodes from the same nested Mobile 1024 Network. In addition, some amount of modifications to existing 1025 protocols is also required, such as a new type of IPv6 routing 1026 header, or new options in Router Advertisement messages. 1028 5.5.3 Binding to the Location of Root Mobile Router 1030 A third approach is to bind the identity of the Mobile Network Node 1031 to the location of the root Mobile Router, regardless of how deeply 1032 nested the Mobile Network Node is within a nested Mobile Network. 1033 Whenever the Correspondent Agent needs to forward packet to the 1034 Mobile Network Node, it only needs to forward the packet to this 1035 point of attachment. The mobile network will figure out how to 1036 forward the packet to the Mobile Network Node by itself. This kind 1037 of approach can be viewed as flattening the structure of a nested 1038 Mobile Network, so that it seems to the Correspondent Agent that 1039 every node in the Mobile Network is attached to the Internet at the 1040 same network segment. 1042 There are various approaches to achieve this: 1044 o Prefix Delegation 1046 Here, each Mobile Router in a nested mobile network is delegated a 1047 Mobile Network Prefix from the access router (such as using DHCP 1048 Prefix Delegation [15]). Each Mobile Router also autoconfigures 1049 its care-of address from this delegated prefix. In this way, the 1050 care-of addresses of Mobile Routers are all from an aggregatable 1051 address space starting from the access router. Mobile Network 1052 Nodes with Mobile IPv6 functionality may also autoconfigure its 1053 care-of address from this delegated prefix, and use standard 1054 Mobile IPv6 mechanism to bind its home address to this care-of 1055 address. 1057 Examples of this approach includes [18] and [19]. 1059 This approach has the advantage of keeping the implementations of 1060 Correspondent Nodes unchanged. However, it requires the access 1061 router (or some other entity within the access network) and Mobile 1062 Router to possess prefix delegation functionality, and also 1063 maintain information on what prefix is delegated to which node. 1064 How to efficiently assign a subset of Mobile Network Prefix to 1065 child Mobile Routers could be an issue because Mobile Network 1066 Nodes may dynamically join and leave with an unpredictable 1067 pattern. In addition, a change in the point of attachment of the 1068 root Mobile Router will also require every nested Mobile Router 1069 (and possibly Visiting Mobile Nodes) to change their care-of 1070 addresses and delegated prefixes. These will cause a burst of 1071 Binding Updates and prefix delegation activities where every 1072 Mobile Router and every Visiting Mobile Node start sending Binding 1073 Updates to their Correspondent Agents. 1075 o Neighbor Discovery Proxy 1077 This approach (such as [20]) achieves Route Optimization by having 1078 Mobile Routers to act as a Neighbor Discovery [21] proxy for its 1079 Mobile Network Nodes. Mobile Router will configure a care-of 1080 address from the network prefix advertised by its access router, 1081 and also relay this prefix to its subnets. When a Mobile Network 1082 Node configures an address from this prefix, the Mobile Router 1083 will act as a Neighbor Discovery proxy on its behalf. In this 1084 way, the entire mobile network and its access network form a 1085 logical multilink subnet, thus eliminating any nesting. 1087 This approach has the advantage of keeping the implementations of 1088 Correspondent Nodes unchanged. However, it requires the root 1089 Mobile Router to act as a Neighbor Discovery proxy for all the 1090 Mobile Network Nodes that are directly or indirectly attached to 1091 it. This increases the processing load of the root Mobile Router. 1092 In addition, a change in the point of attachment of the root 1093 Mobile Router will require every nested Mobile Router (and 1094 possibly Visiting Mobile Nodes) to change their care-of addresses. 1095 Not only will this cause a burst of Binding Updates where every 1096 Mobile Router and every Visiting Mobile Node start sending Binding 1097 Updates to their Correspondent Agents, it will also cause a burst 1098 of Duplicate Address Discovery messages to be exchanged between 1099 the mobile network and the access network. 1101 o Hierarchical Registrations 1103 Hierarchical Registration involves Mobile Network Nodes (including 1104 nested Mobile Routers) to register itself with either their parent 1105 Mobile Routers, or the root Mobile Router itself. After 1106 registrations, Mobile Network Nodes would tunnel packets directly 1107 to the upstream Mobile Router they register with. At the root 1108 Mobile Router, packets tunneled from sub-Mobile Routers or Mobile 1109 Network Nodes are tunneled directly to the Correspondent Agents, 1110 thus avoiding nested tunneling. 1112 One form of such approach uses the principle of Hierarchical 1113 Mobile IPv6 [13], where the root Mobile Router acts as a Mobility 1114 Anchor Point. It is also possible for each parent Mobile Router 1115 to act as Mobility Anchor Points for their child Mobile Routers, 1116 thus forming a hierarchy of Mobility Anchor Points. One can also 1117 view these Mobility Anchor Points as local Home Agents, thus 1118 forming a cascade of mobile Home Agents. In this way, each Mobile 1119 Router terminates its tunnel at its parent Mobile Router. Hence, 1120 although there are equal number of tunnels as the level of 1121 nesting, there is no tunnel encapsulated within another. 1123 Examples of this approach includes [22] and [23]. 1125 An advantage of this approach is that the functionalities of the 1126 Correspondent Nodes are unchanged. 1128 o Mobile Ad-Hoc Routing 1130 It is possible for nodes within a mobile network to use Mobile Ad- 1131 hoc routing for packets forwarding between nodes in the same 1132 mobile network. An approach of doing so might involve a router 1133 acting as a gateway for connecting nodes in the mobile network to 1134 the global Internet. All nodes in the mobile network would 1135 configure their care-of addresses from one or more prefixes 1136 advertised by that gateway, while their parent Mobile Routers use 1137 Mobile Ad-hoc routing to forward packets to that gateway or other 1138 destinations inside the mobile network. 1140 One advantage that is common to all the approaches listed above is 1141 that local mobility of a Mobile Network Node within a nested Mobile 1142 Network is hidden from the Correspondent Agent. 1144 5.6 How is Signaling Performed? 1146 In general, Route Optimization signaling can be done either in-plane, 1147 off-plane, or both. In-plane signaling involves embedding signaling 1148 information into headers of data packets. A good example of in-plane 1149 signaling would be Reverse Routing Header [10]. Off-plane signaling 1150 uses dedicated signaling packets rather than embedding signaling 1151 information into headers of data packets. Proposals involving the 1152 sending of Binding Updates fall into this category. 1154 The advantage of in-plane signaling is that any change in the mobile 1155 network topology can be rapidly propagated to the Correspondent Agent 1156 as long as there is a continuous stream of data to be transmitted. 1157 However, this might incur a substantial overhead on the data packets. 1158 Off-plane signaling, on the other hand, sends signaling messages 1159 independently from the data packet. This has the advantage of 1160 reducing the signaling overhead in situations where there are 1161 relatively less topological changes to the mobile network. However, 1162 data packets transmission maybe disrupted while off-plane signaling 1163 takes place. 1165 5.7 How is Data Transmitted? 1167 With Route Optimization established, one remaining question to be 1168 answered is how data packets can be routed to follow the optimized 1169 route. There are the following possible approaches: 1171 o Encapsulations 1173 One way to route packets through the optimized path is to use IP- 1174 in-IP encapsulations [24]. In this way, the original packet can 1175 be tunneled to the location bound to the identity of the Mobile 1176 Network Node using the normal routing infrastructure. Depending 1177 on how the location is bound to the identity, the number of 1178 encapsulations required might vary. 1180 For instance, if the Correspondent Agent knows the full sequence 1181 of points of attachment, it might be necessary for there to be 1182 multiple encapsulations in order to forward the data packet 1183 through each point of attachment. This may lead to the need for 1184 multiple tunnels and extra packet header overhead. It is possible 1185 to alleviate this by using Robust Header Compression techniques 1186 [25][26] to compress the multiple tunnel packet headers. 1188 o Routing Headers 1190 A second way to route packets through the optimized path is to use 1191 routing headers. This is useful especially for the case where the 1192 Correspondent Agent knows the sequence of locations of upstream 1193 Mobile Routers, (see Section 5.5.2), since a routing header can 1194 contain multiple intermediate destinations. Each intermediate 1195 destination corresponds to a point of attachment bound to the 1196 identity of the Mobile Network Node. 1198 This requires the use of a new Routing Header type, or possibly an 1199 extension of the Type 2 Routing Header as defined by Mobile IPv6 1200 to contain multiple addresses instead of only one. 1202 o Routing Entries in Parent Mobile Routers 1204 Yet another way is for parent Mobile Routers to install routing 1205 entries in their routing table that will route Route Optimized 1206 packets differently, most likely based on source address routing. 1207 This usually applies to approaches described in Section 5.5.3. 1208 For instance, the Prefix Delegation approach [18][19] would 1209 require parent Mobile Routers to route packets differently if the 1210 source address belongs to the prefix delegated from the access 1211 network. 1213 5.8 What are the Security Considerations? 1215 5.8.1 Security Considerations of Identity-Location Binding 1217 The most important security consideration in Route Optimization is 1218 certainly the security risks a Correspondent Agent is exposed to by 1219 creating a binding between the identity of a Mobile Network Node and 1220 the specified location(s) of the Mobile Network. Generally, it is 1221 assumed that Correspondent Agent and Mobile Network Node do not share 1222 any pre-existing security association. However, the Correspondent 1223 Agent must have some ways of verifying the authenticity of the 1224 binding specified, else it will be susceptible to various attacks 1225 described in [17], such as snooping (sending packets meant for a 1226 Mobile Network Node to an attacker) or denial-of-service (flooding a 1227 victim with packets meant for a Mobile Network Node) attacks. 1229 When the binding is performed between the identity of the Mobile 1230 Network Node and one care-of address (possibly of the Mobile Router, 1231 see Section 5.5.1 and Section 5.5.3), the standard Return Routability 1232 procedure specified in Mobile IPv6 might be sufficient to provide a 1233 reasonable degree of assurance to the Correspondent Agent. This also 1234 allows the Correspondent Agent to re-use existing implementations. 1235 But in other situations, an extension to the Return Routability 1236 procedure might be necessary. 1238 For instance, consider the case where the Mobile Router sends Binding 1239 Update containing Mobile Network Prefix information to Correspondent 1240 Agent (see Section 5.5.1). Although the Return Routability procedure 1241 allows the Correspondent Agent to verify that the care-of and home 1242 addresses of the Mobile Router are indeed collocated, it does not 1243 allow the Correspondent Agent to verify the validity of the Mobile 1244 Network Prefix. If the Correspondent Agent accepts the binding 1245 without verification, it will be exposed to attacks where the 1246 attacker tricks the Correspondent Agent into forwarding packets 1247 destined for a mobile network to the attacker (snooping) or victim 1248 (DoS). [27] discusses this security threat further. 1250 The need to verify the validity of network prefixes is not 1251 constrained to Correspondent Agents. In approaches that involve the 1252 Correspondent Routers (see Section 5.1.3), there have been 1253 suggestions for the Correspondent Router to advertise the network 1254 prefix(es) of Correspondent Nodes the Correspondent Router is capable 1255 of terminating Route Optimization on behalf of to Mobile Network 1256 Nodes. In such cases, the Mobile Network Nodes also need a mechanism 1257 to check the authenticity of such claims. Even if the Correspondent 1258 Routers do not advertise the network prefix, the Mobile Network Nodes 1259 also have the need to verify that the Correspondent Router is indeed 1260 a valid Correspondent Router for a given Correspondent Node. 1262 In Section 5.5.2, the signaling of Route Optimization involves 1263 sending the location of one or more upstream Mobile Routers. The 1264 Correspondent Agent must also have the means to verify such 1265 information. Again, the standard Return Routability procedure is 1266 inadequate here. An extension such as attaching a routing header to 1267 the Care-of Test (CoT) message to verify the authenticity of the 1268 locations of upstream Mobile Routers is likely to be needed. The 1269 risk, however, is not confined to the Correspondent Agents. The 1270 Mobile Network Nodes are also under the threat of receiving false 1271 information from their upstream Mobile Routers, which they might pass 1272 to the Correspondent Agents. There are some considerations that this 1273 kind of on-path threat exists in the current Internet anyway 1274 especially when no (or weak) end-to-end protection is used. 1276 All these concerns over the authenticity of addresses might suggest 1277 that perhaps a more radical and robust approach is necessary. This 1278 is currently under extensive study in various Working Groups of the 1279 IETF, and many related documents might be of interest here, such as 1280 Securing Neighbor Discovery (SEND) [28], the use of Cryptographically 1281 Generated Addresses (CGA) [29], various enhancements to the Route 1282 Optimization scheme of Mobile IPv6 [30][31], and possibly Host 1283 Identity Protocol (HIP) [32] with end-host mobility considerations 1284 [33]. 1286 5.8.2 End-to-End Integrity 1288 In some of the approaches, such as "Mobile Router as a Proxy" and 1289 "Mobile Router as a Transparent Proxy" in Section 5.5.1, the Mobile 1290 Router sends messages using the Mobile Network Node's address as the 1291 source address. This is done mainly to achieve zero new 1292 functionalities required at the Correspondent Agents and the Mobile 1293 Network Nodes. However, adopting such a strategy may interfere with 1294 existing or future protocols, most particularly security-related 1295 protocols. This is especially true for the "Mobile Router as a 1296 Transparent Proxy" approach, as it requires the Mobile Router to make 1297 changes to packets sent by Mobile Network Nodes. In a sense, these 1298 approaches break the end-to-end integrity of packets. 1300 The concern over end-to-end integrity arises for the use of Reverse 1301 Routing Header (see Section 5.5.2) too, since Mobile Routers would 1302 insert new contents to the header of packets sent by downstream 1303 Mobile Network Nodes. This makes it difficult for Mobile Network 1304 Nodes to protect the end-to-end integrity of such information with 1305 security associations. 1307 5.8.3 Location Privacy 1309 Another security related concern is the issue of location privacy. 1310 This draft currently does not consider the location privacy threats 1311 caused by an on path eavesdropper. For more information on that 1312 aspect, please refer to [16]. Instead, we consider the following 1313 three aspects to location privacy: 1315 o Revelation of Location to Correspondent Agent 1317 Route optimization is achieved by creating a binding between the 1318 identity of the Mobile Network Node and the current location of 1319 the Mobile Network. It is thus inevitable that the location of 1320 Mobile Network Node be revealed to the Correspondent Agent. The 1321 concern may be alleviated if the Correspondent Agent is not the 1322 Correspondent Node, since this implies that the actual traffic 1323 end-point (i.e. the Correspondent Node) would remain ignorant of 1324 the current location of the Mobile Network Node. 1326 o Degree of Revelation 1328 With network mobility, the degree of location exposure varies, 1329 especially when one considers nested mobile networks. For 1330 instance, for approaches that bind the identity of the Mobile 1331 Network Node to the location of the root Mobile Router (see 1332 Section 5.5.3), only the topmost point of attachment of the mobile 1333 network is revealed to the Correspondent Agent. Whereas for 1334 approaches such as those described in Section 5.5.1 and 1335 Section 5.5.2, more information (such as Mobile Network Prefixes 1336 and current locations of upstream Mobile Routers) is revealed. 1338 o Control of the Revelation 1340 When Route Optimization is initiated by the Mobile Network Node 1341 itself, it is in control of whether or not to sacrifice location 1342 privacy for an optimized route. However, if it is the Mobile 1343 Router that initiates Route Optimization (e.g. "Binding Update 1344 with Mobile Network Prefix" and "Mobile Router as a Proxy" in 1345 Section 5.5.1), then control is taken away from the Mobile Network 1346 Node. Additional signaling mechanism between the Mobile Network 1347 Node and its Mobile Router can be used in this case to prevent the 1348 Mobile Router from attempting Route Optimization for a given 1349 traffic stream. 1351 6. Conclusion 1353 The problem space of Route Optimization in the NEMO context is 1354 multifold and can be split into several work areas. It will be 1355 critical, though, that the solution to a given piece of the puzzle be 1356 compatible and integrated smoothly with others. With this in mind, 1357 this document attempts to present a detail and in depth analysis of 1358 the NEMO Route Optimization solution space by first describing the 1359 benefits a Route Optimization solution is expected to bring, then 1360 illustrating the different scenarios in which a Route Optimization 1361 solution applies to, and next presenting some issues a Route 1362 Optimization solution might face. We have also asked ourselves some 1363 of the basic questions about a Route Optimization solution. By 1364 investigating different possible answers to these questions, we have 1365 explored different aspects to a Route Optimization solution. The 1366 intent of this work is to enhance our common understanding of the 1367 Route Optimization problem and solution space. 1369 7. IANA Considerations 1371 This is an informational document and does not require any IANA 1372 action. 1374 8. Security Considerations 1376 This is an informational document that analyze the solution space of 1377 NEMO Route Optimization. Security considerations of different 1378 approaches are described in the relevant sections throughout this 1379 document. Particularly, please refer to Section 4.8 for a brief 1380 discussion of the security concern in with respect to Route 1381 Optimization in general, and Section 5.8 for a more detailed analysis 1382 of the various Route Optimization approaches. 1384 9. Acknowledgments 1386 The authors wish to thank the co-authors of previous drafts from 1387 which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki 1388 Ohnishi, Felix Wu, and Souhwan Jung. In addition, sincere 1389 appreciation is also extended to Thierry Ernst, Greg Daley, Erik 1390 Nordmark, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji 1391 Wakikawa and Patrick Wetterwald for their various contributions. 1393 10. References 1395 10.1 Normative References 1397 [1] Ng, C., "Network Mobility Route Optimization Problem Statement", 1398 draft-ietf-nemo-ro-problem-statement-00 (work in progress), 1399 July 2005. 1401 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1402 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1403 January 2005. 1405 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1406 IPv6", RFC 3775, June 2004. 1408 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 1409 RFC 3753, June 2004. 1411 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1412 draft-ietf-nemo-terminology-03 (work in progress), 1413 February 2005. 1415 [6] Ernst, T., "Network Mobility Support Goals and Requirements", 1416 draft-ietf-nemo-requirements-04 (work in progress), 1417 February 2005. 1419 10.2 Informative References 1421 [7] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", 1422 draft-wakikawa-nemo-orc-01 (work in progress), November 2004. 1424 [8] Na, J., "Route Optimization Scheme based on Path Control 1425 Header", draft-na-nemo-path-control-header-00 (work in 1426 progress), April 2004. 1428 [9] Bernardos, C., "Mobile IPv6 Route Optimisation for Network 1429 Mobility (MIRON)", draft-bernardos-nemo-miron-00 (work in 1430 progress), July 2005. 1432 [10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 1433 its application to Mobile Networks", 1434 draft-thubert-nemo-reverse-routing-header-05 (work in 1435 progress), June 2004. 1437 [11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization 1438 with Access Router Option", 1439 draft-ng-nemo-access-router-option-01 (work in progress), 1440 July 2004. 1442 [12] Na, J., "Secure Nested Tunnels Optimization using Nested Path 1443 Information", draft-na-nemo-nested-path-info-00 (work in 1444 progress), September 2003. 1446 [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 1447 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1448 RFC 4140, August 2005. 1450 [14] Thubert, P., "Global HA to HA protocol", 1451 draft-thubert-nemo-global-haha-00 (work in progress), 1452 October 2004. 1454 [15] Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6", 1455 draft-troan-dhcpv6-opt-prefix-delegation-01 (work in progress), 1456 May 2002. 1458 [16] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 1459 Problem Statement", draft-irtf-mobopts-location-privacy-ps-00 1460 (work in progress), July 2005. 1462 [17] Nikander, P., "Mobile IP version 6 Route Optimization Security 1463 Design Background", draft-ietf-mip6-ro-sec-03 (work in 1464 progress), May 2005. 1466 [18] Perera, E., "Extended Network Mobility Support", 1467 draft-perera-nemo-extended-00 (work in progress), July 2003. 1469 [19] Lee, K., "Route Optimization for Mobile Nodes in Mobile Network 1470 based on Prefix Delegation", draft-leekj-nemo-ro-pd-02 (work 1471 in progress), February 2004. 1473 [20] Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes 1474 in Mobile Network", draft-jeong-nemo-ro-ndproxy-02 (work in 1475 progress), February 2004. 1477 [21] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1478 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1480 [22] Kang, H., "Route Optimization for Mobile Network by Using Bi- 1481 directional Between Home Agent and Top Level Mobile Router", 1482 draft-hkang-nemo-ro-tlmr-00 (work in progress), June 2003. 1484 [23] Ohnishi, H., "HMIP based Route optimization method in a mobile 1485 network", draft-ohnishi-nemo-ro-hmip-00 (work in progress), 1486 October 2003. 1488 [24] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1489 Specification", RFC 2473, December 1998. 1491 [25] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1492 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 1493 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 1494 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 1495 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 1496 RFC 3095, July 2001. 1498 [26] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology 1499 and Channel Mapping Examples", RFC 3759, April 2004. 1501 [27] Ng, C., "Extending Return Routability Procedure for Network 1502 Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), 1503 October 2004. 1505 [28] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1506 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1508 [29] Aura, T., "Cryptographically Generated Addresses (CGA)", 1509 RFC 3972, March 2005. 1511 [30] Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements 1512 to Mobile IPv6 Route Optimization", 1513 draft-irtf-mobopts-ro-enhancements-01 (work in progress), 1514 July 2005. 1516 [31] Zhao, F., "Extensions to Return Routability Test in MIP6", 1517 draft-zhao-mip6-rr-ext-01 (work in progress), February 2005. 1519 [32] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 1520 (work in progress), June 2005. 1522 [33] Nikander, P., "End-Host Mobility and Multihoming with the Host 1523 Identity Protocol", draft-ietf-hip-mm-02 (work in progress), 1524 July 2005. 1526 Authors' Addresses 1528 Chan-Wah Ng 1529 Panasonic Singapore Laboratories Pte Ltd 1530 Blk 1022 Tai Seng Ave #06-3530 1531 Tai Seng Industrial Estate 1532 Singapore 534415 1533 SG 1535 Phone: +65 65505420 1536 Email: chanwah.ng@sg.panasonic.com 1537 Fan Zhao 1538 University of California Davis 1539 One Shields Avenue 1540 Davis, CA 95616 1541 US 1543 Phone: +1 530 752 3128 1544 Email: fanzhao@ucdavis.edu 1546 Masafumi Watari 1547 KDDI R&D Laboratories Inc. 1548 2-1-15 Ohara 1549 Kamifukuoka, Saitama 356-8502 1550 JAPAN 1552 Email: watari@kddilabs.jp 1554 Pascal Thubert 1555 Cisco Systems Technology Center 1556 Village d'Entreprises Green Side 1557 400, Avenue Roumanille 1558 Biot - Sophia Antipolis 06410 1559 FRANCE 1561 Email: pthubert@cisco.com 1563 Appendix A. Change Log 1565 o draft-ietf-nemo-ro-space-analysis-00: 1567 * Adapted from Sections 3, 4 & 5 of 1568 'draft-thubert-nemo-ro-taxonomy-04.txt' into: 1570 + Section 3 - "Different Scenarios of NEMO Route Optimization" 1572 + Section 4 - "Issues of NEMO Route Optimization" 1574 * Included various parts from 'draft-zhao-nemo-ro-ps-01.txt' 1576 * Re-vamped Section 5 - "Analysis of Solution Space" 1578 Intellectual Property Statement 1580 The IETF takes no position regarding the validity or scope of any 1581 Intellectual Property Rights or other rights that might be claimed to 1582 pertain to the implementation or use of the technology described in 1583 this document or the extent to which any license under such rights 1584 might or might not be available; nor does it represent that it has 1585 made any independent effort to identify any such rights. Information 1586 on the procedures with respect to rights in RFC documents can be 1587 found in BCP 78 and BCP 79. 1589 Copies of IPR disclosures made to the IETF Secretariat and any 1590 assurances of licenses to be made available, or the result of an 1591 attempt made to obtain a general license or permission for the use of 1592 such proprietary rights by implementers or users of this 1593 specification can be obtained from the IETF on-line IPR repository at 1594 http://www.ietf.org/ipr. 1596 The IETF invites any interested party to bring to its attention any 1597 copyrights, patents or patent applications, or other proprietary 1598 rights that may cover technology that may be required to implement 1599 this standard. Please address the information to the IETF at 1600 ietf-ipr@ietf.org. 1602 Disclaimer of Validity 1604 This document and the information contained herein are provided on an 1605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1607 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1608 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1609 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1612 Copyright Statement 1614 Copyright (C) The Internet Society (2005). This document is subject 1615 to the rights, licenses and restrictions contained in BCP 78, and 1616 except as set forth therein, the authors retain all their rights. 1618 Acknowledgment 1620 Funding for the RFC Editor function is currently provided by the 1621 Internet Society.