a comparative study of ipv4/ipv6 co-existence...

1

A Comparative Study of IPv4/IPv6 Co-existence

Technologies

Jinesh Doshi, Rachid Chaoua, Saurabh Kumar, Sahana Mallya

[email protected], [email protected], [email protected],

[email protected]

A capstone paper submitted as partial fulfillment of the requirements for the

degree of Masters in Interdisciplinary Telecommunications at the University of

Colorado, Boulder, 4 May 2012. Project directed by Dale N. Hatfield.

1 Introduction Prior to implementation of IPv4, engineers and scientists working on ARPANET debated

on the length of an IP address. The debate was between 32-bit and 128-bit address lengths.

Although the consensus was 128-bit, Vint Cerf, in 1977, made the decision to use a 32-bit length

for the IPv4 address. He made this decision because he never foresaw the need for more than 4.3

billion address and wanted to move the project forward [1]. Thus, IPv4 was to be 32-bits long

and the internet was born. On the 3rd of February 2011, the Internet Corporation for Assigned

Names and Numbers (ICANN) handed out the last block of the IPv4 addresses [2].

The resulting scarcity of IPv4 address blocks leads to gradual depletion of IPv4 address

space. In order to save and reuse the address blocks, service providers (SP) resort to mechanisms

like multiple layers of Network Address Translation (NAT). The more ideal approach to solve

the issue of address scarcity facing the networking industry is to move towards the IPv6

addressing scheme.

IPv6 provides 3.4 x 1038

addresses and comes with other additional improvements. First,

it provides increased efficiency in routing. Second, it provides faster packet processing. Third, it

supports multicast thereby overpowering the hassles of broadcasting packets. Fourth, it avoids

network address translation (NAT), therefore, proves to be more robust [3].

IPv6 adoption has been slow and faces numerous obstacles. First, there is no true

financial driver for companies. The exhaustion of IPv4 address space has been advertised for

years and the industry has developed technology to extend IPv4 address usage. The most popular

of these technologies is Network Address Translation (NAT). NAT helped to push out the

exhaustion of IPv6 by roughly a decade. This has bought time for IPv6 to mature further.

During this year’s world IPv6 day, the goal is to enable approximately one percent of the

Internet with IPv6 support. This is not an estimate of actual IPv6 traffic. The experts expect

IPv6 traffic to increase exponentially in the coming years.

1.1 Research Question

The need of the hour is to enable IPv6 capabilities on all existing networks. However,

IPv4 networks cannot upgrade to IPv6 networks immediately. This is partially due to the

perception of the technical immaturity of IPv6 as compared to IPv4. Also, service providers are

highly risk-adverse and are not receptive to new changes so instantly. Additionally, there is a

lack of IPv6 awareness. The technical incompatibilities to convert all the network devices to

2

understand IPv6 instantly is another issue that must be met. These factors lead us to look for

alternatives that support co-existence of IPv4 and IPv6 addressing schemes in networks [4].

The deployment of IPv6 is a phenomenon that has started and is set to grow further in the

years to come. There are many issues and obstacles to achieve 100% IPv6 networks directly.

Therefore, this paper focuses on the transitional technologies and strategies required to achieve

IPv4-IPv6 co-existent networks.

2 Scope & Assumptions This research paper comments on some of the common transition technologies that would

facilitate the co-existence of both IPv4 and IPv6 addresses in the coming years. This research

paper provides a cable provider-centric approach in describing the transition technologies. Our

research paper only discusses existing co-existence technologies and tries to determine the

advantages and disadvantages in the transition techniques we've researched. Additionally, our

research is focused on those technologies being considered for deployment by our interviewees.

Those technologies are Large Scale Network Address Translation (LSN), Dual Stack, IPv6 rapid

deployment (6rd), Dual Stack Lite (DS-Lite), and NAT64. Our observations and conclusions are

based on our interactions with the industry experts in IPv6 as well as academic research.

Our research paper follows certain assumptions. The first assumption is that additional

