This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
IP version 6 (IPv6) [RFC 2460] is a new version of the Internet Protocol, designed as a successor to the current IP version 4 (IPv4). The transition between today's IPv4 Internet and a future IPv6-based internet will be a long process during which both protocol versions will coexist. Internet will continue to grow at the rate it was growing, the IP version 4 (IPv4) 32 bit address space would be depleted by the turn of 2018 by the estimates of IETF's Address Lifetime Expectations working group [Solensky 1996].
The main reason for a new version of the Internet Protocol was to increase the address space to 128 bits.
Our topic mainly includes the work of Transition mechanisms proposed by IETF to ensure smooth and independent changeover from IPv4 to IPv6 where IPv6 is backward compatible to send, route, and receive IPv4 datagram's whereas IPv4 doesn't. So, to enable IPv6 integration into the current networks, several transition mechanisms from IPv4 to IPv6 have been proposed which includes mainly using IPv4 and IPv6, IPv6 tunneling over IPv4 and many more.
In this project report, I tried to explain ISATAP which is an IPv6 protocol that best supports the automatic tunneling technology.
In my project analysis, I came across many benefits of IPv6 compared to IPv4.My keen of interest was to do in Linux systems due to its security features for which I took various practical results explained in this report. My strategies may also result in reducing overall transmission time, loss of information inherent in IPv4/IPv6 header transmission thus, I conclude that the Internet Protocol version 6 (IPv6) is an emerging technology that have been migrated from IPv4 by many organizations.
Internet Protocol was first developed in the early 1980s. In the early 1990s when the internet is growing it became pretty evident that if the Internet will continue to grow at the rate it was growing, Some temporary solutions were offered, such as NAT (Network Address Translator) or CIDR (Classless Inter Domain Routing), however work began on a new Internet Protocol, namely IP version 6 (IPv6) [RFC 2460].The IP version 4 (IPv4) 32 bit address space would be depleted by the turn of 2018 by the estimates of IETF's Address Lifetime Expectations working group [Solensky 1996].
The years 1992, 1993 and 1994 of the IPv6 History (in general) IP version 6 (IPv6) [RFC 2460] is a new version of the Internet Protocol in Linux, and other operating systems which was designed as a successor to the current IP version 4 (IPv4). The first IPv6 related network code was added to the Linux kernel 2.1.8 in November 1996 by Pedro Roque. It was based on the BSD API (Berkley Sockets) ( Application Programme Interface).The transition between today's IPv4 Internet and a future IPv6-based internet will be a long process during which both protocol versions will coexist.
IP v 4 Addressing: IP v4 is the first version of the internet protocol that was widely deployed as data-oriented protocol on a packet switched network. IP v4 uses 32-bit(4-byte) IP addresses for host and destination which can limit to 4,294,967,296 possible unique addresses. It is represented in dot decimal notation.
For example, 11000001 .00100000.11011000.00001001 or 22.214.171.124 i.e., each byte of address is written in decimal form and separated by period dot from other bytes.
Under class full networking IP v4 created five classes of its (A,B,C,D & E) where A, B C are primary classes. Class D is created for multicasting and class E is reserved.
- It requires security at the Internet layer.
- The need to support better real time delivery of data.
- Ability to maintain large routing tables.
IP v 6 Addressing:
IP v6 is a new version of Internet protocol whereas efforts from IP(IPng) [Brander 1996; RFC 1752] & IETF resulted in IP version 6 (IPv6) [RFC 2460].
It has 128-bit (16 bytes) source & destination IP addresses expressed as 3.4 X 10 38 possible combinations. It is shown in hexadecimal notation as BA34: 5768: FFBA: 76DF: FFFF: CADB: D343.
IP v6 addresses come in unicast, multicast and any cast format where it also simplifies header format than IP V4.
They are 4 times longer than IP v4 addresses.
Features & Benefits:
- Large address space.
- Efficient & hierarchical addressing and routing infrastructure.
- High security level than IP v4
- Enhanced support for Mobile IP and mobile computing devices
- Increased number of multicast addresses.
- Listing the different types of IPv4 and IPv6 nodes and their features.
- Explaining different mechanisms for IPv4 to IPv6 transition.
- Describing the types of Tunnelling configurations.
- Define the differences between configured and automatic tunnelling.
- Describe ISATAP in terms of its purpose, requirements, and addresses.
- Describe 6to4 in terms of its purpose, requirements, and addresses.
- Describe Teredo in terms of its purpose, requirements, and addresses.
- List and describe the steps in migrating from IPv4 to IPv6.
Problem Description & Evaluation:
The two most important problems of IPv4 are the limited available address space and the increasing explosion of route tables. Besides solving the shortage of addresses problem, IPv6 also has introduced significant enhancements such as security, mobility, quality of service and improved performance.
Some experts predict that in 20 years most Internet users will be using IPv6, but that pockets of IPv4 will still exist as parts of legacy systems. Thus the transition to IPv6 will likely be a long process and may never attain complete penetration before the protocol becomes obsolete. So hardware and software interoperability is, therefore, a key requirement for interconnecting networks across heterogeneous environments and thus will be a major consideration in an enterprise's decision to adopt IPv6.
Several transition mechanisms have been proposed by the IETF IPng Transition Working Group. My project examines and empirically evaluates different transition mechanisms as they relate to the performance of IPv6. These mechanisms are intended to eliminate deployment dependencies between networks and thereby to allow enterprises to decide when to adopt IPv6, if at all, based upon their own needs and goals, without regard to the decisions of other enterprises.
Transition criteria for IPv4 to IPv6:
We can deploy IPv6 hosts anytime without dependencies on other hosts or routing infrastructure [RFC 1752].
Existing IPv4 hosts, with IPv6 installed, can continue to use their IPv4 addresses and do not need additional addresses.
An IPv4 host that has IPv6 installed can be used as IPv4 address.
The inherent lack of dependencies between IPv4 and IPv6 hosts, IPv4 routing infrastructure, and IPv6 routing infrastructure requires a number of mechanisms that allow seamless coexistence.
According to the nodes specified in the RFC 2893 are classified as:
- IPv4-only node
A node that implements only IPv4 (and has only IPv4 addresses) and does not support IPv6. Most hosts and routers installed today are IPv4-only nodes.
IPv6 only node
A node that implements only IPv6 (and has only IPv6 addresses) and does not support IPv4. This node is only able to communicate with IPv6 nodes and applications.
This type of node is not common today, but might become more prevalent as smaller devices such as cellular phones and handheld computing devices include the IPv6 protocol.
An IP v6 node that interoperates with IPv4 needs an IPv6/IPv4 node. It has both IPv4 and IP v6 address. It has the ability to send and receive IPv4 and IPv6 datagram's.
This node implements an IPv4 addressing. An IPv4 node can be an IPv4-only node or an IPv6/IPv4 node.
This node implements an IPv6 addressing. An IPv6 node can be an IPv6-only node or an IPv6/IPv4 node.
For coexistence to occur, the largest number of nodes (IPv4 or IPv6 nodes) can communicate using an IPv4 infrastructure, an IPv6 infrastructure, or an infrastructure that is a combination of IPv4 and IPv6. This true migration is achieved when all IPv4 nodes are converted to IPv6-only nodes. However, in future, practical migration is achieved when as many IPv4-only nodes as possible are converted to IPv6/IPv4 nodes. IPv4-only nodes can communicate with IPv6-only nodes only when using an IPv4-to-IPv6 proxy or translation gateway.
- [RFC 1519]- The internet's address assignment strategy is also known as classless interdomain Routing (CIDR) referred in this RFC also refers Internet standards track protocol for Internet community.
- [RFC 2131] Dynamic Host Configuration Protocol (DHCP) -DHCP allows a host to obtain an IP address automatically, as well as to learn additional information about subnet mask, the address of its first-hop router, and the address of its local DNS server.
- [RFC 2131; RFC 3022] Network Address Translation (NAT)-In an attempt to provide transparent routing to hosts, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses.
- BSD API: Berkley Sockets (Application Programming Interface) The Berkeley socket interface is an application programming interface (API), which allows communications between hosts or between processes on one computer, using the concept of an Internet socket. It can work with many different I/O devices and drivers, although support for these systems depends on the operating-system implementation.
- IP version 6 (IPv6) [RFC 1752; RFC 2460] - It represents the recommendation of next generation IP(IPng) effort where it replace the current version of the Internet protocol. This recommendation is accepted by the Internet Engineering Steering Group (IESG). The result of this effort was the specification of IP v6 [RFC 2460] replacing older IP version [RFC 791].
- Dual Stack Approach: It is a transition mechanism where it shows that IPv6 nodes are capable enough to implement complete IPv4 datagram. According to [RFC -2893] it includes providing complete implementations of both versions of Internet protocol (IPv6 and IPv4) and tunneling IPv6 packets over IPv4 routing infrastructure.
- Dual IP layer Approach: It is a transition mechanism in which it interoperates with both IPv6 and IPv4 nodes i.e., it can send and receive both IPv4 and IPv6 packets. It involves no data encapsulation like dual stack approach.
- Tunneling: In computer networks tunneling protocol (delivery protocol) encapsulates the different payload protocol i.e., It carries a payload over an incompatible delivery-network. It can also provide a secure path through an untrusted network without any data loss.
- Domain Name System (DNS): It is a hierarchical naming system for computers or any resource connected to Internet. Most importantly it translates domain names into numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. It actually assigns domain names to group of internet users independent of each user's physical location.
- Address Records & Record Types: Domain Name System (DNS) implements a distributed, hierarchical and redundant database of information associated with internet domain names and addresses. DNS record types of database records which are stored in zone files of the Domain Name System (DNS).
- DNS Zone & [RFC 1035; RFC 3596]- Zone files (text files) describe the portion of DNS which contains information that defines mapping between domain name and IP addresses organized in the form of resource records (RR).
- As it referred in RFC 1035 the Resource records type A returns a 32-bit IPv4 address i.e. used to map hostnames to an IP address of the host. In RFC 3596 the Resource record type AAAA returns a 128-bit IPv6 address most commonly used to map hostname to an IP address of the host.
- Pointer Records: These records are the opposite of A and AAAA resource records that are used in Reverse map zone files to map an IP address (IPv4 or IPv6) to a host name.
- Dynamic Host Configuration Protocol (DHCP): In a computer network DHCP is used to distribute dynamic IP address to the destination host. As referred in RFC 2132 states that DHCP definition for IPv4 networks and RFC 3315 for IPv6 (DHCPv6).
Modern Linux distributions contain IPv6-ready kernels, and the IPv6 capability is generally compiled as a module, but it's possible that this module is not loaded automatically on startup.
In the present technology we anymore use kernel series 2.2.x, because it's not IPv6-up-to-date anymore. According to the latest RFC's it's recommend to use series 2.6.x now.
Migration Technologies Overview
There are various technologies which are available to facilitate the migration to IPv6. These technologies will be discussed according to the following basic categories:
- Dual Stack Approach - It supports both IPv4 and IPv6 on network devices.
- Tunneling- Encapsulation of IPv6 packet within an IPv4 packet for transmission over an IPv4 network without any data lost.
- Translation-address or port translation of the addresses for e.g., gateway devices or translation code on the TCP/IP code of the host or router.
IPv4 to IPv6 Transition Mechanisms:
During the time that the routing infrastructure is being transitioned from IPv4-only, to IPv4 and IPv6, and finally to IPv6-only, hosts must be able to reach destinations using either IPv4 or IPv6. For example, during the transition, some server services will be reachable over IPv6. However, some services, which have not yet been updated to support both IPv4 and IPv6, are only reachable over IPv4. Therefore, hosts must be able to use both IPv4 and IPv6. To use both IPv4 and IPv6 Internet layers on the same host, IPv6/IPv4 hosts can have the following architectures:
There are many transition mechanisms developed so far, these are classified as follows.
1) Using both IPv4 and IPv6
- Dual IP layer architecture
Dual Stack Architecture:
The dual stack architecture is a basic mechanism, which relies on both IPv4 and IPv6 network layers with separate protocol stacks containing separate implementations of transport layer protocols such as TCP and UDP.
Here the routers, infrastructure and end-user devices will be configured with both IPv4 and IPv6 addresses with their respective protocols which are enabled by administrators.
This approach is really benefit for layered protocol model and may be desirable in the case of network servers with multiple applications or services.
Dual Stack Deployment:
In deploying dual-stack devices it shares a common network interface which implies the operation of both IPv4 and IPv6 over the same physical link. Dual stack devices requires routers supporting suck links to be dual-stacked as well.
In this approach, if either the sender or the receiver is only IPv4 capable, an IPv4 datagram must be used. So, it is possible that two IPv6 capable nodes can end up, in essence, sending IP v4 datagram's each other.
In the above diagram, the information contained in IP datagram's between IPv6 nodes can be capable enough to send and receive them but in IP v6 and IP v4 the dual stack approach the data field of the IP v6 datagram can be copied into the data field of the IP v4 datagram and appropriate address mapping can be done.
However, while doing this conversion there will be IP v6 specified fields in the IP v6 datagram where the information in this will be lost. Another disadvantage of this implementation is that two routing tables and two routing processes may be required. Hosts and routers that support dual stack may use tunneling mechanisms to route IPv6 traffic over IPv4 networks. The ability to operate with different nodes makes the dual stack approach a flexible and simple to deploy solution to work in networks that are connected with both IPv4 and IPv6 nodes.
Dual IP Layer Architecture:
A dual IP layer architecture contains both IPv4 and IPv6 Internet layers with a single implementation of Transport layer protocols such as TCP and UDP.
Communication types with a Dual IP layer Architecture
A host with a dual stack can interoperate with both IPv4 and IPv6 nodes using IPv4 or IPv6 packets. Dual stack has the possibility to disable one of the IP stacks for operational reasons. A node configured with a dual stack can make decisions on TCP connections based on the IP header of the TCP packet:
- The IPv4 protocol stack will be used if the destination address used by the application is an IPv4 address.
- The IPv6 protocol stack will be used if the destination address used by the application is an IPv6 address.
- Encapsulation of an IPv6 packet inside an IPv4 packet will occur if the destination address used by the application is an IPv6 address with embedded IPv4 address.
Dual stack makes it possible to continue provide access to IPv4 resources, while adding IPv6 functionality. The IP address acquisition in the dual stack nodes occurs by using IPv4 mechanisms like DHCP or IPv6 mechanisms, as for instance the stateless address auto-configuration. The ability to operate with different modes makes the dual stack approach a flexible and simple to deploy solution to work in networks that are connected with both IPv4 and IPv6nodes. A disadvantage of this implementation is that two routing tables and two routing processes may be required. Hosts and routers that support dual stack may use tunneling mechanisms to route IPv6 traffic over IPv4 networks.
It translates domain names into numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing networked devices worldwide. A Domain Name System (DNS) infrastructure is actually needed for successful coexistence of the prevalent use of names rather than IP addresses to refer to network resources. Upgrading the DNS infrastructure consists of populating the DNS servers with records to supports IPv6 name-to-address and address-to-name resolutions. After the addresses are obtained using a DNS name query, the sending node must select the addresses which are used for communication.
Domain Name System (DNS) contains address records (database of records) associated with internet domain name and addresses. Any user attempting to access dual-stack devices will enquiry DNS zone files which can be configured by administrators with resource records for 32-bit IPv4 and 128-bit IPv6 addresses.
The DNS infrastructure must contain the following resource records (populated either manually or with DNS dynamic update) for the successful resolution of domain names to addresses:
- A records for IPv4 nodes
- AAAA records for IPv6 nodes
For example in dual stack approach if we consider then it will be like
Dual-stack-host.name.com 81290 IN A 12.320.0.16
Dual-stack-host.name2.com 81290 IN AAAA 4EFE:240:390::A
In DNS the Pointer Records are needed to convert IP-address to host name with appropriate .arpa domain:
The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of address to domain names (reverse queries). These are opposite of A and AAAA resource records and are used in reverse map zone files to map IP addresses to domain names.
PTR records in the IN-ADDR.ARPA domain for IPv4 nodes
PTR records in the IP6.ARPA domain for IPv6 nodes (optional).
For example in dual stack approach:
16.0.320.20 .in-addr.arpa. 81290 IN PTR dual-stack-host.name.com.
A.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.3.0.0.2.0.E.F.E.4.ip6.arpa.81290 IN PTR dual-stack-host.name.com
Address Selection Rules:
For name-to-address resolution, after the querying node obtains the set of addresses corresponding to the name, the node must determine the set of addresses to choose as source and destination for outbound packets. This is typically not an issue in today's prevalent IPv4-only environment. However, in an environment in which IPv4 and IPv6 coexist, the set of addresses returned in a DNS query might contain both IPv4 and IPv6 addresses. The querying host is configured with at least one IPv4 address and (typically) multiple IPv6 addresses. The host must decide which type of address (IPv4 vs IPv6) and the scope of the address for the source and the destination when initiating communication. The host must use a set of address selection rules. Here, the default address selection rules are described in RFC 3484. The IPv6 addresses in DNS name query responses are preferred over IPv4 addresses.
The original version of Dynamic Host Configuration Protocol (DHCP) [RFC 2131] was made with IPv4 and then specification was revised and updated to the latest version of DHCP known as DHCPv6. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was standardized by IETF through RFC 3315 which was released in 1997. It has the capability for automatic allocation to reusable network addresses and additional configuration flexibility. It also enables DHCP servers to pass configuration parameters like IPv6 network addresses to IPv6 nodes.
DHCP Deployment Issues:
In early IPv6 deployments, the dual stack of operation was typically used where a node requires both IPv4 and IPv6 configuration settings. A node actually needs to obtain both IPv4 and IPv6 configuration settings flexibly such as
- IP v4 address
- IP v6 address
- NTP or DNS or NIS server
These have raised few issues in setting dual stack environment.
Types of Issues:
Handling Multiple Responses:
There were issues handling configuration information that might be gathered from multiple sources such as DHCP and DHCPv6 servers which are running on the same node. Here, the client needs to know whether to use most recent data or union of responses by certain rules.
Different Administrative management:
In some deployments such as wireless environment IPv4 and IPv6 may not be administered by the same organization because of their connectivity issues. As the client need to use different received information depending on the connectivity.
Some other issues have also been raised in Multiple Interfaces, DNS Load balancing and security etc. Thus the thesis gathered from different sources have suggested potential solutions such as running separate DHCP and DHCPv6 servers which could lead to information consistency managed by administrators.
The other is to run only DHCPv6 server and relay IPv4 configuration information within new IPv4 configuration options.
Tunneling: As discussed in RFC 2893 it is an alternative to Dual Stack approach which can solve the problems faced in dual stack architecture. As the picture shown below, we refer to the intervening IPv4 routers between two IPv6 routers with a tunnel. With tunneling, the IPv6 node on the sending side of the tunnel takes the entire IPv6 datagram and puts it in the data (payload) field of an IP4 datagram. This IPv4 datagram is then addressed to the IPv6 node on the receiving side of the tunnel and by dong this IPv4 datagram unaware that it contains IPv6 datagram.
IP V6 over IPV4 Tunneling
IPv6 over IPv4 tunneling is the encapsulation of IPv6 packets with an IPv4 header so that IPv6 packets can be sent over an IPv4 infrastructure within the IPv4 header:
The IPv4 Protocol field is set to 41 to indicate an encapsulated IPv6 packet.
The Source and Destination fields are set to IPv4 addresses of the tunnel endpoints. The tunnel endpoints are either manually configured as part of the tunnel interface or automatically derived from the next-hop address of the matching route for the destination and the tunneling interface.
IPv6 over IPv4 Tunneling
For IPv6 over IPv4 tunneling, the IPv6 path maximum transmission unit (MTU) for the destination is typically 20 less than the IPv4 path MTU for the destination. However, if the IPv4 path MTU is not stored for each tunnel, there are instances where the IPv4 packet will need to be fragmented at an intermediate IPv4 router. In this case, IPv6 over IPv4 tunneled packet must be sent with the no Fragment flag in the IPv4 header set to 0.
Tunneling is used on the internet and requires manual configuration. Because IPv6 will be developed over the IPv4 infrastructure, tunneling provides a way to use the existing routing infrastructure to carry IPv6 traffic over Ipv4. Tunneling IPv6 packets over IPv4 infrastructure is done by encapsulating IPv6 packets inside IPv4 packets. The IPv6 header contains the address of the final destination and the IPv4 header contains the address of the tunnel endpoint.
We have two types of tunneling which in turn have two more mechanisms of each as described below. The two main types are: Configured Tunneling and Automatic Tunneling
Configured Tunneling: A configured tunneling requires manual configuration of tunnel endpoints. In a configured tunnel, the IPv4 addresses of tunnel endpoints are not derived from addresses that are encoded in the next-hop address when sending or forwarding the packet. The diagrammatic representation of router-router and host-router tunneling mechanisms are explained below which refers to configured tunneling.
There are four types of configurations in tunneling .The first two are configured and the last two are automatic tunneling of IPv6 over IPv4.
- Router-to-Router tunneling
- Host-to-Router tunneling
- Router-to-Host tunneling
- Host-to-Host tunneling
In this configuration, two routers IPv6/IPv4 connect two IPv6 infrastructures over an IPv4 infrastructure. The tunnel is created between the two edge routers. The tunnel endpoints extend a link in the path between the source and destination. The IPv6 over IPv4 tunnel between the two routers acts a single hop. Routes in each IPv6/IPv4 infrastructure point to the router on the edge. For each IPv6/IPv4 router, there is a tunnel interface representing the IPv6 over IPv4 tunnel and routes which use the tunnel interface. Router-to-Router tunneling has one segment at both ends of the path which support IPv6. If one segment has to send an IPv6 packet and the network is interconnected by IPv4 infrastructure then the IPv4 infrastructure can tunnel IPv6 packet between them.
In this type of configuration, an IPv6/IPv4 node which remains in an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach an IPv6/IPv4 router. The tunnel endpoints extend the first segment of the path between the source and destination nodes. The IPv6 over IPv4 tunnel between the node and the router acts as a single hop.
A tunnel interface representing the IPv6 over IPv4 tunnel is created and a route is added using the tunnel interface. The IPv6/IPv4 node tunnels the IPv6 packet depending on the similar route, the tunnel interface, and the destination address of the IPv6/IPv4 node. This type of tunneling is used when the IPv6/ IPv4 hosts wants to tunnel IPv6 packets to the intermediate IPv6/IPv4 router via IPv4 infrastructure.
In this type of configuration, an IPv6/IPv4 router creates an IPv6 over IPv4 tunnel across the IPv4 infrastructure to reach an IPv6/IPv4 node. The tunnel endpoints extend the last segment of the path between the source node and destination node. A tunnel interface representing the IPv6 over IPv4 tunnel is created and a route is added using the tunnel interface. The IPv6/IPv4 router tunnels the IPv6 packet depending on the similar subnet route, the tunnel interface, and the destination address of the IPv6/IPv4 node. This type of tunneling is used when the IPv6/IPv4 routers wants to tunnel IPv6 packets to its final destination of IPv6/ IPv4 host.
In this configuration, an IPv6/Ipv4 node which remains within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach another node which remains in the same IPv4 infrastructure. This type of tunneling needs the whole end-to-end path that the packets take. The tunnel end points extend the whole path between the source and destination nodes. The tunnel between the IPv6/IPv4 nodes acts as a single hop. If the IPv6/IPv4 hosts are interconnected by an IPv4 infrastructure, then they can tunnel the IPv6 packets between them. An interface representing the IPv6 over IPv4 tunnel is created on every IPv6/Ipv4 node. Routes may be present to point that the destination node is on the same subnet defined by the IPv4 infrastructure. Depending on the sending interface, the route, destination address and the host tunnels the IPv6 traffic to the destination.
Automatic Tunneling of IPv6 over IPv4 Networks: Automatic tunneling means that the IPv4 address is automatically delivered from the IPv6 address without any pre-configuration of the tunnels. When compared with configured tunneling, automatic tunneling is used between networks where there is need to exchange traffic between the networks. This tunneling mechanism has the advantage of being automatically configured, and it is limited because it requires one IPv4 address per host.
An automatic tunnel doesn't require pre-configuration. Here, the tunnels are created based on the information contained in the IPv6 packets such as source or destination IP address.
Various Automatic Tunneling Techniques:
- 6to4 -automatic Router-to-Router tunneling
- 6over4-automatic host-to-host tunneling
- ISATAP-automatic host-to-host, host-to-router, router-to-host tunneling based on the particular IPv6 address format.
- Tunnel Brokers-automatic tunnel setup by a server acting as tunnel broker
- Teredo-automatic tunneling through NAT firewalls over IPv4 networks
6to4 is a tunneling technique which allows IPv6 packets to be delivered over IPv4 network without the need to configure any explicit tunnels. It is totally based IPv6 address format to identify 6to4 packets and tunnel them accordingly.
It is used when end-user wanted to connect IPv6 internet using their present IPv4 network. It might be used by an individual host or by IPv6 network. Here, any individual host must have IPv4 connectivity which could encapsulate outgoing IPv6 packets and decapsulate incoming 6to4 packets.
It can also route traffic between 6to4 and native IPv6 networks.
Here, any host which has assigned 32-bit global IPv4 address then 48-bit 6to4 prefix can be added for use by that host by prep ending 2002(hex) to the IPv4 address. IPv4 addresses use dot-decimal notation and IPv6 use hexadecimal notation. For e.g. 192.0.2.42 represents IPv4 address and the corresponding 6to4 prefix would be 2002:c000:022a::/48 where the prefix length of 48 bits leaves space for a 16-bit subnet field and 64-bit host address within the same subnet.
Encapsulation and Transmission:
Here in the encapsulation 6to4 embeds an IPv6 packet in the payload of IPv4 packet with protocol 41 in order to send an IPv6 packet over IPv4 network to a 6to4 destination address. The IPv4 destination address for the prep ended packet header came from the IPv6 destination address of the inner packet by extracting the 32 bits following the IPv6 destination address 2002::prefix. The resulting IPv4 packet is then routed to its Ipv4 destination address just like normal IPv4 packet.
However, the 6to4 routers require 6to4 relay routers to map global unicast (native) IPv6 address for tunneling. The routing between 6to4 and native IPv6 address can be imparted by configuring routes to destination native IPv6 networks with the 6to4 relay router as the next hop. It can utilize normal routing protocols which enables 6to4 relay router to advertise to IPv6 networks. 6to4 packets which arrives on IPv4 interface will have their IPv6 payloads routed to IPv6 network where as packets arriving on IPv6 interface with destination address prefix of 203::/16 will be encapsulated and forwarded over IPv4 network.
RFC 3068 defines any cast address for 6to4 relay routers:
This address corresponds to the IPv4 address of 126.96.36.199.
6over4 is an IPv6 transition mechanism where it transmits IPv6 packets between dual-stack nodes on the top of a multicast-enabled IPv4 network. IPv4 is used as a virtual data link layer (virtual Ethernet) on IPv6 cab be run.
Link-local address generation:
Because of the virtual link layer perspective, IPv6 addresses are formed using a link local scope
Any host wanted to participate in 6over4 over a given IPv4 network can set up a virtual IPv6 network interface referred in RFC 2529. The link-local address is determined as follows :
It starts with fe80::the lower-order 32 bits to the binary value must be that of the IPv4 address of the host.
For example, host 192.0.2.142 would use fe80::c000:028e as its link-local IPv6 address (192.0.2.142 is c000028e in hexadecimal notation). A shortened notation would be fe80::c000:28e.
6over4 mostly relies on IPv4 multicast availability, which is not very widely supported by IPv4 networking infrastructure (multicast is almost as recent as IPv6), 6over4 is of limited practical use, and is not supported by the most common operating systems
It is a tunneling protocol designed to grant IPv6 connectivity to nodes that are located behind IPv6 NAT devices. Teredo defines a way of encapsulating IPv6 packets within IPv4 UDP datagram's that can be routed through NAT devices and on the IPv4 internet.
Due to certain limitation in 6to4, Teredo alleviates the problem by encapsulating IPv6 packets within UDP/IPv4 datagram's through which NAT's can be forwarded.
Even when they don't have dedicated public IPv4 address, IPv6 aware hosts behind NATs can be used as Teredo tunnel endpoints. As a result, the host implementing Teredo can gain IPv6 connectivity without any co-operation from any local network environment.
Teredo protocol performs the following functionalities:
- It discovers the kinds of NAT by diagnosing UDP over IPv4 connectivity.
- Routes traffic between its hosts and IPv6 hosts.
- For a transmission over IPv4 network it encapsulates IPv6 packets inside UDPv4 datagram's
- Assigns globally route unique IPv6 addressing to each host.
Teredo node types
It defines several different kinds of node:
It has the IPv4 connectivity to the internet from behind the NAT and access to the IPv6 which is named as Teredo tunneling protocol. Its clients are assigned an IPv6 address that starts with the Teredo prefix (2001:0000::/32).
This host is used for initial configuration of a Teredo tunnel. A Teredo server never forwards any traffic for the client (apart from IPv6 pings), so therefore very modest bandwidth requirements which allows a single server to support large numbers of clients.
Regardless of how many clients it has, teredo server can be implemented in a fully stateless manner using the same amount of memory.
It acts as remote end of a Teredo tunnel. A Teredo relay must forward all of the data on behalf of the Teredo clients it serves. Therefore, a relay requires a lot of bandwidth and can only support a limited number of simultaneous clients. Teredo relay serves a range of IPv6 hosts (e.g. a single campus/company, an ISP or a whole operator network, or even the whole IPv6 Internet); it forwards traffic between any Teredo clients and any host within said range.
Teredo host-specific relay
As the Teredo relay range of service is limited to the host it runs on though it has no particular bandwidth or any routing requirements. A computer with a host-specific relay will use Teredo to communicate with Teredo clients, but anyway it will stick to its main IPv6 connectivity provider to reach the rest of the IPv6 Internet.
Teredo IPv6 addressing
Teredo client is assigned with public IPv6 address which is represented as follows:
Here the higher order bit is numbered 0.
- Teredo prefix (normally 2001:0000::/32) in which bits 0 to 31 are set to its prefix.
- Here bits 32 to 63 embed the primary IPv4 address of the Teredo server which is used.
- Bits 64 to 79 will be used to define some flags. Currently only the higher order bit is used and it is set to 1 if the Teredo client is located behind a cone NAT 0 otherwise.
- Bits 80 to 95 contain theobfuscated UDP port number. This port number is mapped by the NAT to the Teredo client with all its bits inverted.
- Bits 96 to 127 contains theIPv4 address. Here, the public IPv4 address of the NAT with all bits inverted.
The Teredo addresses are composed of 5 components:
- Prefix: the 32-bit Teredo service prefix.
- Server IPv4: the IPv4 address of a Teredo server.
- Flags: a set of 16 bits that document type of address and NAT.
- Port: the obfuscated mapped UDP port of the Teredo service at client.
- Client IPv4: the obfuscated mapped IPv4 address of the client.
a) Teredo IPv6 addressing table
As an example of Teredo client represented as the IPv6 address 2001:0000:4136:e378:8000:63bf:3fff:fdd2
With the help of simplifies STUN qualification procedure Teredo clients auto-detect the kind of NAT behind located by Teredo servers.
By sending a UDP packet at regular interval times, Teredo clients maintains a binding on their NAT toward their Teredo server in order to ensures that the server can always contact any of its clients for whole punching to work properly.
Teredo server also transmits ICMPv6 packet from Teredo clients toward the IPv6 Internet community.
Coming to Maintenance Teredo server requires little bandwidth because they are not actually involved in the actual transmission and reception of IPv6 packets.
However the requirements for any Teredo servers are:
The ability to emit ICMPv6 packets with a source address belongs to the Teredo prefix,
Two distinct public IPv4 addresses the second IPv4 address is needed for the purpose of NAT detection.
Teredo relay actually requires a better network bandwidth. It must advertise a route toward the Teredo IPv6 prefix (2001:0::/32) to other IPv6 hosts. In this way Teredo relay will receive traffic from the IPv6 hosts addressed to any Teredo client, and it forwards over UDP/IPv4. Symmetrically, it will receive packets from Teredo clients which are addressed to native IPv6 hosts over UDP/IPv4 and inject those packets into the native IPv6 network.
In reality, network administrators can set up a private Teredo relay for any company or campus. This will provide a short path between their IPv6 network and any Teredo client. However, setting up a Teredo relay beyond the scale of single network requires the ability to export BGP IPv6 routes to the other autonomous systems (AS's).
However coming to its usage, it has got some limitations where Teredo is not compatible with all NAT devices. Using the terminology of RFC 3489, cone, restricted and port-restricted NAT devices are supported, while symmetric NATs are not supported. Anyway, enhanced original Teredo protocol to support symmetric NAT implementations implements a certain unspecified non-standard extensions in order to improve support for symmetric NATs. However, the connectivity between a Teredo client behind a symmetric NAT and a Teredo client behind a port-restricted or symmetric NAT remains seemingly impossible.
In computer networking, a tunnel broker is a service which provides a network tunnel which can provide encapsulated connectivity over existing infrastructure to a new infrastructure.
There are a variety of tunnel broker, the term is used to refer to an IPv6 tunnel broker, as defined in [RFC 3053]. These Tunnel broker provide IPv6 tunnels to sites or end users. In general, tunnel brokers offer so called 'protocol 41' or proto-41 tunnels. These are tunnels where IPv6 is tunneled directly inside IPv4 by having the protocol field set to '41' (IPv6) in the IPv4 packet.
Automated Configuration is usually done using the Tunnel Setup Protocol (TSP), or using Tunnel Information Control protocol (TIC). A single client capable of this is AICCU (Automatic IPv6 Connectivity Client Utility)
In this, proto-41 tunnels (direct IPv6 in IPv4) may not be operating well with NATs. One way around this is to configure the actual endpoint of the tunnel to be the DMZ on the NAT-box. Another method is to either use AYIYA (Tunneling protocol for connecting islands of IP traffic with each other) or TSP( signaling protocol used to negotiate IP tunnel setup parameters between two tunnel end points) both of which send IPv6 inside UDP, which is able to cross NAT setups and firewalls when its needed.
A problem that still might occur is that of the timing out of the state in the NAT machine.
As a NAT remembers that a packet went outside the Internet will allow another packet to come back in from the Internet that will be related to the initial proto-41 packet. When this state expires, no other packets from the Internet will be accepted. Therefore, it breaks the connectivity of the tunnel until the users host again sends out a packet to the Tunnel Broker.
Whenever the endpoint is not a static IP address, then the user, or a program, has to instruct the tunnel broker to update the endpoint address. This will be done using the tunnel broker's web site or it might use an automated protocol like TSP which is used by AICCU. In the case of a tunnel broker using TSP, the client automatically restarting the tunnel will cause the endpoint address and port to be updated.
ISATAP is an address assignment and host-to-host, host-to-router, and router-to-host automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6/IPv4 hosts across an IPv4 intranet. ISATAP is described in RFC 4214. ISATAP hosts do not require any manual configuration and can create ISATAP addresses using standard address auto configuration mechanisms.
ISATAP addresses use the locally administered interface identifier ::0:5EFE:w.x.y.z, in which w.x.y.z is any unicast IPv4 address (public or private). The ISATAP interface identifier can be combined with any 64-bit prefix that is valid for IPv6 unicast addresses, including the link-local address prefix (FE80::/64) and global prefixes. The interface identifier potion of an ISATAP address contains an embedded IPv4 address that is used to determine the destination IPv4 address for the IPv4 header when ISATAP-addressed IPv6 traffic is tunneled across an IPv4 network. By default, the IPv6 protocol for Windows Server 2003 automatically configures the link-local ISATAP address of FE80::5EFE:w.x.y.z on the ISATAP tunnel interface (known as the Automatic Tunneling Pseudo-Interface) for each IPv4 address that is assigned to the node. These link-local ISATAP addresses allow two hosts to communicate over an IPv4-only network by using each other's link-local ISATAP address.
ISATAP hosts have an ISATAP tunneling interface and perform their own tunneling to either other ISATAP hosts or an ISATAP router. The use of link-local ISATAP addresses allows ISATAP hosts on the same logical subnet (an IPv4-only intranet) to communicate with each other, but not with other IPv6 hosts on other IPv6 subnets. To communicate outside the logical ISATAP subnet using ISATAP-based global addresses, ISATAP hosts must tunnel their packets to an ISATAP router.
An ISATAP router is an IPv6 router that performs the following:
Advertises address prefixes to identify the logical ISATAP subnet on which ISATAP hosts are located. ISATAP hosts use the advertised address prefixes to configure global ISATAP addresses.
It forwards packets between ISATAP hosts on the logical ISATAP subnet and IPv6 hosts on other subnets. The other subnets can be other IPv4 networks (such as a portion of an intranet or the IPv4 Internet) or subnets in a native IPv6 routing domain (such as an organization's IPv6 network or the IPv6 Internet).
Components of ISATAP
When an ISATAP host receives a router advertisement from an ISATAP router, the ISATAP host adds a default route (::/0) using the Automatic Tunneling Pseudo-Interface with next-hop address set to the link-local ISATAP address of the ISATAP router. When ISATAP hosts send packets destined to locations outside the logical ISATAP subnet, the packets are tunneled to the IPv4 address of the ISATAP router corresponding to the ISATAP router's interface on the IPv4-only network. The ISATAP router then forwards the IPv6 packet.
ISATAP hosts use the following routes:
An on-link route for the logical ISATAP subnet prefixes that ISATAP interface. This route allows ISATAP hosts to perform host-to-host tunneling to reach other ISATAP hosts on the same logical ISATAP subnet. In the example configuration, this is the 2001:DB8:0:7::/64 route.
A default route that uses the ISATAP interface has the next-hop address of the ISATAP router. This route allows ISATAP hosts to perform host-to-router tunneling to reach other IPv6 hosts on other IPv6 subnets.
An on-link route for the ISATAP subnet prefixes that uses the ISATAP interface. This route allows the ISATAP router to perform router-to-host tunneling to reach other ISATAP hosts on the logical ISATAP subnet. In the example configuration, this is the 2001:DB8:0:7::/64 route.
A default route that uses a LAN or tunneling interface has the next-hop address of the next router on the IPv6-capable network. This route allows the ISATAP router to forward IPv6 traffic to destinations that are not located on the logical ISATAP subnet.
A route for the logical ISATAP subnet prefixes that points back to the ISATAP router. This route allows the routers of the IPv6-capable network to forward traffic destined for ISATAP hosts to the ISATAP router.
ISATAP Communication Examples:
There are two types of communications in ISATAP.
- ISATAP Host to ISATAP Host
- ISATAP Host to IPv6 Host
ISATAP Host to ISATAP Host Communication:
In this example, ISATAP Host A wants to send a packet to ISATAP Host B. ISATAP Host A has resolved ISATAP Host B's IPv6 address through a DNS name query. When sending the packet, IPv6 on ISATAP Host A performs the IPv6 route determination process and finds that the closest matching route to the destination is the on-link 2001:DB8:0:7::/64 route. Because it is an on-link route, the next-hop IPv6 address is set to the destination address (2001:DB8:0:7:0:5EFE:188.8.131.52). The IPv6 packet and the next-hop address are handed to the ISATAP interface for processing.
The ISATAP interface sets the destination IPv4 address in the IPv4 header to the last 32-bits of the next-hop address, which in this case is ISATAP Host B's IPv4 address of 184.108.40.206. IPv4 on ISATAP Host A determines that the best source address to use is the IPv4 address assigned to ISATAP Host A (192.168.47.99) and then sends the packet. On ISATAP Host B, IPv4 processes the IPv4 header and because the Protocol field is set to 41, it hands the IPv6 packet to the IPv6 protocol for further processing.
When ISATAP Host A sends to a destination that is not on the logical ISATAP subnet (IPv6 Host C), IPv6 on ISATAP Host A performs the route determination process and finds that the closest matching route to the destination is the default route (::/0). The default route has a next-hop IPv6 address of the link-local ISATAP address of the ISATAP router's interface on the IPv4-only intranet, which for our example is FE80::5EFE:10.0.0.1. The IPv6 packet and the next-hop address are handed to the ISATAP interface for processing. The ISATAP interface sets the destination IPv4 address in the IPv4 header to the last 32-bits of the next-hop address, which in this case is the ISATAP router's IPv4 address of 10.0.0.1. IPv4 on ISATAP Host A determines that the best source address to use is the IPv4 address assigned to ISATAP Host A (192.168.47.99) and then sends the packet. The above Figure shows the journey of the packet from ISATAP Host A to the ISATAP router.
Migrating to IPv6:
The migration of IPv4 to IPv6 will be a long process and some details of migration have yet to be determined. As a general methodology, to migrate from IPv4 to IPv6, we must perform the following steps:
- Upgrade the applications to be independent of IPv6 or IPv4.
- Update the DNS infrastructure to support IPv6 address and PTR records.
- Upgrade hosts to IPv6/IPv4 nodes.
- Upgrade routing infrastructure for native IPv6 routing.
- Convert IPv6/IPv4 nodes to IPv6-only nodes.
Applications must be changed to use new Windows Sockets application programming interfaces (APIs) so that name resolution, socket creation, and other functions are independent of whether IPv4 or IPv6 is being used.
The DNS infrastructure might need to be upgraded to support the new AAAA records (required) and PTR records in the IP6.ARPA reverse domain (optional). Additionally, ensure that the DNS servers support DNS dynamic update for AAAA records so that IPv6 hosts can automatically register their names and IPv6 addresses.
Hosts must be upgraded to use a dual IP layer or dual IP stack. DNS resolver support must also be added to process DNS query results that contain both IPv4 and IPv6 addresses. Deploy ISATAP to ensure that IPv6/IPv4 hosts can reach each other over the IPv4-only intranet.
Routers must be upgraded to support native IPv6 routing and IPv6 routing protocols.
IPv6/IPv4 nodes can be upgraded to be IPv6-only nodes. This should be a long-term goal because it will take years for all current IPv4-only network devices to be upgraded to IPv6-only. For those IPv4-only nodes that cannot be upgraded to IPv6/IPv4 or IPv6-only, employ translation gateways as appropriate so that IPv4-only nodes can communicate with IPv6-only nodes.
- When we compare IPv6 over IPv4, we have Efficient Routing in IPv6 since it has large hierarchical address space which allows efficient routing whereas IPv4 has lack of uniformity in hierarchical system, limited address, reduces performance, and increases routing information in backbone routers.
- IPv6 header size is better than IPv4 due to its fixed size which is easily predictable, the extension headers in it also allow new headers to add easily.
- IPv6 is Exhaustion Imminent whereas in IPv4, the gross expansion of the internet was not expected in the design of IPv4 and many addresses are lost due to the hierarchical structure of the protocol.
- It was clear that IPv6 was not to make the same mistake IPv4 had by making their number system dependent on location. One of the reasons IPv4 is quickly running out of numbers is that entire blocks can be lost.
- Instead of using 32 bit to store an address like IPv4, IPv6 uses 128.
- IPv4 has no built in security, all modern security precautions are a result of retrofit. IPv6 has multiple modes for the header to have increased functionality and IPSec is mandatory in all IPv6 packets.
- The security features of IPv6 are built in the protocol; it makes a more secure system than IPv4.
Most of the industry wide routers implement their functionality in hardware and therefore we believe that hardware based routers are more efficient than a software-based router implementation. The reason few researchers tested IPv6's performance using hardware based routers supporting dual stack IPv4/IPv6 are relatively expensive. As a result, most of the work done in the research community has been performed using software-based routers utilizing off-the-shelf PCs. Various works have been attempted which evaluated the IPv6 protocol stack, however none of them used hardware-based routers, had such a wide range of metrics, and none investigated transition mechanisms.
As per the observations from the current scenario it is obvious that no problems arise in implementing the IETF standards for IPv6 because major operating system and router vendors already have implemented and periodically demonstrated interoperability. In the short run, differences in the implementation of IPv6 could potentially lead to interoperability problems in some areas. From our observation we can keep up with the ongoing developments by adding test beds and some testing activities.
In absence of these we assume that future IPv6 products developed in any company might not be able to interact with the available general protocol standards. In today's commercial world many companies are implementing IPv6 which results in better security and routing practices.
- IETF IPv6 Transition Working Group
- I. Raicu. "An Empirical Analysis of Internet Protocol version 6 (IPv6)", Master Thesis,Wayne State University, 2002.
- Kent, R. Atkinson. "Security Architecture for the Internet Protocol", Request for Comments 2401, Internet Engineering Task Force, November 1998
- G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT),"Request for Comments 2766, Internet Engineering Task Force, February 2000.
- A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel Broker, " Request for Comments 3053, Internet Engineering Task Force, January 2001.
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.