8

A Seminar Report on

IPv6:The Next Generation

Protocol

Submitted in partial fulfillment of award of

BACHELOR OF TECHNOLOGY
degree

By
(Vineet Kumar Chaudhari)
(Computer Science & Engg.)
(0808210107)

Under the guidance of

Mr. Rakesh Ahuja

Deptt. of Computer Science & Information Technology

Moradabad (U.P.)

Moradabad Institute of Technology

 9

CERTIFICATE

This is to certify that the seminar report entitled IPV6 THE NEXT
GENERATION PROTOCOL submitted by VINEET KUMAR
CHAUDHARI Roll No. 0808210107 in the partial fulfillment of the
requirement of the Degree of B.Tech in COMPUTER SCIENCE &
ENGINEERING embodies the work done by him under my guidance.

(Semester-6th)
Date: 12-Feb, 2011
Place: Moradabad

Mr. Rakesh Ahuja

(Seminar In-
charge)
Assistant Professor
CS & IT
Department
 10

ABSTRACT

IPv6 has come with a package of advantages including simple header

format, very large address space and extensibility. However, IPv6 packets

transmission still uses the traditional infrastructure of protocol stacks such as

TCP/IP. Thus, the big advantages cannot be taken optimally. One of the

limitations of TCP/IP is duplication of error detection code verification and

regeneration in Data Link layer. Every router has to verify CRC code at

incoming port and regenerate the CRC code at outgoing port before forward an

IPv6 packet to the next router. With advance networking technology this is a

time consuming task. This paper proposes CRC Extension Header (CEH) to do

error detection in Network layer and replaces the current error detection in

Data Link layer. In CEH, verification of CRC code is only done in the final

destination indicated by destination address field of IPv6 header.

Experimentation results showed network latency of IPv6 packets transmission

decreases 68%.
 11

ACKNOWLEDGEMENT

With the immense pleasure, I would like to add a few hearts full thanks to people

who were pail of this seminar in numerous ways under whose guidance I have been able to

complete my seminar report successfully. I am thankful to Mr. Rakesh Ahuja (Assistant

Prof.) Computer Department for his guidance.

VINEET KUMAR CHAUDHARI

CS-3rd YEAR
 12

TABLE OF CONTENTS

CHAPTER 1: Introduction……………………………………………..…….. 8

CHAPTER 2: Evolution Of The Internet Protocol.....................................

10

2.1 Internet Protocol Version Four………………………..….

10

2.2 Internet Protocol Version Six……………………….………..

12

2.3 Migration Strategies From Ipv4 To Ipv6…………………....

23

2.3.1 The Dual Stack Transition Method………………….…….

24

2.3.2 Ipv6 Over Ipv4 Tunnelling…………………………….......

26

2. 4 Comparison Between Ipv4 And Ipv6 Packet Header…….....

29

CHAPTER 3: Implementing Ip Version Six On Two Platforms......... ….…..

30
 13

3.1 The Windows 2000 Machine……………………………......

30

3.2 The Free BSD Machine…………….......................................

31

3.3 Establishing The IPv4-IPv6 Tunnels…………………...……

32

CHAPTER 4: Testing and Benchmarking.......................................................

34

4.1 Internet Control Message Protocol (ICMP)…………………

34

4.1.1. Ping 6…………………………………………………......

34

4.1.2 Traceroute 6………………………………………………..

35

4.2 Benchmarking…………………………………………….....
35

CHAPTER 5: Conclusion................................................................................
37

Bibliography……………………………………………………………….…
39
 14

LIST OF FIGURES

FIGURE Page
no

FIGURE 1: Ipv6 Address Format 9

FIGURE 2: The Ipv4 Packet Header 11

FIGURE 3: The Ipv6 Packet Header 13

FIGURE 4: Ipv6 Extension Headers 14

FIGURE 5: Graphical View Of The Aggregated Allocation Structure 17

FIGURE 6: Neighbour Discovery Message Exchange 21

FIGURE 7: The Dual Stack Approach 25

FIGURE 8: Ipv6 Over Ipv4 Tunneling 26

FIGURE 9: Ipv6 Packet And Encapsulated Ipv6 Packet 27

FIGURE 10: Multiple Nodes On Separate Subnets Using 6to4 To

Communicate Across An Ipv4 Router
28

FIGURE 11: The Implementation Of Ipv6 Over Ipv4 Tunneling

 15

CHAPTER-1

INTRODUCTION

This report contains information about the creation of a more up to date internet
protocol, version six, more commonly known as IPv6. Currently, most of the internet uses
internet protocol version four, or IPv4, which is now nearly twenty years old. IPv4 as
proven to serve its purpose by providing internet protocol addresses, but now is in need of
many improvements. The amount of addresses provided by IPv4 is limited and necessitates
a dramatic increase to avoid severe future problems. The researched problem addressed the
following questions: What is it exactly? What will it do? What does this mean for the
business and personal users and how will this affect the internet as we know it today? The
background section gives the scope, limitations, sources, and methods of data collection,
and the report organization.

IPv6 is the formal name in which they call this protocol. The 6 in the abbreviation means
the version of the protocol being recommended. Currently released out right now is Internet
Protocol Version 4.

The functionality of IPv6 is supposed to be that greater than the current release of IP.
IPng can be installed with current software and also works back and forth with IPv4. IPng is
created to work well with higher performance networks such as ATM’s but also can work
well with smaller bandwidth networks such as wireless. Also, IPv6 will be providing
something for the internet in the near future in terms of function.

IPv4, the current version of the Internet Protocol deployed worldwide, has proven
remarkably robust, easy to implement, and interoperable with a wide range of protocols and
applications. Though substantially unchanged since it was first specified in the early 1980s,
IPv4 has supported the scaling of the Internet to its current global proportions. However, the
ongoing explosive growth of the Internet and Internet services has exposed deficiencies in
IPv4 at the Internet's current scale and complexity. IPv6 was developed specifically to
address these deficiencies, enabling further Internet growth and development.
 16

