Case Study of Mobility Support for IPv4/IPv6 Transition

Mechanisms over IPv6 Backbone Networks

Jiang Xie and Aarthi BalanDepartment of Electrical and Computer Engineering

The University of North Carolina at CharlotteEmail: {jxie1, abalan1}@uncc.edu

Abstract— The rapid growth of the Internet leads to antic-ipated depletion of Internet addresses in the existing InternetProtocol version 4 (IPv4). Internet Protocol version 6 (IPv6)provides increased address space and desired features that meetthe predicted growth of the Internet. However, the currentwidespread deployment of IPv4 equipment means that IPv4-based applications will coexist with IPv6-based applications foran extended period of time. The crux of the problem associatedwith the co-existence of IPv4 and IPv6 is the IP header incom-patibility. Incompatibility can fail the Internet connectivity andseriously degrade the overall performance. The current proposedIPv4/IPv6 transition mechanisms are not designed to operate ina mobile environment. Mobility adds a new dimension to thetransition and interoperability problems. This paper conductsa comprehensive case study on mobility support for IPv4/IPv6transition mechanisms over IPv6 backbone networks. Designchallenges for all the communication scenarios between IPv4 andIPv6 hosts are investigated. Solutions for transition mechanismswith mobility support are proposed.

I. INTRODUCTION

The limited address space currently available in the existingInternet, Internet Protocol version 4 (IPv4), is insufficient toglobally address each of today’s devices. This expected deple-tion of IPv4 addresses drives the development and deploymentof a new version of IP, Internet Protocol version 6 (IPv6). IPv6has a number of features that meet the predicted growth ofthe Internet. It has a much increased address space from 32bits to 128 bits, hierarchical addresses to reduce the size ofrouting tables, improved security and data integrity features,and an autoconfiguration facility that enables a host to obtainan IP address via the network without human intervention.However, the currently widespread deployment of IPv4 equip-ment means that a considerable number of legacy IPv4-basedapplications and devices will remain in use for many years.IPv6-based network infrastructure will be parallelly operatedwith IPv4-based networks and their applications will coexistfor an extended period of time.

The crux of the problem associated with the co-existenceof IPv4 and IPv6 is the IP header incompatibility. A routerwith only an IPv4 implementation is unable to forward pack-ets containing an IPv6 header. Similarly, hosts with onlyIPv4 implementation cannot communicate with others usingIPv6 because they are not able to parse the IPv6 header.There are three different incompatibilities [1]: host-routerincompatibility, router-router incompatibility, and end-to-endincompatibility, as shown in Fig. 1. Incompatibility can failthe Internet connectivity and seriously degrade the overallperformance. Therefore, it is imperative to provide a means oftransitioning or interworking between two types of networks

at both the address level and protocol level to overcome theincompatibilities.

Router 1Host 1

End−to−end incompatibility

Internet

Router 2 Host 2

Host−router incompatibility

Router−router incompatibility

Fig. 1. IPv4/IPv6 incompatibilities.

Internet Engineering Task Force (IETF) is developing anumber of mechanisms to ease the transition from IPv4 toIPv6 [2]. However, none of these transition mechanisms aredesigned to operate in a mobile environment. Mobility adds anew dimension to the transition and interoperability problems.The current mobility solution of IPv6, Mobile IPv6, does notallow mobile nodes to use an IPv4 home address. Moreover,applications perform poorly in a mixed IPv4 and IPv6 mobileenvironment because they do not dynamically support changesbetween IPv4 and IPv6 connectivity. Therefore, it is necessaryto design new transition mechanisms that support dynamiclocation changes of mobile hosts.

In this paper, we focus on the mobility support for IPv4/IPv6transition mechanisms over IPv6 backbone networks. It hasbeen mandated that future mobile telecommunication networkssupport IPv6 as part of the 3GPP Release 5 specification,with IPv4 support defined as optional [3]. Several militaryprograms are also taking approaches to migrate core networkinfrastructure to IPv6 to reduce operational and maintenancecosts of managing both IPv4 and IPv6 infrastructure. Inthis paper, we conduct a comprehensive case study on allthe possible scenarios when a mixture of IPv4 and IPv6mobile hosts communicate with each other over IPv6 backbonenetworks. Design challenges and constraints for each scenarioare investigated. Possible solutions for transition mechanismswith mobility support are proposed.

