Mobility Management Based on Mobile IP in Mixed IPv4/IPv6 Networks Hyun-Ho Choi and Dong-Ho Cho Division of Electrical Engineering Department of Electrical Engineering and Computer Science Korea Advanced Institute of Science and Technology (KAIST) 373-1 Guseong-dong Yuseong-gu Daejeon, Republic of Korea TEL: +82-42-869-8067, FAX: +82-42-869-0550 E-mail: [email protected], [email protected]

Abstract— The current network is evolving gradually from IPv4 to IPv6 network in order to acquire sufficient IP addresses and guarantee the QoS. However, the current mobile IP protocol is supported only when the MN moves within networks of the same IP version because the mobile IPv4 protocol is not compatible with mobile IPv6 protocol. Therefore, we propose an efficient method for the mobility support in mixed IPv4/IPv6 networks by introducing a Mobile IP-Application Level Gateway (MIP-ALG) into the Network Address Translation-Protocol Translation (NATPT). This MIP-ALG compatibly translates MIPv4 messages to MIPv6 messages and vice versa. In addition, the proposed scheme minimizes the triangular routing problem of MIPv4 by inserting the binding function into the NAT-PT. Thus, the proposed mobility management scheme shows good delay performances compared with the conventional MIPv4 and MIPv6 operations.

I. I NTRODUCTION Recently, an efficient and robust mobility management is needed for internet access as wireless mobile communications grow and the use of laptops and handheld devices is widespread [1],[2]. The Mobile IP (MIP) protocol of IETF is a representative standard for the mobility support at the network layer, and it defines MIP operations according to each IP version (i.e. IP version 4 or IP version 6) [3]. Namely, the mobile IP version 4 (MIPv4) protocol is only used in the IPv4 network and the mobile IP version 6 (MIPv6) protocol is applied within the IPv6 network alone. However, if the current network evolves gradually from IPv4 to IPv6 network in order to acquire sufficient IP addresses and guarantee the quality of service (QoS), the conventional MIP protocols (MIPv4 and MIPv6) cannot support anymore the mobility of mobile nodes (MNs) when MNs move between two different IP networks. The mobile IP can be used only when the MN moves within the same IP network because the MIPv4 protocol is not compatible with the MIPv6 protocol. Hence, the mobility area of MNs is limited to the networks using the same IP version, and the current MIP protocols cannot support the overall mobility in the mixed IPv4/IPv6 network. Moreover, there is no proposal for the mobility management in mixed IPv4/IPv6 networks until now. Therefore, in this paper, we focus on a mobility management scheme in mixed IPv4/IPv6 environments. We could propose

an efficient method for the mobility support in the mixed IPv4/IPv6 network by using Mobile IP protocols. This paper is organized as follows. We describe some related works such as mobile IPv4 and IPv6 protocols and the version translation method in Section II. In Section III, the proposed mobility management scheme for mixed IPv4/IPv6 networks is explained in detail. In Section IV, the system performances are analyzed and numerical results are provided. Concluding remarks are presented in Section V. II. R ELATED W ORKS A. Mobile IPv4 The Mobile IP is the most widely known mobility management proposal and is the most common solution for offering seamless roaming to mobile devices in the internet [4]. The basic operation of MIP protocol is shown in Fig. 1. The MIP basically uses a couple of addresses to manage user’s movements. Each time the MN connects to a foreign network, it obtains a temporary address called Care-of-Address (COA) from a mobile agent (MA) called the foreign agent (FA) by exchange of agent solicitation and advertisement massages. This COA remains valid only while the MN stays in this connected network. Then, the MN informs its home agent (HA) of the COA by the registration process in which the registration request and registration reply messages are exchanged between the MN and the HA. When the HA is aware of the MN’s current FA by this registration process, the HA is able to re-tunnel the packets destined for the MN toward the FA. If the correspondent node (CN) sends packets to the MN, these packets are normally routed and so obviously arrive at the home network. Then, the HA intercepts and encapsulates them toward the FA through the created tunnel. B. Mobile IPv6 The IPv4 protocol has insufficient address spaces and the MIPv4 leads to asymmetric route for packets transmitted by the CN and the MN. This phenomenon is called triangular routing and will in most cases be far from the optimal