The most important issue addressed by IPv6 is the need for increased IP addresses: IPv4's
32-bit address space is nearly exhausted, while the number of Internet users continues to
grow exponentially. This need is exacerbated by the continual introduction of address
hungry Internet services and applications (Internet-enabled PDAs, home and small office
networks, Internet-connected vehicles and appliances, IP telephony and wireless services,
etc.). The exhaustion of IPv4 addresses has been long anticipated, and various techniques
have been introduced to extend the life of the existing IPv4 infrastructure, including
Network Address Translation (NAT), Dynamic Host Configuration Protocol (DHCP), and
Classless Inter-Domain Routing (CIDR).

While these techniques provide a workaround for the lack of address space, they fail to
meet the requirements of the Internet's end-to-end architecture and peer-to-peer applications.
Additionally, residential broadband Internet requires always-on, always-contactable global
addresses, which are unsupportable with current IP address conversion strategies, pooling,
and other temporary allocation techniques.

The global need for IP addresses has even added political force to the drive for IPv6
implementation. For latecomers to the Internet explosion, IPv6 is the only solution that will
accommodate billions of new users. Many countries, such as China and Japan, have
legislated an implementation schedule for IPv6 to meet their urgent deployment
needs.Simply stated, IPv6's ample (128-bit) address space provides an adequate number of
globally unique addresses to support the anticipated growth and development of the Internet
for the foreseeable future. However, as the following section illustrates, IPv6 is much more
than just a software fix to provide more IP addresses.

Figure 1. IPv6 address format.

 17

CHAPTER-2

EVOLUTION OF THE INTERNET PROTOCOL

The phenomenal growth of the Internet since its inception in the 1960’s as ARPANET
(The Advanced Research Projects Agency’s Network), mostly due to the creation of the
World Wide Web in 1990, has caused immense problems to those who regulate and
maintain the Internet. From its beginnings as four nodes at Stanford Research Institute, the
University of Utah, and the Universities of California at Santa Barbara and Los Angeles, it
has grown to well over 15 Million nodes. Increased routing tables and the vast
consumption of the available address space provided under the current Internet Protocol,
version four, led the Internet Engineering Task Force (IETF) to conclude that a re-working
of the protocol was needed.

INTERNET PROTOCOL VERSION FOUR

In 1973 development began on what later became known as the Transmission Control
Protocol/Internet Protocol (TCP/IP) protocol in the Defence Advance Research Projects
Agency (DARPA). Since RFC 791 (DARPA Internet Program Protocol specification) in
1981 there have been no changes made to the standard for the network layer of the TCP/IP
protocol, internet Protocol (IP). By January 1st 1983, everyone who was connected to
ARPANET had to connect using TCP/IP, and from this point on TCP/IP became the main
protocol, and its predecessor Network Control Protocol (NCP) became obsolete.

The problem of address space exhaustion has been known since the early 1990’s, and

measures such as Classless Internet Domain Routing (CIDR) and Network Address

Translators (NAT) have been introduced to slow down the exhaustion of Internet addresses,

but these are only stop-gap measures.

The Internet Network Information Centres (InterNIC) original policy of handing out IP
addresses in Class Structure - Class A, Class B, and Class C, meant that thousands of IP
addresses were allocated where they weren’t needed, and thus went unused. Network
 18

Address Translators were brought in to allow for networks to be connected to the Internet,
but without all of their machines being allocated a globally unique IP address of its own.
This is achieved by converting private internal addresses to a smaller group of globally
unique addresses. Unfortunately, NAT does not support standards-based network layer
security or the correct mapping of all higher layer protocols, and difficulties can arise when
two organisations that use private addresses try connecting to each other.

IPv4 survived the rapid changes in technology for so long because of its robustness, its

ease of implementation, and its interoperability. Unfortunately, the current IP lacks features

needed in today’s rapidly expanding Internet – security, and scalability of networks. Now

quality of service (QoS) levels are required of IP. Three main things cause the scalability

problems of IP: Host Configuration, Address allocation and expanding backbone routing

tables.

IPv4 supports a number of fields in its packet header, such as Time To Live (TTL),

Source address, Destination Address, and Identification. The address space is 32-bits long

and is written as four eight bit blocks that are separated by a decimal point, e.g.

136.206.15.5. Each number can vary between 0 and 255 (256 Bits, 28), but 0 and 255 are

reserved, and are not normally used as machine addresses.

 19

Figure2.1 The IPv4 Packet Header

The security issues that frequently arise with IPv4 such as Denial of Service (DoS)

attacks and other security bugs are caused by the way the above headers are misused. The

fragmentation and overlapping of packets are the main causes of problems such as buffer

overflow and bugs with the IP stack.

The IPv4 headers are of variable length in the above packet header. This in itself is a

problem because the header has to tell the system its size, which is bandwidth consuming,

and more difficult for routers to interpret. There are 14 fields in the packet header, some of

which rarely get used, such as the Header Checksum, which is a computationally expensive

way to compute errors in the packet, and the Options field, which was meant to supply

information on Security and Source routing among other things, but rarely does. These have

all been made obsolete, or have been merged to create different fields in the new packet

header of IPv6.
 20

2.2 INTERNET PROTOCOL VERSION SIX

On November 17th 1994, the Internet Engineering Task Force approved the Next–

Generation Internet Protocol, IPv6 as a proposed standard. The steering group developing

this new standard originally proposed that the new addressing structure would be 6-Bytes

(48 Bits) in length, which would provide for 65,000 times as many addresses as IPv4. But