The rest of this paper is organized as follows. In Section II,background and related work on IPv4 and IPv6 are introduced.Then, in Section III, the details of each scenario in a mixedIPv4 and IPv6 mobile environment and possible solutions foreach case are explained. In Section IV, conclusions are given.

II. BACKGROUND AND RELATED WORK

A. Mobile IPv4 vs. Mobile IPv6

1) Mobile IPv4: Mobile IPv4 is a solution to provide con-tinual Internet connectivity to mobile users over the existingglobal Internet [4]. It introduces three new functional entities:

1-4244-0667-6/07/$25.00 © 2007 IEEE 363

home agent (HA), foreign agent (FA), and mobile node (MN).Each MN has a permanent home address (HoA) from itshome network. When an MN moves out of its home network,it obtains a temporary address: care-of address (CoA). Thisaddress is used to identify the MN in the visited local network.The mobility agent in the visited network, FA, can provide aCoA to the MN that is shared by many MNs or assign aunique, co-located CoA to each MN. When the MN movesfrom one foreign network to another, it registers its new CoAto the HA which is located in the home network. The HAkeeps a binding of the HoA and the current CoA for eachMN. Packets sent from a correspondent node (CN) for an MNare sent to its permanent address, i.e., its HoA first. The HAintercepts all the IP packets destined to the MN and tunnelsthem to the CoA of the MN.

Mobile IPv4 suffers from long handoff delay due to thetriangle routing problem, which is, packets from an MN to aCN can follow the direct path, but packets from a CN to anMN have to be sent to the home network of the MN first.Route optimization [5] is later proposed to solve this trianglerouting problem under which MNs keep updating its CNs ofits new CoA so that packets can be transmitted from a CN toan MN directly.

2) Mobile IPv6: Mobile IPv6 [6] offers a number ofimprovements over Mobile IPv4 mainly due to the capabilitiesinherited from IPv6. It continues to allow MNs to use two IPv6addresses: a HoA and a temporary CoA which is automaticallyallocated on the visited network due to the new addressautoconfiguration feature of IPv6 [7]. Because of the enormousaddress space of IPv6, an MN can acquire a co-located CoAon any foreign link quickly and easily. As a result, the FAfunction is gone from Mobile IPv6.

Route Optimization is embedded in Mobile IPv6, whichmeans, an MN periodically sends Binding Update messagesnot only to the HA, but also to its CNs. Each CN maintains alocal Binding Cache of bindings known to it so that packetscan be routed directly to an MN, thus avoiding the trianglerouting problem. The HA is still responsible for forwardingpackets to the MN sent from CNs unaware of the new CoAof this MN.

B. IPv4/IPv6 Transition Mechanisms

Three transition mechanisms are developed by IETF toovercome the IP header incompatibility problem between IPv4and IPv6 [2].

1) Dual Stack: Dual protocols can be used to support bothIPv4 and IPv6 concurrently. Dual stack mechanism consistsof installing both an IPv4 and an IPv6 stack in a host or arouter. For a host, an IPv6-based application communicateswith IPv4 hosts through the IPv4 stack, while communicateswith IPv6 hosts through IPv6 stack. The selection of the stackcan be a function of the IP destination address (IPv4 or IPv6)given by the user or by the result of a DNS (Domain NameSystem) resolution. For a router, it has both an IPv4 and anIPv6 protocol at the network layer. The value in the versionfield of the datagram header is then used by the link layerprotocol to pass a datagram to the appropriate IP. In this way,the upper layer protocols are unaware of the type of IP beingused at the network layer.

The dual stack mechanism needs the installation of bothIPv4 and IPv6 stacks. It makes the assumption that every node

will be updated and will need both stacks during a transitionperiod.

