Transition mechanisms through tunnels: 6to4, Teredo and 6RD

Danny Santiago Guamn Loachamn UPM Dpto. de Ingeniera de Servicios Telemticos ds.guaman@alumnos.upm.es Abstract. This paper begins with a brief discussion of the importance of IPv6 deployment and implementation of transition mechanisms through tunnels. In this paper were analyzed three specific cases: 6to4, 6RD and Teredo. In each transition mechanism are described: the scenario in which can be implemented, requirements, model of operation and security considerations. These transition mechanisms have problems when the client's local network behind a NAT. Then described the types of NATs: Full Cone, Restricted Cone, Port Restricted Cone and Symmetric NATs. Also, it describes a technique to cross NAT: Session Traversal Utilities for NAT (STUN) which is used by Teredo. Teredo does not work with symmetric NAT, but this paper presents a proposal for traversing this type of NAT, it is called SymTeredo. Finally, a comparison is made between the three transition mechanisms. It concludes that 6RD provides better performance than 6to4, and that Teredo should be considered as a last resort mechanism because it has poor performance.

Keywords: IPv6 , NAT , Teredo , 6RD, 6to4, Tunneling, IP networks.

1. Introduction
On February 3, 2011 Rod Beckstrom, President of the Internet Corporation for Assigned Names and Numbers (ICANN), announced that had been delivered the last five IPv4 address blocks to Regional Internet Registries [1]. This event has already announced from the 90s shows that the exhaustion of public IPv4 addresses is a reality. So the question arises: We begun IPv6 deployment around the world? The answer to this question is relative and depends on the region where we do. The urgency exists in the regions where to get an IPv4 address is not easy and where the proliferation of new services and the number of mobile devices are growing at an accelerated rate [2]. So it is very important to start with the deployment of IPv6 around the world now!. There are several enhancements that IPv6 offers in addition to increasing the address length: more efficient routing mechanism, better support for security, quality of service, improved mobility, etc. It also opens a range of possibilities for innovation and development of new services and applications. Lowering costs and reducing time in the development of such applications due to return to the principle end-to-end [3]. Another reason is that the Internet is growing faster and converged services: telephony, multimedia, data, Internet of things, all over IP. It presents a great opportunity to innovate and create new applications and services and not limited ourselves by those limitations that impose the IP version 4. However, although several companies in some countries are aware of the exhaustion of IP addresses, they do not know what the next step. Implement one of the many transition mechanisms? Or maybe,

implement a mechanism to increase the time of IPv4, such as Carrier Grade NAT [4] access networks?. If we will decide to go for the second option, Geoff Huston (2011) says: "The risk here is that after making this additional capital investment in Carrier Grade NAT infrastructure, the ISP will be very motivated to protect the value of this investment and will not an effort to implement IPv6 ". In this case an increase of NAT-level - will result in a degradation of service to clients and the opportunity to innovate with new applications and services would be impractical or too expensive because it goes against the principle end-to-end. The first option, without a doubt, the most successful. Compared with Carrier Grade NAT, IPv6 is the only strategy that ensures the continued growth of the Internet, improving simplicity and innovation through connectivity end-to-end.. But the transition must start now!, this transition is not instantaneous it takes time. The transition from Google's internal network began in 2008 and still continue with some drawbacks. Around 95% of the engineers accessing at the corporate network have IPv6 access [5]. In any case, for those who have decided to begin the transition to IPv6, there are several alternatives when choosing a transition mechanism [6]. This paper describes three transition mechanisms through tunnels: 6to4 [7], 6RD [8] and Teredo [9]. These mechanisms could be very useful, because they allow to have IPv6 connectivity even if your ISP does not support native IPv6. Teredo is a transition mechanism that allows IPv6 connectivity, even if it is behind a NAT. Therefore, in the following section describes the types of NAT and a technique called STUN (Session Traversal Utilities for NAT) to traverse[10].

2. Network Address Translation

This section briefly describes the four types of NAT. This classification is of great importance to understand the STUN technique used to traverse NAT.

2.1. Full Cone NAT

Full Cone NAT is the least restrictive of all types of NAT. All requests sent from the same internal source address and port are mapped to the same external address and port. In addition, any external host can send a packet to the internal host by sending packets to the mapped external address and port. In Figure 1, once the Host A with internal address (IPa:Pa) is mapped to the external address (IPb:Pb) any package from IPa:Pa always be mapped to the external address IPb:Pb. In addition, any external host (IPs2:Pd) can send packets to the internal host A (IPa:Pa) through NAT external address IPB:Pb.