the predicted ubiquitous nature of the Internet, and Internet connected devices (printers,

scanners as well as PC’s and Servers), convinced them to opt for a far greater number of

addresses. It was decided that the new standard would be 128 Bits in length (16-Bytes),

which is approximately 3.4 x 1038 addresses. It is difficult to imagine that number of

addresses ever being used, but no matter the rate at which the Internet continues to expand,

we certainly will have sufficient addresses for at least the next decade.

It is important to note that although IPv6 seems like a completely new protocol, its

differences are well planned and are really a reworking of the current protocol. What

worked well in IPv4 has been returned, and what did not has been changed in version six.

The new addressing structure is only one of the changes that has been made. These changes

are most easily demonstrated when you look at the new packet header for version si
 21

IPv6 Packet Header

Version Priority Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

Figure 2.2.1 The IPv6 Packet Header

As with IPv4, the Packet Header has a version, source and destination address fields. It
is easily noted though, that the new header is considerably more simplified than its
predecessor. It has only 8 fields compared to the 14 fields that IPv4 has. This obviously
makes routing more efficient. The reduced number of fields in the new header has been
achieved by amalgamating some of the previous fields into one field for IPv6. For example,
the functionality of the Type of Service field in version four has been moved to the priority
field and the flow control field. These are used to provide support for real-time delivery of
data.

The Header Length field has been abolished altogether as IPv6 has a fixed header
length for all packets. The payload length field has replaced the Total Length field. It is
assumed that the length of the header is always 40 bits, so this doesn’t actually hold any
value for the length of the header. The Payload length field can register a payload up to
64,000 bits in length, and even more, if its value is set to zero, and the optional extension
header is added.

The Time To Live (TTL) field has also been changed for this version of the protocol, to
the Hop-Limit field. Although the name has been changed the field still does the same thing
– It’s used by routers to decrement a maximum hop value by one, for each hop in an end-to-
end route. When the hop-limit value is decremented to zero the packet is discarded. The new
 22

version of this field can hold a value up to 255 hops (8 bits); this is hopefully enough for
even the largest imaginable networks of the future.

Although the 16-byte IPv6 addresses are four times the size of the 4-byte IPv4
addresses, the restructuring of the packet header means the new protocols header is only
twice the size of the current one. This will offset the bandwidth cost of having larger address
fields (128 Bits instead of 32 Bits) that need to be transferred with each packet. IPv6 has
been designed with a view to keeping header overhead to a minimum. This was achieved by
moving non-essential and optional fields from version 4, to extension headers in version 6.
It’s important to note, that IPv4 and IPv6 headers are not interoperable. A host or router
must run both implementations of the protocol in order to recognize and process header
information, if both protocols co-exist on a network.

In IPv4, an options field was added to the packet header, to allow for optional
information relevant to the routing process such as security and source routing. This has
been replaced in version six by flexible extension headers that come after the primary
packet header and before the transport header and payload data (As can be seen in Figure
2.3 below.) Unlike the options field in the IPv4 header, which only supports 40Bytes of
options, the size of the new extension headers are constrained only by the size of the IPv6
packet.

IPv6 Header Routing Destination Options Header Transport Header & Payload
Header Data

Figure 2.2.2 IPv6 Extension Headers

These optional extension headers provide the means for supporting much-needed
features like security, fragmentation, source routing and network management capability.
They are also much easier to implement in version six, than in version 4. These extension
headers also impact on the old Protocol Type field of version four, which is used to indicate
whether TCP or User Datagram Protocol (UDP) is used within the datagrams payload. Now
called the Next Header field.
The proposed order for the extension headers for the new standard are as follows:
 23

• (Primary IPv6 header)

• Hop-by-Hop options header
• Destination Options header –1
• Source Routing header
• Fragmentation header
• Authentication header
• IPv6 Encryption header
• Destination Options header –2
• (Upper-layer headers)
• (Payload)

Each extension only occurs once except for the Destination Options header, which has
two instances. The first is for carrying information to the destination listed in the IPv6
destination address field, and the second is for optional information that is only to be read
by the final destination.

The Fragmentation header has been updated in version six, so en-route routers can no
longer fragment the packet as it passes; only the source nodes are allowed to do this. If a
packet is received that is too big, it is discarded, and an Internet Control Message Protocol
(ICMP) message is sent back to the originator to inform it that the packet was dropped. This
feature fixes the problems associated with fragmentation in IPv4, such as the overlapping of
packets and stack bugs.

Aside from the size difference in the address fields of the old and new protocols
header, there is a notable difference in the abilities of each to provide an advanced
hierarchal address space that allows for efficient routing architectures. As has been
previously mentioned in this chapter, IPv4 was designed with a class based allocation
system in mind. This does not, however, cater for a hierarchy that would allow for a single
high-level address to represent many lower-level addresses – much like the way our
telephone system for country codes and area codes work; this method allows for long haul
calls to be patched efficiently to their destination using only a portion of the full phone
number. A similar implementation for IP would obviously be the most efficient way of
keeping routing tables manageable and efficient.
 24

Top Level Aggregators (TLA) would be at the top of this hierarchy – mainly
international registries like the Higher Education Authority Network (HEAnet) and the Irish
Domain Registry (IEDR) in Ireland. These would act as ‘exchanges’ for worldwide traffic
coming to Ireland, where peering could be established. These Top Level Aggregators would
then allocate blocks of addresses to Next Level Aggregators (NLA), which would comprise
of the larger Internet Service Providers (ISP) and corporate giants’ networks such as Intel,
Sun Microsystems and Cisco. In the cases where an NLA is a provider of Internet access
(e.g. ESATnet), it in turn allocates addresses to its subscribers. Routing tables are kept
efficient as NLAs with a common TLA will have the same TLA prefix at the start of their
addresses, e.g. 3ffe:b00:c18:1fff:0:0:0:193, where 3ffe would be the TLAs prefix.