0-7803-7955-1/03/$17.00 (C) 2003 IEEE

MN

FA

CN

HA

Agent Solicitation Agent Advertisement

[NAT-PT s address mapping table] IPv6 addr

IPv4 addr

DNS-ALG

2001:230::1

120.130.26.10

...

...

mapping table

Registration Request Request Relay Registration Reply Proxy ARP Gratuitous ARP

Tunnel Open

address pool

Outbound traffic

Reply Relay

Send packet to MN

IPv6 Host

NAT-PT

IPv4 Host

www.ipv6.net (2001:230::1)

Address pool : 120.130.26/24 Domain prefix : 2001:230:d:fffd::/96

www.ipv4.net (129.254.19.28)

SA=2001:230::1 DA=2001:230:d:fffd::129.254.19.28

Packet Interception & Encapsulation Send packet through tunnel

1.Assign new IPv4 address 120.130.26.10 for source IPv6 address from address pool 2. IPv6->IPv4 Header Translation

Fig. 3.

SA=120.130.26.10 DA=129.254.19.28

Basic operation of NAT-PT.

Decapsulation Send packet to MN

Fig. 1.

Operation procedure of Mobile IPv4.

routing path. To solve and improve these problems, the MIPv6 protocol is proposed as the natural evolution of MIPv4 [5],[6]. The operation procedure of MIP protocol is shown in Fig. 2. The basic operation of MIPv6 is similar to that of MIPv4. More accurately, the process of MIPv6 is the same until the HA forwards packets to the COA for the first time. But, at this point, the MN and CN are bound together by using binding update and binding acknowledgement messages. Through this process, the MN can inform the CN of its COA so that the MN and CN can directly communicate each other, without the HA. C. Network Address Translation-Protocol Translation When IPv4 and IPv6 networks are coexisting, Network Address Translation-Protocol Translation (NAT-PT) is one of the methods to communicate between IPv4 and IPv6 nodes by translating each IP version [7]. The NAT-PT is gateway MN

FA

CN

HA

Router Solicitation Router Advertisement Address Autoconfiguration Binding Update Binding Acknowledgement

Tunnel Open

Proxy Neighbor Discovery start Gratuitous Neighbor Discovery CN sends packet 1 to MN Packet Interception & Encapsulation

Packet 1 is sent to MN through tunnel Binding Update Binding Acknowledgement Other Packets are sent to MN directly

Fig. 2.

Operation procedure of Mobile IPv6.

node located between IPv4 and IPv6 networks, and provides a combination of address translation and IPv6/IPv4 protocol translation by using the address pool and mapping table. The NAT-PT has several modified versions according to the applied environments. Fig. 3 shows the basic operation of NAT-PT. In this case, the IPv6 host knows the address of the IPv4 host and begins a connection setup. Though the IPv6 host is aware of the address of the IPv4 host, it must use a special address, which is combined the IPv4 address with a domain prefix, within the IPv6 domain. The domain prefix is broadcasted at the border router of the network where the NAT-PT is located. In addition, the NAT-PT requires some Application Level Gateway (ALG) which is an application specific agent that allows an IPv6 node to communicate with an IPv4 node and vice versa. That is, the ALG could work in conjunction with the NAT-PT to provide some applications such as DNS-ALG and FTP-ALG. III. M OBILITY M ANAGEMENT IN M IXED IP V 4/IP V 6 N ETWORKS We propose a method for the mobility support based on Mobile IP in the mixed IPv4/IPv6 network. In order to support MIP operations between IPv4 and IPv6 networks, we add a Mobile IP-Application Level Gateway (MIP-ALG) to the NAT-PT. The MIP-ALG can exactly translate MIP messages such as registration request, registration reply, binding update, binding acknowledgement and so on, regardless of IP version. Hence, the MIP-ALG compatibly converts MIPv4 messages into MIPv6 messages and vice versa. Fig. 4 shows a simple example of the mixed network structure. The HA and CN are located in the IPv6 network and the FA exists in the IPv4 network. We assume that the MN has moved from IPv6 to IPv4 network and uses the IPv4/IPv6 dual-stack. Here, the NAT-PT is a gateway node located between IPv4 and IPv6 networks and contains the MIP-ALG. Therefore, the all registration procedures of both MIPv4 and MIPv6 can be performed normally between IPv4 and IPv6 networks, and so the overall mobility can be supported by the MIP-ALG. However, the triangular routing problem is still remaining in this case. Thus, we try to solve this problem in some cases