the port restriction. In other words an external host can send packets to the internal host only if the internal host previously sent a packet to a specific IP address and port of the external host. In Figure 3, once the host A with internal address (IPa:Pa) is mapped to the external address (IPb:Pb), any packets from IPa:Pa always be mapped to the external address IPb:Pb. In addition, an external host (IPs1: Pc) can send packets to the internal host A (IPa:Pa) only if previously the host A has sent a packet to IP address and port of the external host IPs1:Pc. Any package delivered from any other host (IPs2:Pd) or any other port (IPs1:Pd) will be rejected.

Figure 3. Port Restricted Cone NAT.

2.4 Symmetric NAT

It is the most restrictive of the four types of NATs described in this paper. All requests sent from the same source address and port internal to the same destination address and port are mapped to the same external address and port. Therefore, if a packet is emitted from the same internal source address and port, but to a different destination address or port, a new mapping is performed. In addition, an external host can send packets to the internal host only if the internal host previously sent a packet to a specific IP address and port of the external host. In Figure 4, once the host A with internal address (IPa:Pa) and destination address (IPs1:Pd) is mapped to the external address (IPb:Pb), any packets from IPa:Pa to IPs1:Pd always be mapped to the external address IPb:Pb. If a packet is transmitted from host A with the same internal address (IPa:P) but to a different destination address (IPs1:Pf) is mapped to a new external address (IPb:Pc). In addition, an external host (IPs1:Pd) can send packets to the internal host A (IPa:Pa) only if previously Host A has sent a packet to IP address and port of the external host IPs1:Pd. Any other package will be rejected (IPs1:Pe or IPs2:Pg).

Figure 1. Full Cone NAT.

2.2 Restricted Cone NAT

Like Full Cone NAT all requests sent from the same internal source address and port are mapped to the same external address and port. But unlike Full Cone NAT, an external host can send a packet to the internal host only if the internal host previously sent a packet to the external host IP address. In Figure 2, once the host A with internal address (IPa:Pa) is mapped to the external address (IPb:Pb), any packets from IPa:Pa always be mapped to the external address IPb:Pb. In addition, an external host (IPs1) can send packets to the internal host A (IPa:Pa) only if previously the host A has sent a packet to the external host IP address (IPs1), regardless of the port (can be IPs1:Pc, IPs1:Pd). Any package delivered from any other host (IPs2) will be rejected.

Figure 2. Restricted Cone NAT.

Figure 4. Symmetric NAT.

2.3 Port Restricted Cone NAT

All requests sent from the same internal source address and port are mapped to the same external address and port. In addition, it fulfills the same function as Restricted Cone NAT but also involves

3. Session Traversal Utilities for NAT (STUN)

STUN is the technique used by others protocols to traverse NATs. STUN allows packets to pass through

three less restrictive types of NAT: Full Cone, Restricted Cone and Port Restricted Cone NATs. One of the major limitations of this technique is that it does not work with Symmetric NAT. STUN allows a client to know if it is behind a NAT and what kind is this. Requires a STUN server and client. The STUN server is located on the Internet and has two ports and two IP addresses (See Figure 5). STUN operation is based on four types of tests, and these are detailed in the following sections.

the client is behind a Symmetric NAT and ends the process. If match is passed to the last Test.

3.4 Test IV
T4-1: The STUN client sends a request to the STUN server address IP1 and Port 1. Also requests the server to send the response using the same IP, but through Port 2. T4-2: The server responds using the address IP1 and port 2. STUN Client: If it receives the answer T4-2, then it concludes that the client is behind a Restricted Cone NAT. If no response is received, then it concludes that the client is behind a Port Restricted Cone NAT.

4. 6to4
Figure 5. Session traversal utilities for NAT.

3.1 Test I
T1-1: The STUN client sends a request to the STUN server address IP1 and Port 1. T1-2: The server responds with a message whose payload contains the source IP address and port of the request T1-1. STUN Client: If not T1-2 response is received, perhaps the firewall may be blocking UDP traffic. If T1-2 response is received and IP address and port contained in the payload match the local IP address and port of the client, it is concluded that there is not NAT in the path and ends the process. If the values differ, the client concludes that there is a NAT in the path and performs the following test to determine the type of NAT.