IPv6 will therefore be allocated according to geographical location and provider

location (Network Topology). Address allocation by provider divides the hierarchy along
the lines of large ISP’s and therefore is not necessarily dependent on location. Geographic
allocation divides the hierarchy strictly on the basis of the location of the Provider and its
subscribers (in the same way as the telephone network operates). These have their
drawbacks – large networks don’t always conform to geographical boundaries, and some
large networks may have more than one ISP, but it is still the most efficient way to allocate
addresses.

Aggregation based allocation is built on the idea that a number of ‘exchanges’ exist,
where long haul providers/telecom companies interconnect, and the new IPv6 address
hierarchy has been designed with this structure in mind. It is hoped that the rigorous
structure of IPv6 allocation will go a long way to keeping the backbone routing tables of the
Internet manageable, no matter the rate at which the Internet continues to grow.
IPv6 embodies a number of addressing systems such as
• Unicast,
• Anycast,
• Multicast.

Unicast is the current method of routing, where a packet that is addressed to

one machine/host is sent and only one machine/host receives it (usually the machine
named as the destination of the packet). RFC 2373 allows for the accommodation of
load-balancing systems, where multiple interfaces may use the same single address,
 25

as long as these interfaces appear as one interface to the IPv6 implementation on the
machine.

Figure 2.2.3 Graphical View of the Aggregated Allocation Structure

IPv6 unicast addresses can be of the following types:

• Aggregatable global unicast addresses,
• Link-local addresses,
• Site-local addresses,
• Special addresses,
 26

• Network Service Access Point (NSAP) and Internetwork Packet Exchange (IPX)
addresses.

Anycast addresses identify multiple interfaces (typically belonging to a number of

different nodes). A packet sent to an anycast address is delivered to one of the interfaces
identified by that address (the "nearest" one, defined by the routing distance). Anycast
addresses are used for ‘one-to-one-of-many’ communication, with delivery to only a single
interface. Anycast addresses are particularly useful in the situation of an organisation that
has many connections to its ISP, and all connections have the same anycast address. In this
case, the organisation could have redundant access points in case that any of its normal
access points goes down or is not responding for some reason. It is also being used to
automate mirroring systems for websites that are frequently visited by people for downloads
– such as http://www.FreeBSD.org, and http://www.linux.org, where the data for
downloading is stored on one server, e.g., in Berkeley, California (in the case of FreeBSD)
and that data is replicated on a number of different websites all over the world. Anycast
addressing would eradicate the need to go to the home site and find the nearest working
mirror site to where you are, as it would automatically redirect to the “nearest” mirror.

Multicast addresses identify multiple interfaces (as the name implies). A packet sent
to a multicast address is delivered to all interfaces identified by that address. IPv6
multicasting operates in the same way as it does for IPv4. Arbitrarily located nodes can
listen for multicast traffic on an arbitrary IPv6 multicast address. IPv6 nodes can listen for
multiple multicast addresses at once. A multicast address is used for ‘one-to-many’
communications, delivering obviously, to multiple interfaces. The IPv4 broadcast address
(i.e. the 255 suffix) has been removed from IPv6 and its functionality has been replaced by
multicast addressing. Multicast addresses are generally used for video conferencing and the
like.
At first glance the addressing syntax of IPv6 seems completely unintelligible
compared with the current 32 bit eight-by-four addressing. For IPv6 the 128 bits
have been broken up into 16 bit boundaries and each boundary is then separated by a
colon (as opposed to a dot in IPv4). Then each 16-bit block is converted to a 4-digit
hexadecimal number, to give the address in its current state. For example, the IPv6
address 3ffe:b00:c18:1fff:0:0:0:408 is derived from the binary sequence
0011111111111110: 0000101100000000: 0000110000011000: 0001111111111111
0000000000000000: 0000000000000000: 0000000000000000: 0000010000001000
 27

The above IPv6 address has been simplified by removing the leading zeros where
they occur within each block. Each block must have at least one digit, except where there is
a continuous set of zero 16 bit blocks, in which case the colon hexadecimal format (as the
IPv6 address format is known as) can be compressed to “::” . So the address would be
further minimized to 3ffe:b00:c18:1fff::408.

Obviously remembering these addresses is out of the question, no more than with
IPv4, and Domain Name Servers (DNS) will be discussed in Chapter 5 as a means to
providing intelligible names to these strings of numbers and characters.

Probably the most useful feature of the new IP is its Auto configuration of addresses.
IPv6 supports both stateless and stateful address configuration. The latter occurs when there
is a Dynamic Host Configuration Protocol (DHCP) server is available, and the former when
there is not. With stateless configuration, the host/device automatically configures itself
with an IPv6 address for the link (a so called ‘link-local address’) and with addresses
derived from the prefixes advertised by local routers. In fact there isn’t even a need for there
to be a local router, hosts on the same link can automatically configure themselves with
link-local addresses, thus making the manual configuration of IP addresses redundant. This
is hugely important for large networks that have to relocate or add new hosts on a frequent
basis, whose IP addresses have to be re-configured. It also takes the error out of establishing
networks, where IP conflicts might occur when two machines are mistakenly given the same
IP.

Autoconfiguration is achieved using the Neighbour Discovery (ND) Protocol. Under

IPv4 Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP)
provided this service. ND has been refined to include these protocols for IPv6, and although
its disguised under a new name it is really only a set of ICMPv6 messages that allow nodes
on an IPv6 network to discover the link layer addresses, and to obtain and advertise network
parameters, such as the address prefix, and reachability information.

Basically, a machine/host starts autoconfiguration by self-configuring a link-local

address for temporary use. The address is usually formed by taking the network card Local
 28

