IETF NGTRANS Working Group Shiao-Li Tsao Jen-Chi Liu INTERNET-DRAFT CCL, ITRI Wolfgang Boehm Siemens 17 Nov. 2000 Mobile IP Application Level Gateway Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 document is an individual submission for the NGTRANS Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ngtrans@sunroof.eng.sun.com mailing list. Abstract Mobile IPv4 and mobile IPv6 have been developed to enhance IPv4 and IPv6 to have mobility support respectively. To solve the triangular routing problem in mobile IP, routing optimization mechanism is proposed for mobile IPv4 as well as mobile IPv6 defines routing optimization as an absolute requirement. However, the routing optimization procedures and the address binding messages are different in mobile IPv4 and mobile IPv6. The incompatible binding message incurs the failure of binding related procedures while IPv4 mobile nodes communicate with IPv6 correspondent nodes or IPv6 mobile nodes talk to IPv4 correspondent nodes. Then, the binding failures result in triangular routing and introduce additional tunneling overhead. This Internet-Draft presents a mobile IP application level gateway to solve this problem. The mobile IP application level gateway intercepts IPv4/IPv6 binding messages, translates the messages of one mobile IP version to the other, and then sends the binding messages to destination nodes. In that way, the triangular routing problem can be solved in a mobile IPv4/mobile IPv6 interworking environment. 1. Introduction Mobile IPv4 and mobile IPv6 have been developed to enhance IPv4 and IPv6 to have mobility support respectively[5][6]. In mobile IPv4, packets sent to a mobile node have to be tunneled to a visited network if the mobile node is away from its home network. This design in mobile IPv4 introduces the triangular routing problem. To solve this problem, routing optimization mechanism is thus proposed for mobile IPv4. In mobile IPv6, the routing optimization is defined as an absolute requirement. However, the routing optimization procedures and the address binding messages are different in mobile IPv4 and mobile IPv6. Supposed an IPv4 mobile node (MN) communicates with an IPv6 correspond node (CN), the MN may change its point of attachment to a visited network. According to routing optimization extension, the IPv4 MN sends a Binding Update message to refresh the binding information on the IPv6 CN. Unfortunately, IPv4 Binding Update that is a UDP packet is not compatible with IPv6 Binding Update that is an IPv6 packet with a destination option, and the message cannot be translated by IPv4/IPv6 translator. So, the IPv6 CN cannot recognize the binding messages sent by the IPv4 MN and packets from the IPv6 CN still go to the home agent and tunneled to the visited network. The triangular routing problem also exists in the other direction, i.e. the communication between an IPv6 mobile node and an IPv4 correspondent node. This Internet Draft aims to solve this problem by presenting a mobile IP application level gateway. We assume that both mobile IPv4 and mobile IPv6 support the routing optimization. The mobile IP application level gateway intercepts IPv4/IPv6 binding messages, translates the messages of one mobile IP version to the other, and then sends the binding messages to destination nodes. Then, the triangular routing problem can be solved and the efficiency of packet transmission can be improved in a mobile IPv4/mobile IPv6 interworking environment. 2. Terminology IPv4/IPv6 router A route implements both IPv4 and IPv6, and can understand both IPv4 and IPv6 protocols. IPv4-only node A host only implements IPv4 protocol stack. IPv4-only mobile node An IPv4-only node can change its point of attachment from one link to another, while still being reachable by its IPv4 address. IPv6-only node A host only implements IPv6 protocol stack. IPv6-only mobile node An IPv6-only node can change its point of attachment from one link to another, while still being reachable by its IPv6 address. IPv4/IPv6 translator A node translates IPv4 packets to IPv6 packets and vice versa, and facilities communications between IPv4-only nodes and IPv6-only nodes. The IPv4/IPv6 protocol translator can use any IPv4/IPv6 transition mechanisms such as SIIT[2], NAT-PT[1] or etc[3][7][8]. 3. Problem Description and Assumption Assume that IPv4 and IPv6 coexist in the Internet. There should be some IPv4/IPv6 transition mechanisms implement on the IPv4 and IPv6 boundary routers. The IPv4/IPv6 transition mechanisms can be NAT-PT[1], SIIT[2] or etc. In IPv4 networks, we assume that mobile IPv4 and routing optimization extension are implemented. Suppose that a mobile node (MN) implements only one protocol stack and it wants to communicate with others which might be an IPv4-only node, an IPv6-only node or an IPv4/IPv6 dual stack node, there are four scenarios which have triangular routing problem even the routing optimization is implemented. The first scenario is that an IPv4-only mobile node (IPv4-only MN) communicates with an IPv6 correspondent node (IPv6 CN). When the IPv4-only MN changes its point of attachment to another IPv4 network, the IPv4-only MN should send a Binding Update message to the IPv6 CN to update its binding information. However, IPv4/IPv6 translators such as NAT-PT, SIIT and etc. cannot translate IPv4 binding messages to IPv6 binding messages so that the binding messages sent by the IPv4-only MN or the binding messages sent by the IPv6 CN cannot be received or understood by the destination nodes. Then, every packet from the IPv6 CN to the IPv4-only MN will go to its home agent first and then they are tunneled to the MN in the visited network. Another similar scenario is that an IPv4-only MN talks to an IPv6 CN and the IPv4-only MN changes its point of attachment to an IPv6 network. Supposed the IPv6 network has IPv4/IPv6 router, and packets from or to the IPv4-only MN can be understood and processed. However, in this scenario, the binding messages between the IPv4-only MN and IPv6 CN still cannot be translated by protocol translator. Then, the binding procedures are also failed. The third scenario is that an IPv6-only MN communicates with an IPv4 CN. The IPv6-only MN may change its point of attachment to another IPv6 network. The IPv6-only MN should send the mobile IPv6 binding update to CNs while it changes its link to a visited network. However, the binding messages defined in mobile IPv4 and mobile IPv6 are not compatible and the existing IPv4/IPv6 transition mechanisms cannot translate the messages, the binding procedures between IPv6-only MN and IPv4 CN will fail. The situation is the same for an IPv6-only MN talks to an IPv4 CN. To summaries the problem, since the binding messages in mobile IPv4 is carried by UDP/IP but that in mobile IPv6 is a destination option in IPv6 packets, the binding messages are not recognized by destinations and binding is failed. The failure of binding related procedures will introduce triangular routing and additional tunneling overhead. In this draft, a mobile IP application level gateway is presented to translate the binding messages between mobile IPv4 and mobile IPv6 and solve the triangular routing in a mobile IPv4/mobile IPv6 interworking environment. 4. Mobile IP Application Level Gateway 4.1 IPv4-only mobile node (MN) communicates with IPv6 correspondent node An IPv4-only MN communicates with an IPv6 correspondent node, and it may change its point of attachment to a visited network which may be IPv4 or IPv6. If the visited network is IPv6, there must have IPv4/IPv6 router so that the packets from or to IPv4-only MN can be understood and processed. Moreover, the IPv6 network must implement IPv4 foreign agents. Once the IPv4-only MN moves to a new network, it receives foreign agent advertisement and performs the registration. Based on mobile IPv4 with routing optimization extension, the IPv4-only MN should send Binding Update to correspondent nodes. However, mobile IPv4 binding messages are UDP packets but mobile IPv6 binding messages are IPv6 Destination Options, the mobile IPv4 Binding Update is not recognized by IPv6 node. The proposed mobile IP application level gateway (mobile IP ALG) acts as a gateway to translate binding messages between two mobile IP versions. The mobile IP application level gateway must be implemented in the border routers between IPv4 and IPv6 networks, and it must cooperate with IPv4/IPv6 transition mechanisms such as NAT-PT, SIIT or etc. In the scenario that an IPv4-only MN talks to an IPv6 CN, the mobile IP ALG intercepts binding messages and performs the mobile IPv4 to mobile IPv6 translation. The mobile IP ALG receives mobile IPv4 Binding Update, translates the mobile IPv4 Binding Update to IPv6 Binding Update and forwards to the IPv6 CN. While receiving mobile IPv6 Binding Acknowledgement and mobile IPv6 Binding from the IPv6 CN, the Mobile IP ALG translates mobile IPv6 binding messages, which are IPv6 Destination Option, to mobile IPv4 binding messages and then send it to mobile IPv4 MN or IPv4 home agent. The detail information exchanging between mobile IPv4 and mobile IPv6 is described later. 4.2 IPv6-only mobile node (MN) communicates with IPv4 correspondent node Consider another scenario that an IPv6-only MN talks to an IPv4 correspondent node. The IPv6-only MN moves to a visited network which may be IPv4 or IPv6. We assume that if the visited network is IPv4, there must be IPv4/IPv6 routers so that the packets from/to IPv6-only MN can be recognized. Based on the specification in mobile IPv6, once the IPv6-only MN receives the router advertisement and detects the change to a new network, the IPv6-only MN must perform the registration and send Binding Update to correspondent nodes. However, since mobile IPv6 binding messages are incompatible with mobile IPv4 binding messages, the binding related procedures couldn't be realized in this situation. The mobile IP ALG must be implemented in the border routers between IPv4 and IPv6 networks, and it must cooperate with IPv4/IPv6 transition mechanisms such as NAT-PT, SIIT or etc. The mobile IP ALG intercepts binding messages, translates between two mobile IP versions and forwards to the destinations. Once the mobile IP ALG receives Binding Update from IPv6-only MN, it translates the messages to mobile IPv4 Binding Update and sends the message to the IPv4 MN. While receiving mobile IPv4 Binding Acknowledgement, it generates an IPv6 packet with Bind Acknowledgement which is an IPv6 Destination Option and sends to the IPv6 MN. For receiving mobile IPv6 Binding Request from the IPv4 CN, the mobile IP ALG translates mobile IPv6 Binding Request to mobile IPv4 Binding Request. Since the mobile IPv4 binding messages are based on UDP but mobile IPv6 binding messages are IPv6 Destination Option, the mobile IP ALG acts like a gateway which receives IPv4 UDP packets and sends IPv6 packets or vice versa. The detail information exchange of the fields in binding messages are listed in the next section. 4.3 Binding messages translation between mobile IPv4 and mobile IPv6 To translate mobile IPv4 binding messages to mobile IPv6 binding messages or vice versa, the mobile IP ALG must have the IPv4 addresses with the corresponding IPv6 addresses of IPv4-only MN, IPv4 home agents, IPv4 foreign agents and IPv4 correspondent nodes. Moreover, it also needs the IPv6 addresses with the corresponding IPv4 addresses of IPv6-only MN, IPv6 home agent and IPv6 correspondent nodes. The mapping of IPv4 to IPv6 and IPv6 to IPv4 may be obtained by asking IPv4/IPv6 translators, but to obtain the mapping between IPv4 and IPv6 addresses is out of scope in this I-D. Moreover, the mobile IP ALG only process binding messages for communication involved in IPv4/IPv6 translators. The binding messages can be obtained from IPv4/IPv6 translator such as NAT-PT servers, SIIT servers, and etc. o Binding Update There are two types of translations, i.e, from mobile IPv4 Binding Update to mobile IPv6 Binding Update and from mobile IPv6 binding update to mobile IPv4 Binding Update. To translate mobile IPv4 Binding Update to IPv6 Binding Update, the mobile IP ALG generates an IPv6 Binding Update packets once it receives a mobile IPv4 Binding Update. It puts the care-of-address in mobile IPv4 Binding Update in the source address field of the IPv6 packet or in the alternate care-of-address of the sub-option. The home address that specified in mobile IPv4 Binding Update is put in a home address destination option in the IPv6 packet. In the second type of translation, i.e. from mobile IPv6 binding update to mobile IPv4 Binding Update, the mobile IP ALG generates a mobile IP Binding Update packet if mobile IP ALG receives a mobile IPv6 Binding Update. The packet contains the care-of-address that is IPv4 and the home address in IPv4. Then, the UDP packet is sent to IPv4 CN. o Binding Acknowledgement There are two types of translations, i.e. from mobile IPv4 binding acknowledgement to mobile IPv6 Binding Acknowledgement and from mobile IPv6 Binding Acknowledgement to mobile IPv4 binding acknowledgement. For the first type of translation, the mobile IP ALG receives IPv4 Binding Acknowledgement, it generate an IPv6 packet with destination option (Binding Acknowledgement) and sends the packet to the IPv6 CN. To translate mobile IPv6 Binding Acknowledgement to mobile IPv4 Binding Acknowledgement, the mobile IP ALG receives IPv6 packets with mobile IPv6 Binding Acknowledgement destination option, it generates a mobile IPv4 Binding Acknowledgement that is an IPv4 UDP packet. The message contains the care-of-address which is IPv4 and home address in IPv4. Then, the UDP packets can send to the IPv4 CN. o Binding Request To translate mobile IPv4 Binding Request to mobile IPv6 binding request, once the mobile IP ALG receives mobile IPv4 binding request, it generate an IPv6 packet with destination option (Binding Request) and sends the packet to IPv6 MN. On the other hand, if mobile IP ALG receives IPv6 Binding Request, it generate an IPv4 Binding Request and sends to IPv4-only MN. o Binding Warning Binding Warning message is used to transmit advice that a Binding Update should be sent to one or more correspondent nodes or foreign agents. The message is sent by home agents, foreign agents to mobile nodes. Since mobile nodes, its home and foreign agents are IPv4, this messages don't need to translate and don't have to process by mobile IP ALG. 5. References [1] G. Tsirtsis, and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, Feb. 2000. [2] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, Feb. 2000. [3] K. Yamamoto and M. Sumikawa, "Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication", , March 2000 (work in progress). [4] Charles Perkins and David B. Johnson, "Route Optimization in Mobile IP", , Feb. 2000 (work in progress). [5] Charles Perkins, "IP Mobility Support", RFC 2002, Oct. 1996. [6] David Johnson and Charles Perkins, "Mobility Support in IPv6", , March 2000 (work in progress). [7] R. Gilligan, FreeGate Corp and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [8] B. Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", , Sep. 2000. Authors' Addresses Shiao-Li Tsao CCL, ITRI K400 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan, 310, R.O.C. Tel: +886-3-5914651 Fax: +886-3-5820310 E-mail: sltsao@itri.org.tw Jen-Chi Liu CCL, ITRI K400 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan, 310, R.O.C. Tel: +886-3-5914663 Fax: +886-3-5820310 E-mail: jcliu@itri.org.tw Wolfgang Boehm Siemens Mobile Internet Postal Address: Siemens AG, ICM CA MS MI E Hofmannstr. 51 81379 Munich / Germany Tel: +49 89 722 31462 Fax: +49 89 722 37661 e-mail: wolfgang-j.boehm@icn.siemens.de