6to4 is a transition mechanism through tunnels which encapsulates IPv6 packets within IPv4 packets so that it can pass through IPv4-only networks and to allow IPv6 traffic through ISPs that only offer IPv4 service. The protocol number of the IPv4 header should be 41, which is reserved for tunneling IPv6 packets. The IPv6 address of a 6to4 host accessible has the prefix 2002::/16. It carries a IPv6 address corresponding IPv4 address, as shown in Figure 6. For example, the address 2002:BF50:4143::1 /128 contains the 6to4 prefix 2002 and the IPv4 address 191.80.65.67 (BF50:4143).
0x2002 Address IPv4 Customer site ID Subnet ID Interface

16 bits

32 bits

16 bits

64 bits

Figure 6. A 6to4 address format.

3.2 Test II
T2-1: The STUN client sends a request to the STUN server address IP1 and port 1. Unlike T1-1, the client requests the server which send the answer using the address IP2 and Port 2. To achieve this in the request must send certain parameters [10]. T2-2: The server responds using the address IP1 and port 1. STUN Client: If it receives the T2-2 response then it concludes that it is behind a Full Cone NAT, and ends the process. If no response is received Test III is performed.

4.1 Deployment scenario.

6to4 is an especially useful mechanism in the initial phase of the deployment of IPv6, where also the ISP does not provide native IPv6. However, we must be aware that 6to4 transition mechanism is temporary and not meant to be used permanently. There are two scenarios where you can implement 6to4: a) A simple scenario allows connectivity between a 6to4 IPv6 site and other 6to4 IPv6 site, separated by only-IPv4 Internet. See Figure 7. b) A mixed scenario allows connectivity between a 6to4 IPv6 site and a native IPv6 site, separated by only-IPv4 Internet. See Figure 8.

3.3 Test III

T3-1: The STUN client sends a request to the STUN server address IP2 and Port 1. T3-2: The server responds with a message whose payload contains the source IP address and port of requested T3-1. STUN Client: If the address and port contained in the payload of T3-2 are different from the values contained in the T1-2 payload, it is concluded that

Figure 7. A 6to4 simple scenario

4.2 Simple scenario requirements.

1) A 6to4 router located on the border of the 6to4 IPv6 network and IPv4 Internet. 2) Each site should have an IPv6 prefix 2002:V4ADDR::/64. 3) Each site should have at least one IPv4 Internet (V4ADDR). 4) Site A and Site B should be able to send IPv4 packets with protocol type 41 between them.

4.3 Mode of operation in simple scenario

When an outgoing packet reach the 6to4 router, it is encapsulated IPv4 packet with protocol type 41. The IPv4 destination address is contained within the packet's destination IPv6 address 2002:v4ADR::/64, while the source address is the 6to4 router's public IPv4 . In Figure 2, T-1: If a host in site A sends a packet to site B, the 6to4 router encapsulates the IPv6 packet within an IPv4 packet, whose source and destination addresses are 192.1.6.7 (C0010607) and 191.80.65.67 (BF504143), respectively. T-2: The IPv4 packet is routed as any IPv4 packet through the IPv4 Internet. T-3: At the 6to4 destination router the IPv4 header is discarded, and the IPv6 packet is routed normally within the site B. In this scenario any number of 6to4 sites can communicate with each other, do not require more than additional requirements listed above.

sent to the anycast address 192.88.99.1, which is the nearest 6to4 relay. T-3: The relay discards the IPv4 header and extracts the IPv6 packet. Then it is routed to the server as any IPv6 packet. T-4: The server sends the response to the address 2002:C001:0607::100. The route to the IPv6 prefix 2002:: / 16 is announced by the relay, then the answer will be directed to him. T-5: The relay receives the packet and encapsulates the IPv6 packet within an IPv4 packet. The protocol number is 41. The source IPv4 address is the address IPv4 of the relay, and the destination address is 192.1.6.7 (It is extracted from the IPv6 destination address of T-5). T-6: Finally, the 6to4 router discards the IPv4 header and extracts the IPv6 packet, routed to the host 2002:C001:0607::100. The main difference between the two scenarios mentioned above is that in the simple scenario 6to4 routers do not use an IPv6 exterior routing protocol, while in the second scenario, the relay must advertise the prefix 2002:: / 16 to their peers.