0-7803-7955-1/03/$17.00 (C) 2003 IEEE

IPv6 network

MIP-ALG

IPv4 network FA

HA NAT-PT MN Movement

IPv6 network

MN

FA

MN

FA

(MNv6)

(FAv4)

(MNv4)

(FAv6)

MNv6 : MNv4

MNv4 : MNv6

MN B in din g

First packet route

IPv4 network

Agent Solicitation IPv4 : MNv4

broadcast or multicast

Router Solicitation [ IPv6 : MNv6

multicast ]

Next packet route Agent Advertisement IPv4 : FAv4

broadcast or multicast

Router Advertisement [ IPv6 : FAv6

multicast ]

CN Obtain COAv4

IPv6 network

Obtain COAv6 (a)

(b)

Fig. 4. Operation example of proposed scheme in mixed IPv4/IPv6 networks. Fig. 5. Procedure that MN obtains a Care-of-Address in IPv4 (a) and IPv6 foreign networks (b).

by binding the NAT-PT and the CN. That is, the NAT-PT is able to use the binding function. For example, in Fig. 4, the first packet of the CN is transmitted to the HA, then the HA delivers it to the MN via the NAT-PT. In this moment, the NAT-PT can bind itself with the CN because it can know the CN’s address by analyzing the MIP header information. Thus, the next packets of the CN are sent to the FA via the only NAT-PT without the HA, and so the communication route can be reduced. Detailed operations of the proposed mobility management scheme are composed of three steps, which are Discovering of Mobility Agents, Registration to the HA, and Routing and Tunneling. The operation procedure of each step can be explained according to the IP version of network and the position of MN, HA and CN.

A. Discovering of Mobility Agents When the MN moves into a new IPv4 or IPv6 network, it discovers the FA and acquires the COA from it. The version of the assigned COA is identical with one of the current network, and so this COA can be used as a source IP address of the MN in this foreign network. Fig. 5 shows the procedure that the MN obtains a COA in IPv4 and IPv6 networks. In this Fig. 5, we name the IP address used at each node the node type plus version number in order to explain the procedure easily. E.g. the IP address of MN in the IPv4 network is expressed as MNv4. Also, we assume that the MN uses the dual stack protocol to deal with both IPv4 and IPv6 packets. Therefore, if the MN moves from IPv6 to IPv4 network, it can use a valid IPv4 address as a source IP address instead of the original IPv6 address. Here, two IP addresses of the MN, MNv6 and MNv4, have a mapping relation. In the IPv4 network, the MN sends the agent solicitation message to acquire the COA from the FA. This message contains information that the IP version is 4, the source IP address is MNv4, and the destination IP address is broadcast or multicast address, as shown in each message of Fig. 5. If the FA receives the agent solicitation message from the MN, it sends the agent advertisement message, and so the MN can obtain the COAv4.