Area Network (LAN) interface address. Once it forms this address, the host sends out an
ND message to see if it’s unique. If it’s not, an ICMP message will come back to the
machine complaining that it’s already in use. If the machine receives no ICMP message
back, it knows the address is unique and keeps it. If a message comes back saying that the
address is already in use, then a different token is used, like an administrative token or even
a randomly generated token.

Using its link-local address, the machine then sends out an ND router solicitation,
using a multicast address. Routers respond to this solicitation message, with a unicast router
advertisement that contains the network prefix(es) and also indicates a valid range of
addresses available on the subnet. The Neighbour Discovery protocol is demonstrated as
follows:

D
S
P 1 1
0

S D

S D
1 1 0
P

P ro fe
s s io
n a lW o rk s
ta tio n 5 0 0

P ro
f e
s s
i o
n a
l Wo
r k
s ta tio n 5
0 0

Router Solicitation

[ND]
Host
3C o m
S D
1 1 0
P

3Com Router
Router Advertisement

P ro
f e
s s
i o
n a
l Wo
r k
s ta tio n 5
0 0
[ND]

S D
1 1 0
P

S D
1 1 0
P

D
S
P 1 1
0

P ro
f e
s s
i o
n a
l Wo
r k
s ta tio n 5
0 0

P ro
f e
s s
i o
n a
l Wo
r k
s ta tio n 5
0 0

P ro fe
s s io
n a lW o rk s
ta tio n 5 0 0

Figure 2.2.4 Neighbour Discovery Message Exchange

 29

Previously IP addresses were assigned to whoever wanted them by the various Top
Level Internet Registries; such as RIPE-NCC (in Europe), APNIC (in Asia and the Pacific)
and ARIN (in Northern America), and they were obtained independently of the ISP they
intended to use. So it was possible for users to change ISP without having to go and change
their IP address. But with IPv6, when an organisation wants to change ISP, it has to change
its address (because of the way addresses are assigned.) This is only made an acceptable
address assignment model because of the ease with which whole networks can be re-
numbered using IPv6s autoconfiguration.

IPv6 aims to establish three important security services in the form of:
• Packet Authentication,
• Packet Integrity,
• Packet confidentiality

All of these security features are encapsulated in one of IPv6s optional extension
headers – the Authentication header, as previously noted in this section. It provides
integrity validation, guaranteeing network applications that the packet did actually
come from where it claims to have come from. This will combat the increasingly
frequent attacks on networks, where the cracker configures a host to impersonate
another, to gain access to private resources. Under IPv6s Authentication headers,
hosts establish a standard based security association that is based on the exchange of
the keyed MD5 digest algorithm (but those implementing the protocol can use a
different algorithm, as long as it’s appropriate.)

Before each packet is sent, the header creates a ‘checksum’ based on the key
supplied with the packet. This checksum is re-run on the receivers end and compared
to the original. In this way authentication is proved, and the sender of the packet can
guarantee that it hasn’t been interfered with en-route.

The Authentication header provides security in the form of eliminating ‘host

spoofing’ and packet modification cracks, but it doesn’t safeguard against packet sniffing
and snooping as the packet is transferred over the Internet (and other large networks). The
IPv6 Encryption header aided by the Encapsulating Security Payload (ESP) header is used
to do this. They are also part of the optional extension headers that I discussed previously.
 30

ESP encryption methods offer high levels of privacy and integrity for packets, which you
would rarely find available in an IPv4 environment, except in the case of certain secure
applications like Secured Shell (SSH), and secure Web Servers.

Most importantly, ESP provides encryption on the network layer, so it is

standardised and all applications can avail of it. IPv6 ESP is also used to encrypt the
transport-layer header and payload (i.e. either TCP or UDP) that follow the optional
extension headers (see Figure 2.3). It can also be used to encrypt the entire IP datagram.
Obviously fully encrypted datagrams are more secure than transport layer encryption only,
due to the fact that the headers of the datagram are also encrypted and not available for
traffic analysis like packet sniffing. ESP uses the Data Encryption Standard – Cipher Block
Chaining (DES-CBC) as the default, and will be required for all implementations.

2.3 MIGRATION STRATEGIES FROM IPV4 TO IPV6

The current spate of hype about the exhaustion of IP(v4) addresses has provoked
debate about the urgency of a transition from IPv4 to IPv6. It is obvious that the changes
IPv6 will bring about will improve greatly on the current set-up, and is necessary in both the
short and the long term for network dependent industries. How to go about this transition,
however, is not quite as clear-cut. There is a feeling among some that until there is complete
address space exhaustion; the current set up will suffice. Others on the other end of the scale
are lobbying for a complete upheaval and transferral to IPv6 as soon as possible. It is clear
that IPv4 and IPv6 will have to co-exist until the changeover is completed. Also many
organizations are completely dependent on the Internet for their daily work and they cannot
therefore tolerate the loss of connectivity for the replacement of the IP protocol. Thus, there
will not be a flag day in which IPv4 will be turned off and IPv6 turned on, since the two
protocols can coexist without any problem.

In anticipation of this, the IETF expanded the protocol to ensure that the transition would
be as smooth as possible, and Cisco and Nortel Networks have already begun producing
IPv6 capable routers. It is going to be a very expensive change for companies who did not
prepare by purchasing upgradeable equipment, as it means a whole new networking
 31

structure for their organisation. The rate at which IPv6 transfers will be dependent on how
prepared companies are in this respect, and how quickly IPv4 will become obsolete. For
companies who planned ahead for this change, it should only be a matter of upgrading their
Operating System (OS) and their Internetwork Operating System (IOS).
 32