4.4 Security considerations

The main security threats are Denial of Service (DoS) and Spoofing. The reason is the 6to4 router must accept traffic from any other 6to4 router or 6to4 relay. Several of them may come from malicious nodes are launching a Denial of Service attack. Another threat to consider is the theft of service, in which a malicious node, site or operator can make unauthorized use of the service. The security and operational problems that arise in 6to4 mainly due to the 6to4 relay are controlled and managed by a third party. In addition the 6to4 relay is "forced" to accept traffic from any host whose IPv6 prefix is 2002:: /16. 6RD transition mechanism described below proposes an alternative that attempts to correct these problems.

4.4 Mixed scenario requirements

In addition to the above requirements: 1) A 6to4 relay, it is a router that allows the transit of 6to4 packets to a native IPv6 network. 2) The 6to4 router should configure the default gateway with the anycast address 192.88.99.1.

5. IPv6 Rapid Deployment (6RD)

6RD enables rapid deployment of IPv6 in the infrastructure of the ISP. It is a transition mechanism similar to 6to4, but trying to solve some problems in it. The main problem with 6to4 is that an ISP operates one or several 6to4 relay and it advertise the IPv6 prefix 2002::/16 to the IPv6 Internet. Then the relays are forced to receive packets destined to 6to4 routers located in other ISPs infrastructures. Then these 6to4 relay may be subject to Denial of Service attacks easily. Hence, it cannot guarantee delivery of packets from native IPv6 network to a host in site6to4. To resolve this problem 6RD proposes the following changes: 1) Replace the IPv6 prefix 2002::/16 for another IPv6 prefix given by an RIR (see Figure 9), and replaces the anycast address used by 6to4 (192.88.99.1) for another anycast address chosen by the ISP. 2) The ISP deploys one or more gateways 6RD (formerly called 6to4 relay) within its own infrastructure and be located on the border between IPv4 ISP network and IPv6 Internet. 3) The Home Gateway 6RD (formerly called 6to4 router)

Figure 8. A 6to4 mixed scenario.

4.5 Mode of operation in mixed scenario.

Model of operation: In Figure 8, T-1: A host in site A sends a packet to a server located in native IPv6 Internet. The 6to4 router encapsulates the IPv6 packet within an IPv4 packet whose protocol number is 41. The source IPv6 address is 2002:C001:0607::100 where C0010607 (192.1.6.7) is the source IPv4 address of site A. While the IPv6 destination address is the server's native IPv6 address. T-2: The packet is

supports IPv6 on the client side and 6RD on the ISP side. These changes solve the problem because the ISP itself manages all 6RD network infrastructures and allows input of packets arriving from the IPv6 Internet to Gateway 6RD only if they are destined to a site's ISP.

2) The 6RD Gateway should not use the same anycast address 192.88.99.1, the ISP must choose a different anycast address, for example in Figure 9 uses the anycast address 192.88.99.102. 3) The most important difference is perhaps that 6RD Gateway are located within the ISP's network infrastructure.

5.3 Security considerations

Prefix assigned by RIR Address IPv4 Customer Site ID Interface

32 bits

32 bits

64 bits

Figure 8. A 6RD address format.

5.1 Deployment Scenario

6RD is a very useful especially in the initial phase of the deployment of IPv6 in an ISP. This transition mechanism is ideal for ISPs to rapidly deploy IPv6 service in IPv4 residential sites, where they also provide a CPE (Customer Premises Equipment). In 6RD as well as 6to4 there are a simple scenario or a mixed scenario of operation. A simple scenario allows two sites 6RD through the Internet IPv4 and a mixed scenario in which a 6RD site communicates with hosts within native IPv6 Internet.

6RD must consider threats of Spoofing and Denial of Service (DoS), but are less common and more difficult to perform compared to 6to4. At this point I would like to mention a problem that has 6RD and is not necessarily a security threat. The problem is that sometimes 6RD is against policies address assignment an RIR. The reason is that an RIR normally assigned an IPv6 address prefix /32 to an ISP. According to what was described in section 5, after of 32 bits assigned by the RIR the next 32 bits are the IPv4 address of the site. Then, the address would complete the first 64 bits and there are no bits for subnets. Two solutions have been proposed: one is that the RIR allocated IPv6 address with a prefix smaller and the other solution is to not use the IPv4 address of 32 bits, discarding the redundant prefix [8].