2) Tunneling: Tunneling is used to transfer a packet relatingto one type of network layer protocol across a network thatuses a different type of network layer protocol. For example,an IPv6 packet can be encapsulated within the payload portionof an IPv4 packet and forwarded to a remote IPv6 networkover an IPv4 network. This is called IPv6 over IPv4 tunneling.On receipt of the packet, the IPv4 in the edge router whichis located at the boundary of IPv4 and IPv6 networks andcontains dual IP stacks decapsulates the IPv4 packet andpasses the original IPv6 packet to the IPv6 layer. The latterthen forwards the packet to the destination host.

The tunneling mechanism does not affect the functionalityof services running above IP. It can overcome the host-routerand router-router incompatibilities.

3) Translation: In the case of end-to-end incompatibility,both the addresses and the packet formats are different.Therefore, a translation operation must be carried out by anintermediate router/gateway, NAT-PT gateway [8]. It involvesa network address translator (NAT) and a protocol translator(PT). A NAT-PT device resides at the boundary between anIPv6 and IPv4 network. The NAT has a pool of globallyroutable IPv4/IPv6 addresses. For each new session from theIPv6 site, it allocates an unused IPv4 address from the addresspool for the duration of the session. The NAT translatesbetween one address and the other as the packet is relayed. Theprotocol translation operation is concerned with translating theremaining fields in the packet header.

The translation mechanism attempts to provide transparentrouting to overcome the end-to-end incompatibility. However,it is essential that all packets belonging to a session musttraverse the same NAT-PT device. Moreover, the protocoltranslation can only be carried out at a best-effort basis.

III. CASE STUDY OF MOBILITY SUPPORT OVER IPV6BACKBONE NETWORKS

In the rest of the paper, we assume both MNs and CNscan be hosts with either IPv4-only implementation, IPv6-only implementation, or both IPv4 and IPv6 implementation,i.e., with dual stack implementation. An IPv6-only node oran IPv4-only node has only one permanent HoA, while anIPv4/IPv6 node has two HoAs. IPv6-only and IPv4/IPv6 nodeshave Mobile IPv6 implementations as the mobility solution.IPv4-only and IPv4/IPv6 nodes support Mobile IPv4. The HAis the mobility agent responsible for mobility management ofMNs. There are nine possible communication scenarios basedon the node type of an MN and CN, as listed in Table I. AnMN and CN communicate with each other over IPv6 backbonenetworks.

TABLE ICOMMUNICATION SCENARIOS IN A MIXED IPV4/IPV6 ENVIRONMENT

Mobile Node (MN)Correspondent Node (CN) IPv6 IPv4 IPv4/IPv6

IPv6 Case 1 Case 2 Case 3IPv4 Case 4 Case 5 Case 6

IPv4/IPv6 Case 7 Case 8 Case 9

We conduct comprehensive case study for all the ninescenarios and propose different solutions to facilitate com-

1-4244-0667-6/07/$25.00 © 2007 IEEE 364

munications under different scenarios. We propose to usea dual stack HA. Besides the basic functions defined inMobile IPv4 and Mobile IPv6 such as maintaining a bindingcache and forwarding packets to and from MNs, the HA isalso responsible for tunneling and translation under differentscenarios. Since tunneling-based mechanisms appear to bemore apt for mobile networks due to their transparency andtranslation-based mechanisms introduce different challenges,the translation mechanism is selected by the HA only whenend-to-end incompatibility problem arises.

A. Case 1: IPv6 MN vs. IPv6 CN

Mobile IPv6 is the adopted mobility solution. No specialtransition mechanism is required under this case.

B. Case 2: IPv4 MN vs. IPv6 CN

As shown in Fig. 2, this scenario causes end-to-end incom-patibility and translation mechanism is required to overcomethis incompatibility.

CNMN

IPv6 Backbone IPv6−only

Dual−stack

IPv4−only

HA

Fig. 2. Case 2: MN is IPv4-only host and CN is IPv6-only host.

When the CN is unaware of the current CoA of the MN, itputs the HoA of the MN as the destination address for outgoingpackets. Since the HoA of the MN is an IPv4 address with32 bits long, the CN needs to map the IPv4 HoA into anIPv6 address which is 128 bits long. Several industry standardtechniques are proposed for the address mapping between IPv4and IPv6, including padding the first 96 bits of the IPv6address with zeros and fill the rest 32 bits with the bytevalue of the IPv4 address. This type of address is called IPv4-compatible IPv6 address [2].