In the IPv6 network, the MN sends the router solicitation message to obtain the COA from the FA. After the MN receives the router advertisement message from the FA, it acquires the COAv6 available in the IPv6 network. B. Registration to the HA If the MN moved from IPv6 to IPv4 network obtains the COA from the FA of IPv4 network, then it starts to register the COAv4 to the HA of IPv6 home network. Fig. 6 shows the registration procedure from the MN of IPv4 network to the HA of IPv6 network. The operation procedure is explained as follows. 1) The MN requests the NAT-PT to get the IPv4 address of HA by using the domain name of HA. The MN is assumed to basically know the domain name of its HA. 2) The NAT-PT looks for the IP address of the HA (HAv6) by the DNS-ALG and assigns the MN a HAv4 address from its address pool. This HAv4 address is coupled with HAv6 address and this relationship is recorded at mapping table. 3) The MN sends the binding update message to the NATPT through the IPv4 encapsulation in which the HAv4 is used as the destination IP address. The IPv6 and MIPv6 header information are included inside this encapsulated message. 4) When the NAT-PT receives the binding update message from the MN, it decapsulates the IPv4 header and relays the message to the HA after insertion of the COAv6, which is obtained from the address pool in order to use instead of COAv4 in the IPv6 home network. 5) If the HA receives the binding update message, it registers the COAv6 as the MN’s COA and replies to the NAT-PT through the binding acknowledgement message. 6) When the NAT-PT gets the binding acknowledgement message, it checks the source and destination IP addresses and transmits the message to the MN of IPv4 network through the IPv4 encapsulation. On the contrary, Fig. 7 shows the registration procedure from the MN of IPv6 network to the HA of IPv4 network.

0-7803-7955-1/03/$17.00 (C) 2003 IEEE

IPv4 network

IPv6 network MIP-ALG DNS-ALG NAT-PT

MN (MNv6, COAv4)

IPv6 network

IPv4 network

HA

MN

(HAv6)

(MNv4, COAv6)

MIP-ALG DNS-ALG NAT-PT

HA (HAv4)

HA address query

HA address query

HAv6 : HAv4

HAv4 : HAv6

HA address reply (HAv6)

HA address reply (HAv4)

IPv6 Encapsulation

IPv4 Encapsulation

Registration Request

Binding Update

IPv6 : COAv6 HAv6 IPv4 : MNv4 HAv4 MIPv4 : MNv4, HAv4

IPv4 : COAv4 HAv4 IPv6 : MNv6 HAv6 MIPv6 : MNv6

Decapsulation

Decapsulation

COAv4 : COAv6

COAv6 : COAv4

MIP-ALG operation

MIP-ALG operation Registration Request

Binding Update

IPv4 : MNv4 HAv4 MIPv4 : MNv4, HAv4, COAv4

IPv6 : MNv6 HAv6 MIPv6 : MNv6, COAv6

Registration Reply

Binding ACK

IPv4 : HAv4 COAv4 MIPv4 : MNv4, HAv4

IPv6 : HAv6 COAv6 MIPv6 : MNv6

IPv6 Encapsulation

IPv4 Encapsulation Binding ACK

Registration Reply

IPv4 : HAv4 COAv4 IPv6 : HAv6 COAv6 MIPv6 : MNv6

IPv6 : HAv6 COAv6 IPv4 : HAv4 COAv4 MIPv4 : MNv4, HAv4

Decapsulation

Decapsulation

Fig. 6. Registration procedure from MN of IPv4 network to HA of IPv6 network.

Fig. 7. Registration procedure from MN of IPv6 network to HA of IPv4 network.

Except the version of IP address and the MIP message format used in each message, the operation procedure is the same as the previous explanation.

informs the binding completion by transmission of the binding acknowledgement message. 5) Now, the next packets are directly transmitted to the NAT-PT instead of the HA because the destination address is set as the COAv6 by the previous binding. By these operations, the proposed scheme can minimize the triangular problem of MIPv4 in some cases. This characteristic can be an additional advantage of the proposed scheme with the mobility support in mixed IPv4/IPv6 networks.