5. Teredo
Teredo is a tunneling transition mechanism that encapsulates IPv6 packets within a UDP IPv4 packets. Thus a packet can traverse an IPv4-only network, and enable IPv6 traffic through ISPs that only offer IPv4 service. The IPv6 address Teredo host has a prefix 2001:0000::/32 (See Figure 10). This IPv6 address contains: the Teredo server IPv4 address, a flag to indicate if the host is behind a NAT (most significant bit set to 1), and the public IPv4 address and port mapped by NAT device. These public IPv4 address and port mapped have bits reversed for obfuscation mechanism [9]. The structure is shown in Figure 6.
Teredo Server IPv4 Port mapped by NAT IPv4 mapped by NAT

Figure 9. A deployment scenario for 6RD.

5.2 Requirements
1) Home Gateway 6RD provided by the ISP. It is located between the IPv6 site and the IPv4 ISP network. 2) Each site should have an IPv6 prefix provided by a Regional Internet Registry (RIR). 3) Each site must have at least one IPv4 Internet (V4ADDR). 4) Site A and Site B should be able to send IPv4 packets with protocol type 41 between them. 5) A 6RD Relay allows the transit of packets from 6RD site to a native IPv6 network.

0x20010000

Flags

32 bits

32 bits

16 bits

16 bits

32 bits

Figure 10. A Teredo address format.

5.3 Operation Mode

The 6RD operation mode is the same as 6to4. In a simple scenario is performed the same procedure described in Section 4.3. While, for a mixed scenario is performed the same procedure described in section 4.5. However some differences should be noted. 1) 6RD sites should not use the IPv6 prefix 2002::/16, instead using an IPv6 prefix assigned by an RIR, for example in Figure 9 uses the prefix 2000:0000:/32.

For example, in the Teredo client IPv6 address 2001:0000:BF50:4143:8000:63BF:3FFF: FDD2/128: 2001000 is the IPv6 prefix, BF504143 (191.80.65.67) is the Teredo server IPv4 address, 8000 indicates that it is behind a NAT (the most significant bit set to 1), 63BF (after investing the bits: 40000) is the port mapped by NAT, and 3FFFFDD2 (after investing the bits: 192.0.2.45) is the address mapped by NAT. See Figure 11.

5.1 Deployment Scenario

Teredo is a very useful especially in the initial phase of the deployment of IPv6 in which also the ISP does not provide native IPv6. However, one must be aware that Teredo is a temporary transition mechanism and is not meant to be used permanently. Unlike 6to4, Teredo does not require a public IPv4 address to be implemented. Teredo IPv6 ensures connectivity to nodes that are located in an IPv4 network, even if it is behind a NAT Router. The ideal environment for Teredo is a home network, such as residential ADSL service. Teredo provides IPv6 access of last resort therefore only be used when it is not possible to use another transition mechanism.

mapped the addresses 192.0.2.45:40000 to 192.168.1.100:3800 according to the address mapping table.

5.3 Security Considerations

Teredo is considered a transitional mechanism of last resort because it has several security threats and have poor performance. A host is reachable via IPv6 address, although it is behind a NAT. Spoofing a Teredo server by attacking man-in-the-middle. Denial of Service Attack (DoS) to the Teredo client. Denial of Service (DoS) to the relay or Teredo server by routing loops. Then Teredo requires special care to maintain the initial security by setting: access control lists, firewalls, only accept traffic from locals and IPSec configuration [9]. Teredo has some limitations, one of which is that provides a single IPv6 address for each end of the tunnel. Another limitation is that Symmetric NAT is not supported. There is a proposal for traversing this type of NAT called SymTeredo described in the next section.

Figure 11. A deployment scenario for Teredo

6. SymTeredo
SymTeredo [11] is an extension of Teredo for traversing the Symmetric NAT. Requires slight modifications in the Teredo Relay and the Teredo Client, but is compatible with the current protocol. No changes in the Teredo server.

5.2 Requirements
1) Teredo Server is used by Teredo clients to identify if this is behind a NAT, and identify what type it is. This uses a simplified version of STUN described in Section 3. 2) Teredo client is a dual stack host and must be assigned an IPv6 address (prefix 2001:0000::/32). 3) Teredo relay must advertise the prefix 2001:000:: / 32 to their peers IPv6.