IPv6 packets from the CN containing the IPv4-compatibleIPv6 HoA of the MN as the destination address are carriedover the IPv6 backbone network and reach the HA of theMN which is located at the boundary of the IPv4 accessnetwork and the IPv6 core network. The translator inside theHA performs both address and protocol translation to convertIPv6 packets to IPv4 packets. It first assigns an unused IPv4address from its address pool as the source address for all thepackets destined to the MN. It records the mapping of the IPv6address of the CN and its equivalent temporary IPv4 address.Then, the HA obtains the HoA of the MN by extracting thelast 32 bits in the IPv4-compatible IPv6 address. The HAlooks up its binding cache and finds the current CoA of theMN. In addition, the translator conducts protocol translationfor the remaining fields in the IPv6 packets. At last, the HAforwards the translated IPv4 packets to the MN. Since underthis scenario, all the packets from the CN are first transmittedto the HoA of the MN, it is guaranteed that all the IPv6 packetstraverse the same HA for translation.

When the CN is aware of the current CoA of the MN, itfollows Mobile IPv6 operations, which means, the CN putsthe IPv4-compatible IPv6 CoA of the MN as the destinationaddress in the header of the outgoing IPv6 packets. These

packets are routed over IPv6 networks to an edge routerbetween IPv4 access network and the IPv6 core network.Usually, edge routers located at the boundary of two typesof networks are dual stack routers with both IPv4 and IPv6implementations. The IPv6 packets from the CN could betranslated by the edge router to IPv4 packets if the edge routeris also an NAT-PT gateway. However, in order to ensure thatall packets belong to a session must traverse the same NAT-PT device, we propose that the translation of the IPv6 packetsfrom a CN to an MN can only be performed by the HA of theMN. Thus, when translation function is needed, the edge routerneeds to forward these IPv6 packets to the HA. It obtains theHoA of the MN from the IPv6 routing header which is anextension header after the main header in IPv6 packets. Themain content in the routing header is the HoA of the MN.Hence, the edge router encapsulates the original IPv6 packetsinside IPv4 packets with the HoA of the MN as the destinationaddress and its own IPv4 address as the source address in theIPv4 packet header. The HA decapsulates these packets andfurther translates and forwards them to the MN according tothe procedures described above.

The advantage of this solution is that it works in a mannerthat is transparent to the CN. The CN follows Mobile IPv6operations without any change. The drawback is that thepackets traverse route is no longer optimal even when the CNis aware of the current CoA of the MN. These packets haveto go through the HA for translation. However, this is not aserious problem since Mobile IPv4 does not provide route op-timization function. Therefore, when IPv6 hosts communicatewith IPv4 hosts in a non-optimal manner, it is no worse thantwo IPv4 hosts communicate with each other [1].

C. Case 3: IPv4/IPv6 MN vs. IPv6 CN

As shown in Fig. 3, the access network for the MN canbe either an IPv4, IPv6, or IPv4/IPv6 network with all thenodes (both routers and hosts) possessing dual stacks. End-to-end incompatibility is no longer in this case since theMN can parse the IPv6 packet header. Therefore, translationmechanism is unnecessary for Case 3. Instead, the HA usestunneling transition mechanism.

IPv6 Backbone

MNDual−stack

IPv6−onlyIPv4/IPv6

IPv4−onlyIPv6−only

Dual−stackHA CN

Fig. 3. Case 3: MN is IPv4/IPv6 host and CN is IPv6-only host.

1) The access network of the MN is an IPv4 network:There are two possible scenarios for this case:

CN initiates communications: The CN sends out IPv6packets. When the HA of the MN receives these IPv6 packets,it performs IPv6 over IPv4 tunneling with the IPv4 HoA ofthe MN as the destination and the IPv4 address of the HA asthe source address in the outer IPv4 packet header. The MNdecapsulates these packets and gets the original IPv6 packetsfrom the CN. Similar tunneling operations are conducted atedge routers if IPv6 packets from the CN do not go throughthe HA of the MN.