IPv4 addresses will not be available in the immediate future as a result of IPv4 exhaustion.

Secondly, that transitioning to IPv6 or implementing IPv4 extension technology are the only

solutions that will solve the problem of IPv4 address exhaustion.

3 IPv6 Adoption Strategies & Technologies

Native Dual Stack

The Dual Stack implementation consists of a network topology that provides the ability

to route and forward IPv4 and IPv6 packets. This functionality can be at just the customer's

environment, on the SP's network core, its edges, or some other combination. The dual stack

approach can be deployed across the entire network or in regional areas but in order for the dual

stack approach to work, protocol continuity for packets in transit must be met [6].

Translation Technologies

Translation technologies translate one protocol into another protocol. This facilitates

interoperability between the protocols. There are many transitional technologies. In this paper,

we focus on NAT64 as most of the interviewees cited this translation technology the most.

NAT64/DNS64

NAT64/DNS64 uses a protocol translation technology that connects IPv6 users to IPv4

services. The clients devices in NAT64 are IPv6 enabled and it gets translated to IPv4 at the

NAT64 server. Thus the data available only via IPv4 can be retrieved and returned to an IPv6

user [6].

3

Figure 1 - NAT64 with DNS64

Tunneling Technologies

Tunneling is used when there are two isolated hosts that wish to communicate over a

network that does not support its protocol stack. Tunneling allows new network technologies to

be implemented while using the existing network infrastructure. One of the major issues inherent

in the tunneling approach, is the requirement to configure each tunnel endpoint [7].

IPv6 tunneling technologies have been widely explored. Examples of this technology are

Teredo, ISATAP, 6to4, 6rd, 4to6 and DS-Lite. The focus of this paper will be on 6rd and DS-

Lite. These technologies were focused on because the companies interviewed cited these

tunneling technologies the most.

IPv6 rapid deployment on IPv4 infrastructure (6rd)

6rd uses the IPv4 network to deliver "production" level IPv6 services to customers while

minimizing the amount of change required to the SP's network [8]. 6rd uses the core mechanisms

of 6to4 tunneling. The major difference between the 6rd and 6to4 is that 6rd uses the service

provider's (SP) IPv6 address prefix versus a well-known prefix (2002::/16) [8]. Since the IPv6

prefix used is the SP's, the 6rd tunnels are controlled by the SP. This allows the SP's network to