Transition methods have been designed to give maximum flexibility to Network Engineers,
for how and when they need to upgrade their networks. Thus, IPv6 can be deployed in routers
first, or in machines/hosts first, or in a limited number of adjacent or remote hosts or routers for
the purposes of testing. A number of functions have been incorporated into the IPv6 standard
including dual-stack hosts and routers, translators, and tunnelling IPv6 via IPv4 to facilitate this.

2.3.1 The Dual Stack Transition Method

When a number of nodes have been converted to IPv6, they will most likely need to
maintain communication with the existing IPv4 nodes. This is accomplished by means of the
dual-stack IPv4/IPv6 approach. Dual stack machines (and routers) can handle both IPv4 and
IPv6 packets, with a separate stack implemented for both. When a dual-stack is being run on a
host, the host will have access to both IPv4 and IPv6 services. Routers running a dual-stack will
handle IPv4 and IPv6 traffic for an IPv4 node and an IPv6 node. These two protocols act
independently of each other and are unable to communicate with each other.

The migration from IPv4 to IPv6 has to incorporate the following, in order for there to be
a smooth and easily implemented transition.

• IPv6 and IPv4 hosts must be interoperable,

• The use of IPv6 hosts and routers must be diffused in the Internet in a simple and
progressive way, with a little inter-dependence,
• Networks Engineers and final users must feel that the migration is simple to understand
and will be easy to implement.

Below is a possible organization of the stack, to give a better idea of how the dual-stack will
work within the whole system from end-user to the Internet or network they’re connected to.

USER

Applications

Transport Protocols
(TCP/UDP)
 33

IPv4 IPv6

Ethernet

IEEE 802.3 Physical Level

Figure 2.3.1 The Dual Stack Approach

So, if the destination address is in IPv4 format, then the IPv4 protocol stack is used; if the
destination address is in IPv6 format, then the IPv6 protocol stack is used, and if the destination
address is an IPv4 address embedded in an IPv6 address, then IPv6 is encapsulated within IPv4
(for the purposes of tunnelling).

2.3.2 IPV6 OVER IPV4 TUNNELLING

While the IPv6 routing infrastructure is being developed, routing will continue in IPv4. It is
necessary for IPv6 traffic to be forwarded (for the purposes of testing mainly at this time), and
tunneling provides a means to this, using the current IPv4 networks.
 34

I Pv4 only
IPv6 Domain IS C
C OSYS
EM
T S IS C
C OSYS
TEMS I Pv6 Domain
Network
A Cis c o Router Cis c o Router B

Fi
gure 2.3.2 IPv6 over IPv4 tunneling.

In this scenario, a packet is sent from host A in its native IPv6 format. The packet is then
retransmitted over the current IPv4 network to its destination, as an IPv4 tunnel. When it reaches
the second router, it transmits the packet to its destination in its original format. In this case the
routers manage the tunnel.

Another method of tunneling is to use Encapsulation. This is where the IPv6 packet is
encapsulated inside an IPv4 packet. With this method, the packet is sent under the guise of it
being an IPv4 packet, so has the address of the routers as its destination addresses. The packet is
transmitted by the addition of an IPv4 header, with the IPv6 packet as the payload, complete with
its own native IPv6 headers. When it is received at the other router the IPv4 header is removed to
reveal the original IPv6 packet, which can then traverse the IPv6 network. Figure 2.10 shows the
encapsulated and the normal IPv6 packet:

IPv6 Payload
Header
IPv4 IPv6 Payload
Header Header

Figure 2.3.3 IPv6 Packet and Encapsulated IPv6 packet

 35

To accommodate different administrative needs, there are two types of tunneling

methods: automatic and configured. Automatic tunneling uses the encapsulation method
described above.

Configured tunnels are established by the administrator manually defining IPv6 to IPv4
address mappings at the tunnel endpoints. At the entry point of the tunnel, a router table entry is
defined manually to decide what IPv4 address is used to traverse the tunnel. The traffic is then
routed dynamically, without the knowledge that IPv6 is involved at all. The IPv6 address does
not have to be compatible with the IPv4 address.

If there are a number of machines/hosts on an IPv4 network, there is a method of

tunneling IPv6 traffic between nodes on different subnets of the network known as 6to4. It is
designed for connecting a number of IPv6 hosts over an existing IPv4 network. It works by
creating a unique IPv6 address prefix, to give isolated IPv6 sites their own address space; it’s
best described as a “pseudo ISP” providing IPv6 connectivity. 6to4 can be used to communicate
directly with other 6to4 sites, without the need for an IPv6 compatible router. The IPv6 traffic
travels as an encapsulated packet.
 36
Subnet One

Connected
by a router

CISC OS YSTEM S

Cisco Router

Subnet Two
F
igure2.3.4 Multiple nodes on separate subnets using 6to4 to communicate across an IPv4
router.

The only real requirement for the 6to4 configuration is to have a globally unique routable
IPv4 address (i.e. not a private address or one generated by a NAT). This address will act as the
6to4 gateway, and must be run on a machine with the IPv6 protocol.

There are many options for Network Engineers to choose from in order to change to IPv6
for every network set up. A configured tunnel was implemented on both of the machines, for this
project, and is described in the next chapter.
 37

2.4 COMPARISON BETWEEN IPV4 AND IPV6 PACKET

HEADER

1. The header length field is eliminated in IPv6 because the length of the header is fixed in
this version.
2. The service type field is eliminated in Ipv6. The priority and flow label fields together
take over the function of the service type field.
3. The total length field is eliminated in IPv6 and replaced by the payload length field.
4. The identification, flag, and offset fields are eliminated from the base header in IPv6.
They are included in the fragmentation extension header.
5. The TTL field is called hop limit in IPv6.
6. The protocol field is replaced by the next header field.
7. The header checksum is eliminated because the checksum is provided by upper layer
protocol; it is therefore not needed at this level.
8. The option fields in IPv4 are implemented as extension headers in IPv6.
 38