6.1 Problem
In the NAT table in Figure 12, when the Teredo client is behind a Symmetric NAT, it generates two different mappings: the first (port 40000) when it communicates with the Teredo server and the second (port 50000) when this communicates with the Teredo relay. According to the mode of operation described in section 5.3, when a native IPv6 host try to communicate with Teredo client, the relay will send packets to 192.0.2.45:40000 without success. Thus the goal of SymTeredo is to discover the correct address and port (192.0.2.45:50000) at which the relay should send the packets.

5.3 Operation Mode

Mode of operation described below is for Full cone NAT type, the section 6 describes the mode operation for Symmetric NAT. In Figure 11, T-1: The Teredo client interacts with the Teredo server and determines if there is a NAT and the type. The qualification procedure uses the STUN protocol that was described in Section 3. If the type is not Symmetric NAT, the server assigns an IPv6 address whose structure was described in section 5. T-2: If the Teredo client wants to communicate with native IPv6 host should use the Teredo relay. The Teredo relay announces the prefix 2001:000::/32 to the IPv6 Internet. T-3: The IPv6 packet is sent from the Native IPv6 host to the Teredo relay. T-4: The Teredo relay encapsulates the IPv6 packet in UDP IPv4 packet. The IPv4 address information and UDP port information of this packet are determined based on Teredo IPv6 address as follows. The source IPv4 address is the IPv4 address of the Teredo relay (191.40.3.6), and the destination IPv4 address and port (192.0.2.45:40000) is contained in destination IPv6 address (2001:0000:BF50:4143:8000:63BF:3FFF:FDD2). Then, the Teredo relay sends the packet through IPv4 Internet. After the NAT receives this IPv4 packet, it

Figure 12. A deployment scenario for SymTeredo

6.2 Modifications
Teredo client modification: The acquired IPv6 address includes a symmetric flag 0x4000 instead of 0x8000 to indicate that the NAT server is symmetric. In Figure 12, the address is 2001:0000:BF50:4143:4000:63BF:3FFF:FDD2. Changes in the Teredo relay: Maintains a addresses cache, their use is described in the next section.

6.3 Operation Mode.

Steps T-1 to T-2 in Figure 12 are the same as described in section 5.3. T-3: The SymTeredo relay accepts the packet from a native IPv6 node, and detects that the SymTeredo client is behind a Symmetric NAT for the flag 0x4000. The packet is stored for transmission later. T-4: Relay sends a Bubble message [9] to the Teredo server. Bubble message is an IPv6 packet encapsulated in IPv4 UDP packet whose source address is the IPv6 address SymTeredo Relay and destination address is the IPv6 address of SymTeredo Client. T-5: The Teredo Server forwards the Bubble message to the

SymTeredo Client (192.0.2.45:40000), but the source IPv4 address and port belong to the Teredo server (191.80.65.67:3544). Therefore the packet through the NAT.. T-6: SymTeredo client discards the UDP IPv4 header and get the Bubble message. The source address of Bubble menssage is the IPv6 address of the relay SymTeredo (contains its own IPv4 address). The SymTeredo client sends a reply packet to the SymTeredo relay, T-7: When the response packet through the NAT, it creates a new mapped address in the NAT table. The new address can be used by the SymTeredo relay to achieve the SymTeredo client. T-8: The relay SymTeredo once receives the response, stores the source IPv4 address and source UDP port in the addresses cache. Where the client IPv6 address is used as an index to find the IPv4 address and port right. T-9: The SymTeredo relay recovers the IPv6 packet stored in the buffer (T-3). The IPv6 packet is encapsulated within an UDP IPv4 packet whose source address and port were recovers from Address Cache. Finally it sends the packet to the client SymTeredo, this time the message passes through NAT because an entry was created before (T-9). Thus an IPv6 packet sent from an IPv6 host to the SymTeredo client can successfully pass through the symmetric NAT.

6. Comparison between 6to4, 6RD y Teredo

Comparison Factor IPv6 Prefix Allocation Deployment scenario. Transparent to customer Requirements Direct Connectivity Security Level. Mayor security threats Performance