1-4244-0667-6/07/$25.00 © 2007 IEEE 365

MN initiates communications: The MN prepares IPv6packets with its IPv6 HoA as the source address and theIPv6 address of the CN as the destination address in thepacket header. Then, the MN encapsulates these packets inthe payload of IPv4 packets with its IPv4 HoA as the sourceaddress and the IPv4 address of the HA as the destinationaddress. These encapsulated IPv4 packets are tunneled to theHA of the MN. The HA decapsulates the packets and forwardsthe IPv6 packets to the CN over the IPv6 backbone network.

2) The access network of the MN is an IPv6 or IPv4/IPv6network: This is similar to Case 1. Mobile IPv6 is the solution.

D. Case 4: IPv6 MN vs. IPv4 CN

As shown in Fig. 4, this scenario also causes end-to-end incompatibility and translation mechanism is required toovercome this incompatibility.

MN NAT−PTGateway

IPv6−only IPv4−only

CN

IPv6 Backbone

Fig. 4. Case 4: MN is IPv6-only host and CN is IPv4-only host.

The MN maps the IPv4 address of the CN into an IPv4-compatible IPv6 address and puts it in the IPv6 packet headeras the destination address. The MN follows Mobile IPv6operations and sends out IPv6 packets to the CN. When thesepackets reach the boundary of IPv4 access network of theCN and the IPv6 backbone network, a NAT-PT gateway isnecessary at the boundary of the two networks to translatethese packets into IPv4 packets. Translated IPv4 packets aredelivered over the IPv4 access network to the CN.

E. Case 5: IPv4 MN vs. IPv4 CN

For the scenario shown in Fig. 5, IPv4 packets sent by theCN or MN are carried over the IPv4 access network. TheseIPv4 packets reach a dual stack edge router residing at theboundary of the IPv4 access and IPv6 backbone networks. Thedual stack edge router maps the IPv4 source and destinationaddresses into IPv4-compatible IPv6 addresses. It then con-ducts IPv4 over IPv6 tunneling by encapsulating IPv4 packetsinto IPv6 packets with IPv4-compatible IPv6 addresses as thesource and destination addresses in the IPv6 packet header.These IPv6 packets are carried by the IPv6 backbone networkand reach another edge router. The original IPv4 packets areextracted by the edge router and forwarded.

IPv6 BackboneEdge RouterDual−stack

IPv4−only

MN

IPv4−only

CNHADual−stack

Fig. 5. Case 5: MN is IPv4-only host and CN is IPv4-only host.

F. Case 6: IPv4/IPv6 MN vs. IPv4 CN

As shown in Fig. 6, the access network for the MN can beeither an IPv4, IPv6, or IPv4/IPv6 network.

1) The access network of the MN is an IPv4 network: Thisscenario is the same as Case 5.

Dual−stack

IPv6−onlyIPv4−only

IPv4−only

MN HACNDual−stack

IPv6 BackboneIPv4/IPv6

Edge RouterDual−stack

Fig. 6. Case 6: MN is IPv4/IPv6 host and CN is IPv4-only host.

2) The access network of the MN is an IPv6 or IPv4/IPv6network: Tunneling transition mechanism is used for this case.

CN initiates communications: The CN conducts the DNSquery and gets the IPv4 HoA of the MN. It follows MobileIPv4 procedures and sends out IPv4 packets to the HoA ofthe MN. The edge router located at the boundary of the IPv4access network of the CN and the IPv6 backbone networkperforms IPv4 over IPv6 tunneling. The encapsulated IPv6packets reach the dual stack HA of the MN. The HA finds thecurrent CoA of the MN from its binding cache and tunnelsthese IPv6 packets to the CoA of the MN.

MN initiates communications: The MN prepares IPv4packets to the CN and encapsulates these packets into IPv6packets. When these IPv6 packets reach a dual stack edgerouter residing at the boundary of the IPv4 access network ofthe CN and the backbone, the edge router obtains the innerIPv4 packets and forwards them to the CN.