CHAPTER-3
IMPLEMENTING IP VERSION SIX ON TWO PLATFORMS

For the purpose of testing the new IP, it was decided that testing on two separate platforms
would help give a greater understanding of how the deployment of IPv6 is progressing, and to
compare two of the current implementations. FreeBSD was chosen initially, because it was the
first Operating System (OS) that supplied an IPv6 stack. Windows 2000 was chosen as a contrast
to the FreeBSD operating system (one is Open Source, and the other is a Commercial Operating
System), and Microsoft had just released the new version of their research IPv6 stack as I was
undertaking this project.

3.1. THE WINDOWS 2000 MACHINE

Windows 2000 machine is running on an AMD K6 500 processor with 128Mbytes of RAM.
The installation of the Windows 2000 operating system posed a few problems at first. The
original machine that Windows 2000 was installed on had air circulation problems, which caused
the motherboard to overheat which then caused the machine to crash at random intervals. There
were also a lot of problems getting a network card, which didn’t cause interrupt request (irk)
conflicts with the other hardware in the machine. There were also some notable differences
between Windows 2000 and Windows NT4, Windows 2000’s predecessor – such as the network
dial-up properties being moved from the Control Panel in the Settings menu, to a panel of its
own. Once a familiarity with the changes was achieved, and the problems with the hardware
were ironed out, the installation of the operating system was relatively trouble-free.

IPv6 protocol to the list of available protocols on the machine. This was done by going
into the settings menu, to the network dial-up properties, to the local area network connection.
Clicking on the “properties” button here brings you to a menu of the protocols on the machine.
There is an install option, from which you can then ‘add’, and select the Network Protocol you
want from a list, in this case IPv6. When you click ok after adding the IPv6 protocol, you can see
 39

that it has been added to the list of protocols on the machine. Unlike IPv4, you can’t manually
configure the IPv6 address from the properties menu when you click on the protocol, as the IPv6
address is automatically configured, as is expected.

3.2 THE FREE BSD MACHINE

The FreeBSD machine is an Intel 486 with 64 Mbytes of RAM, a considerably less
powerful machine than the Windows 2000 machine. When I first installed the operating system, I
used version 4.1.1 RELEASE, the then most up to date version of the OS. A couple of weeks
later it was updated to version 4.2 RELEASE, but there was no need for me to upgrade at that
point. Before installing the operating system I had to partition the hard-drive with a FreeBSD
partition using the software ‘FDISK’.

The FreeBSD operating system was installed by booting from two floppy disks, mfsroot.flp
and kern.flp, that held image files of the root file system, and the FreeBSD kernel respectively.
Once this was done, an installation menu allows you to pick the type of installation you would
like –the file transfer protocol (ftp) installation was chosen, as the CD ROM on the machine
didn’t work properly. From there, another menu which lists the various mirror-sites of the
operating system all over the world is brought up. The Irish ftp mirror site was chosen, which is
hosted by East at ftp.esat.net. The download and installation of the operating system took
overnight to complete. The type of Internet connection you have and the speed of your computer
dictate how long this installation will take if done over FTP.

The installation guide was then used to set up user accounts on the machine, to configure
the IPv4 address of the machine and it’s net mask and broadcast addresses. An X server and
client was then set up for ease of use of the computer – this creates a windows based operating
environment to work from. A number of packages were installed at this point for the testing
section, such as Term, SSH, and Telnet. When these were all installed and configured correctly,
the IPv6 tunnel was set up.
 40

3.3 ESTABLISHING THE IPV4 – IPV6 TUNNELS

The theory behind how tunneling works is very important, but more so is the actual
implementation of this theory. Both machines have a tunnel to the 6Bone that goes through the
IPv4 network using configured tunnels. The next sections describe this set up in detail for two
different platforms.

D
S

FreeBSD
The
Internet
d i gi t al (IPv4)

Generic 486PC
Compaq Monitor

S D

The 6Bone
Windows2000 (IPv6)
di g i t a l

Compaq Monitor
Generic Clone Tower-1

Figure3.1 The implementation of IPv6 over IPv4 Tunneling

For the purpose of describing the tunnels it is assumed that the machines are correctly
configured with the IPv6 protocol stack. Routing equipment capable of processing IPv6 and the
routing protocols that are used to forward this IPv6 traffic are still being developed, and are not
widely available for the purpose of testing the IPv6 protocol, so most people connect to the
6Bone by way of an IPv6 over IPv4 tunnel as described previously. There are a number of
groups that provide these tunnels available on the Internet. If you don’t have routing equipment
 41

available to establish your own tunnel and route your own packets, this is the quickest and
easiest way to go about connecting to the 6Bone.

All the routing table configuring that needs to be done, is done by the tunnel providers, so all
that remains on the users side of the tunnel is to set up the interfaces to listen for IPv6 traffic and
then to create the tunnel between the machine in question and the server the other end.
 42

CHAPTER-4
TESTING AND BENCHMARKING

To test IPv6 it was decided to approach it from the point of view of the user, and not the
administrator. That is, what applications are supported by IPv6 that are currently widely used by
the Internet community at large, and how well are they supported for the two platforms –
FreeBSD and Windows 2000. The testing was broken down into two main sections, Internet
Control Message Protocol (ICMP) testing and Transmission Control Protocol (TCP).

4.1 INTERNET CONTROL MESSAGE PROTOCOL (ICMP)

ICMP is the control message protocol used by the Internet. It is probably most recognized in
its form of ping and trace route, which are generally used to check the status of remote hosts, and
the ‘distance’ they are away.