C. Routing and Tunneling When the MN completes the registration procedure to the HA, the MN can receive the packets from every CNs because the HA re-tunnels the packets toward the FA. Therefore, the mobility support is possible in mixed IPv4/IPv6 networks. For example, when the HA is located in the IPv6 network and the MN is moved from IPv6 to IPv4 network, the operation procedure that the CN of IPv6 network transmits packets is shown in Fig. 8. The detailed operations are as follows. 1) If the CN transmits the first packet to the MN, the HA intercepts and encapsulates it by using the COAv6 registered in the HA. Then the HA delivers the packet to the NAT-PT for version translation. 2) In the NAT-PT, an IPv4 address for the CN (CNv4) is allocated for use in IPv4 network. And, the packet is encapsulated again to be transmitted to the IPv4 network. 3) If the MN receives the first packet, it sends the response message about the first packet. If the NAT-PT receives the response, it makes the binding update message for binding the MNv6 with the COAv6 by MIP-ALG operation, and sends it to the CN. 4) When the CN receives the binding update message, it processes the binding of the MNv6 with the COAv6 and

IV. P ERFORMANCE A NALYSIS AND R ESULTS The performances of the proposed mobility management scheme are evaluated analytically for the all possible cases. According to locations of the HA and FA(or MN) in the mixed IPv4/IPv6 network, signalling costs needed for the MIP registration are calculated as shown in Table I. Here, CA−B is assumed to be the signalling cost between A and B nodes. When the HA and FA are located in the network of the same IP version, the signaling costs of the proposed scheme are the same as those of basic MIPv4 and MIPv6 protocols. However, TABLE I S IGNALLING COST FOR REGISTRATION TO THE HA HA v4 v4 v6 v6

FA/MN v4 v6 v6 v4

Signalling Cost 4CM N −F A + 2CF A−HA 2CM N −F A + 4CM N −N AT P T + 2CN AT P T −HA 2CM N −F A + 2CM N −HA 2CM N −F A + 4CM N −N AT P T + 2CN AT P T −HA

0-7803-7955-1/03/$17.00 (C) 2003 IEEE

TABLE II P ERFORMANCE COMPARISONS OF DELAY HA v4 v6 v6 v4 v6 v4 v4 v6

FA/MN v4 v4 v6 v6 v6 v6 v4 v4

IPv6 network

CN v4 v4 v4 v4 v6 v6 v6 v6

Registration Delay 2T1 + 2T2 + Tp(F A) + Tp(HA) 2T1 + 2T3 + Tp(F A) + Tp(HA) + 2Tp(N AT P T ) 2T1 + 2T2 + Tp(F A) + Tp(HA) 2T1 + 2T3 + Tp(F A) + Tp(HA) + 2Tp(N AT P T ) 2T1 + 2T2 + Tp(F A) + Tp(HA) 2T1 + 2T3 + Tp(F A) + Tp(HA) + 2Tp(N AT P T ) 2T1 + 2T2 + Tp(F A) + Tp(HA) 2T1 + 2T3 + Tp(F A) + Tp(HA) + 2Tp(N AT P T )

MIP-ALG DNS-ALG NAT-PT

IPv6 network

CN

HA

(CNv6)

(HAv6) First Packet Tx [ IPv6 : CNv6

IPv4 network

MN (MNv6, COAv4)

COAv6 : COAv4

MNv6 ]

Interception & Encapsulation First Packet Tx Tunneling

IPv6 : HAv6 IPv6 : CNv6

COAv6 MNv6

Decapsulation CNv4 : CNv6 Encapsulation First Packet Tx IPv4 : CNv4 IPv6 : CNv6

COAv4 MNv6

Tunneling First Packet Response IPv4 : COAv4 CNv4 IPv6 : MNv6 CNv6

Decapsulation MIP-ALG operation Binding Update IPv6 : MNv6 CNv6 MIPv6 : MNv6, COAv6

Binding (MNv6 + COAv6)

Packet Tx. Delay T2 + T4 T3 + T5 + 2Tp(N AT P T ) T2 + T5 + Tp(N AT P T ) T3 + T4 + Tp(N AT P T ) T6 T6 T7 + Tp(N AT P T ) T7 + Tp(N AT P T )