G. Case 7: IPv6 MN vs. IPv4/IPv6 CN

As shown in Fig. 7, the access network for the CN can beeither an IPv4, IPv6, or IPv4/IPv6 network.

CN

IPv4−onlyIPv6−only

Dual−stack

IPv4/IPv6IPv6 Backbone

Edge RouterDual−stack

MN

IPv6−only

Fig. 7. Case 7: MN is IPv6-only host and CN is IPv4/IPv6 host.

1) The access network of the CN is an IPv4 network: OnlyIPv4 packets can be delivered to and from the CN over theIPv4 access network.

CN initiates communications: No matter whether the CNis aware or unaware of the current IPv6 CoA of the MN, itprepares IPv6 packets with its own IPv6 address as the sourceaddress in the packet header. Then, the CN encapsulates theseIPv6 packets into IPv4 packets with its IPv4 address as thesource address in the IPv4 header. Depends on how the tunnelentry point, i.e., the CN, discovers the IPv4 address of thetunnel exit point, i.e., a dual stack edge router located at theboundary of the IPv4 access network and the IPv6 backbonenetwork, manual configured tunneling and dynamic automatictunneling are proposed [2].

The encapsulated IPv4 packets travel over the IPv4 accessnetwork of the CN and reach one dual stack edge router. Thedual stack edge router decapsulates these packets and forwardsthe inner IPv6 packets to the MN through IPv6 backbone andaccess networks.

MN initiates communications: The MN queries the DNSfor the IP address of the CN. The MN may get both IPv4and IPv6 addresses of the CN or only the IPv6 address. If theDNS resolver library returns two addresses, we propose thatthe MN chooses the IPv4 address of the CN and converts it to

1-4244-0667-6/07/$25.00 © 2007 IEEE 366

TABLE IITRANSITION MECHANISMS FOR MOBILITY SUPPORT IN A MIXED IPV4/IPV6 MOBILE ENVIRONMENT

End-to-end Main transition Main location implementing Version ofincompatibility mechanisms adopted transition mechanisms mobility solution

Case 1 No N/A N/A Mobile IPv6Case 2 Yes Dual stack & translation Dual stack HA Mobile IPv6 (CN → MN)Case 3 No Dual stack & tunneling (IPv6 over IPv4) Dual stack HA & edge router Mobile IPv6 (CN → MN)Case 4 Yes Dual stack & translation NAT-PT Mobile IPv6 (MN → CN)Case 5 No Dual stack & tunneling (IPv4 over IPv6) Dual stack HA & edge router Mobile IPv4Case 6 No Dual stack & tunneling (IPv4 over IPv6) Dual stack HA & edge router Mobile IPv4 (CN → MN)Case 7 No Dual stack & tunneling (IPv6 over IPv4) Dual stack edge router Mobile IPv6Case 8 No Dual stack & tunneling (IPv4 over IPv6) Dual stack HA & edge router Mobile IPv4Case 9 No Dual stack Dual stack edge router Mobile IPv6

IPv4-compatible IPv6 address to reduce operations at the edgerouter located at the boundary of the IPv6 backbone networkand the IPv4 access network. The MN sends IPv6 packets tothe CN and these packets reach one edge router. The edgerouter conducts IPv6 over IPv4 tunneling by encapsulatingIPv6 packets into IPv4 packets and forwards IPv4 packets tothe CN. The source address in the outer IPv4 packet header isthe IPv4 address of the edge router. The destination addressis the IPv4 address of the CN. If the edge router cannot getthe IPv4 address of the CN from the IPv6 packet header itreceives, it will conduct a DNS query. After receiving theencapsulated IPv4 packets, the CN can extract the originalIPv6 packets and also uses the edge router IP address as thetunneling exit point for packets initiated from the CN.

2) The access network of the CN is an IPv6 or IPv4/IPv6network: This is similar to Case 1. Mobile IPv6 is used.

H. Case 8: IPv4-only MN vs. IPv4/IPv6 CN

As shown in Fig. 8, the access network for the CN can beeither an IPv4, IPv6, or IPv4/IPv6 network.

