idnits 2.17.1 draft-cui-mext-route-optimization-cn-proxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4672 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Cui, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational A. Makela 5 Expires: January 12, 2012 Aalto University, Department of 6 Communications and 7 Networking (Comnet) 8 P. McCann 9 Huawei Technologies 10 July 11, 2011 12 Proxy Correspondent Node Operation for Mobile IPv6 Route Optimization 13 draft-cui-mext-route-optimization-cn-proxy-01 15 Abstract 17 Route Optimization is a useful aspect of Mobile IPv6. In Route 18 Optimization mode a Mobile Node (MN) can communicate with a 19 Correspondent Node (CN) without the involvement of the MN's home 20 agent. However, there are some limitations to this feature, 21 including that the Mobile Node and the Correspondent Node must both 22 be capable of Route Optimization. This document introduces a Route 23 Optimization Proxy function that can be used to enable Route 24 Optimization between an MN and an arbitrary other IP CN - the Route 25 Optimization functions are delegated to the Proxy. The Route 26 Optimization Proxy function may be implemented in the access router 27 attached to the CN or any other node present on both the path from 28 the MN to the CN and from the HA to the CN, and the Route 29 Optimization Proxy can conduct RO-related signaling and accomplish 30 the Route Optimization procedure on behalf of the Correspondent Node. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 12, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Scenario analysis and use case . . . . . . . . . . . . . . . . 4 69 3.1. Route Optimization Requirement from Other SDOs . . . . . . 4 70 3.2. Issues if the CN doesn't support Route Optimization . . . 5 71 3.3. Previous analysis of the problem and proposed solutions . 6 72 3.4. Use case for Route Optimization proxy . . . . . . . . . . 7 73 3.5. Additional motivation for Route Optimization Proxy . . . . 10 74 4. Concerns on different approaches for initiating Route 75 Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. Static Shared Key Authorization . . . . . . . . . . . . . 12 77 4.2. Enhanced Route Optimization . . . . . . . . . . . . . . . 12 78 5. Route Optimization Proxy operation . . . . . . . . . . . . . . 13 79 5.1. Requirements on Route Optimization Proxy . . . . . . . . . 13 80 5.2. Route Optimization Proxy operation . . . . . . . . . . . . 14 81 5.2.1. Incoming Flow Transmission . . . . . . . . . . . . . . 15 82 5.2.2. Outgoing Flow Transmission . . . . . . . . . . . . . . 17 83 5.2.3. Conceptual Data Structures . . . . . . . . . . . . . . 17 84 6. Configuration Variables . . . . . . . . . . . . . . . . . . . 18 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Mobile IPv6 protocol [RFC3775] provides mobility support to basic 96 IPv6 and introduces the Route Optimization (RO) mechanism. Route 97 Optimization enables a mobile node (MN) to establish a direct 98 communications path between itself and a Correspondent Node (CN) 99 without the involvement of the MN's home agent (HA). 101 Route Optimization typically requires the MN and CN to have certain 102 capabilities, such as the ability to conduct the Return Routability 103 procedure. In this procedure, the MN transmits a Home Test Init 104 (HoTI) message, a Care-of Test Init (CoTI) message, and a direct 105 Binding Update message to the CN, and the CN responds with the 106 respective Home Test (HoT), Care-of Test Init (CoT), and Binding 107 Acknowledgement messages to the MN. 109 If the CN is a basic IP node without support for Route Optimization, 110 the MN with support for Route Optimization can't set up Route 111 Optimization to this CN, as RFC 3775 [RFC3775] specifies "If a mobile 112 node attempts to set up route optimization with a node with only 113 basic IPv6 support, an ICMP error will signal that the node does not 114 support such optimizations and communications will flow through the 115 home agent". 117 From the MN's viewpoint, the IPv6 nodes with support for MIP and IPv6 118 nodes without support for MIP are using the unified address space, so 119 the MN can't distinguish whether a correspondent node is a RO-capable 120 node or a non-RO-capable node. When the network is composed of 121 mobile IPv6 nodes, IPv6 nodes with support for Route Optimization, 122 and an enormous quantity of basic IPv6 nodes without Route 123 Optimization support, a lot of Route Optimization attempts are made 124 for naught as they are prone to fail. 126 The result is that Route Optimization has a deployment problem 127 because specific functionalities are required from CNs. However, if 128 we can delegate that functionality to occur on the network level 129 (e.g. in an access router) it might be a help toward getting wider 130 deployment for RO. For this purpose, this document introduces a 131 mechanism for such delegation - a Route Optimization Proxy - which 132 can be used to obtain Route Optimization for IP nodes with only 133 support for the basic IPv6 protocol. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 All the mobility related terms used in this document are to be 142 interpreted as defined in the Mobile IPv6 specification [RFC3775]. 144 This document also provides the following context-specific 145 explanation to the following terms used in this document. 147 Route Optimization Proxy (ROP) 149 Route Optimization Proxy is the logical function that acts 150 on behalf of the CN to achieve Route Optimization with MN. 151 The Route Optimization Proxy entity MUST be present on the 152 path in both directions between MN and CN, and MUST be 153 present on the path in both directions between the HA and 154 CN. 156 Proxy Binding Cache (PBC) 158 The Proxy Binding Cache is the cache for binding source 159 nodes and destination nodes together and is maintained by 160 the Route Optimization Proxy entity. The cache contains 161 associations that bind the Home Address of the MN, the 162 Care-of Address(es) of the MN, and the IP address of the 163 CN. Note the Proxy Binding Cache can, if permitted, 164 support Multiple Care-of Addresses Registration defined in 165 [RFC5648], in a single Proxy Binding Cache entry. 167 3. Scenario analysis and use case 169 3.1. Route Optimization Requirement from Other SDOs 171 Route Optimization is specified in RFC 3775 [RFC3775] and also 172 adopted by other SDOs, such as 3GPP2, because Route Optimization can 173 provide better performance and avoid bottlenecks at the Home Agent. 174 3GPP2 has highlighted the requirements and feature description in 175 3GPP2 documents. 177 Section 4.4 "MIP6" of [X.S0011-001-D] is about the MIP6 protocol and 178 Figures 13 and 16 in this section illustrate the protocol reference 179 model for MIP6 Route Optimization mode. 181 Section 5.3 "Home Agent Requirements" of [X.S0011-002-D] introduces 182 the requirements of Home Agent on Route Optimization, as specified in 183 section 5.3.6 "Return Routability Support for Route Optimization": 184 "The Home Agent shall support Return Routability (RR) for Route 185 Optimization as specified in RFC 3775 [RFC3775] with the exception 186 that IPsec is not used to protect the RR messages". 188 Section 6 "MIP6 Route Optimization" of [X.S0047-0] introduces the 189 requirements on MNs for Route Optimization, as specified in section 190 6.1 "MS Requirements", "The MS may support the return routability 191 procedure, binding update procedure, and packet processing for the 192 Mobile Node Operation and Correspondent Node Operation, according to 193 RFC 3775 [RFC3775]". 195 Based on these statements, MN and HA in a 3GPP2 network can support 196 Route Optimization already; however, the Correspondent node might not 197 implement Mobile IPv6 at all and would therefore not be capable of 198 participating in the route optimization process. 200 3.2. Issues if the CN doesn't support Route Optimization 202 If the correspondent node does not support Route Optimization, the 203 correspondent node will reply an with an ICMP Parameter Problem, Code 204 1 message to the Mobile Node who attempted to initiate Route 205 Optimization. The process is shown in Figure 1. 207 MN HA Network AR CN 208 | | | | | 209 (a) ============= the CN is a node with basic IP ========== 210 | | | | | 211 | HoTI | | | | 212 (b) |---------->| HoTI | | | 213 (c) | |------------>| HoTI | | 214 (d) | | |---------->| HoTI | 215 (e) | | | |---------->| 216 | | | | ICMP(err) | 217 (f) | | | |<----------| 218 | CoTI | | | 219 (g) |------------------------>| CoTI | | 220 (h) | | |---------->| CoTI | 221 (I) | | | |---------->| 222 | | | | ICMP(err) | 223 (j) | | | |<----------| 224 | ICMP(err) | | | | 225 (k) |<----------| | | | 226 | | | | | 227 | | | | | 229 Figure 1: Rejection of Route Optimization Messages by a CN 231 The detailed descriptions of events in are as follows: 233 (a) Scenario:The MN supports MIP6 and the CN supports only 234 basic IPv6. 236 (b-e) The MN initiates Route Optimization and sends a Home Test 237 Init message to the CN. The destination address of the 238 packet is the address of the CN and the packet goes through 239 the HA and the access router of the CN. 241 (f) The CN does not recognize the Home Test Init message and 242 replies with an ICMP Parameter Problem, Code 1 message to 243 the MN. 245 (g-i) The MN sends a Care-of Test Init message to the CN. The 246 destination address of the packet is the address of the CN 247 and the packet goes through the access router of the CN. 249 (j) The CN does not recognize the Care-of Test Init message and 250 replies with an ICMP Parameter Problem, Code 1 message to 251 the MN. 253 (k) The MN receives the ICMP error messages sent by the CN and 254 stops (aborts) Route Optimization establishment. 256 In this example, because the CN does not support Route Optimization, 257 the direct communication path fails. 259 3.3. Previous analysis of the problem and proposed solutions 261 RFC 4889 [RFC4889] focuses on NEMO Route Optimization and provides 262 many valuable analyses on this topic. The conclusions section 263 (section 6) shows some considerations on various aspects of Route 264 Optimization: the benefits that the Route Optimization solution is 265 expected to bring; the different scenarios in which a Route 266 Optimization solution applies; and, issues a Route Optimization 267 solution might face. 269 Some scenarios are also included in Section 5. When RO is applied 270 between a Mobile Router (MR) and CN, RFC 4889 [RFC4889] states, 271 "However, new functionality is likely to be required on the 272 Correspondent Node". 274 Draft draft-ohnishi-nemo-ro-hmip-00 [I-D.ohnishi-nemo-ro-hmip] 275 introduces some scenarios and solutions about Route Optimization as 276 well. For example, Figure 11 in section 3 illustrates the Proxy CN 277 case. In this case a Mobile Router takes the proxy role of the 278 correspondent node. But the solution in this scenario is not 279 introduced in detail and the solution also requires the correspondent 280 node (here an MN but not an LFN) to support Routing Header and Home 281 Address Options. 283 The Route Optimization Proxy introduced in this documents provides a 284 new approach for a similar scenario. In this solution there are no 285 requirements or new functionality on the CN and the proxy can manage 286 all the mobility management functions for the CN. 288 3.4. Use case for Route Optimization proxy 290 In this section we present a use case related to a 3GPP2 network. An 291 MN in a 3GPP2 network can attempt to set up Route Optimization with a 292 CN, but as mentioned before, Route Optimization might fail due to 293 e.g. CN being only a basic IP node. 295 As an approach to these issues, this document introduces Route 296 Optimization Proxy functionality. The functionality allows a 297 separate network entity to manage Route Optimization-related 298 signaling on behalf of the CN, thus allowing for deployment of Route 299 Optimization on a network level. Additional benefits consist of 300 bringing higher QoE/QoS to both the initiating and responding user 301 and reducing network resource costs. The applicable scenarios 302 include CN's that are basic IPv6 nodes and MN's that only support the 303 basic IPv6 protocol. The possible caveat is performance issues 304 appearing on the entity running Route Optimization Proxy 305 functionality. However, similar packet interception functionality is 306 already present in several network entities, e.g., the Home Agent, so 307 performance loss should be acceptable for any router-like component. 309 Furthermore, if required by e.g. security and accounting policies the 310 ROP may be used to conduct all Route Optimization-related 311 functionalities, even if some or all of the possible CN's managed by 312 the ROP are capable of Route Optimization. 314 One use case example is show below in Figure 2. 316 MN HA Network AR (ROP) CN 317 | | | | | 318 a ============= CN is a node with basic IP ============= 319 | | | | | 320 | HoTI | | | | 321 b1 |---------->| HoTI | | | 322 b2 | |------------>| HoTI | | 323 b3 | | |---------->| HoTI | 324 b4 | | | |---------->| 325 | | | | ICMP(err) | 326 d1 | | |<----------| 327 | CoTI | | | 328 c1 |------------------------>| CoTI | | 329 c2 | | |---------->| | 330 | | | HoT | | 331 d2 | | HoT |<----------| | 332 d3 | HoT |<------------| | | 333 d4 |<----------| | | CoTI | 334 c3 | | | |---------->| 335 | | | | ICMP(err) | 336 e1 | | | |<----------| 337 | | | CoT | | 338 e2 | CoT |<----------| | 339 e3 |<------------------------| | | 340 | | | | 341 | | | | 342 | BU | | | 343 f1 |------------------------>| BU | | 344 f2 | |---------->| | 345 | |Binding Ack| | 346 g1 | Binding Ack |<----------| | 347 g2 |<------------------------| | | 348 | Traffic data | | | 349 -|------------------------>| Traffic | | 350 / | |---------->| Traffic | 351 / | | |---------->| 352 h | | | | Traffic | 353 \ | | Traffic |<----------| 354 \ | Traffic data |<----------| | 355 -|<------------------------| | | 356 | | | | 358 Figure 2: Route Optimization Proxy operations. 360 The detailed descriptions are as follows: 362 (a) The MN supports MIP6 and the CN supports only basic IPv6. 364 (b1-b3) The MN initiates Route Optimization and sends a Home Test 365 Init message to the CN. The source address of this packet 366 is the home address of the MN and the destination address 367 of the packet is the address of the CN and the packet goes 368 through the MN's HA and reaches the CN's access router 369 (AR). 371 (b4) When the CN's AR, which is running the Route Optimization 372 Proxy function, receives the HoTI message, it recognizes 373 the HoTI message, caches the message, starts a timer 374 Timer(HoTI) for this transaction (identified by the address 375 pair and MH Type value) and forwards the message to the CN. 376 If the AR can't recognize this packet, or this packet is 377 not a validated RO-related message, the AR MUST forward 378 this packet as normal (i.e. without any additional 379 operations). 381 (c1-c2) The MN sends Care-of Test Init message to the CN. The 382 source address of the packet is the care-of address of the 383 MN and the destination address of the packet is the address 384 of the CN and the packet reaches the CN's AR. 386 (c3) When the CN's AR, who is running the Route Optimization 387 Proxy function, receives the CoTI message, it recognizes 388 the CoTI message, caches the message, starts a timer 389 Timer(CoTI) for this transaction (identified by the address 390 pair and MH Type value) and forwards the CoTI message to 391 the CN. If the AR can't recognize this packet, or this 392 packet is not an RO-related message, the AR MUST forward 393 this packet as normal (i.e. without any additional 394 operation). 396 (d1-d4) When the Route Optimization Proxy entity receives an ICMP 397 Parameter Problem, Code 1 message from the correspondent 398 node, it checks if there is a cached HoTI or CoTI message 399 for this transaction (depending on the IP address pair and 400 MH Type value), and if so the AR will 402 * Stop Timer (CoTI) or (HoTI) depending on the 403 message the ICMP message was a response to 405 * Discards the ICMP message 407 * Generates a HoT message or a CoT message to the 408 MN as the role of CN as specified in RFC 3775 409 [RFC3775]. 411 * If both HoT and CoT have been transmitted for the 412 same MN/CN pair, starts timer Timer(BU) if the 413 timer Timer(BU) is not running 415 (e1-e3) See (d1-d4). 417 (f1-f2) The MN receives Home Test and Care-of Test message and 418 sends Binding Update message to the address of the CN as 419 specified in RFC 3775 [RFC3775]. The Binding Update 420 message reaches the AR. 422 (g1-g2) When the Route Optimization Proxy entity receives a Binding 423 Update message (i.e. Correspondent registration request) 424 from the mobile node, if there is a cache for this 425 transaction (depending on the IP address set and 426 Timer(BU)), it stops the running timer, establishes the 427 Proxy Binding Update entity and responds with a Binding 428 Acknowledgement message to the MN playing the role of CN as 429 specified in RFC 3775 [RFC3775].. 431 (h) Route Optimization is achieved and the Home Agent of the MN 432 is not involved in the traffic data transport. For the 433 traffic flow between the MN and the CN, the Route 434 Optimization Proxy entity forwards all the traffic between 435 the node pair, with some additional operations (specified 436 in Section 5.2) implemented. 438 3.5. Additional motivation for Route Optimization Proxy 440 (Editor's Note: this section may be removed in the final version.) 442 The motivation for this extension is based on some mechanisms that 443 have been introduced in IETF. For example, Proxy ARP (Address 444 Resolution Protocol) protocol, which is specified in[RFC1027], has 445 been adopted by a number of routers and gateways. 447 One basic Proxy ARP flow is as below: 449 Host A Gateway Host B 450 | e0 | e1 | 451 | | | 452 ------- Host A and Host B attached to the Gateway ------- 453 | | | 454 | ARP request (IP B) | | 455 |------------------------->| | 456 | | | 457 | proxy ARP reply (IP B) | | 458 |<-------------------------| | 459 | | | 460 | traffic data (IP B) | | 461 |------------------------->| traffic data (IP B) | 462 | |-------------------->| 463 | | | 464 | | | 466 Proxy ARP message flow 468 In this case, when host A wants to send IP packets to host B, if host 469 A knows only the IP address of host B but doesn't know the MAC 470 address of host B, host A need send out a ARP request message and 471 broadcast the message in MAC layer. The gateway will receive this 472 ARP request, whose destination IP address is the IP address of host 473 B. The destination of this message is not the gateway, but the 474 gateway knows that the destination (i.e. host B) is attached to 475 itself and also knows the destination can't receive this ARP request, 476 so in this situation, the gateway replies an ARP reply message for 477 host B. In the proxy ARP reply message, the source IP address is the 478 IP address of host B and the source MAC address is the MAC address of 479 the e0 interface in the gateway. When host A receives this proxy ARP 480 reply message, it can know how to send IP packets to host B. Host A 481 will send IP packets to the gateway (i.e. the e0 interface) and the 482 gateway will forward these packets to host B. 484 Similar to this case, when the CN's access router receives some 485 mobility-related signal messages (i.e. HoTI, CoTI and BU) destined 486 to the correspondent node that is attached to its access link, it can 487 also know that the corresponding node can't recognize these messages 488 (by receiving ICMP Error message from the correspondent node). This 489 judgment may depend on the policy profile of the corresponding node, 490 the configuration variables of the access router, or other manners. 491 Since the Route Optimization Proxy entity is the mobility proxy of 492 the correspondent node and can manage the mobility-related signaling 493 for the correspondent node, it is reasonable for the Route 494 Optimization Proxy entity to dispose these messages on behalf of the 495 correspondent node. 497 4. Concerns on different approaches for initiating Route Optimizations 499 Besides the Return Routability procedure introduced in [RFC3775], a 500 few additional methods for setting up RO have been published as RFCs. 502 4.1. Static Shared Key Authorization 504 RFC 4449 [RFC4449] introduces another method to protect signaling 505 related to the route optimization in Mobile IPv6. The static shared 506 key authentication mechanism requires the configuration of a shared 507 secret between Mobile Node and Correspondent Node. However, if the 508 Correspondent Node doesn't support Route Optimization feature, this 509 shared secret is meaningless. On the other hand, pre-shared keys 510 might be even more manageable when there is a centralized node to 511 configure rather than numerous CNs. Thus, Route Optimization Proxy 512 may be used in this scenario and the shared secret is configured on 513 the Route Optimization Proxy instead of the CN. 515 A policy may be configured in the access router with the shared key. 516 The policy may be used to decide when to trigger the Route 517 Optimization Proxy function - the moment when the Route Optimization 518 Proxy receives the BU message from the MN or the moment when the 519 Route Optimization Proxy receives the ICMP Error message from the CN. 520 When the Route Optimization Proxy decides to take over the role of CN 521 Proxy after the CN responds ICMP Error, it MUST cache the BU message. 522 The Route Optimization Proxy can be involved in the Route 523 Optimization procedure on behalf of CN and acts as specified in this 524 document and [RFC4449]. 526 4.2. Enhanced Route Optimization 528 RFC 4866 [RFC4866] introduces an enhanced route optimization 529 mechanism. If the mobile node initiates enhanced route optimization, 530 the Route Optimization Proxy can act as a proxy for the following CN 531 operations defined in RFC 4866 [RFC4866]: 533 1. Intercepting and receiving Binding Update messages as 534 specified in section 4.2; 536 2. Sending Binding Acknowledgment Messages as specified in 537 section 4.3; 539 3. Sending CGA Parameters as specified in section 4.; 540 4. Intercepting and receiving CGA parameters as specified in 541 section 4.6; 543 5. Sending Permanent Home Keygen Tokens as specified in 544 section 4.7; 546 6. Credit Aging as specified in section 4.11. 548 5. Route Optimization Proxy operation 550 5.1. Requirements on Route Optimization Proxy 552 The Route Optimization Proxy function introduced in this document 553 depends on the operation of the network entity. The Home Test, the 554 Care-of Test and the Binding Acknowledgement messages are essentially 555 spoofed by the Route Optimization Proxy entity so that from the 556 viewpoint of the Mobile Node they appear to be coming from the CN. 558 The requirements of the Route Optimization Proxy function include 559 following: 561 R1 Route Optimization Proxy can monitor, intercept and recognize 562 mobility-related signaling messages. When the Route 563 Optimization Proxy receives mobility-related signaling destined 564 to a CN that is attached to the monitored network, the Route 565 Optimization Proxy can intercept the messages and temporarily 566 cache them. When the Route Optimization Proxy receives 567 (intended for forwarding) the corresponding ICMP Error message 568 from the Correspondent Node, it can discard the ICMP Error 569 message and send Return Routability response messages to the 570 Mobile Node which initiated the Route Optimization. Since all 571 the mobility-related signaling messages contain mobility header 572 and MH Type field, the Route Optimization Proxy can fulfill this 573 requirement with relative ease. 575 R2 Route Optimization Proxy can conduct the operations of a CN for 576 Return Routability and Route Optimization specified in RFC 3775 577 [RFC3775]. Route Optimization Proxy maintains a Proxy Binding 578 Cache and inserts entries as necessary for this purpose. In 579 addition, the ROP maintains additional caches for mobility 580 signaling-related information. 582 R3 Route Optimization Proxy can modify the outgoing packets and 583 route the packets via optimized route depending on the created 584 Proxy Binding Cache. The Route Optimization Proxy checks 585 whether a Proxy Binding Cache entry exists and if yes (i.e., 586 destination address is equal to the home address of the MN and 587 source address is equal to the address of the CN), the Route 588 Optimization Proxy modifies the destination address in the IP 589 header and includes Type 2 Routing Header in the outgoing 590 packets. The Route Optimization Proxy sets the destination 591 address to the care-of address of the destined mobile node and 592 sets the Home Address field in the Type 2 Routing Header to the 593 home address of the destination mobile node. 595 R4 Route Optimization Proxy can modify the source address of the 596 incoming packets depending on the Proxy Binding Cache entries. 597 The Route Optimization Proxy checks whether a Proxy Binding 598 Cache entry exists and if yes (i.e., destination address is 599 equal to the address of the CN and source address is equal to 600 the care-of address of the MN), the Care-of Address in the 601 source address of the packet is replaced by the home address of 602 the remote mobile node and the Home Address Option contained in 603 the packet is removed. 605 R5 Route Optimization Proxy can dynamically disable the proxy 606 functionality when it runs out of resources (e.g. capacity and 607 PBU entry resource). When the proxy functionality is disabled, 608 the proxy entity stops intercepting the packets and only 609 forwards them as normal. 611 R6 Route Optimization Proxy is topologically located in correct 612 position in the network to execute previous functionalities. 614 5.2. Route Optimization Proxy operation 616 The Route Optimization Proxy is a function that would typically runs 617 on the access router for nodes with only basic IP. The Route 618 Optimization Proxy forwards all the IP packets sent from or destined 619 to the basic IP node that is attached to the network. However, some 620 more operations are defined in this document for the expansion 621 solution. 623 The operations for Route Optimization Proxy consist of following: 625 o Monitoring, intercepting and disposing of the mobility-related 626 signaling destined to the attached IP nodes. 628 o Creating, maintaining and deleting the Proxy Binding Cache entries 629 for the IP node to which the initiator wants to establish or 630 release a Route Optimization. 632 o Destination Address replacement and Type 2 Routing Header 633 insertion for the outgoing traffic from the attached IP node. 635 o Source Address replacement and Home Address Option elimination for 636 the incoming traffic destined to the attached IP node. 638 o Security operation for the Return Routability Procedure and Route 639 Optimization. The Route Optimization Proxy MUST works as 640 specified in section 5.2 and section 15.4 of RFC 3775 [RFC3775]for 641 the role of correspondent node. 643 5.2.1. Incoming Flow Transmission 645 For an incoming packet (from the remote IP node (the Mobile Node) to 646 the IP node that is attached to the Route Optimization Proxy), the 647 Route Optimization Proxy needs to parse the IP header to check the 648 packet type as soon as it receives the packet from the remote IP 649 node. 651 If no mobility header and no Home Address Option are included in the 652 packet, the Route Optimization Proxy MUST forward the packet 653 according to normal routing rules, without any modifications. 655 If the IP packet received does not contain a mobility header but 656 includes a Home Address Option, i.e. the IP packet is not mobility- 657 related signaling, the Route Optimization Proxy needs to examine its 658 Proxy Binding Cache for an entry for the 3-Tuple address set (the 659 Home Address, the source address and the destination address of the 660 IP packet). 662 If a corresponding Proxy Binding Cache entry exists, it means Route 663 Optimization has been established between the IP node pair. In this 664 situation the Route Optimization Proxy replaces the source address 665 (MN's CoA) of the packet with the Home Address of the Mobile Node, 666 removes the Home Address Option and forwards the modified packet to 667 the attached Correspondent Node. 669 If no mobility header is contained in the packet and the Home Address 670 Option is contained, but no Proxy Binding Cache entry exists, the 671 Route Optimization Proxy MUST forward the packet according to normal 672 routing rules, without any modifications. This implies that the RO 673 has been established between the MN and CN directly (or that the 674 packet has arrived due to error). 676 If the IP packet received from other IP node contains a mobility 677 header, the Route Optimization Proxy needs to further check the MH 678 type field in the mobility header: 680 If the received packet is Home Test Init Message, the Route 681 Optimization Proxy MUST conduct one of the following options, 682 depending of configuration and policy decisions: 684 1. Caches the message, starts Timer(HoTI) for the message and 685 forward the packet to the attached IP Node. When the Timer(HoTI) 686 expires, the HoTI message is removed from the cache. 688 2. Immediately respond with a HoT message as described below and not 689 forward the packet to the attached IP node. 691 If the received packet is Home Test Init Message, the Route 692 Optimization Proxy MUST conduct one of the following options, 693 depending of configuration and policy decisions: 695 1. Caches the message, starts Timer(CoTI) for the message and 696 forward the packet to the attached IP Node. When the Timer(CoTI) 697 expires, the CoTI message is removed from the cache. 699 2. Immediately respond with a CoT message as described below and not 700 forward the packet to the attached IP node. 702 If the Route Optimization Proxy opted to forward the message to the 703 Correspondent Node and receives a ICMP Error message from the CN node 704 that the HoTI and CoTI messages are destined to, the Route 705 Optimization Proxy pops the cached HoTI or CoTI message, stops the 706 corresponding timer, and responds a HoT or a CoT message to the 707 Mobile Node which originated the init-messages, and executes the 708 operations as specified for the correspondent node role in section 709 9.4.1, 9.4.2, 9.4.3 and 9.4.4 of RFC 3775 [RFC3775]. 711 When the Route Optimization Proxy transmits the HoT message, it 712 starts the timer of Timer(BU) for the Mobile Node. 714 If the received packet is a valid Binding Update message, the Route 715 Optimization Proxy checks if a corresponding timer exists. If yes, 716 the ROP stops the Timer(BU), does not forward the packet to the 717 attached IP node and executes the operation as specified for the 718 correspondent node role in section 9.5.1 and 9.5.4 of RFC 3775 719 [RFC3775]. The exception is that the Route Optimization Proxy 720 creates or updates Proxy Binding Cache entity and includes the 721 destination address of the BU message in the Proxy Binding Cache 722 entry. 724 If the ROP receives an ICMP Error message from a CN for which no 725 cached HoTI or CoTI message exists, or a Binding Update message from 726 a Mobile Node for which no timer exists, the ROP MUST forward the 727 packet according to normal routing rules. 729 5.2.2. Outgoing Flow Transmission 731 For the outgoing (from the IP node that is attached to the Route 732 Optimization Proxy to the remote IP (Mobile) node) flow, the Route 733 Optimization Proxy needs to examine its Proxy Binding Cache for an 734 entry for the address pair (i.e. the source address and the 735 destination address of the IP packet) as soon as it receives packet 736 from the attached IP node. 738 If no corresponding Proxy Binding Cache entry exists, the Route 739 Optimization Proxy MUST forward the packet without any modification 740 according to normal routing rules. 742 If a corresponding Proxy Binding Cache entry exists, it means Route 743 Optimization has been established between the IP node pair. The 744 Route Optimization Proxy can use a type 2 routing header to route the 745 packet to the destination node by the way of its care-of address. 747 The Route Optimization Proxy conducts following operations on the 748 packet: 750 o Inserts Type 2 routing header and sets the Home Address in the 751 routing header to the remote Mobile Node's Home Address (the 752 original destination address to which the packet was being sent). 754 o Sets the Destination Address in the packet's header to the remote 755 mobile node's Care-of Address according to the corresponding Proxy 756 Binding Cache entry. 758 Route Optimization Proxy MUST NOT conduct the operations in the 759 following cases: 761 o When forwarding an IPv6 Neighbor Discovery packet. 763 o When forwarding the packets that are noted in Section 6.1 of RFC 764 3775 [RFC3775]. 766 Note that the implementation creates some additional requirements for 767 path MTU discovery since the modification changes the packet size. 768 The Route Optimization Proxy should choose an appropriate way to 769 indicate the attached IP node this situation. 771 5.2.3. Conceptual Data Structures 773 This document introduces Proxy Binding Cache to the Route 774 Optimization Proxy entity. When the Route Optimization Proxy 775 receives the Binding Update message destined to the attached IP node 776 the Route Optimization Proxy creates or updates the Proxy Binding 777 Cache entry and includes the destination address of the Binding 778 Update message in the Proxy Binding Cache entry. 780 The newly introduced Proxy Binding Cache entry for this extension 781 contains two additional fields than the Binding Cache entry data 782 structure specified in section 9.1 of RFC 3775 [RFC3775]. 784 The Proxy Binding Cache entry contains a flag indicating either this 785 is an Proxy Binding Cache entry (Defined by this document) or a 786 normal Binding Cache entry (Defined by RFC 3775 [RFC3775]). 788 The Proxy Binding Cache entry contains a destination IP address, 789 which is the true destination of the intercepted Binding Update 790 message. 792 Each Proxy Binding Cache entry is mapped with a 3-Tuple address set 793 (i.e. HoA of MN, CoA of MN and IP address of CN). The incoming 794 packet (from MN to CN) lookup key is the 3-Tuple address set (i.e. 795 the source address, the destination address of the IP packet and the 796 Home Address Option contained in the packet). For the incoming 797 packet, if the HoA of MN, CoA of MN and CN address all matches, then 798 the Proxy Binding Cache entry is found. The outgoing packet lookup 799 key is the 2-Tuple address pair (i.e. the destination address and the 800 source address of the IP packet). For the outgoing packet, if the 801 HoA of MN and CN address pair matches, then the Proxy Binding Cache 802 entry is found. Proxy Route Optimization may be applied between the 803 IP node pair in these two cases. 805 6. Configuration Variables 807 A configuration variable of EnableRouteOptimizationProxy is defined 808 in this document for Route Optimization Proxy function. 810 This variable is available in Route Optimization Proxy entity. When 811 the value of this variable is 1, the Route Optimization Proxy 812 function is enabled. When the value of this variable is 0, the Route 813 Optimization Proxy function is disabled. 815 The default value of EnableRouteOptimizationProxy is 0. 817 Three Timer is defined in this document, Timer(HoTI), Timer(CoTI) and 818 Timer(BU). 820 Timer(HoTI) default value is 10 seconds. 821 Timer(CoTI) default value is 10 seconds. 822 Timer(BU) default value is 10 seconds. 824 7. Security Considerations 826 The extension in this document expands the scope of the mobility 827 management to cover the reactive mobility management proxy function, 828 such as the acceptance of Route Optimization, and the Route 829 Optimization Proxy still follows the principle that providing 830 network-based mobility management to the IP node that is attached to 831 its access link. So this extension brings no new security issue to 832 mobility management. 834 But this extension requires the Route Optimization Proxy to implement 835 packet inspection on the packets destined to the IP node, which would 836 impact the performance of the proxy entity and maybe bring some 837 security risk. By the time when this document is written, no 838 explicit security problem has been found and the accurate security 839 consideration needs to be further studied. 841 Security concerns primarily consist of authorization; does an 842 arbitrary ROC implicitly have permission of any CN to act as a proxy. 844 8. IANA Considerations 846 This memo includes no requests to IANA. 848 9. Acknowledgements 850 The authors would like to thank Jouni Korhonen, Hidetoshi Yokota, Sri 851 Gundavelli, Qin Wu, Yungui Wang and Carlos J. Bernardos for their 852 comments and discussion on this extension idea. 854 10. References 856 10.1. Normative References 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, March 1997. 861 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 862 in IPv6", RFC 3775, June 2004. 864 10.2. Informative References 866 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 867 implement transparent subnet gateways", RFC 1027, 868 October 1987. 870 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 871 Using a Static Shared Key", RFC 4449, June 2006. 873 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 874 Optimization for Mobile IPv6", RFC 4866, May 2007. 876 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 877 Mobility Route Optimization Solution Space Analysis", 878 RFC 4889, July 2007. 880 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 881 and K. Nagami, "Multiple Care-of Addresses Registration", 882 RFC 5648, October 2009. 884 [I-D.ohnishi-nemo-ro-hmip] 885 Ohnishi, H., "HMIP based Route optimization method in a 886 mobile network", draft-ohnishi-nemo-ro-hmip-00 (work in 887 progress), October 2003. 889 [X.S0011-001-D] 890 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: 891 Introduction, X.S0011-001-D v2.0", 2008. 893 [X.S0011-002-D] 894 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: 895 Simple IP and Mobile IP Access Services, X.S0011-002-D 896 v2.0", 2008. 898 [X.S0047-0] 899 3GPP2 TSG-X, "Mobile IPv6 Enhancements, X.S0047-0 v1.0", 900 2009. 902 Authors' Addresses 904 Xiangsong Cui (editor) 905 Huawei Technologies 906 Beijing, 907 P.R. China 909 Phone: 910 Email: Xiangsong.Cui@huawei.com 911 Antti Makela 912 Aalto University, Department of Communications and Networking (Comnet) 913 FIN-00076 Aalto 914 P.O. BOX 13000 915 FINLAND 917 Phone: 918 Email: antti.makela@aalto.fi 920 Pete McCann 921 Huawei Technologies 922 400 Crossings Blvd. (2nd floor) 923 Bridgewater, NJ 08807-2863 924 U.S.A. 926 Phone: +1 908 541 3563 927 Email: Peter.McCann@huawei.com