An Investigation into

IPv4 to IPv6
Migration Techniques 2012
The following document is a report of a project undertaken by a 4th year IT
Management student in IT Tallaght. The project is part of the last semester in the
final year of the IT Management course. With the problem of IPv4 address
exhaustion becoming an ever increasing issue, the project will look into this topic a
little deeper. The project will take the shape of an investigation which will look
into the migration techniques from IPv4 to IPv6, specifically tunnelling
techniques.

Word Count

Total 9615

References, ToC & Glossary 970

 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Contents
1. Project Introduction + Proposal ................................................................................................................. 3
1.1 Main Tasks (Outline of Work) ............................................................................................................. 4
1.1.1 Task 1........................................................................................................................................... 4
1.1.2 Task 2........................................................................................................................................... 4
2. Literature Review ........................................................................................................................................ 5
2.1 Introduction ......................................................................................................................................... 5
2.2 History of IPv6 .................................................................................................................................... 5
2.2.1 IPv5.............................................................................................................................................. 5
2.2.2 IPv6.............................................................................................................................................. 5
2.3 Current State of IPv4 & IPv6 .............................................................................................................. 6
2.3.1 IPv4.............................................................................................................................................. 6
2.3.2 IPv6.............................................................................................................................................. 7
2.3.3 World IPv6 Day ........................................................................................................................... 8
2.4 Conclusion ........................................................................................................................................... 9
3. Case Study ................................................................................................................................................. 10
3.1 Introduction ....................................................................................................................................... 10
3.2 Tunnelling Techniques....................................................................................................................... 10
3.2.1 Manual Tunnels ......................................................................................................................... 10
3.2.2 Automatic Tunnels ..................................................................................................................... 11
3.2.3 Teredo Tunnels .......................................................................................................................... 12
3.3 Tunnel Implementation ...................................................................................................................... 13
3.3.1 Configured ................................................................................................................................. 13
3.3.2 GRE ........................................................................................................................................... 16
3.3.3 6to4 ............................................................................................................................................ 19
3.3.4 ISATAP ...................................................................................................................................... 22
3.4 Analysis of Results ............................................................................................................................. 24
3.5 Conclusion of Implementation ........................................................................................................... 26
4. Conclusion ................................................................................................................................................. 27
5. References.................................................................................................................................................. 28
6. Glossary..................................................................................................................................................... 30

2
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

1. Project Introduction + Proposal

As the IPv4 address exhaustion becomes more and more of an issue, the idea of implementing IPv6 networks
is fast becoming more of a realistic and logical option for network administrators and IT managers. With this
in mind, there has been migration techniques developed and implemented to slowly help the integration of
IPv6 into a primarily IPv4 world. Mark Townsley, a Cisco Fellow, states in an online article (2011) about
World IPv6 day, “IPv4 has served us remarkably well for the past 30 years. Moving to a new version will not
be easy, but it is essential to the continued growth of the Internet we have come to depend upon.” The purpose
of this project is to investigate the migration techniques that have been developed to help with the continued
growth of the internet, that allow IPv6 networks to coexist with IPv4 networks, and how they perform. The
migration technique being investigated in this project is Tunnelling. While other migration techniques do
exist, tunnelling will be the primary case for investigation.

While there have been many tunnelling techniques developed, this project will not investigate all of them.
Rather a select group of the more commonly discussed and used techniques will be investigated and
implemented. As it stands now, in 2012, these techniques are a very necessary and needed tool; as even with
the address exhaustion of IPv4, the transition to IPv6 has been a slow and minimal one. Figure 1, taken from
the CAIDA website, puts the usage rates for IPv4 & IPv6 (2010) into a visual format. It can clearly be seen
that IPv6 is being used at a very small scale compared to IPv4. The major implications of this image, from a
networking point of view are that, although IPv6 is being used on a very small scale, at least it is finally being
used and implemented.

Figure 1 – CAIDA 2010 IPv4 & IPv6 AS-core Maps. (Klaffy, K., & Huffaker, B. 2010)

3
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

1.1 Main Tasks (Outline of Work)

The project will be separated into two sub-sections; Literature Review & Case Study. This section of the
project will outline both sections in detail, giving an overview of the work and tasks that will be undertaken.
Before any specifics are discussed, it is necessary to point out the intended flow/structure of the overall
project. While the case study involves the major technical aspects of the overall project, the literature review
is used to give a broad knowledge of the problem domain which will then allow the project to take a narrower
journey with the case study at the end. Figure 2 is a simple visualisation of how the project is intended to
flow:

Literature Review
(Provide knowledge of PD)

Technical Case Study

Figure 2 - Visualization of project flow.

1.1.1 Task 1

Firstly, as with any report or project, it is necessary to build up a broad knowledge of the problem
domain/area; this will be done with a Literature Review. It will investigate the history of IPv6, describing how
it has developed over time. The “current state” of each protocol 4 & 6, will lead on from the history. Included
in this section will be a brief investigation into “World IPv6 day.” A day in which many top ICP’s and ISP’s
tested the capabilities of IPv6 over the World Wide Web.

The final part of the literature review will be a short conclusion/comparison. Summarizing the major findings
from the literature reviewed. This literature review will provide a broad knowledge of the problem domain.

1.1.2 Task 2

Task 2 involves the investigation, implementation and testing of the tunnelling techniques. It first involves
investigation into some tunnelling techniques that exist.

The next section of the project will be to implement a couple of the tunnelling techniques, test them and
analyse the data found. This section will provide topologies, commands, screen shots and steps taken to
implement the test networks. Discussion and views will be provided alongside stats and analysis.

4
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

2. Literature Review
2.1 Introduction

As discussed in sub-section 1.1.1, the first major section of this investigation will be a literature review. This
section will review literature around the problem domain of the investigation, providing a broad knowledge of
the domain which will allow the project to flow in the manor intended.

2.2 History of IPv6

2.2.1 IPv5

Questions are often rightfully asked about why there was no IPv5. This section will briefly explain why it
seems a whole internet protocol was ‘skipped’ or forgotten. The reality is IPv5 in a way did exist, it was just
never named after the well-known naming convention of IPv4 (IP - Internet Protocol, v – Version, 4 – The
fourth version of Internet Protocol). ‘IPv5’ or ST2 (Internet Stream Protocol 2), was first discussed in RFC
1190 (1990), and later in RFC 1819 (1995). The protocol is based on previous work by Jim Forgie in 1979.

In the book titled ‘Cisco Self-Study: Implementing Cisco IPv6 Networks’, by Régis Desmeules (2003),
Desmeules states (p.13) in relation to ST2, “ST2 is not a replacement for IPv4. It is designed to run and
coexist with IPv4.” Because of this, ST2 uses the same addressing schemes as IPv4 to identify hosts and is
almost like an ‘add-on’ to IPv4, not a unique Internet Protocol itself.

2.2.2 IPv6

The need for a new IP became a relevant issue in 1990. Due to the foreseen address exhaustion of IPv4, the
IETF began work on a successor. Adding more address spaces was the main port of call for the development
teams, as that was the main problem, but there also began development on new functionality. From there a
group was set up in 1993 by the IETF, this group was labelled the “IPng”. Their job was to investigate all of
the different proposals that were made for a successor and to give recommendations on each.