6to4 2002::/16 6to4 IPv6 Site - Internet IPv4 - 6to4 IPv6 Site. 6to4 IPv6 Site - Internet IPv4 Native IPv6 Site. No IPv6 host support. Router 6to4. Relay 6to4. Public Address IPv4. Only between 6to4 hosts. Low: Better than Teredo. Denial of Service. Spoofing. On average: Lower overhead that Teredo (IPv6 packet over IPv4 packet)

6RD Assigned by RIR. 6RD IPv6 Site - Internet IPv4 6RD IPv6 Site. 6RD IPv6 Site - Internet IPv4 Native IPv6 Site. Yes IPv6 host support. Home Gateway RD (CPE). Border Gateway RD. Public Address IPv4. Only between 6RD hosts. On Average: Better than Teredo and 6to4. Denial of Service. Spoofing. On average: Lower overhead that Teredo (IPv6 packet over IPv4 packet)

Teredo 2001:000::/32 Teredo Client - Internet IPv4 - Teredo Client Teredo Client - Internet IPv4 - Native IPv6 Site. No Dual-Stack Host. Teredo Server. Teredo Relay. Public or Private IPv4 Only between Teredo Clients. Low. Denial of Service. Spoofing. Poor performance: Overhead (IPv6 packet over UDP datagram and over IPv4 packet) and additional messages Bubble sent. Depends on the NAT type.

NAT Traversal

No 6to4 Relay are outside the ISP's infrastructure. Then it can't guarantee delivery of packets from native IPv6 host to 6to4 site. Also it increased security threats.

No Sometimes it is against the policy of the RIR address allocation because it requires less than one IPv6 prefix /32.

Major drawbacks

Poor performance and high security risks. Also it can't traverse Symmetric NATs.

Table 1. Comparison between 6to4, 6RD y Teredo

7 Conclusions
The transition mechanisms through tunnels 6to4, 6RD and Teredo are temporary alternatives for IPv6 deployment. These may be useful to familiarize themselves with IPv6, and build IPv6 test environments for developing of new applications and services, while our ISP deployed IPv6 natively. 6RD is the best alternative of the three mechanisms described in this paper. 6RD allows rapid deployment of IPv6 safer than 6to4. Furthermore, this mechanism is implemented by the ISP and it is transparent to the user. However, we must be aware that has a problem because it goes against the policy address assignment to the RIRs. Now, we have to wait if ISPs are willing to change or update the CPEs in each of the clients. The implementation of NAT was an important solution to the IPv4 address exhaustion, but it introduced a lot of complexity in the network and this is against the principle end-to-end. This complexity causes serious problems in IPv6 deployment, and it resulting in complex transition mechanisms such as Teredo. Teredo should be considered as a transition mechanism of last resort due to its poor performance by the overhead added and additional messaging as Bubble Messages.

[7] B. Carpenter and K. Moore. "Connection of IPv6 Domains via IPv4 Clouds". RFC 3056. February 2001. [8] W. Townsley and O. Troan. " IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification". RFC 5969. August 2011. [9] C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, RFC 4380, February 2006. [10] J. Rosenberg, J. Weinberger and R. Mahy, Session Traversal Utilities for NAT (STUN), RFC 5389, October 2008. [11] S. M. Huang, Q. Wu and Y. B. Lin, "Enhancing Teredo IPv6 tunneling to traverse the symmetric NAT," Communications Letters, IEEE, vol. 10, pp. 408-410, 2006.

References
[1] ICANN. Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied. 2011(04/12/2011). Available: http://www.icann.org/en/news/releases/release03feb11-en.pdf [2] S. Hogg. Techniques for Prolonging the Lifespan of IPv4. 2011(14/10/2011). Available: http://www.networkworld.com/community/node /79152. [3] J. H. Soltzer, D. P. Reed, and D. D. Clark, "Endto-end arguments in system design," ACM Tmns. Comp. Sys., vol. 2, no. 4, 1984, pp. 27788. [4] G. Huston. "NAT++: Address sharing in IPv4". Internet Protocol Journal. vol. 13(2), pp. 2-15. 2010. [5] H. Babiker, I. Nikolova and K. K. Chittimaneni. "Deploying IPv6 in the Google Enterprise Network: Lessons learned". 2011. [6] G. Huston. "Transitioning protocols". Internet Protocol Journal. vol. 14(1), pp. 22-46. 2011.