Operation Conventional mobile IPv4 Triangular routing problem exists Triangular routing problem exists Triangular routing problem exists Conventional Mobile IPv6 Binding between MN and CN Binding between NAT-PT and CN Binding between NAT-PT and CN

T4 : link delay between HA and CN when they are in the same network version • T5 : link delay between HA and CN when they are in the different network version • T6 : link delay between CN and MN when they are in the same network version • T7 : link delay between CN and MN when they are in the different network version • Tp(A) : processing time needed in node A If the versions of the HA and FA are different, the registration delay is more larger because of the processing time of the NAT-PT with version conversions. However, if the CN is an IPv6 node, the packet transmission delay effectively decreases compared with the conventional MIPv4 protocol. This is because the binding is formed between the CN and the NAT-PT and so the triangular routing problem is resolved. Therefore, the proposed scheme reduces the packet transmission delay as much as possible, together with support of overall mobility in the IPv4/IPv6 network. •

Binding ACK

V. C ONCLUSIONS

IPv6 : CNv6 COAv6 MIPv6 : COAv6

Next Packet Tx [ IPv6 : CNv6

Next Packet Tx

COAv6 ]

[ IPv4 : CNv4

Next Packet Tx [ IPv6 : COAv6

COAv4 ]

Next Packet Tx [ IPv4 : COAv4

CNv4 ]

CNv6 ]

Fig. 8. Procedure that CN of IPv6 transmits packets to MN moved from IPv6 to IPv4 network.

when the network versions of the HA and FA are different each other, more signallings between the NAT-PT and the HA are required because the MIP version translation must be executed mutually. Therefore, the proposed scheme requires more signalling costs in order to support mobility in the mixed IPv4/IPv6 network. When the HA, FA and CN are existing in mixed IPv4/IPv6 networks, all events are total 8 cases as shown in Table II. We could calculate both registration delay and packet transmission delay according to the 8 cases when each delay component occurring in the network is assumed as follows. • • •

T1 : link delay between FA and MN T2 : link delay between HA and MN when they are in the same network version T3 : link delay between HA and MN when they are in the different network version

In this paper, we propose an efficient method for the mobility support in the mixed IPv4/IPv6 network by introducing a MIP-ALG into the NAT-PT. The proposed scheme makes it possible to support the mobility management in the mixed IPv4/IPv6 network and minimizes the triangular routing problem by realizing the binding function into NATPT. Although the proposed scheme induces more complexity for MIP version conversions in the NAT-PT, it is expected to be applied usefully in mixed IPv4/IPv6 networks in the near future as the current network is evolving gradually from IPv4 to IPv6 network. R EFERENCES [1] F.M. Chiussi, et al., ”Mobility management in third-generation all-IP networks,” IEEE Commun. Magazine, vol. 40, no. 9, pp. 124-135, Sep. 2002. [2] I-Wei Wu, et al., ”A seamless handoff approach of Mobile IP protocol for mobile wireless data networks,” IEEE Trans. on Consumer Electronics, vol. 48, no. 2, pp. 335 -344, May 2002. [3] P. Reinbold and O. Bonaventure, ”A Comparison of IP mobility protocols,” Infonet group, University of Namur, Belgium, Dec. 2001. [4] C. Perkins, ”IP Mobility Support,” RFC 2002, Oct. 1996. [5] D. B. Johnson, ”Mobility Support in IPv6,” IETF Internet draft, Jul. 2000. [6] S.J. Vaughan-Nichols, ”Mobile IPv6 and the future of wireless Internet access,” Computer, vol. 36, no. 2, pp. 18-20, Feb. 2003. [7] G. Tsirtsis and P. Srisuresh, ” Network Address Translation - Protocol Translation (NAT-PT),” RFC 2766, Feb. 2000.

0-7803-7955-1/03/$17.00 (C) 2003 IEEE