In December, 1993 RFC 1550 was issued. This RFC was a call for proposals for a successor to IPv4. It was
directed at the internet community as a whole. The RFC documented what was needed and how they should
be presented.

With three major proposals studied (TUBA, RFC 1347; CATNIP, RFC 1707; SIPP, RFC 1752), IPng
recommended the later of the three, SIPP (Simple Internet Protocol Plus). In 1995, RFC 1883 was the first
documented specification of IPv6 as we know it today. The document describes, in detail, how the new IP will
work and the major functional changes that were added. The major changes stated in the RFC are:

- Expanded Addressing Capabilities (32 bits to 128 bits)

- Header Format Simplification (IPv4 Header Fields dropped or made optional)
- Improved Support for Extensions and Options
- Flow Labelling Capability (Ability to label individual packets)
- Authentication and Privacy Capabilities

Following on from 1995, 1996 saw the backbone of IPv6 being developed. Named ‘6bone’, it was made up of
mainly Cisco Routers with IPv6 capabilities. The 6bone was mainly used for testing, with a later expectation
of fostering the full implementation of IPv6. Soon after 6bone was developed, RFC 2073 (1997) was
published. It contained a description of how the IPv6 address space could be a “Provider-Based Unicast
Address Format”, which was “...intended to facilitate scalable Internet routing.” (Rekhter, Et. Al., 1997.)

5
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

To give a better overall visualisation of the evolution and development of IPv6, Figure 4 has been produced.

Figure 4 - IPv6 History Timescale (Desmeules, R. 2003)

When IPv6’s history is put into a visual timescale, it becomes very clear to see the speed at which the protocol
has evolved. With idea’s beginning in and around 1990, it is quite extraordinary to see just 11 years later,
Microsoft adopted it into their OS. It says something about how IPv6 really was becoming a known necessity
to insure the “continued growth of the Internet we have come to depend upon.”

2.3 Current State of IPv4 & IPv6

While the history of anything is important to note, what really matters is what’s happening now and in the
future. To continue on from the previous sections about the history of internet protocols, a brief investigation
will be done into how the protocols are shaped today and into World IPv6 Day.

2.3.1 IPv4

In its current state IPv4 is still the most commonly used internet protocol. Although it is the most commonly
used protocol, as of February 3rd, 2011, IANA’s (Internet Assigned Numbers Authority) supply of IPv4
addresses has been completely emptied; they have no more available addresses to assign (White, B. 2011;
Smith, L. 2011 )

As there are no addresses left, the internet now depends on the implementation of IPv6 on a larger scale. With
its added functionality and larger address space, the depletion of IPv4 addresses could be looked at as an event
that has accelerated development of internet technologies. With the depletion of addresses in mind, the
internet saw the development of not only a whole new protocol (IPv6), but processes like CIDR, NAT
(Network Address Translation, Defined in RFC 1631) and later many other spin off developments (PAT, NAT
Overload, SNAT) that had similar objectives but worked in different ways. The objective of these network
processes was essentially to utilise the use of addresses in a network, and they do that very well.

6
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

2.3.2 IPv6

In a paper titled “Evaluating IPv6 Adoption in the Internet” by Lorenzo Collitti, Google, Inc. he states in the
opening paragraph, “IPv6 adoption, while growing significantly is still low, varies considerably by country,
and is heavily influenced by a small number of large deployments.” This section will look into IPv6 and how
it is currently shaped in today’s technology and internet driven environment.

As mentioned in the previous section, the exhaustion of IPv4 addresses has left IPv6 as the next protocol to
drive the internet and all of the technologies that use it. Now, more than ever, there needs to be a fully
functioning, efficient network in place to allow the incredible growth and development of technology that has
been going on since the 1970’s (The First Personal Computer).

Other than the larger address space, many people are unaware of its other functions and benefits; thus creating
a reluctant attitude toward implementing the protocol. As stated in the paper by Lorenzo Colliti, IPv6 has been
adopted in different amounts by many different countries, and even in the countries that have adopted it, the
deployment of the protocol has been done by a small number of groups on a large scale.

Figure 5, a screenshot of an interactive world map, showing IPv6 adoption rates (%) for each country
indicates only a handful of countries have actually begun implementation of IPv6.

Figure 5 – “Per-Country IPv6 adoption” (Google Statistics, 2012)

The graph shows “...the availability of native IPv6 connectivity around the world”. ‘Native’ connectivity
refers to connectivity to IPv6 without any tunnels. France is the leading country around the world with 4.3%,
followed by Japan with 1.57% native connectivity. On a side note, Ireland (0.14%) is ahead of their close
neighbours the United Kingdom (0.11%).

7
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

2.3.3 World IPv6 Day

The day quoted by NetworkWorld.com, as being “Tech Industries most-watched event since Y2K” was held on
the 8th of June, 2011. The objective of World IPv6 Day was to have a “...successful global-scale trial of the
new Internet Protocol, IPv6.” The trial involved top websites and internet service providers from around the
world participating in a “24-hour test flight” of IPv6. The top participators of the day were Google &
YouTube, Facebook and Yahoo. The interest these organisations provided spurred 1000s of others to get
involved. (worldipv6day.org, 2012)

Results taken from before, during and after the event (Keränen, A. & Arkko, J., 2011; Daigle, L. Et. Al., 2011;
Wijnen, B. Et. Al., 2011) provided a good overview of how the day went. The data analysed proved IPv6 was,
and could be, a great success. The concluding factors of the event were:

- Organised events like this one work very well. The day was a great success; many tests were done by
many large organisations which has cleared up many of the worries that surrounded IPv6.
- Having a date set for an event may increase interest. “People definitely responded to having a date”
(Daigle, L. 2011)
- “Adapting tools for v6 is largest effort” (Lee, D. 2011)
- In relation to delay characteristics, Keränen, A. & Arkko, J. (2011) concluded, “IPv6 often even
faster than IPv4”
- “IPv6/dual-stack works just fine…” (Wijnen, B. Et. Al., 2011)

The implications of these positive conclusions are that the future of IPv6 looks like a bright one. With the tests
that were done and with the people and organisations that did them, it will only create confidence in others to
participate in this ‘movement’ like event of getting IPv6 implemented worldwide.

