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 Incharge) 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 no
FIGURE 1: Ipv6 Address Format FIGURE 2: The Ipv4 Packet Header FIGURE 3: The Ipv6 Packet Header FIGURE 4: Ipv6 Extension Headers FIGURE 5: Graphical View Of The Aggregated Allocation Structure FIGURE 6: Neighbour Discovery Message Exchange FIGURE 7: The Dual Stack Approach FIGURE 8: Ipv6 Over Ipv4 Tunneling

Page
9 11 13 14 17 21 25 26

FIGURE 9: Ipv6 Packet And Encapsulated Ipv6 Packet 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

27

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-toend 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 Header

Destination Options Header

Transport Header & Payload 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:

P 1 1 0

D S

S D

1 P1 0

S D

P r f s i a l o r s t n 5 0 0 o e s n o W k t i a o

P r e s o a Wo k t t n 5 0 f o s i n l r s a i o 0

Router Solicitation Ho t s
1 P1 0 S D

[N ] D
3C o m

Router Advertisement [N ] D
P r e s o a Wo k t t n 5 0 f o s i n l r s a i o 0

3Com Router

1 P 1 0

S D

1 P 1 0

S D

P 1 1 0

D S

P r e s o a Wo k t t n 5 0 f o s i n l r s a i o 0

P r e s o a Wo k t t n 5 0 f o s i n l r s a i o 0

P r f s i a l o r s t n 5 0 0 o e s n o W k t i a o

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 renumbered 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 Networks Engineers and final users must feel that the migration is simple to understand

progressive way, with a little inter-dependence, 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

IPv6 Domain

I Pv4 only
S I OY T S C CSSM E S I OY T M C CSSE S

A

Network
Cis c o Router Cis c o Router

I Pv6 Domain

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:

IPv4 Header

IPv6 Header IPv6 Header

Payload Payload

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.

Subnet One

36

Connected by a router
C C O YSTEM S S S I

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
d i gi t al

The Internet (IPv4)

Generic 486PC

Compaq Monitor

S D

Windows2000
di g i t a l

The 6Bone (IPv6)

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