Internet Engineering Task Force X. Cui, Ed. Internet-Draft Huawei Technologies Intended status: Informational A. Makela, Ed. Expires: January 5, 2012 Aalto University, Department of Communications and Networking (Comnet) P. McCann, Ed. Huawei Technologies July 4, 2011 Proxy Correspondent Node Operation for Mobile IPv6 Route Optimization draft-cui-mext-route-optimization-cn-proxy-00 Abstract Route Optimization is an useful aspect of Mobile IPv6. In Route Optimization mode Mobile Node (MN) can communicate with Correspondent Node (CN) without the involvement of MN's home agent. However, there are some limitations to this feature, including that the Mobile Node and the Correspondent Node must both be capable of Route Optimization. This document introduces a Route Optimization Proxy function used for Route Optimization which can be used to enable Route Optimization between Mobile Node and arbitrary IP node - the Route Optimization functions are delegated to the Proxy. The Route Optimization Proxy function may be implemented in the access router attached to the CN or any other node present on the path between MN and CN, and the Route Optimization Proxy can conduct RO-related signaling and accomplish the Route Optimization procedure on behalf of the Correspondent Node. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2012. Cui, et al. Expires January 5, 2012 [Page 1] Internet-Draft Route Optimization Proxy July 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenario analysis and use case . . . . . . . . . . . . . . . . 4 3.1. Route Optimization Requirement from Other SDOs . . . . . . 4 3.2. Issues if the CN doesn't support Route Optimization . . . 5 3.3. Previous analysis of the problem and proposed solutions . 6 3.4. Use case for Route Optimization proxy . . . . . . . . . . 7 3.5. Additional motivation for Route Optimization Proxy . . . . 10 4. Concerns on different approaches for initiating Route Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Static Shared Key Authorization . . . . . . . . . . . . . 12 4.2. Enhanced Route Optimization . . . . . . . . . . . . . . . 12 5. Route Optimization Proxy operation . . . . . . . . . . . . . . 13 5.1. Requirements on Route Optimization Proxy . . . . . . . . . 13 5.2. Route Optimization Proxy operation . . . . . . . . . . . . 14 5.2.1. Incoming Flow Transmission . . . . . . . . . . . . . . 15 5.2.2. Outgoing Flow Transmission . . . . . . . . . . . . . . 17 5.2.3. Conceptual Data Structures . . . . . . . . . . . . . . 17 6. Configuration Variables . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Cui, et al. Expires January 5, 2012 [Page 2] Internet-Draft Route Optimization Proxy July 2011 1. Introduction Mobile IPv6 protocol [RFC3775] provides a mobility support to basic IPv6 and introduces Route Optimization (RO) mechanism. Route Optimization enables mobile node (MN) to establish a direct communications path between Mobile Node(MN) and correspondent node (CN) without the involvement of MN's home agent (HA). Route Optimization typically requires Mobile Node and Correspondent Node to have certain capabilities, such as possibility to conduct Return Routability procedure - MN transmitting Home Test Init (HoTI), Care-of Test Init (CoTI) and direct Binding Update messages to CN, and CN responding with respective Home Test (HoT), Care-of Test Init (CoT), and Binding Acknowledgement messages to MN. If the correspondent node is a basic IP node without support for Route Optimization, the MN with support for Route Optimization can't set up Route Optimization to this CN, as RFC 3775 [RFC3775] specifies "If a mobile node attempts to set up route optimization with a node with only basic IPv6 support, an ICMP error will signal that the node does not support such optimizations and communications will flow through the home agent". From the MN's viewpoint, the IPv6 nodes with support for MIP and IPv6 nodes without support for MIP are using the unified address space, so the MN can't distinguish whether a correspondent node is a RO-capable node or a non-RO-capable node. When the network is composed of mobile IPv6 nodes, IPv6 nodes with support for Route Optimization and enormous quantity of basic IPv6 nodes without Route Optimization support, a lot of Route Optimization attempts are made for naught as they are prone to fail. The result is that Route Optimization has a deployment problem because specific functionalities are required from CNs. However, if we can delegate that functionality to occur on network level (e.g. In an access router) it might be a help toward getting wider deployment for RO. For this purpose, this document introduces a mechanism for such delegation - a Route Optimization Proxy - , which can be used to obtain Route Optimization for IP nodes with only support for basic IPv6 protocol. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Cui, et al. Expires January 5, 2012 [Page 3] Internet-Draft Route Optimization Proxy July 2011 All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC3775]. This document also provides the following context-specific explanation to the following terms used in this document. Route Optimization Proxy (ROP) Route Optimization Proxy is the logical function that acts on behalf of the CN to achieve Route Optimization with MN. The Route Optimization Proxy entity MUST be present on the path on both directions between MN and CN. Proxy Binding Cache (PBC) The Proxy Binding Cache is the cache of for binding source nodes and destination nodes together and is maintained by the Route Optimization Proxy entity. The cache contains associations of Home Address of the source node, the Care-of Address(s) of the source(Mobile) node and the IP address of the destination (Correspondent) node. Note the Proxy Binding Cache can, if permitted, support Multiple Care-of Addresses Registration defined in [RFC5648], in a single Proxy Binding Cache entry. 3. Scenario analysis and use case 3.1. Route Optimization Requirement from Other SDOs Route Optimization is specified in RFC 3775 [RFC3775] and also adopted by other SDOs, such as 3GPP2, because Route Optimization can provide better performance and avoid bottleneck at the Home Agent. 3GPP2 has highlighted the requirements and feature description in 3GPP2 documents. Section 4.4 "MIP6" of [X.S0011-001-D] is about MIP6 protocol and Figures 13 and 16 in this section illustrate the protocol reference model for MIP6 Route Optimization mode. Section 5.3 "Home Agent Requirements" of [X.S0011-002-D] introduces the requirements of Home Agent on Route Optimization, as specified in section 5.3.6 "Return Routability Support for Route Optimization": "The Home Agent shall support Return Routability (RR) for Route Optimization as specified in RFC 3775 [RFC3775] with the exception that IPsec is not used to protect the RR messages". Section 6 "MIP6 Route Optimization" of [X.S0047-0] introduces the Cui, et al. Expires January 5, 2012 [Page 4] Internet-Draft Route Optimization Proxy July 2011 requirements of mobile node on Route Optimization, as specified in section 6.1 "MS Requirements", "The MS may support the return routability procedure, binding update procedure, and packet processing for the Mobile Node Operation and Correspondent Node Operation, according to RFC 3775 [RFC3775]". Based on these statement, MN and HA in a 3GPP2 network can support Route Optimization already, however, the Correspondent node would disregard the Route Optimization procedure just like a basic IP node. 3.2. Issues if the CN doesn't support Route Optimization If the correspondent node does not support Route Optimization, the correspondent node will reply an with an ICMP Parameter Problem, Code 1, message to the Mobile Node who attempted to initiate Route Optimization. The process is shown in Figure 1. MN HA Network AR CN | | | | | (a) ============= the CN is a node with basic IP ========== | | | | | | HoTI | | | | (b) |---------->| HoTI | | | (c) | |------------>| HoTI | | (d) | | |---------->| HoTI | (e) | | | |---------->| | | | | ICMP(err) | (f) | | | |<----------| | CoTI | | | (g) |------------------------>| CoTI | | (h) | | |---------->| CoTI | (I) | | | |---------->| | | | | ICMP(err) | (j) | | | |<----------| | ICMP(err) | | | | (k) |<----------| | | | | | | | | | | | | | Figure 1: Issue in Route Optimization The detailed descriptions of events in are as follows: Cui, et al. Expires January 5, 2012 [Page 5] Internet-Draft Route Optimization Proxy July 2011 (a) Scenario:The MN supports MIP6 and the CN supports only basic IPv6. (b-e) The MN initiates Route Optimization and sends Home Test Init message to the CN. The destination address of the packet is the address of the CN and the packet goes through the HA and the access router of the CN. (f) The CN does not recognize the Home Test Init message and replies an ICMP Parameter Problem, Code 1, message to the MN. (g-i) The MN sends Care-of Test Init message to CN. The destination address of the packet is the address of the CN and the packet goes through the access router of the CN. (j) The CN does not recognize the Care-of Test Init message and replies an ICMP Parameter Problem, Code 1, message to the MN. (k) The MN receives the ICMP error message sent by the CN, stops (aborts) Route Optimization establishment. In this example, because the CN does not support Route Optimization, the direct communication path fails. 3.3. Previous analysis of the problem and proposed solutions RFC 4889 [RFC4889] focuses on NEMO Route Optimization and provides many valuable analyses on this topic. The conclusions section (section 6) shows some consideration on the aspects of Route Optimization: the benefits that Route Optimization solution is expected to bring, the different scenarios in which a Route Optimization solution applies and issues a Route Optimization solution might face. Some scenarios are also included in Section 5. When RO is applied between Mobile Router and Correspondent Node, RFC 4889 [RFC4889] states, "However, new functionality is likely to be required on the Correspondent Node". Draft The draft-ohnishi-nemo-ro-hmip-00 [I-D.ohnishi-nemo-ro-hmip] introduces some scenarios and solutions about Route Optimization, as well. For example, Figure 11 in section 3 illustrates the Proxy CN case. In this case a Mobile Router takes the proxy role of the correspondent node. But the solution in this scenario is not introduced in detail and the solution also requires the correspondent node (here an MN but not an LFN) to support Routing Header and Home Cui, et al. Expires January 5, 2012 [Page 6] Internet-Draft Route Optimization Proxy July 2011 Address Options. This Route Optimization Proxy introduced in this documents provides a new approach for the similar scenario. In this solution there are no requirements or new functionality on the Correspondent Node and the proxy can manage all the mobility management functions for the Correspondent Node. 3.4. Use case for Route Optimization proxy The use case is related to 3GPP2 network. A mobile node in 3GPP2 network can attempt to set up Route Optimization with a Correspondent Node, but as mentioned before, Route Optimization might fail due to e.g. CN being basic IP node. As an approach to these issues, this document introduces Route Optimization Proxy functionality. The functionality allows a separate network entity to manage Route Optimization-related signaling on behalf of the CN, thus allowing for deployment of Route Optimization on a network level. Additional benefits consist of bringing higher QoE/QoS to both the initiating and responding user and reducing network resource costs. The applicable scenarios include CN's that are basic IPv6 nodes and Mobile Nodes that only support basic IPv6 protocol. The possible caveat is performance issues appearing on the entity running Route Optimization Proxy functionality. However, similar packet interception functionality is already present in several network entities, e.g. Home Agent, so performance loss should be acceptable for any router-like components. Furthermore, if required by e.g. Security and accounting policies the ROP may be used to conduct all Route Optimization-related functionalities, even if some or all of the possible CN's managed by the ROP are capable of Route Optimization. One use case example is show below in Figure 2. Cui, et al. Expires January 5, 2012 [Page 7] Internet-Draft Route Optimization Proxy July 2011 MN HA Network AR (ROP) CN | | | | | a ============= CN is a node with basic IP ============= | | | | | | HoTI | | | | b1 |---------->| HoTI | | | b2 | |------------>| HoTI | | b3 | | |---------->| HoTI | b4 | | | |---------->| | | | | ICMP(err) | d1 | | |<----------| | CoTI | | | c1 |------------------------>| CoTI | | c2 | | |---------->| | | | | HoT | | d2 | | HoT |<----------| | d3 | HoT |<------------| | | d4 |<----------| | | CoTI | c3 | | | |---------->| | | | | ICMP(err) | e1 | | | |<----------| | | | CoT | | e2 | CoT |<----------| | e3 |<------------------------| | | | | | | | | | | | BU | | | f1 |------------------------>| BU | | f2 | |---------->| | | |Binding Ack| | g1 | Binding Ack |<----------| | g2 |<------------------------| | | | Traffic data | | | -|------------------------>| Traffic | | / | |---------->| Traffic | / | | |---------->| h | | | | Traffic | \ | | Traffic |<----------| \ | Traffic data |<----------| | -|<------------------------| | | | | | | Figure 2: Route Optimization Proxy operations. The detailed descriptions are as follows: Cui, et al. Expires January 5, 2012 [Page 8] Internet-Draft Route Optimization Proxy July 2011 (a) The MN supports MIP6 and the CN supports only basic IPv6. (b1-b3) The MN initiates Route Optimization and sends Home Test Init message to the CN. The source address of this packet is the home address of the MN and the destination address of the packet is the address of the CN and the packet goes through MN's HA and reaches the CN's access router (AR). (b4) When the CN's AR, who is running Route Optimization Proxy function, receives the HoTI message, it recognizes the HoTI message, caches the message, starts a timer Timer(HoTI) for this transaction (identified by the address pair and MH Type value) and forwards the message to the CN. If the AR can't recognize this packet, or this packet is not a validated RO-related message, the AR MUST forward this packet as normal (i.e. without any additional operations). (c1-c2) The MN sends Care-of Test Init message to the CN. The source address of the packet is the care-of address of the MN and the destination address of the packet is the address of the CN and the packet reaches the CN's AR. (c3) When the CN's AR, who is running Route Optimization Proxy function, receives the CoTI message, it recognizes the CoTI message, caches the message, starts a timer Timer(CoTI) for this transaction (identified by the address pair and MH Type value) and forwards the CoTI message to the CN. If the AR can't recognize this packet, or this packet is not a RO-related message, the AR MUST forward this packet as normal (i.e. without any additional operation). (d1-d4) When the Route Optimization Proxy entity receives an ICMP Parameter Problem, Code 1, message from the correspondent node, it checks if there is a cached HoTI or CoTI message for this transaction (depending on the IP address pair and MH Type value), the AR will * Stops Timer (CoTI) or (HoTI) depending on the message the ICMP message was a response to * Discards the ICMP message * Waits for CoTI or HoTI message, if needed * Starts timer Timer(BU) if the ICMP error message is the response to HoTI and the timer Timer(BU) is not running Cui, et al. Expires January 5, 2012 [Page 9] Internet-Draft Route Optimization Proxy July 2011 * Generates a HoT message or a CoT message to the MN as the role of CN as specified in RFC 3775 [RFC3775]. (e1-e3) As described in d1-d4, if the ICMP error message is the response to CoTI message, no new timer is started. (f1-f2) The MN receives Home Test and Care-of Test message and sends Binding Update message to the address of the CN as specified in RFC 3775 [RFC3775]. The Binding Update message reaches the AR. (g1-g2) When the Route Optimization Proxy entity receives a Binding Update message (i.e. Correspondent registration request) from the mobile node, if there is a cache for this transaction (depending on the IP address set and Timer(BU)), it stops the running timer, establishes the Proxy Binding Update entity and responds a Binding Acknowledgement message to the MN as the role of CN as specified in RFC 3775 [RFC3775].. (h) Route Optimization is achieved and the Home Agent of the MN is not involved in the traffic data transport. For the traffic flow between the MN and the CN, the Route Optimization Proxy entity forwards all the traffic between the node pair, with some additional operation (specified in section 6.2) implemented. 3.5. Additional motivation for Route Optimization Proxy (Editor's Note: this section may be removed in the final version.) The motivation for this extension is based on some mechanisms that have been introduced in IETF. For example, Proxy ARP (Address Resolution Protocol) protocol, which is specified in[RFC1027], has been adopted by a number of routers and gateways. One basic Proxy ARP flow is as below: Cui, et al. Expires January 5, 2012 [Page 10] Internet-Draft Route Optimization Proxy July 2011 Host A Gateway Host B | e0 | e1 | | | | ------- Host A and Host B attached to the Gateway ------- | | | | ARP request (IP B) | | |------------------------->| | | | | | proxy ARP reply (IP B) | | |<-------------------------| | | | | | traffic data (IP B) | | |------------------------->| traffic data (IP B) | | |-------------------->| | | | | | | Proxy ARP message flow In this case, when host A wants to send IP packets to host B, if host A knows only the IP address of host B but doesn't know the MAC address of host B, host A need send out a ARP request message and broadcast the message in MAC layer. The gateway will receive this ARP request, whose destination IP address is the IP address of host B. The destination of this message is not the gateway, but the gateway knows that the destination (i.e. host B) is attached to itself and also knows the destination can't receive this ARP request, so in this situation, the gateway replies an ARP reply message for host B. In the proxy ARP reply message, the source IP address is the IP address of host B and the source MAC address is the MAC address of the e0 interface in the gateway. When host A receives this proxy ARP reply message, it can know how to send IP packets to host B. Host A will send IP packets to the gateway (i.e. the e0 interface) and the gateway will forward these packets to host B. Similar to this case, when the CN's access router receives some mobility-related signal messages (i.e. HoTI, CoTI and BU) destined to the correspondent node that is attached to its access link, it can also know that the corresponding node can't recognize these messages (by receiving ICMP Error message from the correspondent node). This judgment may depend on the policy profile of the corresponding node, the configuration variables of the access router, or other manners. Since the Route Optimization Proxy entity is the mobility proxy of the correspondent node and can manage the mobility-related signaling for the correspondent node, it is reasonable for the Route Optimization Proxy entity to dispose these messages on behalf of the Cui, et al. Expires January 5, 2012 [Page 11] Internet-Draft Route Optimization Proxy July 2011 correspondent node. 4. Concerns on different approaches for initiating Route Optimizations Besides the Return Routability procedure introduced in [RFC3775], a few additional methods for setting up RO have been published as RFCs. 4.1. Static Shared Key Authorization RFC 4449 [RFC4449] introduces another method to protect signaling related to the route optimization in Mobile IPv6. The static shared key authentication mechanism requires the configuration of a shared secret between Mobile Node and Correspondent Node. However, if the Correspondent Node doesn't support Route Optimization feature, this shared secret is meaningless. On the other hand, pre-shared keys might be even more manageable when there is a centralized node to configure rather than numerous CNs. Thus, Route Optimization Proxy may be used in this scenario and the shared secret is configured on the Route Optimization Proxy instead of the CN. A policy may be configured in the access router with the shared key. The policy may be used to decide when to trigger the Route Optimization Proxy function - the moment when the Route Optimization Proxy receives the BU message from the MN or the moment when the Route Optimization Proxy receives the ICMP Error message from the CN. When the Route Optimization Proxy decides to take over the role of CN Proxy after the CN responds ICMP Error, it MUST cache the BU message. The Route Optimization Proxy can be involved in the Route Optimization procedure on behalf of CN and acts as specified in this document and [RFC4449]. 4.2. Enhanced Route Optimization RFC 4866 [RFC4866] introduces an enhanced route optimization mechanism. If the mobile node initiates enhanced route optimization, the Route Optimization Proxy can act as a proxy for the following CN operations defined in RFC 4866 [RFC4866]: 1. Intercepting and receiving Binding Update messages as specified in section 4.2; 2. Sending Binding Acknowledgment Messages as specified in section 4.3; 3. Sending CGA Parameters as specified in section 4.; Cui, et al. Expires January 5, 2012 [Page 12] Internet-Draft Route Optimization Proxy July 2011 4. Intercepting and receiving CGA parameters as specified in section 4.6; 5. Sending Permanent Home Keygen Tokens as specified in section 4.7; 6. Credit Aging as specified in section 4.11. 5. Route Optimization Proxy operation 5.1. Requirements on Route Optimization Proxy The Route Optimization Proxy function introduced in this document depends on the operation of the network entity. The Home Test, the Care-of Test and the Binding Acknowledgement messages are essentially spoofed by the Route Optimization Proxy entity so that from the viewpoint of the Mobile Node they appear to be coming from the CN. The requirements of the Route Optimization Proxy function include following: R1 Route Optimization Proxy can monitor, intercept and recognize mobility-related signaling messages. When the Route Optimization Proxy receives mobility-related signaling destined to a CN that is attached to the monitored network, the Route Optimization Proxy can intercept the messages and temporarily cache them. When the Route Optimization Proxy receives (intended for forwarding) the corresponding ICMP Error message from the Correspondent Node, it can discard the ICMP Error message and send Return Routability response messages to the Mobile Node which initiated the Route Optimization. Since all the mobility-related signaling messages contain mobility header and MH Type field, the Route Optimization Proxy can fulfill this requirement with relative ease. R2 Route Optimization Proxy can conduct the operations of a CN for Return Routability and Route Optimization specified in RFC 3775 [RFC3775]. Route Optimization Proxy maintains a Proxy Binding Cache and inserts entries as necessary for this purpose. In addition, the ROP maintains additional caches for mobility signaling-related information. R3 Route Optimization Proxy can modify the outgoing packets and route the packets via optimized route depending on the created Proxy Binding Cache. The Route Optimization Proxy checks whether a Proxy Binding Cache entry exists and if yes (i.e., destination address is equal to the home address of the MN and Cui, et al. Expires January 5, 2012 [Page 13] Internet-Draft Route Optimization Proxy July 2011 source address is equal to the address of the CN), the Route Optimization Proxy modifies the destination address in the IP header and includes Type 2 Routing Header in the outgoing packets. The Route Optimization Proxy sets the destination address to the care-of address of the destined mobile node and sets the Home Address field in the Type 2 Routing Header to the home address of the destination mobile node. R4 Route Optimization Proxy can modify the source address of the incoming packets depending on the Proxy Binding Cache entries. The Route Optimization Proxy checks whether a Proxy Binding Cache entry exists and if yes (i.e., destination address is equal to the address of the CN and source address is equal to the care-of address of the MN), the Care-of Address in the source address of the packet is replaced by the home address of the remote mobile node and the Home Address Option contained in the packet is removed. R5 Route Optimization Proxy can dynamically disable the proxy functionality when it runs out of resources (e.g. capacity and PBU entry resource). When the proxy functionality is disabled, the proxy entity stops intercepting the packets and only forwards them as normal. R6 Route Optimization Proxy is topologically located in correct position in the network to execute previous functionalities. 5.2. Route Optimization Proxy operation The Route Optimization Proxy is a function that would typically runs on the access router for nodes with only basic IP. The Route Optimization Proxy forwards all the IP packets sent from or destined to the basic IP node that is attached to the network. However, some more operations are defined in this document for the expansion solution. The operations for Route Optimization Proxy consist of following: o Monitoring, intercepting and disposing of the mobility-related signaling destined to the attached IP nodes. o Creating, maintaining and deleting the Proxy Binding Cache entries for the IP node to which the initiator wants to establish or release a Route Optimization. o Destination Address replacement and Type 2 Routing Header insertion for the outgoing traffic from the attached IP node. Cui, et al. Expires January 5, 2012 [Page 14] Internet-Draft Route Optimization Proxy July 2011 o Source Address replacement and Home Address Option elimination for the incoming traffic destined to the attached IP node. o Security operation for the Return Routability Procedure and Route Optimization. The Route Optimization Proxy MUST works as specified in section 5.2 and section 15.4 of RFC 3775 [RFC3775]for the role of correspondent node. 5.2.1. Incoming Flow Transmission For an incoming packet (from the remote IP node (the Mobile Node) to the IP node that is attached to the Route Optimization Proxy), the Route Optimization Proxy needs to parse the IP header to check the packet type as soon as it receives the packet from the remote IP node. If no mobility header and no Home Address Option are included in the packet, the Route Optimization Proxy MUST forward the packet according to normal routing rules, without any modifications. If the IP packet received does not contain a mobility header but includes a Home Address Option, i.e. the IP packet is not mobility- related signaling, the Route Optimization Proxy needs to examine its Proxy Binding Cache for an entry for the 3-Tuple address set (the Home Address, the source address and the destination address of the IP packet). If a corresponding Proxy Binding Cache entry exists, it means Route Optimization has been established between the IP node pair. In this situation the Route Optimization Proxy replaces the source address (MN's CoA) of the packet with the Home Address of the Mobile Node, removes the Home Address Option and forwards the modified packet to the attached Correspondent Node. If no mobility header is contained in the packet and the Home Address Option is contained, but no Proxy Binding Cache entry exists, the Route Optimization Proxy MUST forward the packet according to normal routing rules, without any modifications. This implies that the RO has been established between the MN and CN directly (or that the packet has arrived due to error). If the IP packet received from other IP node contains a mobility header, the Route Optimization Proxy needs to further check the MH type field in the mobility header: If the received packet is Home Test Init Message, the Route Optimization Proxy MUST conduct one of the following options, depending of configuration and policy decisions: Cui, et al. Expires January 5, 2012 [Page 15] Internet-Draft Route Optimization Proxy July 2011 1. Caches the message, starts Timer(HoTI) for the message and forward the packet to the attached IP Node. When the Timer(HoTI) expires, the HoTI message is removed from the cache. 2. Immediately respond with a HoT message as described below and not forward the packet to the attached IP node. If the received packet is Home Test Init Message, the Route Optimization Proxy MUST conduct one of the following options, depending of configuration and policy decisions: 1. Caches the message, starts Timer(CoTI) for the message and forward the packet to the attached IP Node. When the Timer(CoTI) expires, the CoTI message is removed from the cache. 2. Immediately respond with a CoT message as described below and not forward the packet to the attached IP node. If the Route Optimization Proxy opted to forward the message to the Correspondent Node and receives a ICMP Error message from the CN node that the HoTI and CoTI messages are destined to, the Route Optimization Proxy pops the cached HoTI or CoTI message, stops the corresponding timer, and responds a HoT or a CoT message to the Mobile Node which originated the init-messages, and executes the operations as specified for the correspondent node role in section 9.4.1, 9.4.2, 9.4.3 and 9.4.4 of RFC 3775 [RFC3775]. When the Route Optimization Proxy transmits the HoT message, it starts the timer of Timer(BU) for the Mobile Node. If the received packet is a valid Binding Update message, the Route Optimization Proxy checks if a corresponding timer exists. If yes, the ROP stops the Timer(BU), does not forward the packet to the attached IP node and executes the operation as specified for the correspondent node role in section 9.5.1 and 9.5.4 of RFC 3775 [RFC3775]. The exception is that the Route Optimization Proxy creates or updates Proxy Binding Cache entity and includes the destination address of the BU message in the Proxy Binding Cache entry. If the ROP receives an ICMP Error message from a CN for which no cached HoTI or CoTI message exists, or a Binding Update message from a Mobile Node for which no timer exists, the ROP MUST forward the packet according to normal routing rules. Cui, et al. Expires January 5, 2012 [Page 16] Internet-Draft Route Optimization Proxy July 2011 5.2.2. Outgoing Flow Transmission For the outgoing (from the IP node that is attached to the Route Optimization Proxy to the remote IP (Mobile) node) flow, the Route Optimization Proxy needs to examine its Proxy Binding Cache for an entry for the address pair (i.e. the source address and the destination address of the IP packet) as soon as it receives packet from the attached IP node. If no corresponding Proxy Binding Cache entry exists, the Route Optimization Proxy MUST forward the packet without any modification according to normal routing rules. If a corresponding Proxy Binding Cache entry exists, it means Route Optimization has been established between the IP node pair. The Route Optimization Proxy can use a type 2 routing header to route the packet to the destination node by the way of its care-of address. The Route Optimization Proxy conducts following operations on the packet: o Inserts Type 2 routing header and sets the Home Address in the routing header to the remote Mobile Node's Home Address (the original destination address to which the packet was being sent). o Sets the Destination Address in the packet's header to the remote mobile node's Care-of Address according to the corresponding Proxy Binding Cache entry. Route Optimization Proxy MUST NOT conduct the operations in the following cases: o When forwarding an IPv6 Neighbor Discovery packet. o When forwarding the packets that are noted in Section 6.1 of RFC 3775 [RFC3775]. Note that the implementation creates some additional requirements for path MTU discovery since the modification changes the packet size. The Route Optimization Proxy should choose an appropriate way to indicate the attached IP node this situation. 5.2.3. Conceptual Data Structures This document introduces Proxy Binding Cache to the Route Optimization Proxy entity. When the Route Optimization Proxy receives the Binding Update message destined to the attached IP node the Route Optimization Proxy creates or updates the Proxy Binding Cui, et al. Expires January 5, 2012 [Page 17] Internet-Draft Route Optimization Proxy July 2011 Cache entry and includes the destination address of the Binding Update message in the Proxy Binding Cache entry. The newly introduced Proxy Binding Cache entry for this extension contains two additional fields than the Binding Cache entry data structure specified in section 9.1 of RFC 3775 [RFC3775]. The Proxy Binding Cache entry contains a flag indicating either this is an Proxy Binding Cache entry (Defined by this document) or a normal Binding Cache entry (Defined by RFC 3775 [RFC3775]). The Proxy Binding Cache entry contains a destination IP address, which is the true destination of the intercepted Binding Update message. Each Proxy Binding Cache entry is mapped with a 3-Tuple address set (i.e. HoA of MN, CoA of MN and IP address of CN). The incoming packet (from MN to CN) lookup key is the 3-Tuple address set (i.e. the source address, the destination address of the IP packet and the Home Address Option contained in the packet). For the incoming packet, if the HoA of MN, CoA of MN and CN address all matches, then the Proxy Binding Cache entry is found. The outgoing packet lookup key is the 2-Tuple address pair (i.e. the destination address and the source address of the IP packet). For the outgoing packet, if the HoA of MN and CN address pair matches, then the Proxy Binding Cache entry is found. Proxy Route Optimization may be applied between the IP node pair in these two cases. 6. Configuration Variables A configuration variable of EnableRouteOptimizationProxy is defined in this document for Route Optimization Proxy function. This variable is available in Route Optimization Proxy entity. When the value of this variable is 1, the Route Optimization Proxy function is enabled. When the value of this variable is 0, the Route Optimization Proxy function is disabled. The default value of EnableRouteOptimizationProxy is 0. Three Timer is defined in this document, Timer(HoTI), Timer(CoTI) and Timer(BU). Timer(HoTI) default value is 10 seconds. Timer(CoTI) default value is 10 seconds. Timer(BU) default value is 10 seconds. Cui, et al. Expires January 5, 2012 [Page 18] Internet-Draft Route Optimization Proxy July 2011 7. Security Considerations The extension in this document expands the scope of the mobility management to cover the reactive mobility management proxy function, such as the acceptance of Route Optimization, and the Route Optimization Proxy still follows the principle that providing network-based mobility management to the IP node that is attached to its access link. So this extension brings no new security issue to mobility management. But this extension requires the Route Optimization Proxy to implement packet inspection on the packets destined to the IP node, which would impact the performance of the proxy entity and maybe bring some security risk. By the time when this document is written, no explicit security problem has been found and the accurate security consideration needs to be further studied. Security concerns primarily consist of authorization; does an arbitrary ROC implicitly have permission of any CN to act as a proxy. 8. IANA Considerations This memo includes no requests to IANA. 9. Acknowledgements The authors would like to thank Jouni Korhonen, Hidetoshi Yokota, Sri Gundavelli, Qin Wu, Yungui Wang and Carlos J. Bernardos for their comments and discussion on this extension idea. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 10.2. Informative References [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, October 1987. Cui, et al. Expires January 5, 2012 [Page 19] Internet-Draft Route Optimization Proxy July 2011 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [I-D.ohnishi-nemo-ro-hmip] Ohnishi, H., "HMIP based Route optimization method in a mobile network", draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003. [X.S0011-001-D] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Introduction, X.S0011-001-D v2.0", 2008. [X.S0011-002-D] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services, X.S0011-002-D v2.0", 2008. [X.S0047-0] 3GPP2 TSG-X, "Mobile IPv6 Enhancements, X.S0047-0 v1.0", 2009. Authors' Addresses Xiangsong Cui (editor) Huawei Technologies Beijing, P.R. China Phone: Email: Xiangsong.Cui@huawei.com Cui, et al. Expires January 5, 2012 [Page 20] Internet-Draft Route Optimization Proxy July 2011 Antti Makela (editor) Aalto University, Department of Communications and Networking (Comnet) FIN-00076 Aalto P.O. BOX 13000 FINLAND Phone: Email: antti.makela@aalto.fi Pete McCann (editor) Huawei Technologies U.S.A. Phone: Email: Peter.McCann@huawei.com Cui, et al. Expires January 5, 2012 [Page 21]