Since World IPv6 Day, another major day has been organised. In 2012, World IPv6 Launch Day will happen.
The date has been set at the 6th of June, 2011. The idea of this day is to have IPv6 permanently enabled, with
participation expected to be larger, the organisers (The Internet Society, http://www.internetsociety.org/)
expect it to be a massive success. (http://www.worldipv6launch.org/).

8
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

2.4 Conclusion

To conclude this section of the project a final comparative look at the two protocols, 4 and 6.

Benefits may come from implementing IPv6, but there may also be disadvantages. The following is a list
of possible benefits and disadvantages that may come from implementing IPv6 over IPv4.

Benefits
- Larger Address Space - This is the key reason the protocol was developed. The addresses are made up
128bit source and destination addresses. This massive address space would rid the need of NAT for IT
managers and implementers.
- Hierarchical Address Table Structure – Ipv6 provides the ability to have extremely structured
addressing tables. Addresses can have a clear identity to them, going from continent, region, country,
city, and even at the lowest level postal codes. This creates an easily readable address table for
everyone.
- Auto Configuration – The ability to automate address configuration has been made easier with IPv6.
Addresses can auto configure without the use of a DHCP server. This again creates benefits for
anyone implementing an IPv6 network.
- Built in Security – Internet Protocol Security (IPsec) is now built into IPv6. It creates security
standards at which the protocol has to adhere to. All IPv6 networks are required to have this security
standard, which allows for greater secure interaction between networks.

Disadvantages

- Not Widely Deployed – As it is not widely deployed, organisations that do deploy it may have trouble
communicating with other networks around the world.
- Requires Companies to Train Staff – The current working generation have grown up using IPv4 as the
main protocol and addressing mechanism. Companies would have to spend money on training and
education for their employees in order to insure a smooth transition.
- Address Size – This may be considered a small disadvantage, but create this situation in your head. A
help desk worker gets a phone call with a customer or worker complaining about having no internet
connection. Usually one of the first things the help desk worker would do is ask the customer or
worker to open CMD and ping an address. With the maximum of 32 digits in an IPv6 address, not
including the colons, it can be seen how it may frustrate both a help desk worker and a customer to
have to call out all 32 digits over the phone.

ISP’s around the world need to realise IPv4 addresses are no more, migration techniques like tunnelling
and dual stacking are here, and they’re here to stay. The sooner IPv6 is implemented the better, as
inevitably, IPv6 will become the predominant internet protocol used around the world. To conclude this
section of the report, the quote from section 1 sums up the situation of IPv6 and IPv4 very well; “IPv4 has
served us remarkably well for the past 30 years. Moving to a new version will not be easy, but it is
essential to the continued growth of the Internet we have come to depend upon.” – Mark Townsley (2011)

9
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3. Case Study
3.1 Introduction

Following on from the Literature Review, this Case Study section of the report will discuss the tunnelling
techniques used to allow IPv4 and IPv6 networks to coexist. The tunnelling techniques that will be
investigated are Manual Configured and GRE tunnels, Dynamic/Automatic 6to4 and ISATAP tunnels and
finally Teredo tunnels. Tunnels in general are used to carry incompatible or specific data from network to
network. These networks can be IPv6 or IPv4 networks. In most traditional cases, there would be an IPv6 only
network that would use a tunnel to travel over an IPv4 network. In recent times, the use of ‘Dual Stacking’
along with tunnelling has become a favourable option. In RFC 2893, it is stated that “The key to a successful
IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers.” Tunnels create this
compatibility, as they enable the use of the heavily built up IPv4 internet network to transport IPv6 packets.

3.2 Tunnelling Techniques

Tunnelling Techniques can be separated into two different ‘types’, Manual and Automatic. There are pros and
cons to each, and this section will investigate them and the proceeding section will provide results from
implementing and testing some of these techniques.

3.2.1 Manual Tunnels

3.2.1.1 Configured

A Configured tunnel (Also known as 6in4 or IPv6IP) as described in RFC 4213, was one of the first
tunnelling transition mechanisms supported. A configured tunnel is manually enabled and configured on dual-
stack nodes. On each side of a configured tunnel a Local IPv4, Far-End IPv4 and Local IPv6 address have to
be manually configured in order for the tunnel to function correctly. Configured tunnels work by
encapsulating IPv6 packets within IPv4 headers; these are then carried over a built up IPv4 network.
(Nordmark, E. & Gilligan, R., 2005; Desmeules, R., 2003)

Pros
 Increased Network Knowledge – Both the source and destination addresses of a configured tunnel are
known, this can increase a network managers ability to understand a network, as the addresses provide
more information about how it is structured.
 Security Features – With the destination and source IPv4 addresses being known, security features like
firewalls and ACL’s can be enabled on routers.
 Increased Manageability – If there is many configured tunnels within a network, a network administrator
has the ability to disable an entire tunnel just by shutting down an interface.

Cons
 Additional Coding – As each local ipv4 address, far-end ipv4 address and local IPv6 address must be
configured manually, it creates more lines of code required for the tunnel to be implemented and
configured. The code required for these tunnels will be looked at in the next section.

10
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.2.1.2 GRE

Described in RFC 2784, the GRE tunnelling technique is essentially a packet translation technique that uses
virtual tunnels to transport encapsulated packets. GRE will encapsulate the initial packet which is created (e.g.
IPv6 packet) with a GRE header, this GRE packet can then be encapsulated into another protocol (e.g. IPv4
packet) and forwarded to its destination address. When the packet arrives at its destination at the end of the
tunnel, the packet is de-capsulated and the GRE header is removed to show the original packet. (Farinacci, et
al., 2000; Packeer, A., 2008; Morgan, B. & Lovering, N., 2007)

The pros and cons of the GRE tunnelling technique are described in the book CCNP ISCW Official Exam
Certification Guide (Ch. 14), by Brian Morgan and Neil Lovering, 2007:

Pros
 Multiprotocol Properties – GRE can tunnel any OSI Layer 3 protocol over IP; this gives it VPN
characteristics, which in turn means it is basically a point-to-point private connection.
 Greater Tunnelling Features – GRE allows routing protocols like OSPFv3 and EIGRP to function across
connections.

Cons
 Stateless – GRE tunnels are stateless; the endpoints do not organise packets with any parameters before
sending them. As long as a tunnels destination is reachable, traffic can flow through it, thus GRE offers no
flow control mechanisms.
 Additional 24-Byte Overhead – GRE adds a 24-byte header overhead to the packets sent through the
tunnel. 20-bytes are used up for the new IP header, which indicates the source and destination IP’s of the
GRE tunnel, and 4 bytes are the GRE header itself.
 Weak Security Features – A GRE header provides an optional security key mechanism. This mechanism
is weak, which results in GRE having low confidentiality and no data source authentication or data
integrity mechanism.

3.2.2 Automatic Tunnels

3.2.2.1 6to4

6to4 tunnels make use of the 6in4 tunnelling mechanism of encapsulating IPv6 packets within IPv4 packets.
What makes 6to4 different is that it dynamically assigns the source and destination IPv4 addresses to create
tunnels. This is done by relay routers that retrieve the IPv6 addresses of packets originating from IPv6 nodes
on 6to4 sites, which also means a tunnel interface only needs a source address. 6to4 must be enabled on
networks border routers to insure proper functionality (i.e. the routers within a private network that are also
connected to the outside/public network.) 6to4 was created to make it easier for IPv6 to be implemented, by
reducing the manual configurations required. (Desmeules, R., 2003; Carpenter, B. & Moore, K., 2001;
Packeer, A., 2008; Cisco, 2005)

Pros
 Reduced Code – Because of its automated functionality, the destination addresses are dynamically
retrieved. This reduces the need for an administrator to manually configure static routes.
 Wide Vendor Support – Due to its wide spread use and its simplicity, vendors have supported it. Because
of this, there is a wide range of support for anyone implementing it.

11
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Cons
 No NAT – The 6to4 mechanism does not allow managed NAT to be employed along the tunnel paths.
(Huitema, C., 2006)
 Address Restriction – 6to4 tunnels only provide /48 address blocks; this creates a restriction on the
amount of addresses that can be present on the tunnels.
 Security Issues – Due to the mix of IPv4 and IPv6 addresses in each packet, the ability to spoof addresses
within a packet header has been made easier. This has created some security considerations for Denial of
Service attacks. (Savola, P. & Patel, C., 2004)

3.2.2.2 ISATAP

Intra-Site Automatic Tunnel Addressing Protocol is another form of automatic tunnelling. It follows the same
principle as many other mechanisms; transporting IPv6 packets through tunnels in a predominantly IPv4
network that contains dual-stacked nodes. ISATAP encapsulates IPv6 packets within an IPv4 packet; this
enables IPv6 packets to travel throughout an IPv4 network. ISATAP differentiates itself in a few ways. It
allows individual dual stack hosts within a network to contact each other; this basically creates a virtual IPv6
network over an already existing IPv4 network, as ISATAP views the IPv4 network as a link layer for IPv6
traffic. ISATAP uses a specific type of IPv6 address to identify itself. The address contains a /64-bit unicast
address and a /64-bit interface identifier. The interface identifier is split up into two parts; a /32-bit ISATAP
identifier (000:5EFE) which indicates the address is an ISATAP address and a /32-bit IPv4 address. This IPv4
address is the address assigned to the ISATAP host, as the host must be a dual-stack machine; it has to have
an IPv4 address. When the IPv6 address is encapsulated within an IPv4 packet, the source address within the
header would also be this IPv4 address. (Templin, et al. 2008; Cisco Systems, Inc, 2011; Desmeules, R., 2003)

Pros
 Reduced Code – Because of its automated functionality, the destination addresses are dynamically
retrieved. This reduces the need for an administrator to manually configure static routes to the destination.

Cons
 Security Issues – Just like the 6to4 technique, due to the mix of IPv4 and IPv6 addresses in each packet,
the ability to spoof addresses within a packet header has been made easier. This has created some security
considerations for Denial of Service attacks. (Savola, P. & Patel, C., 2004)

3.2.3 Teredo Tunnels

The Teredo tunnelling technique is a technique that has been developed predominantly by Microsoft but with
help from the IETF. The main purpose of Teredo is to provide a way for nodes that are positioned behind an
IPv4 NAT to connect to IPv6 nodes on the internet. It does this primarily by tunnelling IPv6 packets over
IPv4 UDP datagram’s. In order to implement a Teredo tunnel, there some components that are required. In
order to implement Teredo successfully a Teredo Server, a Teredo Relay Router and a Teredo Host are all
required. Teredo is enabled by default on Windows Vista and Windows 7 machines. (Hoagland, J., 2007;
Desmeules, R., 2004; Huitema, C. 2006; Thaler, et al., 2010)

12
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.3 Tunnel Implementation

There were five different types of tunnels that were implemented or attempted to be implemented. In each
case, the topology will be explained in detail, the commands that were necessary for implementation will then
be given and finally the results of the implementation will be given. After the implementation is discussed, the
results of implementation will be analysed.

With regards to all of the testing that was done, two Cisco routers, two Dell PC’s, a hub and a HP laptop
were all used. The hub and laptop were both used purely for testing purposes. Every device in the network
was connected using Ethernet cables. All of the topologies were created using Cisco Packet Tracer.

3.3.1 Configured

3.3.1.1 Topology

Figure 6 shows the topology of the network that was used to implement the configured/IPv6IP manual tunnel.
PC’s were connected to routers by both Ethernet and Console cables. For this implementation to be considered
successful, PC1 would successfully ping PC2 using the tunnel between both routers (Tu12,
2001:12:12:12::1/64 to Tu12, 2001:12:12:12::2/64).

Figure 6 – Topology for the Configured Tunnel that was implemented.

Each PC was set to take an IPv6 address automatically from their directly connected router. PC1 took an
address related to the Fa0/0 port of R1, 2001:1:1:1::1/64; and PC2 took its address from port Fa0/1 of R2,
2001:2:2:2::2/64.

Both R1 and R2 were given an IPv4 Loopback address on interface Lo0. R1 was assigned Lo0 10.10.10.10/32
and R2 was assigned Lo0 10.20.20.20/32. These IPv4 addresses are the addresses that will be used when
encapsulating IPv6 packets. When PC1 attempts to ping PC2, the IPv6 packet that initially gets sent from PC1
will be encapsulated within an IPv4 packet in R1, using the IPv6 encapsulation protocol 41 (Protocol 41 is an

13
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

IPv6 protocol that is part of the encapsulation and forwarding process of IPv6 packets within IPv4 packets).
Thus the packet should in theory have both an IPv4 source address (Loopback address on R1, 10.10.10.10/32)
and an IPv6 source address (Fa0/1 on R1, 2001:1:1:1::1/64).

After the IPv6 packet is encapsulated within the IPv4 packet, it can now travel to its destination. As the packet
has both an IPv4 and IPv6 source address, it should have both IPv4 and IPv6 destination addresses. The IPv4
packet will have a destination address of 10.20.20.20/32, the Loopback address of R2, and the IPv6 packet
will have a destination address which will be the IPv6 address of PC2 (E.g. 2001:2:2:2::c8f2:410:cde7:326a).

In order for the packet to travel to its destination it must use the manual IPv6IP tunnel between both routers.
The packet will be sent toward the Tunnel destination which is specified as 10.20.20.20 (Lo0 address of R2).
The tunnel interface itself is configured with an IPv6 address, 2001:12:12:12::1/64, but uses the Loopback0
address as its source so it can travel over the IPv4 network of 10.1.123.0, which exists on the Fa connections
between the two routers.

When the packet reaches its destination of 10.20.20.20, the IPv4 packet is decapsulated which reveals the
internal IPv6 packet. The router will read the IPv6 packets destination address, 2001:2:2:2:..../64 and forward
it to PC2 via Fa0/1. PC2 will receive the ping packet and send a reply using the same process.

If the scenario above occurred, it would be considered a successful implementation of the IPv6IP tunnel.
Section 3.3.1.3 will analyse the packets that were sent over the physically implemented network to see if it
was successfully implemented and to analyse the packets.

3.3.1.2 Commands

In order to configure the entire topology, many commands were necessary, but for the purpose of this report
the interest lies in the commands that were needed for the Tunnel implementation. Figure 7 shows the
commands that were needed to configure the tunnel on R1.

Figure 7 – Ipv6IP tunnel Commands.

int Tunnel12 – This command creates the tunnel interface on R1. By putting 12 at the end of the command,
the tunnel has an identity of 12.

Ipv6 address 2001:12:12:12::1/64 – This command assigns the address stated to the tunnel interface.

Tunnel source Loopback0 - It is necessary to state both the source and destination addresses when configuring
an IPv6IP tunnel. This command configures the source as the Loopback of R1, 10.10.10.10/32.

Tunnel destination 10.20.20.20 – This configures the destination of the tunnel to be the Loopback address of
R2, 10.20.20.20.

14
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Tunnel mode ipv6ip – Each tunnel interface that is created must be given a “mode”. The mode is essentially
the type of tunnel that will be used. In this case the mode is IPv6IP.

ipv6 route 2001:2:2:2::/64 2001:12:12:12::2 – A static route must be created to direct the packets in the right
direction. This route directs the packets from R1 to the Fa0/1 port of R2 via the tunnel endpoint
2001:12:12:12::2.

3.3.1.3 Results

This section will provide results of the physical implementation of this IPv6IP tunnel. Results will be provided
from analysis of packets that were sent from PC1 to PC2. Analysis was done using Wireshark. Wireshark was
run on PC1 and the Viewing Laptop.

Firstly, a brief look at the ping packet that is sent from PC1. Figure 8 is a screenshot of the packet that was
captured on PC1 using Wireshark, before it was sent through R1.

Figure 8 – Screenshot of Wireshark ping capture on PC1.

The packet in its current state is IPv6 only. There is an IPv6 source and destination address, with no sign of
any IPv4 addresses or encapsulation. Figure 9 shows a screenshot of the packet which was captured by the
viewing laptop.

Figure 9 – Screenshot of Wireshark ping capture on Viewing Laptop.

The IPv6 packet was encapsulated within an IPv4 packet using protocol 41. This can be seen by the presence
of both protocols within the packet. The IPv4 packet has a source address of 10.10.10.10, the Lo0 address on
R1 and a destination address of 10.20.20.20, the Lo0 address on R2. With this evidence it can be stated that
the packet was successfully encapsulated using the IPv6IP tunnel mode.

15
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Finally, Figure 10 shows a successful reply from PC2.

Figure 10 – Successful ping from PC1 to PC2 using Manual tunnel.

Once again it can be seen that the original IPv6 packet was encapsulated within an IPv4 packet. The
encapsulation was done by protocol 41. The source and destination addresses have switched around. The IPv4
source address is 10.20.20.20 and the destination address is now 10.10.10.10; showing the packet was heading
in the opposite direction.

3.3.2 GRE

3.3.2.1.1 Topology

Figure 11 shows the topology of the network that was used to implement the GRE manual tunnel. The
topology is much the same as the IPv6IP tunnel that was implemented in the previous section. Just like the
IPv6IP topology, for this GRE implementation to be considered successful, PC1 would have to successfully
ping PC2 using the tunnel between both routers (Tu12, 2001:12:12:12::1/64 to Tu12, 2001:12:12:12::2/64).

Figure 11 - Topology for the GRE Tunnel that was implemented.

16
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Both PC’s are configured in the same way as the IPv6IP topology; both take their addresses automatically
from the routers they are connected to. Both routers are configured in basically the same way, loopback
addresses are given to both (LoO of R1, 10.10.10.10/32 and Lo0 of R2, 10.20.20.20/32). While this topology is
configured and functions in very much the same way as the IPv6IP tunnel, there are some minor differences.

When PC1 pings PC2, the IPv6 packet that is sent from PC1 is first encapsulated in a GRE packet and then in
an IPv4 packet. Once this is done, the packet can travel to its destination (10.20.20.20/32) just like it did in the
IPv6IP topology. As discussed in section 3.2.1.2, the extra GRE encapsulation creates an extra 24-bit
overhead for the packet.

When the packet reaches its destination of 10.20.20.20, the IPv4 packet is decapsulated which reveals the
internal GRE packet, which is also decapsulated to reveal the original IPv6 packet. With this IPv6 packet
received, the destination address can be seen and the packet can be sent to its destination of PC2. PC2 will
then reply to PC1 using the same process.

If the scenario above occurred, it would be considered a successful implementation of the GRE tunnel.

3.3.2.1.2 Commands

Once again, there are many commands that are necessary to configure the entire topology, but for the purposes
of this report, the only commands that will be looked at are the commands related to the GRE tunnel.

Figure 12 shows the commands needed.

Figure 12 – Commands used to configure GRE tunnel.

int Tunnel12 – This command creates the tunnel interface with an identity of 12 on R1.

Ipv6 address 2002:12:12:12::1/64 – This command assigns the address stated to the tunnel interface.

Tunnel source Loopback0 - It is necessary to state both the source and destination addresses when configuring
a GRE tunnel. This command configures the source as the Loopback of R1, 10.10.10.10/32.

Tunnel destination 10.20.20.20 – This configures the destination of the tunnel to be the Loopback address of
R2, 10.20.20.20.

Tunnel mode gre ipv6/ip – Problems were encountered when it came to this command. This command
configures the tunnel mode on the tunnel interface. In the lab that was used
(http://ardenpackeer.com/tutorials/routeswitch/tutorial-ipv6-tunnels-part-1-manual-gre-ipv6ip-tunnels), the command was stated as being
just “tunnel mode gre”. When this was entered the error “Incomplete Command” was returned.

Using the command “tunnel mode gre ?”, it was found that there were a number of options that had to be
stated at the end of the command. The two that stood out were “IPv6” and “IP”. After some brief

17
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

investigation, it was found that the command “tunnel mode gre ip” configures the default GRE tunnel mode,
and “tunnel mode gre ipv6” configures an IPv6 GRE tunnel.

After more investigation, it was found that the command that was needed was tunnel mode gre IP. The reason
for this is that the idea of the tunnel in the topology was to enable IPv6 packets to travel over an IPv4 network.
The IP at the end means the packet would be encapsulated within an IPv4 address that was specified (Lo0
10.10.10.10), if IPv6 was used at the end of the command, the packet would expect another IPv6 address to be
used for encapsulation; which would mean an IPv6 packet would be encapsulated within another IPv6 packet.

The problem occurred when tunnel mode gre ip was entered into the CLI. The command would not configure
the router. When the command was typed out and return was pressed, the running config and tunnel interface
would show no sign of a “tunnel mode gre ip” or any “tunnel mode”.

ipv6 route 2001:2:2:2::/64 2001:12:12:12::2 – Just like an IPv6IP tunnel, a static route must be created to
direct the packets in the right direction. This route directs the packets from R1 to the Fa0/1 port of R2 via the
tunnel endpoint 2001:12:12:12::2.

3.3.2.1.3 Results

The initial test for results was to ping PC2 from PC1. This initial test failed.

The second test was to ping from R1 to R2 Fa0/1, again this did not work.

The third test was to test if IPv4 was even working. To do this a ping was sent from Lo0 R1 to Lo0 of R2.
This ping was successful, which meant the only function that wasn’t working was the tunnel for the IPv6
packets.

Due to the errors in testing, the confusion around the command “tunnel mode gre ...” and from further
investigation testing the “tunnel mode IPv6 command”, it was decided that the tunnel would not function
without the command that the routers were not accepting.

18
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.3.3 6to4

3.3.3.1 Topology
Figure 13 shows the topology of the network that was used to implement the automatic 6to4 tunnel. Like the
other implementations, for this to be considered successful, PC1 would have to be able to ping PC2.

Figure 13 – Topology of the 6to4 tunnel implementation.

Each PC was set to take an IPv6 address automatically from their directly connected router. Both R1 and R2
are configured in almost exactly the same way as in the IPv6IP topology. The only difference is in the
configuration of the tunnel and the Loopbacks.

When PC1 issues a ping to PC2, the initial IPv6 packet is sent from PC1 to R1. When the packet reaches R1,
R1 looks up its route table and sees the destination of the packet is tu0. R1 has a static route configured that
says anything that starts with 2002::/16 has to be sent out tu0. As tu0 is configured with the 6to4 tunnel
encapsulation, R1 takes the destination address of the packet, 2002:0A14:1414::2/64, and converts it into an
IPv4 address, 10.20.20.20 (The IPv4 loopback address of R2). The initial IPv6 packet is then encapsulated in
an IPv4 header that has that address as the destination address. This is how 6to4 works automatically, as the
tunnels destinations are configured automatically depending on packet destination addresses.

When the packet reaches R2 and later PC2, decapsulation work s in the same way as it did in the IPv6IP
tunnel.

19
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.3.3.2 Commands

Figure 14 shows the commands used to configure a 6to4 tunnel on R1.

Figure 14 – Commands for a 6to4 tunnel.

int Tunnel0 – This command creates the tunnel interface with an identity of 0 on R1.

Ipv6 address 2002:A0A:A0A:FFFF::1/64 – This command assigns the address stated to the tunnel interface.

Tunnel source Loopback0 – This states the source of the tunnel is the Loopback0 on R1. The Loopback has
both an IPv4 and IPv6 address. The reason for this is to allow other routers and PCs to contact it using the
same technique described in section 3.3.3.1.

Tunnel mode ipv6ip 6to4 – This specifies the tunnel mode to be IPv6IP 6to4.

ipv6 router 2002::/16 Tunnel0 – This configures a route which means any packet that is sent through the
router, with a destination address of 2002::/16, must be sent to Tunnel0 where it would be encapsulated.

3.3.3.3 Results

This section will provide results of the physical implementation of the 6to4 tunnel. Results will be provided
from analysis of packets that were sent from PC1 to PC2. Analysis was done using Wireshark. Wireshark was
run on PC1 and the Viewing Laptop.

Firstly, a brief look at the ping packet that is sent from PC1. Figure 15 is a screenshot of the packet that was
captured on PC1 using Wireshark, before it was sent through R1.

Figure 15 – Screenshot of Wireshark ping capture on PC1.

The packet in its current state is IPv6 only. There is an IPv6 source and destination address, with no sign of
any IPv4 addresses or encapsulation.

20
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Figure 16 shows a screenshot of the packet which was captured by the viewing laptop.

Figure 16 – Screenshot of Wireshark ping capture on Viewing Laptop.

The IPv6 packet was encapsulated within an IPv4 packet using protocol 41. This can be seen by the presence
of both protocols within the packet. The IPv4 packet has a source address of 10.10.10.10, the Lo0 address on
R1 and a destination address of 10.20.20.20, the Lo0 address on R2. With this evidence it can be stated that
the packet was successfully encapsulated using the 6to4 tunnel mode.

Finally, Figure 17 shows a successful reply from PC2.

Figure 17 – Successful ping from PC1 to PC2 using 6to4 tunnel.

Once again it can be seen that the original IPv6 packet was encapsulated within an IPv4 packet. The
encapsulation was done by protocol 41. The source and destination addresses have switched around. The IPv4
source address is 10.20.20.20 and the destination address is now 10.10.10.10; showing the packet was heading
in the opposite direction.

21
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.3.4 ISATAP

3.3.4.1 Topology

The following is the final tunnel that was implemented. Figure 18 is the topology used for the implementation
of an automatic ISATAP tunnel.

Figure 18 – Topology of ISATAP tunnel implementation.

Unlike the other networks and implementations, this implementation did not make use of any PCs for
communication purposes. They were only used for configuring the routers R1 and R2. In order for this
implementation to be successful, R1 must be able to ping R2 using the tunnel to connect IPv6 traffic over the
IPv4 network between Fa0/0 of R1 and R2.

Both R1 and R2 were given an IPv6 Loopback address on interface Lo0. R1 was assigned Lo0 1::1/128 and
R2 was assigned Lo0 2::2. R1 and R2 are configured with tunnel interfaces. Both R1 and R2 have a tunnel
interface address of 131::/64.

When R1 pings R2, the IPv6 packet that is sent to the tunnel interface on R1 with the address of the loopback
on R1, 1::1/64. When it reaches the tunnel interface, the interface address of 131::/128 is assigned as its source
address and the destination address is then set to the end point of the tunnel, 131::/64 on R2. The IPv6 packet
is then encapsulated into an IPv4 packet, with the source address coming from Fa0/0, which is 12.12.12.1 and
the destination address set as 12.12.12.2. This route is set up using a route command that lets the router know
that any packet coming from R1 with the destination address of 2::2/128 will be sent to the tunnel address of
131::5EFE:C0C:C02. This address is specific to ISATAP as it has the 5EFE identifier, which is discussed in
section 3.2.2.2.

22
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.3.4.2 Commands

Figure 19 shows the commands that were necessary in order to configure the ISATAP tunnel.

Figure 19 – Commands used for the implementation of an ISATAP tunnel

int Tunnel12 – This command configures the tunnel interface with an identity of 12

ipv6 address 131::/64 eui-64 – Configures the tunnel interface with an IPv6 address of 131::/64 using eui-64.

tunnel source loopback0 – The source of the tunnel will now be set as the loopback of R1, 1::1/128

tunnel mode ipv6ip isatap – Configures the tunnel mode to be ipv6ip ISATAP; which turns the tunnel into a
functioning ISATAP tunnel.

ipv6 route 2::2/128 131::5EFE:C0C:C02 – A static route which means any packet with the source address of
2::2/128 must be sent to the address of 131::5EFE:C0C:C02, which is the address of the far point of the
tunnel.

3.3.4.3 Results

This section will provide results of the physical implementation of the ISATAP tunnel. Results will be
provided from analysis of packets that were sent from R1 to R2. Analysis was done using Wireshark.
Wireshark was run on the Viewing Laptop.

Firstly, a brief look at the ping packet that is sent from R1. Figure 20 is a screenshot of the packet that was
captured by the viewing laptop as the packet was in transit from R1 to R2.

Figure 20 – Screenshot of Wireshark ping capture.

It is clear to see the tunnel mode has done its job. The original IPv6 packet was encapsulated within an IPv4
packet. The destination of the IPv4 header is now the port Fa0/0 of R2. The source address of the IPv6 has
been assigned with the ISATAP identifier of 5EFE.

23
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Finally, Figure 21 shows a successful reply from R2.

Figure 21 – Successful ping from PC1 to PC2 using 6to4 tunnel.

Once again it can be seen that the original IPv6 packet was encapsulated within an IPv4 packet. The
encapsulation was done by protocol 41. The source and destination addresses have switched around. The IPv4
source address is 12.12.12.2 and the destination address is now 12.12.12.1; showing the packet was heading in
the opposite direction.

3.4 Analysis of Results

This section is a comparative analysis of the results taken from the implementations. Two main aspects will be
compared, 1) Comparatively how much lines of code did it take for each and 2) How scalable are these
tunnelling solutions.

3.4.1 Lines of Code

This analysis will look at the amount of lines that were used to implement each tunnel. Again, each
implementation required many lines of code, but for the purposes of this report, only the code that was used
for specifically the tunnel will be analysed.

Manual/IPv6IP – It can be seen in Figure 7 that it took 7 lines of code to configure the tunnel interface on R1
and the route it had to take. Thus it can be said that to configure the tunnel properly it would take 14 lines of
code.

6to4 – Figure 14 shows it took 6 lines of code to configure the tunnel endpoint on R1 and its route. In order to
configure both ends of the tunnel it would then take 12 lines of code.

ISATAP - As shown in Figure 19, this tunnel required only 5 lines of code to configure one endpoint of the
tunnel. So to configure both ends it would take 10 lines of code.

So from the successful implementations that were done, it can now be seen that with relation to lines of code,
it would be easiest to go with an ISATAP tunnel, as it only takes 10 lines of code to implement the tunnel
between two routers.

24
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.4.2 Scalability
Scalability will be measured by how easy it would be to add more routers and networks to each of the tunnels
that were implemented. How many extra commands are needed will be the core measurement of this analysis.
From the previous section which outlined how much lines of code would be required for the implementation
of a simple network with two routers in it, this section will focus on how much extra lines of code would be
necessary to add one extra router to that topology, once this is found out the number of extra lines can then be
multiplied depending on how much extra routers are being added.

Manual/IPv6IP – As it was shown in section 3.4.1, it took 14 lines of code to implement this tunnel with two
routers. With an extra router added to the network, it would mean an extra tunnel interface on each existing
routers, and two new tunnel interfaces on the new router. As it takes approx. 7 lines of code per interface, with
4 extra interfaces it would take 28 (4x7=28) extra lines of code for just one extra router to be added. So in
total to configure a network with three routers, the tunnels alone would need 42 lines of code to be configured.

With this in mind, it can clearly be seen that adding anymore routers would drastically increase the lines of
code required for implementation. So it can be said that this solution is not very scalable.

6to4 – It was found that it took 12 lines of code to configure a tunnel between two routers. As it is only
necessary to create one interface per router using 6to4 tunnelling, an extra router would only mean one extra
tunnel interface would have to be configured. This would mean an extra 6 lines of code or a total of 18 lines
of code for three routers.

This clearly shows that this tunnelling solution is very scalable and would require very little extra code for
implementation.

ISATAP – Section 3.4.1 showed it only took 10 lines of code to configure a tunnel between two routers. An
ISATAP tunnel works in almost the same way as a 6to4 tunnel. Thus an extra router would only mean one
extra tunnel interface configuration. An extra 5 lines would be required, which in total means for 3 routers in a
network, 15 lines of code would be needed to configure the tunnels.

Again it can be seen that the automatic solution drastically cuts down the amount of code required to
configure a tunnel, which makes this solution as well as the 6to4 solution, very scalable.

25
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

3.5 Conclusion of Implementation

To conclude, a brief overview of the implementations will be given, along with the final results and
conclusions of the implementations. Overview of the case study:

- 5 different tunnelling techniques were investigated, Configured/IPv6IP, GRE, 6to4 and ISATAP.
- These 5 techniques were discussed in detail in section 3.2.
- Pro’s and con’s for each were found and discussed.
- It was found that the automatic tunnels in reality function in almost exactly the same way as the
manual tunnels. The only difference was the amount of code required to configure them was
drastically reduced due to the automated functionality.
- Problems were encountered when configuring both the GRE and Teredo tunnels. And both were
eventually left, as testing of the others needed to begin due to time constraints.
- Manual, 6to4 and ISATAP tunnels were all successfully implemented and tested.

Final results and conclusions:

- After testing all three tunnels, it was found that the ISATAP tunnel took the least amount of code to
configure; which also made it very scalable in the situation of adding more routers.
- Although the ISATAP tunnel was found to require the least amount of code, it would be
recommended that anyone thinking of implementing tunnels in a network should use the 6to4
technique. Due to its high vendor support, it is felt any implementation problems would be sorted
faster compared to an ISATAP implementation. And the difference in code required is very small
compared to the manual solution.
- It is also felt that anyone considering implementing a large network should steer clear of the manual
tunnels, but if it is a small network, the manual tunnel solution would be a good idea. It provides a lot
more control over the network for any network administrators and as it also gives the administrators a
better idea of how it is structured.

Overall, the tunnels functioned well and almost all of the commands that were used weren’t too confusing.
Apart from the GRE and Teredo tunnels, everything was moderately easy to implement. Once the idea of
how these tunnels functioned was learned in detail, the implementation made very clear sense, and what
was required from the commands and address structures was made easier.

26
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

4. Conclusion

In conclusion to this report a brief discussion into the overall conclusion of the literature review and
implementation will be given.

As it was seen from the literature review, IPv6 is here and it is here to stay. As the IPv4 address space has run
out, the implementation of IPv6 will have to begin soon. The techniques used in this investigation are one of
the ways in which IPv6 is able to coexist with the already built up IPv4 infrastructure.

The overall conclusion from the implementation of these tunnels is that in reality, with money, time and
experience, these tunnels should not be an obstacle for anyone interested in implementing an IPv6 network
within their business or organization. In fact it could be considered fairly easy to implement these tunnels if
one was to have strong experience with networking.

It is also felt that considering the findings of both the Literature Review and the Case Study, it is surprising
more companies and organizations haven’t already made the switch to IPv6. Maybe with a new networking
generation that will be trained and have experience in IPv6, the rate at which it is being implemented may
grow.

27
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

5. References

Bradner, S., & Mankin, A. (1993, December). "IP: Next Generation (IPng) White Paper Solicitation" RFC 1550.
Retrieved 03, 02, 2012, from www.IETF.org: http://tools.ietf.org/rfc/rfc1550.txt

Bradner, S., & Mankin, A. (1995, January). "The Recommendation for the IP Next Generation Protocol", RFC
1752. Retrieved 03, 02, 2012, from www.IETF.org: http://www.ietf.org/rfc/rfc1752.txt

Callon, R. (1992, June). "TCP and UDp with Bigger Addresses (TUBA) , A Simple Proposal for Internet
Addressing and Routing" RFC 1347. Retrieved 03, 02, 2012, from www.IETF.org:
http://tools.ietf.org/html/rfc1347

Carpenter, B., & Moore, K. (2001, February). "Connection of IPv6 Domains via IPv4 Clouds" RFC 3056.
Retrieved 04 02, 2012, from www.IETF.org: http://www.ietf.org/rfc/rfc3056.txt

Center, C. D. Standard IPv4 Header. TTL Expiry Attack Identification and Mitigation. Cisco Security Center.

Cisco Systems, Inc. (2005, 08, 10). "6bone Connection Using 6to4 Tunnels for IPv6" Doc ID: 45741. Retrieved
04, 03, 2012, from www.Cisco.com:
http://www.cisco.com/en/US/tech/tk872/technologies_configuration_example09186a00801f3b4f.shtml#li
mitations624

Cisco Systems, Inc. (2011, 09, 26). "Implementing Tunneling for IPv6". Retrieved 04, 11, 2012, from
www.Cisco.com: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel.pdf

Colitti, L., Gunderson, S. H., Kline, E., & Refice, T. (2010). Evaluating IPv6 Adoption in the Internet. Google,
Inc.

Daigle, L., Colitti, L., Lee, D., Gashinsky, I., Townsley, M., & Ucendo, C. R. (2011). World IPv6 Day
Observations. IETF 81 (pp. 3,4,10,32,). Quebec, Canada: IETF.

Deering, S., & Hinden, R. (1995, December). "Internet Protocol, Version 6 (IPv6) Specification" RFC 2460.
Retrieved 03, 02, 2012, from www.IETF.org: http://www.ietf.org/rfc/rfc1883.txt

Degrossi, L., & Berger, L. (1995, August). RFC 1819, "Internet Stream Protocol Version 2". Retrieved 02, 28,
2012, from IETF.org: http://www.ietf.org/rfc/rfc1819.txt

Desmeules, R. (2003). Cisco Self-Study: Implementing Cisco IPv6 Networks (IPV6). Indianapolis: Cisco Press.

Egevang, K., & Francis, P. (1994, May). "The IP Network Address Translator (NAT)" RFC 1631. Retrieved 03,
02, 2012, from www.IETF.org: http://tools.ietf.org/html/rfc1631

Farinacci, D., Li, T., Hanks, S., Meyer, D., & Traina, P. (2000, March). "Generic Routing Encapsulation (GRE)"
RFC 2784. Retrieved 03 21, 2012, from www.IETF.org: http://tools.ietf.org/html/rfc2784

Google, I. (2012, February, 03). IPv6 Statistics. Retrieved 03, 01, 2012, from www.Google.com:
http://www.google.com/intl/en/ipv6/statistics/

Heux, A. L. (2011). A Short History of IPv4. CCC Camp. Berlin: CCCen, Youtube.

28
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Huitema, C. (2006, 02). "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)" RFC
4380. Retrieved 04, 11, 2012, from www.IETF.org: http://www.ietf.org/rfc/rfc4380.txt

Keranen, A., & Arkko, J. (2011). Some World IPv6 Day Measurement Results. IETF 81 (p. 10). Quebec,
Canada: IETF.

Klaffy, K. (2011). Tracking IPv6 Evolution: Data We Have and Data We Need. CAIDA.

Klaffy, K., & Huffaker, B. CAIDA's IPv4 & IPv6 AS Core AS-level Internet Graph. Archipelago. UCSD, San Diego,
California, USA.

Leiner, B. M., Cerf, V. G., Clark, D. D., Kahn, R. E., Kleinrock, L., Lynch, D. C., et al. (2012, 02, 02). Brief History
of the Internet. Retrieved 03, 02, 2012, from www.InternetSociety.org:
http://www.internetsociety.org/internet/internet-51/history-internet/brief-history-internet#LK61

Marsan, C. D. (2011, June, 07). World IPv6 Day: Tech industry's most-watched event since Y2K. Retrieved 03
01, 2012, from www.NetworkWorld.com: http://www.networkworld.com/news/2011/060711-ipv6-
expect.html

Mcgovern, M., & Ullman, R. (1994, October). "CATNIP: Common Architecture for the Internet" RFC 1707.
Retrieved 03 02, 2012, from www.IETF.org: http://tools.ietf.org/html/rfc1707

Morgan, B., & Lovering, N. (2007). "CCNP ISCW Official Exam Certification Guide". Cisco Press.

Packeer, A. (2008, April, 10). "Tutorial: IPv6 Tunnels Part 1 – Manual GRE & IPv6IP Tunnels". Retrieved 03 21,
2012, from www.ArdenPackeer.com: http://ardenpackeer.com/tutorial-ipv6-tunnels-part-1-manual-gre-
ipv6ip-tunnels/

Packeer, A. (2008, 05, 31). "Tutorial: IPv6 Tunnels Part 2 - Automatic 6to4 Tunnels". Retrieved 04, 03, 2012,
from www.ArdenPackeer.com: http://ardenpackeer.com/tutorials/routeswitch/tutorial-ipv6-tunnels-part-2-
automatic-6to4-tunnels/

Postel, J. (1981, September). RFC 791, "Internet Protocol". Retrieved 02, 26, 2012, from IETF.org:
http://www.ietf.org/rfc/rfc791.txt

Potts. (2007, 08, 24). "IPv6 Deployment and Associated" . Retrieved 03, 02, 2012, from www.6diss.org:
http://www.6diss.org/publications/papers/ipv6-deployment.pdf

Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., & Postel, J. (1997, January,). "An Ipv6 Provider-Based
Unicast Address Format", RFC 2073. Retrieved 03, 01, 2012, from www.IETF.org:
http://www.ietf.org/rfc/rfc2073.txt

Savola, P., & Chirayu, P. (2004, 12). "Security Considerations for 6to4" RFC 3964. Retrieved 04, 11, 2012, from
www.IETF.org: http://tools.ietf.org/html/rfc3964

Smith, L. (2011, 02, 03). Free Pool of IPv4 Address Space Depleted. Retrieved 03, 01, 2012, from
www.nro.net: http://www.nro.net/news/ipv4-free-pool-depleted

Stewart, B. (2000, 01, 07). Paul Baran Invents Packet Switching. Retrieved 02, 24, 2012, from Living Internet:
http://www.livinginternet.com/i/ii_rand.htm

29
 An Investigation into IPv4 to IPv6 Migration Techniques 2012

Thaler, D., Krishman, S., & Hoagland, J. (2010, 09). "Teredo Secuirty Updates" RFC 5991. Retrieved 04, 11,
2012, from www.IETF.org: http://www.ietf.org/rfc/rfc5991.txt

Topolcic, C. (1990, October). RFC 1190, "Experimental Internet Stream Protocol, Version 2 (ST-II)". Retrieved
02, 28, 2012, from IETF.org: http://tools.ietf.org/html/rfc1190#ref-8

Townsley, M. (2011, 01 21). World IPv6 Day: Working Together Towards a New Internet Protocol. Retrieved
02 23, 2012, from cisco.com: http://blogs.cisco.com/news/world-ipv6-day-working-together-towards-a-new-
internet-protocol/

White, B. (2011). Available Pool of Unallocated IPv4 Internet. ICANN, News Release , 1-2.

Wijnen, B., Aben, E., Wilhelm, R., & Kisteleki, R. (2011). World IPv6 Day - What did we Learn? IETF 81 (p. 25).
Quebec, Canada: IETF.

6. Glossary

CPU Utilization – How much the CPU is being utilized during an exercise.

IANA – Internet Assigned Numbers Authority.

IETF – The Internet Engineering Task Force.

Packet Loss – The amount of IP packets lost along a connection.

RFC – Request for Comments, a memorandum published by the IETF.

Transmission Latency - The amount of time it takes a packet of data to travel across a network.

Throughput – The average rate of successful message delivery over a communication channel.

Dual Stacking - The process of enabling both IPv4 and IPv6 capabilities on hosts, servers and routers.

30