IPv4/IPv6IPv6−onlyIPv4−only

IPv4−only

MN Dual−stackHA CN

IPv6 Backbone

Dual−stackEdge RouterDual−stack

Fig. 8. Case 8: MN is IPv4-only host and CN is IPv4/IPv6 host.

1) The access network of the CN is an IPv4 network: Thisscenario is the same as Case 5.

2) The access network of the CN is an IPv6 or IPv4/IPv6network: There are two possible scenarios for this case:

CN initiates communications: The CN prepares IPv4packets and encapsulates these packets into IPv6 packets.It converts the IPv4 CoA or HoA of the MN into IPv4-compatible IPv6 address, depending on whether it is awareor unaware of the current CoA of the MN. The IPv6 packetsare delivered through the access network of the CN and theIPv6 backbone network until they reach the HA of the MN ora dual stack edge router residing at the boundary of the IPv4access network of the CN and the backbone. The HA or theedge router obtains the inner IPv4 packets and forwards thesepackets to the CoA of the MN.

MN initiates communications: The MN sends out IPv4packets to the IPv4 address of the CN. The edge routerlocated at the boundary of the IPv4 access network of theMN and the IPv6 backbone network performs IPv4 over IPv6

tunneling. The CN decapsulates these IPv6 packets and obtainsthe original IPv4 packets from the MN.

I. Case 9: IPv4/IPv6 MN vs. IPv4/IPv6 CN

Under this case, both the MN and CN have dual stackIPv4/IPv6 implementations and they can roam using MobileIPv6 to maintain connections.

J. Summary

Solutions of mobility support for IPv4/IPv6 transition mech-anisms are explained for all the scenarios based on the nodetype of an MN and CN. Table II summarizes all the scenariosdiscussed above. The proposed solutions utilize the three mainIPv4/IPv6 transition mechanisms and tailor them into a mixedmobile environment. From the table, we may observe thatthe translation mechanism is adopted only when end-to-endincompatibility occurs. In addition, the dual stack mechanismis combined with other mechanisms to expand its applicability.

IV. CONCLUSION

In this paper, we conducted a comprehensive case studyon mobility support for IPv4/IPv6 transition mechanisms overIPv6 backbone networks. We presented the details of mobilitysolutions for each possible communication scenario whena mixture of IPv4 and IPv6 hosts coexist. To the best ofour knowledge, this paper is the first to provide in-depthcase study on IPv4 and IPv6 co-existence involving mobiledevices. It is aimed at conveying to the research communitythe importance of considering the impact of mobility on thedesign of IPv4/IPv6 transition mechanisms.

REFERENCES

[1] H. Soliman, Mobile IPv6: Mobility in a Wireless Internet. AddisonWesley, 2004.

[2] R. Gilligan and E. Nordmark, “Transition mechanisms for IPv6 hosts androuters,” Request for Comments (RFC) 2893, IETF, August 2000.

[3] “Overview of 3GPP Rlease 5 – summary of all Rlease 5 features,” 3GPPTdoc SP-030336, ETSI, 2003.

[4] C. E. Perkins, “IP mobility support for IPv4,” Request for Comments(RFC) 3220, Internet Engineering Task Force (IETF), January 2002.

[5] C. E. Perkins and D. B. Johnson, “Route optimization in Mobile IP,” In-ternet Draft, Internet Engineering Task Force (IETF), draft-ietf-mobileip-optim-11.txt, Work in Progress, September 2001.

[6] D. Johnson, C. E. Perkins, and J. Arkko, “Mobility support in IPv6,”Request for Comments (RFC) 3775, Internet Engineering Task Force(IETF), June 2004.

[7] S. Thomson and T. Narten, “IPv6 stateless address autoconfiguration,”Request for Comments (RFC) 2462, Internet Engineering Task Force(IETF), December 1998.

[8] T. Tsirtsis and P. Srisuresh, “Network address translation – protocol trans-lation (NAT-PT),” Request for Comments (RFC) 2766, IETF, February2000.

1-4244-0667-6/07/$25.00 © 2007 IEEE 367