appear to be a native IPv6 network to other networks (including the customer's site) [8]. The

tunnel setup and teardown itself is stateless and automatic [9]. 6rd consists of customer edge

(CE) routers and border relays (BR). CEs are also known as residential gateways or customer

premise equipment. The function of CEs is to initiate the 6rd tunnel at the customer's site. BRs

are routers that are managed by the SP at the edge of the 6rd domain. It terminates the 6rd tunnel

and then transmits the IPv6 packet into the IPv6 network [7].

4

Figure 2 - IPv6 Rapid Deployment (6rd)

Dual-Stack Lite (DS-Lite)

DS-Lite uses NAT44 (also referred to as Carrier Grade NAT, CGN) and IPv4-in-IPv6

(4to6) tunneling to transport IPv4 packets across an IPv6 network to an IPv4 destination. DS-

Lite is used to allow all IPv4 traffic that traverses an SP's network after the core of the network is

IPv6. The two main components of DS-Lite are the Basic Bridging Broadband (B4) device and

the Address Family Transition Router (AFTR) [10].

The B4 component is used to connect the IPv4 customer network with the SP's IPv6

network. This function is typically performed at the customer's gateway device. The B4

component initiates a tunnel across the IPv6 network to the AFTR. The AFTR is the end point

for the 4to6 tunnel and is the access point for the IPv4 portion of the network. After the tunnel is

terminated, the AFTR perform Network Address Translation on the customer's IPv4 address to a

public IPv4 and a dynamically assigned port number [6, 10].

5

Figure 3 – Dual-Stack Lite

IPv4 Extension

Large Scale NAT (NAT444)

In Large Scale NAT, NAT is performed twice. The first layer of NAT is at home gateway

and the second layer of NAT is at CGN. There are three types of IPv4 address blocks in LSN.

IPv4 users inside home gateway will get private address [11] from their home router. This

private IPv4 address is translated at home gateway to the IPv4 address in the block 100.64.0.0/10

assigned by IANA for CGN use. This address gets translated to public IPv4 address at the CGN

[12].

6

Figure 4 - Large Scale NAT

4 Analysis and Findings

4.1 Research Methodology

The transition from IPv4 to IPv6 at its core is a network design problem. In order to move

towards IPv6, Service Providers must upgrade their network to support IPv6 while also

supporting IPv4. This must be done while still providing the same level of service to their

customers. All network upgrades first begin with requirements definitions.

Migrating to IPv6 requires that the following scenarios be designed for:

1. IPv4 devices connecting to IPv4 devices using an IPv4 network for transport








At one point or another during a service provider's transition, they must support one or more of

these scenarios [23]. In order to accomplish this, co-existence technologies are required.

Each scenario listed above falls within one of three transitional technology categories;

native dual stack, tunneling, and translation [7]. Since, IPv4 address exhaustion is inevitable,

IPv4 extension technologies must also be considered a co-existent technology. One important

item to keep in mind in regards to IPv4 address extension technologies is it should ultimately

lead to the retiring of IPv4 use and adoption of IPv6. The diagram (Figure 5) below shows the

transitional/co-existence technology "lanes".

7

Figure 5 - IPv4/IPv6 Co-existence and Transitional Technology "Lanes"

In this paper, scenarios 1, 4, 5, 6, and 8 were the focus. These were the scenarios that

those in the cable industry were most concerned with. These scenarios and their associated

weights are shown in Table 1. The requirements defined by each scenario were ranked and then

weighted. The 50% weight was assigned to the most important requirement (everything

migrated to IPv6). This is considered the most important requirement because a native IPv6

Internet is the end goal. The "all IPv4" scenario was given the lowest weight. It weighted the

lowest because it is counter to the end goal.

Metric/Characteristics/Criteria

Weight Source

Network SP network

Destination

Network

IPv4 IPv4 IPv4 0.05

IPv6 IPv4 IPv6 0.15

IPv4 IPv6 IPv4 0.10

IPv6 IPv6 IPv4 0.20

IPv6 IPv6 IPv6 0.50

Score 1.00

Table 1 - Requirements Rating

8

4.2 Analysis

Native Dual Stack

In our research interviews conducted with industry experts, the dual stack transition

technique came out as an indisputable winner among all other transition techniques. This

technique offers a flexible way to transition to IPv6. Dual stack is the ideal technique to maintain

connectivity with IPv4 only sites while providing IPv6 capabilities as well. On a dual stack

device, the IPv4 protocol stack can be removed at any time [14]. Dual stack routers also cater to

other transition mechanisms such as tunneling that require a dual stack end point.

Dual stack implementations do have limitations. First, upgrading the Customer Premise

Equipment (CPE) in a customer's home is a major challenge [14]. Most subscribers in a cable

network have dated equipment and will not replace it until it no longer functions. Secondly, CPU

power and memory requirements increase in order to run both stacks of IPv4 and IPv6 [15].

There is a need to maintain routing tables for both stacks of IPv4 and IPv6. Unless the hosts are

IPv6 capable as well, dual stack will need a translation technique to offer a transition solution

[16]. Thus dual stack mechanism can only support IPv6-IPv6 or IPv4-IPv4 communication on its

own. Another limitation is the requirement of a DNS resolver that can resolve both IPv4 and

IPv6 addresses. The applications communicating with a dual stack device must have the

capability to determine the protocol stack the host needs to communicate with.

Despite the above disadvantages, dual stack is still the most heavily deployed transition

solution. We found from the interviews we conducted that dual stack capable devices are being

aggressively installed to facilitate transition to IPv6.

Translation Technologies

NAT64

NAT64/DNS64 doesn’t require changes to either the IPv6 client or the IPv4 server thus it

is easily deployable. This technology only requires the implementation of the stateful NAT64

function in the devices connecting an IPv6-only network to the IPv4-only network.

At present, some protocols like Skype, SIP, MSNP and IPsec are not able to traverse

NAT64, either due to lack of IPv6 support or due to incompatibility with any NAT in general

[7].

Tunneling Technologies

6rd

6rd allows SP's to rapidly deploy IPv6 on their network. This is its greatest advantage. Its

stateless, auto-configuration supports multiple points in a network topology. Since, only two

devices are being introduced to the network, infrastructure wide upgrades are not required [8].

The placement of 6rd BRs will impact performance [17, 19]. If the BRs are centrally

located, latency could be introduced into the network path which leads to a negative performance

impact. Strategic BR location is required to minimize this issue [18]. Additionally, the number of

6rd BRs must be large enough to support the network load [17, 19].

6rd does have the ability to be rapidly deployed but it still does not help move a company

to its end goal of IPv6. It is ideal for deployment during the early stages of a SPs IPv6 transition

when a SP is attempting to provide IPv6 service while upgrading their network. This is

especially the case when an SP being their transition to IPv6 well after other firms and want to

begin offering IPv6 services to customers.

9

DS-Lite

DS-Lite will enable continued support for IPv4 services by using NAT44 to extend the

usage of IPv4 address space and incentives for the deployment of IPv6. Also, it separates IPv6

deployment in the service provider network from the rest of the Internet, making incremental

deployment easier. DS-Lite facilitates the extension of IPv4 addresses by using IPv4-in-IPv6

tunneling and NAT44. The NAT44 allows SPs to use private IP addresses in their network while

consolidating the public facing IPv4 address. Additionally, it encourages users to migrate to IPv6

since their B4 is IPv6 capable [6].

DS-Lite isn’t designed to prolong IPv4 indefinitely. Using NAT44, adds complexity to

the network and costs more to operate and manage the network. [21, 22]. Additionally, the

inherent issues in NAT will be present due to the NAT44 function of DS-Lite [21, 22].

With DS-Lite the home gateway (B4) must support the DS-Lite technology. Most ISPs

do not manage the CPE. Thus, DS-Lite would require an upgrade of the device by the customer

[L. Howard]. Additionally, the IPv4 service would be dependent on IPv6 for transport.

DS-Lite is being considered as the technology of choice by many ISPs in Europe.

However, the ISPs we interviewed have chosen to not deploy this technology.

IPv4 Extension Technologies

NAT444/LSN

Consumer electronic devices are still producing IPv4 only devices. This means that IPv4

will be a customer requirement for some time. LSN allows SP's to allow more IPv4 users on

their network. LSN is the key to extending the life of IPv4 on an SP's network [22]. LSN allows

users to reach the Internet with their existing home gateway. It helps to extend the life of IPv4

[11].

LSN's core function is its ability to share a pool of IPv4 addresses with a multitude of

users. This functionality limits the number of connections available per a user. Also, end user

device identification is lost. Finally, dynamic applications like peer-to-peer applications, video

streaming, and Voice over IP (VoIP) become difficulty to establish and maintain connectivity

[12, 22]. Devices like X-box, Blue-ray, etc. that doesn’t support IPv6 can still run on NAT444.

LSN is the ideal choice to extend the IPv4 address space. Additionally, NAT444 impacts

to application performance must be communicated to end-users and application developers.

Developers should make their applications NAT444 interoperable. Additionally, service

providers should encourage customers to migrate to IPv6 [13, 22]. It is the best practice to

deploy NAT444 in chunk of 10 - 20% of customers to keep failure domains reasonably small.

Carrier Grade NAT Logging

One of the major issues with Carrier Grade NAT (CGN) solutions (e.g. - NAT444,

NAT64, etc.), is that by default it is stateless and does not provide reverse traceability to the

transmitting source. This characteristic makes it extremely difficult to perform network

forensics. The solution to this problem is to keep a log that allows traceability.

It is mandatory for every Internet service provider to keep store NAT logging details. If

there is an attack from a hacker or some other sort of malicious activity that occurs over the

network, it can be tracked. The logging should have details like source address, destination

address, timestamp, source port, destination port and hostname [24, 25].

CGN logging generates a huge amount of data, therefore, it is difficult to store the logs.

For example, in NAT444, a single logging message is between 150 – 450 bytes. If a host initiates

10

33,000 connections/day, then it requires around 5 – 15 MB/day/subscriber. In a network with one

million subscribers, behind a CGN solution, it requires 150 – 450 TB/month and 1.8 – 5.4

PB/year to store the logs [24, 25].

In Dual-Stack Lite, a single logging message is 172 – 542 bytes. Considering the above

logging calculation, it requires 2.1 – 6.3 PB/year to store the logs. In order to retain this data, it

requires a large investment in storage [24, 25]. Hence, to keep logs of NAT444 and Dual-Stack

Lite is a big challenge for Internet service provider.

4.3 Findings

Based on our finding from research, we scored each transition technology. The ranking of

the IPv4/IPv6 co-existence technologies are summarized in Table 2. If a given technology was

able to address the scenario, it scored the weight of that scenario.

Metric/Characteristics/Criteria

Weight LSN Dual

Stack 6rd DSLite NAT64/DNS64 Customer

Network

SP

network

Destination

Network

IPv4 IPv4 IPv4 0.05 X X

IPv6 IPv4 IPv6 0.15 X




Score 1.00 0.05 0.55 0.15 0.10 0.20

Table 2 - IPv4/IPv6 Co-Existence Technology Comparative Analysis

The results of our interviews are summarized in Table 3. The interview responses were

categorized as Agree (A), Disagree (DA), or Neutral. The responses include IPv4/IPv6 co-

existence technologies that the interviewees have considered for deployment. The overwhelming

co-existence technology winner is Dual Stack with NAT64 providing any necessary translation

for those who do not migrated to IPv6 once the SP's core is Native IPv6 only.

Interviewees LSN Dual Stack 6rd DS-Lite NAT64/

DNS64

1 N A N DA N

2 N A N DA N

3 N A N DA A

4 N A N DA A

5 N A N DA N

6 N A N DA N

7 N A N DA A

Table 3 - Interview Results

5 Conclusion Based on our interviews and research, native Dual-Stack is the technology that

companies should consider for their deployment. It keeps both IPv4 and IPv6 running at the

same time. When the network is fully transitioned to IPv6, operators can stop supporting IPv4.

The two protocols must be supported until native IPv6 is the only protocol in use. The cost of

11

operation for Dual-Stack is more than single stack for operators because they have to support

both stacks.

If it is difficult for operators to move directly to native IPv6, then they can go implement

transition technologies. According to our findings, the next best transition technology to deploy

in the network is NAT64. Some of the companies are planning to run NAT64 in their network

and then move to native IPv6 when all the applications and content is available on IPv6. If the

SP’s access network is not IPv6 ready, then they should plan to deploy 6rd in their network.

NAT444 allows customers to run IPv4 services after the exhaustion of IPv4 addresses. However,

this is not a viable long-term solution. Additionally, the implementation of NAT444 will require

investment in a NAT logging infrastructure.

5.1 Further Research

This research paper offers a broad scope of IPv4/IPv6 co-existence technologies ideal for

a cable provider network. There are numerous options for further research. The scenarios (2, 3

and 7) that were not discussed are areas that require further research. In particular further

research on technologies that allow IPv4 hosts to communicate with IPv6 hosts and services is

needed. Additionally, each of the recommended technologies could also be further researched by

exploring performance and implementation issues.

12

List of Interviewees:

1. Trace Hollifield

Director of IP Network Transport Engineering

Bright House networks

Interviewed on February 14, 2012

2. Jason Weil

Principal Engineer for Standards and Policy

Time Warner Cable


3. Fred Baker

Fellow at Cisco

Cisco


4. John Jason Brzozowski

Chief Architect, IPv6 and Distinguished Engineer

Comcast Cable

Interviewed on March 20, 2012

5. Chris Tuska

Lead IPv6 engineers

Comcast Cable


6. Lee Howard

Director, Technology Development

Time Warner Cable


7. Chris Donley

Project Director - Network Protocols

CableLabs


References:

[1] T.A. Limoncelli. “Successful Strategies for IPv6 Rollouts. Really,” Commun. Of the ACM, vol. 54, no. 4, pp. 44-

50, Apr., 2011.

[2] S. Lawson. "Update: ICANN assigns its last IPv4 Addresses," Computerworld, February 03, 2011.

http://www.computerworld.com/s/article/9207961/Update_ICANN_assigns_its_last_IPv4_addresses

[3] M. Levy. "Six Benefits of IPv6," Network Computing, June 08, 2011.

http://www.networkcomputing.com/IPv6/230500009

[4] "Permanent Adoption of IPv6 Moves a Step Closer with World IPv6 Launch," Domain News, January 18, 2012.

http://www.domainnews.com/en/permanent-adoption-of-ipv6-moves-step-closer-with-world-ipv6-launch.html

[5] IANA. "IANA IPv4 Address Space Registry". IANA IPv4 Address Space Registry. Retrieved March 27, 2012.

[6] T. Rooney, "Service Provider IPv6 Deployment Strategies," BT Diamond IP, 2011.

[7] M. Ciglarc et al. "Practical Evaluation of Stateful NAT4/DNS64 Translation," Advances in Elect. And Comput.

Eng., vol. 11, no. 3, pp. 49-55, 2011.

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt











13

[8] W. Townsley and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,"

IETF RFC 5969, Aug., 2010.

[9] J. Wang, "6rd - Enabling IPv6 Customers on an IPv4-only Network," Cisco, 2011.

[10] R. Droms et al., "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion," IETF RFC 6333,

Aug., 2011.

[11] Y. Rekhter et al., "Address Allocation for Private Networks," IETF RFC 1918, Feb., 1996.

[12] C. Donley et al., "Assessing the Impact of Carrier-Grade NAT on Network Applications," IETF Draft, 15 Nov.,

2011.

[13] H. Ashida et al., "NAT444 Addressing Models," IETF Draft, 5 Jan., 2012.

[14] H. M. Tahir, A. Taa, N. B. Nasir, "Implementation of IPv4 Over IPv6 using Dual Stack Transition Mechanism

(DSTM) on 6iNet", Proceedings of the International Conference on Information & Communication Technologies:

From Theory to Applications (lCTTA), vol. 2, pp. 3156 -3162, 2006.

[15] J. Govil, J. Govil, N. Kaur and H. Kaur, "An examination of IPv4 and IPv6 networks: Constraints and various

transition mechanisms", Proceedings of IEEE Sounteastcon, pp. 178-185, April 2008.

[16] D. G. Waddington and F. Chang, "Realizing the Transition to IPv6", IEEE Communications Magazine, vol. 40,

issue 6, pp. 138-147, June 2002

[17] J. Brzozowski, "ISOC Internet ON: Comcast IPv6," Comcast, Dec., 2010.

[18] J. Brzozowski, "Comcast IPv6 Experiences," IETF, 7 Mar., 2011.

[19] J. Brzozowski,"IPv6 Business Case Review: Strategy and Migration," 6UK Launch Event - Comcast, 11

November 2010.

[20] "6rd Configuration Instructions," Comcast, 30 Jun., 2011

[21] Y. L. Lee, " Dual-Stack Lite - Analyzing how to deliver Internet applications over DS-Lite," NANOG 50, 06

Oct., 2010

[22] "IPv6 Large Scale Network Address Translation," Broadband Internet Tech. Advisory Group, Mar. 2012.

[23] M. Bagnulo and F. Baker, "IPv4/IPv6 Co-existence and Transition: Requirements for Solutions," IETF 71. Mar.

2008.

a comparative study of ipv4/ipv6 co-existence...

Documents