Netext Working Group X. Cui Internet Draft Huawei Intended status: Informational October 16, 2009 Expires: April 2010 Reflector Extension for Route Optimization Agent draft-cui-netext-route-optimization-agent-ext-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 15 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cui Expires April 15, 2010 [Page 1] Internet-Draft Route Optimization Agent Extension October 2009 Abstract Route Optimization is a very useful feature in Mobile IPv6. Mobile node can communicate with correspondent node without the involvement of the home agent by Route Optimization. But there are some limitations to this feature. One problem is that the mobile node and the correspondent node must be capable for Route Optimization. This document introduces an extension mechanism used for Route Optimization and this extension mechanism can enable Route Optimization be used between mobile node and simple IP node. In the extension solution, the MAG can reflect the RO-related signal messages and fulfill the Route Optimization procedure on behalf of the simple IP node. Conventions used in this document 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 [RFC2119]. Cui Expires April 15, 2010 [Page 2] Internet-Draft Route Optimization Agent Extension October 2009 Table of Contents 1. Introduction....................................................4 2. Terminology.....................................................4 3. Scenario Analysis and Use Case..................................5 3.1. Issues if the CN can't support Route Optimization..........5 3.2. Motivation.................................................7 3.3. Requirement................................................9 3.4. Use Case for Agent Extension to Fulfill Route Optimization.9 4. Solution and Operation Consideration...........................12 4.1. MAG Operation.............................................12 4.1.1. Incoming Flow Transmission...........................13 4.1.2. Outgoing Flow Transmission...........................13 4.1.3. Conceptual Data Structures...........................14 4.2. Operation in Other Network Element........................15 5. Security Considerations........................................15 6. IANA Considerations............................................15 7. Acknowledgments................................................16 APPENDIX A: Future Extension and Use Case.........................17 A.1. Extension for Mobile Router in NEMO.......................17 A.2. Extension for IPv4/MIP4...................................18 8. References.....................................................18 8.1. Normative References......................................18 8.2. Informative References....................................18 Author's Addresses................................................18 Cui Expires April 15, 2010 [Page 3] Internet-Draft Route Optimization Agent Extension October 2009 1. Introduction Mobile IPv6 protocol [RFC3775] provides a mobility extension to basic IPv6 and introduces a Route Optimization (RO) mechanism. Route Optimization enables mobile node (MN) to establish a directly connection between mobile node and correspondent node (CN) without the involvement of MN's home agent (HA). But Route Optimization requires mobile node and correspondent node to have some certain capabilities, such as MN's transmitting Home Test Init (HoTI) message, Care-of Test Init (CoTI) message and direct Binding Update message to CN, and CN's reflecting Home Test (HoT) message, Care-of Test Init (CoT) message and Binding Ack message to MN. If the CN is a simple IP node without support for Route Optimization, the MN with support for Route Optimization even can't use Route Optimization with this CN, as [RFC3775] specified ''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 none-RO-capable node. When the network is composed of mobile IPv6 nodes, IPv6 nodes with support for Route Optimization and enormous quantity of simple IPv6 nodes with support for only basic IPv6 protocol, lots of Route Optimization attempts will go to failure. This document introduces an extension mechanism, which can be used for IP nodes with only support for basic IPv6 protocol, to fulfill the Route Optimization. 2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC3775] and Proxy Mobile IPv6 [RFC5213]. Cui Expires April 15, 2010 [Page 4] Internet-Draft Route Optimization Agent Extension October 2009 3. Scenario Analysis and Use Case 3.1. Issues if the CN can't support Route Optimization Mobile IPv6 provides the Route Optimization mechanism, which may be used between mobile nodes with support for MIPv6 or between mobile nodes and IP nodes with support for Route Optimization. In other situation, if the correspondent node can't support Route Optimization, the correspondent node will reply an ICMP ERROR message to the mobile node who initiates the Route Optimization. On the other hand, Proxy Mobile IPv6 [RFC5213] provides a network- based mobility solution. In Proxy Mobile IPv6 domain, Mobile Access Gateway (MAG) can provide a proxy mobility management functionality, e.g. transmitting binding update message to mobility anchor on behalf of the mobile node. The MAG works as the mobility proxy for the mobile node, as [RFC5213] defined, ''Mobile Access Gateway is a function on an access router that manages the mobility-related signaling for a mobile node that is attached to its access link''. But by now the MAG is only a half- function proxy for the mobile node, because the MAG can only transmit mobility-related signal messages for the mobile node but can not dispose the mobility-related signal messages destined to the mobile node. The MAG is only an active proxy function but does not implement reactive agent function in current specification. The function of managing the mobility-related signaling defined for MAG is not fully introduced by now. Take the Route Optimization procedure as the example. If the mobile node is setting up Route Optimization with a simple IP node which is attached to the MAG, the message flow is as below: Cui Expires April 15, 2010 [Page 5] Internet-Draft Route Optimization Agent Extension October 2009 MN1 HA LMA MAG MN2 | | | | | === MN1 attached to HA and MN2 attached to MAG === (a) === MAG runs PMIP protocol for MN2 (Basic IP) === === MN1 has no idea about the capability of MN2 === | | | | | | 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 are as follows: (a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP protocol for MN2, which only supports basic IP protocol. During the lifetime of the session between MN1 and MN2, MN1 has no idea about the capability of MN2. (b~e) MN1 initiates a Route Optimization set up and sends Home Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through HA, LMA and MAG, at last arrives at MN2. (f) MN2 can't recognize the Home Test Init message and replies an ICMP error message to MN1. Cui Expires April 15, 2010 [Page 6] Internet-Draft Route Optimization Agent Extension October 2009 (g~i) MN1 sends Care-of Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through LMA and MAG, at last arrives at MN2 too. (j) MN2 can't recognize the Care-of Test Init message and replies an ICMP error message to MN1. (k) MN1 receives the ICMP error messages sent by MN2, has to stop Route Optimization set up. In this example, Home Test Init message and Care-of Test Init message are both mobility-related signaling, but the MAG doesnot manage or deal these messages for MN2. This miss induces the failure of Route Optimization. 3.2. Motivation The motivation for this extension is based on some mechanisms that have been introduced in IETF. For example, Proxy ARP protocol, which is specified in Using ARP to Implement Transparent Subnet Gateways [RFC1027], has been adopted by lots of routers and gateways. One basic Proxy ARP flow is as below: Cui Expires April 15, 2010 [Page 7] Internet-Draft Route Optimization Agent Extension October 2009 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) | | |------------------- >| | | | | | | Figure 2 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 MAG in the PMIP domain receives some mobility-related signal messages (e.g. HoTI, CoTI and BU) destined to the mobile node that is attached to its access link, the MAG can also know that the mobile node can't recognize these messages. Since the MAG is the mobility proxy of the mobile node and can manage the mobility-related signaling for the mobile node, it is reasonable for the MAG to dispose these messages on behalf of the mobile node. The MAG MAY work as a reactive mobility agent in this situation. Cui Expires April 15, 2010 [Page 8] Internet-Draft Route Optimization Agent Extension October 2009 3.3. Requirement The Route Optimization Agent extension introduced in this document depends on the operation of the MAG. The requirements on the MAG to achieve the extension include following: R1: MAG can recognize mobility-relate signal message. When the MAG receives mobility-related signaling destined to the MN that is attached to its access link, the MAG MAY intercept the messages and reply response messages for the mobile node. Since all the mobility- related signal messages contain a mobility header and a MH Type field, the MAG can easily fulfill this requirement. R2: MAG can achieve the operation of CN role for Route Optimization specified in [RFC3775]. [RFC5213] has specified some mechanisms for MAG to provide network-based mobility management function and the MAG can create and maintain the Binding Update List as a mobile node does, so it is also easy to expand the MAG to create and maintain a Binding Cache Entry to meet this requirement. The MAG MAY do more agent operation than specified in [RFC5213] as specified in this document. R3: MAG can modify the sent-out packets and route the packets to the optimized route basing the created Binding Cache. The MAG MAY check whether a binding cache exists and if the binding cache exists the MAG modifies the destination address in the IP header and includes Type 2 Routing Header in the sent-out packets. The MAG should set the destination address as the care-of address of the destined mobile node and set the Home Address field in the Type 2 Routing Header to the home address of the destined mobile node. 3.4. Use Case for Agent Extension to Fulfill Route Optimization This document extends the mobility proxy function of the MAG to the full-functional proxy and enables the MAG to manage all the mobility- related signaling for the mobile node that is attached to its access link. The use case is as below: Cui Expires April 15, 2010 [Page 9] Internet-Draft Route Optimization Agent Extension October 2009 MN1 HA LMA MAG MN2 | | | | | === MN1 attached to HA and MN2 attached to MAG === a === MAG runs PMIP protocol for MN2 (Basic IP) === === MN1 has no idea about the capability of MN2 === | | | | | | HoTI | | | | b1 |------ > | HoTI | | | b2 | |--------- >| HoTI | | b3 | CoTI |------- >| | c1 |------------------- >| HoT | | d1 | | |< -------| | | | | CoTI | | c2 | | HoT |------- >| | d2 | HoT |< ---------| | | d3 |< -------| | CoT | | e1 | CoT |< -------| | e2 |< -------------------| | | | | | | | | | | | BU | | | f1 |------------------- >| BU | | f2 | |------- >| | | |Binding Ack | g1 | Binding Ack |< -------| | g2 |< -------------------| | | | Traffic data | | | -|------------------- >| Traffic | | / | |------- >| Traffic | / | | |------- >| h | | | | Traffic | \ | | Traffic |< -------| \ | Traffic data |< -------| | -|< -------------------| | | | | | | Figure 3 Agent extension in Route Optimization. The detailed descriptions are as follows: (a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP protocol for MN2, which only supports basic IP protocol. During Cui Expires April 15, 2010 [Page 10] Internet-Draft Route Optimization Agent Extension October 2009 the lifetime of the session between MN1 and MN2, MN1 has no idea about the capability of MN2. (b1~b3) MN1 initiates a Route Optimization set up and sends Home Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through HA and LMA and reaches MAG. (c1~c2) MN1 sends Care-of Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through LMA and reaches MAG too. (d1~d3) MAG recognizes the Home Test Init message, which is a mobility-related signaling, and generates a Home Test message on behalf of MN2. The procedure for the MAG to generate the Home Test message is as the same with CN's operation specified in section 9.4.1 and section 9.4.3 of [RFC3775]. The MAG transmits Home Test message to MN1 and the packet goes through LMA and HA and arrives at MN1 at last. (e1~e3) MAG recognizes the Care-of Test Init message, which is a mobility-related signaling, and generates a Care-of Test message on behalf of MN2. The procedure for the MAG to generate the Care-of Test message is as the same with CN's operation specified in section 9.4.2 and section 9.4.4 of [RFC3775]. The MAG transmits Care-of Test message to MN1 and the packet goes through LMA and arrives at MN1 at last. (f1~f2) MN1 receives Home Test and Care-of Test message and sends Binding Update message to the address of MN2 as specified in [RFC3775]. The Binding Update message also reaches the MAG which the MN2 attached to. (g1~g2) MAG recognizes the Binding Update message, which is a mobility-related signaling, and caches the Home Address, Care- of Address and bindings on behalf of MN2. The procedure is as the same with CN's operation as specified in section 9.5.1 of [RFC3775]. The MAG also includes the IP address of the attached IP node (i.e. the destination of the Binding Update message) in the binding cache. The MAG transmits Binding Ack message to MN1 and the packet goes through LMA and arrives at MN1 at last. (h) Route Optimization is achieved and Home Agent of MN1 is not involved in the traffic data transport. For the traffic flow from MN1 to MN2, the MAG forwards all the traffic packets basing on the destination address of the packets. For the traffic flow Cui Expires April 15, 2010 [Page 11] Internet-Draft Route Optimization Agent Extension October 2009 from MN2 to MN1, the MAG achieves the operation specified in section 4.1.2. 4. Solution and Operation Consideration 4.1. MAG Operation The MAG is a function that typically runs on an access router. The MAG transfers all the IP packets from or destined to the mobile node that is attached to its access link. However, some more operation is defined in this document for the expansion solution. The operations for Route Optimization Agent Function consist of following: o Intercepting and disposing the mobility-related signaling destined to the attached mobile node. o Creating, maintaining and deleting the binding cache for the mobile node to which the initiator wants to establish or release a Route Optimization. o Destination Address replacement for the outgoing traffic from the attached mobile node. o Security operation for the Return Routability Procedure and Route Optimization. The MAG SHOULD works as specified in section 5.2 and section 15.4 in [RFC5213] for the role of correspondent node, if the MAG runs the Route Optimization Agent Function. Editor Note: The introduced Route Optimization Agent Function in the reflector may even be separate with the active Proxy Mobile IP function introduced in [RFC5213]. This is to say that the binding cache management and the binding update list management may be independent. The details need more consideration and discussion. Cui Expires April 15, 2010 [Page 12] Internet-Draft Route Optimization Agent Extension October 2009 4.1.1. Incoming Flow Transmission For the incoming (i.e. from the remote IP node to the IP node that is attached to the access link of the MAG) flow, the MAG needs parse the IP header to check the packet type as soon as it receives the packet from the remote IP node. If the IP packets received from other IP nodes don't contain mobility header, the IP packets are not mobility-related signaling, the MAG works as a normal router for these non-mobility-related IP packets. If the IP packets received from other IP nodes contain the mobility header, the MAG needs further check the MH type field in the mobility header. The MAG MAY execute the expansion solution for these mobility-related packets. When the received packet is Home Test Init Message, the MAG stops transferring the packet to the attached IP node and executes the operation as specified for the correspondent node role in section 9.4.1 and 9.4.3 of [RFC3775]. When the received packet is Care-of Test Init Message, the MAG stops transferring the packet to the attached IP node and executes the operation as specified for the correspondent node role in section 9.4.2 and 9.4.4 of [RFC3775]. When the received packet is Binding Update message, the MAG stops transferring 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 [RFC3775]. 4.1.2. Outgoing Flow Transmission For the outgoing (i.e. from the IP node that is attached to the access link of the MAG to the remote IP node) flow, the MAG needs examine its 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 the packet from the attached IP node. If no corresponding binding cache entry exists, the MAG works as a normal MAG for these packets. If a corresponding binding cache entry exists, it means Route Optimization has been established between the IP node pair. The MAG MAY use a type 2 routing header to route the packet to the Cui Expires April 15, 2010 [Page 13] Internet-Draft Route Optimization Agent Extension October 2009 destination node by way of its care-of address. However, the MAG MUST NOT do this 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 [RFC3775]. The MAG may implement following operation for Route Optimization: o The MAG inserts the 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 The MAG sets the Destination Address in the packet's header to the remote mobile node's care-of address copied from the Binding Cache entry. o The MAG forwards the modified packet as specified in section 6.10.5 of [RFC5213]. Note that the implementation creates some additional requirements for path MTU discovery since the modification changes the packet size. The MAG should choose an appropriate way to indicate the sending IP node this situation. 4.1.3. Conceptual Data Structures Every MAG maintains a Binding Update List Entry as specified in [RFC3775] and this document adds Binding Cache to the MAG. When the MAG receives the Binding Update message destined to the attached mobile node the MAG creates the binding cache entry and associates the entry to the destination mobile node. The newly introduced Binding Cache Entry for this extension contains two additional fields than the data structure specified in section 9.1 of [RFC3775]. o The binding cache entry contains a flag indicating whether or not this binding cache is a agent binding cache entry. Cui Expires April 15, 2010 [Page 14] Internet-Draft Route Optimization Agent Extension October 2009 o The binding cache entry contains an associated mobile node address, which is the true destination of the intercepted Binding Update message. Each binding cache is mapped with an address pair (i.e. the home address of the RO-initiator mobile node and the IP address of the attached mobile node). The binding cache contains the care-of address of the RO-initiator mobile node as specified in section 9.1 of [RFC3775]. Route Optimization may be applied between the address pair. 4.2. Operation in Other Network Element The extension mechanism introduced in this document doesn't impact the operation in MN, HA, LMA and CN. These network elements follow the operation described in other specification. 5. Security Considerations The extension in this document is just to expand the scope of the mobility management to cover the reactive mobility management agent function, such as the acceptance of Route Optimization, and the MAG still follows the principle that providing network-based mobility management to the mobile node that is attached to its access link. So this extension brings no new security issue to mobility management. But this extension needs the MAG to implement packet inspection on the packets destined to the mobile node, which would impact the performance of the MAG 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. 6. IANA Considerations This document has no actions for IANA. Cui Expires April 15, 2010 [Page 15] Internet-Draft Route Optimization Agent Extension October 2009 7. Acknowledgments The author would like to thank Netext Working Group for the review, comment and discussion. Cui Expires April 15, 2010 [Page 16] Internet-Draft Route Optimization Agent Extension October 2009 APPENDIX A: Future Extension and Use Case A.1. Extension for Mobile Router in NEMO This solution can also be applied in Network Mobility (NEMO) extension, in which the Mobile Router provides mobility management for IP node with only support for basic IP. The extension for NEMO is as below: MN1 HA1 HA2 MR MN2 | | | | | === MN1 attached to HA and MN2 attached to MR === a === MR provides mobility management for MN2 === === MN1 has no idea about the capability of MN2 === | | | | | | HoTI | | | | b1 |------ > | HoTI | | | b2 | |--------- >| HoTI | | b3 | CoTI |------- >| | c1 |------------------- >| HoT | | d1 | | |< -------| | | | | CoTI | | c2 | | HoT |------- >| | d2 | HoT |< ---------| | | d3 |< -------| | CoT | | e1 | CoT |< -------| | e2 |< -------------------| | | | | | | | | | | | BU | | | f1 |------------------- >| BU | | f2 | |------- >| | | |Binding Ack | g1 | Binding Ack |< -------| | g2 |< -------------------| | | | Traffic data | | | -|------------------- >| Traffic | | / | |------- >| Traffic | / | | |------- >| h | | | | Traffic | \ | | Traffic |< -------| \ | Traffic data |< -------| | -|< -------------------| | | | | | | Figure 4 Agent extension in Route Optimization. Cui Expires April 15, 2010 [Page 17] Internet-Draft Route Optimization Agent Extension October 2009 In this extension, Mobile Router manages the mobility-related signaling destined to the mobile node that is attached to its access link. Mobile Router responds Care-of Test and Home Test message and manages the binding cache on behalf of the MN. A.2. Extension for IPv4/MIP4 TBD. 8. References 8.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. [RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and Basavaraj, P., "Proxy Mobile IPv6", RFC 5213, August 2008. 8.2. Informative References [RFC1027] Smoot, C. and John Q., "Using ARP to Implement Transparent Subnet Gateways", RFC1027, October 1987. Author's Addresses Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Cui Expires April 15, 2010 [Page 18]