4.1.1 PING 6
Ping uses timed IP/ICMP ECHO_REQUEST and ECHO_REPLY packets to probe the
“distance” to a target machine. It is generally used today to test quickly whether a machine is
“alive” or not, remotely. Unfortunately, due to the misuse of ping to cause Denial of Service
attacks on networks, blocking ICMP traffic at the router is now a frequent occurrence, so it’s not
as reliable as it used to be.

Ping6 is the IPv6 version of ping, and it comes as a standard package with the
FreeBSD/KAME IPv6 stack, and the Microsoft Research IPv6 stack. To test if the tunnels were
active after setting them up – a ping6 command was sent to the other end of the tunnel.

4.1.2 TRACEROUTE 6
 43

Traceroute uses ICMP Time-to-Live Exceeded messages when pinging by modulating the IP
time to life (TTL) header field, to mark out the number of hops between the source address
and the destination address of the packet. This has also been modified for IPv6 in the form
of traceroute6 (tracert6 on Windows 2000). Unlike ping, traceroute does not generally get
blocked at the router.The traceroutes from the Windows machine to a number of IPv6 sites.
The asterisks that appear in the traceroute occur when a response to the packet is not
received.

Ideally a private IPv6 network should be established, with one machine acting as a gateway
to the IPv4 network, and over a tunnel to the IPv6 6Bone in order to compare the traceroute
results. This wasn’t possible in the case due to time and resources constraints. Also it would be
difficult to compare the results unless it was over a very long period of time, as server reliability
and uptime, and load averages on Internet connections all factor into the comparison. From the
point of view of the user, these applications work just as well (if not exactly the same) as the
IPv4 versions.

4.2 BENCHMARKING
There are a number of different benchmarking software packages available for FreeBSD
that provide statistics for network and system performance. Netperf, the network performance
evaluation tool is one of the most frequently used packages. It works using two programs:
netserver (the server) and netperf (the measurement tool). There are a number of scripts available
to give control over a number of test variables such as:
• specification of desired confidence levels for the tests (Netperf will warn the user if these
levels were not achieved).
• filling send buffers with specified data (to beat compression schemes)
• specification of send/receive buffer alignments and data offsets
• requesting cpu utilization and service demand calculations
• specification of sizes of data to send
The snapshot_script, which takes the parameter of the hostname or IP address of the machine,
and performs a quick “snapshot” of the performance of two nodes, performs the following tests:
 44

• TCP Stream test with 56Kbytes socket buffers and 4Kbyte sends
• TCP Stream test with 32Kbytes socket buffers and 4Kbyte sends
• TCP Request/Response test with 1 byte requests and 1 byte responses
• UDP Request/Response test with 1 byte requests and 1 byte responses
• UDP Stream test with 56Kbytes socket buffers and 4Kbyte sends
• UDP Stream test with 32Kbytes socket buffers and 4Kbyte sends
 45

CHAPTER-5
CONCLUSIONS
The transition from Internet Protocol version four (IPv4), to Internet Protocol version six
(IPv6), will be wholly dependent on the speed that the current Internet Protocol
dependent protocols, and applications are updated to cope with IPv6. From the work
covered during this project, it can be seen that there is already a solid move towards
updating the Internet Protocol dependent protocols, such as Domain Name Service
(DNS), and the various routing protocols, such as (Route Information Protocol next
generation) RIPng, and Open Shortest Path First (OSPF). There has also been
considerable work done in updating Internet Protocol dependent applications such as
Telnet, Secure Shell (SSH), and web browsers.
The next generation Internet technologies are being investigated as a means to overcome
the limitations faced today with IPv4. One effort will evaluate a new implementation of
Transmission Control Protocol (TCP), that is aimed at supporting constant-bit-rate traffic such as
video streams. IPv6 is an answer to the long-term Internet addressing limitations of IPv4. There
are a number of research projects underway at present which will make practical use of IPv6s
Quality of Service, such as Telemicroscopy, Video Streaming of conferences and meetings, and
on a slightly lighter note, networked sreamed Quake. The development of Internet 2 (located at
the StarTAP in Chicago), and 6Tap, it’s IPv6 network, allows for the rapid development of these
major scientific developments, and the wide scale distribution of the findings. This will help
demonstrate the validity of this next generation Internet technology.
The setting up and administrating of two machines posed a couple of problems at first,
due to hardware incompatibility, but once these problems were ammended, the two test machines
ran smoothly without any faults (even when both of the Operating Systems were upgraded to
later versions). The configuration of the tunnels for the Windows 2000 machine, and the
FreeBSD machine were easily done with the help of a configuration batch file and perl script
respectively from the tunnel provider, but the understanding of how the tunnels would work and
how Internet Protocol version six worked required a lot of perliminary research of this report,
describes in detail the fundamental changes that have been made to IPv6, and how these changes
affect the usage of the protocol.
 46

Once the addressing structure and the address synax was understood, the understanding
of the header changes and the affects they would have all fell in to place. This project has
allowed for an in depth understanding of Internet Protocol to be achieved, as well as an in depth
knowledge of the protocols which are dependent on it. When this project was started, the author
only had a good working knowledge of how IPv4 and TCP/IP worked. Now an all round solid
knowledge of Networking the Internet has been gained.

“In protocol design, perfection has been reached not when there is nothing left to add, but when
there is nothing left to take away.” -- Ross Callon
 47

BIBLIOGRAPHY

1. Bay Networks “White Paper on Ipv6” - 1997

http://www.baynetworks.com/Products/Routers/Protocols/2789.html
(I have noticed since I printed out a copy of this document in September, that Bay
Networks was acquired by Norton Networks, and this URL is no longer valid, but
I have found a copy of the document at:
http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/papers/BayNetworks/.)
2. Microsoft Windows 2000 Server “Introduction to IP version 6 - White Paper”
http://www.microsoft.com/windows2000/library/howitworks/communications/nameadrm
gmt/introipv6.asp