Email Trace | Email Tracking | Reverse Email Trace | IP-Adress.com

Email Trace | Email Tracking | Reverse Email Trace | IP-Adress.com

Fred Bovy New Blog

Hi,

I have created a new blog in my domain.

This may help as some companies are blocking social networking sites like this one!


You can now find some new publications from
http://fredbovy.com

and more directly
http://fredbovy.com/dotclear2

You can eve subscribe to an RSS Feeder of this site.

Regards,

Fred

6RD

6RD (RFC5969)

In 2007, Remi Despres already famous for having designed Transpac, an X25 Network in the 80s had the idea to customized 6to4 to make a protocol that a Service Provider could use to deploy an IPv6 Service over an IPv4 Backbone. http://en.wikipedia.org/wiki/R%C3%A9mi_Despr%C3%A9s


For a full overview of all the principle Transition Protocols, please refer to this blog:
http://www.fastlaneus.com/blog/?p=335

And this video:
http://youtu.be/TqmKCqYsk5A


The first popular automatic tunnels were 6to4. 6to4 solved two problems, IPv6 addressing and automatic destination tunnel configuration. 6to4, Connection of IPv6 Domains via IPv4 Clouds, RFC 3056 was published in 2001. It was one of the first transition to IPv6 protocols after the static tunnels and dual-stack.
It provided the reserved IPv6 prefix, 2002::/16. Following this prefix was configured the 6to4 gateway public IPv4 address. This way, the destination IPv4 address of the tunnel was coded in the destination IPv6 address. For instance if a 6to4 Gateway public IPv4 address was 193.2.4.5, the IPv6 site which would be reachable from this 6to4 Gateway would use the prefix: 2002:193.2.4.5::/48 or 2002:c102:405::/48.
Microsoft provided 6to4 relays on the Internet using the IPv4 anycast address 192.88.99.1 for anyone using 6to4 to have access to the IPv6 Internet from IPv4.
The biggest problem with 6to4 for Internet Service Provider is the lack of flexibility due to the fixed 2002::/16 prefix. 6to4 also lack of any basic security feature (RFC3964). Because the prefix was not controlled by the Service Provider it was impossible to control the return traffic which would use the closest 6to4 Relay.
To make it suitable for the Service Providers, it was needed to replace the fixed prefix 2002::/16 by a prefix which could be customized by the service providers.
In 2007, Rémi Desprès had this simple idea and went to Free to talk about his idea:
Nov. 7th, 2007: Rémi Desprès knocks on our door
Nov. 9th, 2007: Got IPv6 prefix from RIPE
Nov 10th, 2007: First prototype of 6RD GW and CPE support
Dec. 11th, 2007: Opt-in made available to all of our customers
March 2008: First IPv6-only service : “Telesite

6RD Like 6to4:
Stateless IPv6 in IPv4 encapsulation

6RD Unlike 6to4:
IPv6 prefix rather than fixed 6to4 prefix
Packets from IPv6 Internet entering 6rd GW are only for 6rd customer sites
Provides control over routing return path.
Provides native IPv6 access to home user


For more details about 6RD, Please check out the presentation:
http://www.slideshare.net/fredbovy/6rd

And the Video:
http://youtu.be/PrnFWgqlhj0

Cisco IPv6 for SP Labs: 6PE, 6VPE, QoS with 6VPE, InterAS, CsC, 6RD, Security...

Cisco IPv6 for SP Labs: 6PE, 6VPE, QoS with 6VPE, InterAS, CsC, 6RD, Security...

A+P An Interesting Alternative To Large Scale NAT (LSN) or Carrier Grade NAT (CGN)

A+P An Interesting Alternative To Large Scale NAT (LSN) or Carrier Grade NAT (CGN)

A+P: An IPv4 address sharing solution not using NAT

  1. Introduction

As IPv4 addresses are pretty much consumed and the lazy ones have not even yet started their transition process to IPv6 we need to make sure that we have all the tools available to make the most with the remaining addresses without breaking the Internet even more than we did with NAT.

Carrier Grade NAT (CGN) or Large Scale NAT (LSN) proposes to run NAT at the Service Provider rather than or in addition to the Customer Premises Equipment (CPE).

There are many solutions based on LSN such as NAT444, NAT464 or DS-Lite. These solutions have many issues including severe scalability issues and sometimes also some network design issues (NAT444). LSN is a single point of failure as it must keep a big amount of states and should any LSN device reboot, many users will see their sessions restarted and will experiment some problems with their applications. It is a severe concern when more and more people use the Internet for Real Time applications like VoIP, WebEx or Video.

With LSN, it becomes also impossible to track a user with its IP address; a user cannot configure some static NAT translations to run some inside servers and if an Application Layer Gateway (ALG) must be installed to support a new application, the Service Provider must install it.

2. An alternative to LSN/CGN: A+P

A+P (Experimental rfc6346) gives another solution for sharing IPv4 addresses among users without LSN and all its known issues.

This solution uses some bits of the source port to share an IPv4 address among multiple users.

A+P has many benefits:

• It does not have the scalability issue of LSN.
• It does not break the end-to-end model of the Internet in most cases.
• It does not require keeping much states in the SP network.
• Users can be tracked with their IP address and source port.
• It does not bias the users from migrating to IPv6 as NAT444 does.

 

 

A+P Features

For successful implementation, A+P requires the following features:

Tunneling:

A+P can run on all hosts and routers in the network. If this is not the case, some routers called Port Range Routers will be responsible to establish tunnels through existing devices. These tunnels can be Ipv6, IPv4 or Layer 2.

Translation:

If hosts are not upgraded to support A+P, they will still think that they have all the source ports available for a given address and the CPE will have to do some kind of translation to make sure that only the ports allocated to a site will be used.

Signaling:

A+P requires some signaling to discover which ports are available for an address.

3. A+P Limitations

A+P also comes with some limitations but it does not share the scalability issue and should require keeping fewer states not to be such a hot single point of failure than LSN.
The A+P limitations are:

• ICMP will need a particular processing, as it does not have any port available.
• Fragmentation will need reassembly as A+P needs the port information in each packet.
• An application that may require a particular port may not have it available, as only a port range will be allocated to each CPE.

4. Conclusion

A+P is an alternate choice to LSN transition tools but not an alternate choice to IPv6 that is still the only solution for the Internet.

It does not have most of the LSN/CGN issues.

On the other hand, it will not be of any help for enterprises that will require IP addresses without any port restrictions.

Most of the signaling protocols are still “Work In Progress” but the developers are confident to deliver it in time. So it is still mostly in development but could be ready in a bout 5 months from now.

For some early testing, there is an Open Source implementation available from Orange FT Labs:
http://opensourceaplusp.weebly.com/


Also find this blog:
http://www.fastlaneus.com/blog/2011/10/17/ap-an-interesting-alternative-to-large-scale-nat-lsn-or-carrier-grade-nat-cgn/

Where are we with the Transition to IPv6: LSN, CGN, NAT444, 6RD, 4RD, DS-Lite, A+P

Table of Contents

1    Introduction: Transition Technologies Needed
2    Transition to IPv6 Status
3    Dual-Stack
4    Network Address Translation
4.1    Network Address Translation from NAT to NPT6
4.1.1    IPv4 to IPv4 Translation: NAT or NAT44
4.1.2    IPv6 to IPv6 Translation: NAT66 to NPT6
4.1.3    Network Address Translation from NAT-PT to NAT464
4.1.4    IPv4 to IPv4 Translation: Double NAT or NAT444
5    Tunneling
5.1    IPv4 in IPv6 Tunneling
5.1.1    IPv4 in IPv6 Tunneling: 4rd
5.1.2    IPv4 in IPv6 Tunneling + LSN: DS-Lite
5.1.3    IPv4 Tunneling and Address Sharing: A+P (Experimental rfc6346)
5.2    IPv6 in IPv4 Tunneling
5.2.1    IPv6 in IPv4 Static Tunnels
5.2.2    IPv6 in IPv4 Automatic Tunnels
5.3    IPv6 in IPv4 MPLS Tunneling
6    Carrier Grade IPv6 (CGv6)
6.1    Network Address Translation
6.2    Tunneling

1 Introduction: Transition Technologies Needed

As connected devices become more pervasive, available IPv4 addresses decline and soon will be completely depleted. IPv6 has been around for more than 10 years and supported by most operating systems and network vendors. Despite this, most companies have not transitioned to this next generation Internet protocol. As a consequence, more time is needed to allow a smooth transition to IPv6. Because of this, you may need to support mixed IPv4 and IPv6 networks.

Maximum performance, security, and other benefits  will be achieved once the transition to IPv6 is complete. Meanwhile, features, performance, and security will have to be compromised in order to support IPv4 nodes and applications.

The methods for transition are based on the following:

• Dual-stack
• Network Address Translation (NAT44, NAT64, DNS64, NAT444, NAT464)
• Tunneling (6rd, 4rd, A+P, 6PE, 6VPE)
• Tunneling and Translation (DS-Lite, 4rd, A+P)
• Tunneling and Address Sharing (A+P)

This paper discusses each.

2 Transition to IPv6 Status

A site reports 6281 referenced IPv6 Web sites on the Internet:
http://ipv6.sixy.ch/

CISCO started CCO on IPv6:
http://www.ipv6.cisco.com/

JUNIPER has started an IPv6 Web site:
http://ipv6.juniper.net

We have already almost 2000 IPv6 Applications:
http://www.ipv6-to-standard.org/http://www.deepspace6.net/docs/ipv6_status_page_apps.html

Here is a presentation that shows how to upgrade applications to support IPv6:
http://www.6diss.org/workshops/carib/applications.pdf

Most ISPs have started to provide an IPv6 service to their customers.

The Mobile Phone networks are migrating to IPv6, this is a requirement for 4G/LTE:
http://www.eurecom.fr/util/publidownload.en.htm?id=2085
http://www.netlab.tkk.fi/opetus/s384030/k05/IPv6In3GAnd4G.pdf

Cable Networks with DOCSIS 3.0 now support IPv6.

All the workstations now come with IPv6 as the preferred protocol: Windows, Linux, Mac OS X. Even your iPhone WiFi is running IPv6.

There are some solutions to make the most of the last available IPv4 addresses but these solutions only apply to the consumers market and not to the enterprises. The consumers will only have a need for IPv4 addresses as long as some content will not be available from IPv6.

The Enterprises who will need public IP addresses will not be able to get an IPv4 address in most countries and will have no choice than starting the new offices with IPv6.  We are going to see what are the options for these enterprises to keep the communication between the existing IPv4 sites and the new one running IPv6 but the only solution for the long term is the full migration to IPv6.

3 Dual-Stack

Dual-stack is the preferred transition method. All workstation and server operating systems (Windows, MAC, Linux) come configured as dual-stack with IPv6 as default. When a host needs to transmit a packet, it sends a DNS Request to get an address. If the DNS reply includes both IPv6 and IPv4 addresses, it will prefer the IPv6. The only drawback of this method is the duplicated effort to maintain IPv4 and IPv6 concurrently. Also, you must apply the same level of security to both protocols or you may risk that IPv4 will be used to discover the nodes and IPv6 will be used to breach security if the IPv6 security is not as strong as IPv4 security.

But to run dual stack, we also need IPv4 addresses.

We are going to see that some new solutions based on NAT running at the Service Provider (Carrier Grade Nat or Large Scale Nat) or a solution for Address Sharing using the IPv4 source port (A+P) permit to make the most of the remaining IPv4 addresses. Problem is that these solutions are only good for the consumers market; the enterprises will have no choice than using IPv6 addresses for the new deployments.

4  Network Address Translation

When the Internet community became concerned about IPv4 address depletion, they created workarounds. These workarounds included classless interdomain routing (CIDR) or variable-length subnet masking (VLSM) to save addresses, Dynamic Host Configuration Protocol (DHCP) for better address management, and Network Address Translation (NAT).

4.1      Network Address Translation from NAT to NPT6

4.1.1      IPv4 to IPv4 Translation: NAT or NAT44

Introduced in the mid-90s to support private addressing, NAT and NAT44 extended the life of IPv4 by making people think that address depletion would no longer be an issue. However, NAT also introduced some side effects—both good and bad. RFC2993 discusses the architectural implications, advantages, and problems of NAT.

On one hand, NAT broke the end-to-end IP model. Applications that must be supported, like DNS or FTP, require NAT software updates (application layer gateway [ALG]). For more details about ALG, see RFC2663: NAT Terminology and Considerations.

When an inside host must be reachable from an outside public space, it consumes a public address and a static translation must be configured. Some users see this as a security feature. IPv4 firewalls usually do NAT, but a NAT router is not a firewall!

Stateful NAT is a bottleneck, a single point of failure, and can be the target of denial of service (DoS) attacks. NAT also permits undetected Man-In-The-Middle exploits, which could only prevented using end to end security.

On the other hand, with NAT and private addresses, users are not constrained by public addresses (address independency).

NAT also permits obscuring the end user network. Hiding topology and hosts makes some people think that NAT is an important security feature. For these reasons, some architects will not consider a network design without NAT!

RFC6092 provides recommendations for implementing security in an IPv6 network. This document also differentiates between actual security and the features of NAT gateways.

4.1.2      IPv6 to IPv6 Translation: NAT66 to NPT6

With the introduction of IPv6 and its 128-bit addresses, NAT was no longer needed to provide a unique address to Internet users and the end-to-end IP model was restored. Larger address space was a main driver for IPv6. The introduction of NAT66 into IPv6 was a frustration for IPv6 proponents.

In addition to its well-known problems, NAT66 broke the security implemented by IPSec by changing the IPv6 header.  But proponents of NAT did not like that NAT benefits were missing from IPv6 and also argued that NAT could solve the multihoming issue. After much discussion and an RFC to document everything, the IETF rejected the proposed NAT66 drafts.

RFC5902 discusses the pros and cons of NAT66. It tries to justify the request for NAT66:
« 2.  What is the problem?
The discussions on the desire for IPv6 NAT can be summarized as follows. Network address translation is viewed as a solution to achieve a number of desired properties for individual networks: avoiding renumbering, facilitating multihoming, making configurations homogenous, hiding internal network details, and providing simple security. »

RFC4864 explains IPv6 solutions to the NAT66 claimed benefits without requiring any address translation. NAT supporters were not deterred.  They responded by developing a simplified stateless NAT66 that was renamed Network Prefix Translation or NPT6, which was approved in the Experimental RFC6296. Experimental means that it is not supposed to become an Internet standard.

4.1.3      Network Address Translation from NAT-PT to NAT464

4.1.3.1     NAT-PT (RFC2766)

For transitioning to IPv6, Network Address Translator-Protocol Translator (NAT-PT) was the first protocol translation method implemented by Cisco IOS.
NAT-PT equates to NAT64 + NAT46 + ALG.
NAT64 is the NAT translation initiated by the IPv6 side, and NAT46 was initiated by the IPv4 side. NAT-PT was the answer for all of these cases, but it consumed too many resources, and with the IOS running NAT-PT, process switching demonstrated very low performance.
Use of NAT-PT is now deprecated (RFC4966).

4.1.3.2     NAT64/DNS64

4.1.3.2.1    What is the problem we want to solve?

Workstations run dual-stack by default. Equipment using Windows, MAC OS, and Linux operating systems are set up with dual stack by default. It is not difficult to upgrade a workstation if it runs an old operating system without dual stack. From the initialization side, IPv6 support is not the problem.
On the other hand it may be more difficult to upgrade an application, which was written specifically for IPv4. While people are working on the application upgrade to IPv6, what could help IPv6 clients to access the old IPv4 application ? Answer: NAT64 and DNS64.

4.1.3.2.2    DNS64 (RFC6147)

NAT64 relies on DNS64 to manage the DNS request and send a reply to the source with an IPv6 prefix built from the IPv4 address received from the target node. DNS64 first sends a request for a AAAA prefix. If it receives an error, it then tries to ask an A prefix. Then if it receives an answer, DNS64 converts it to a AAAA IPv6 prefix.
This IPv6 address is built using a NAT64 well-known prefix (64:FF9B::/96) followed by the IPv4 address coded as an IPv6 address. The A record with 193.45.5.1 address will be converted to the AAAA record with 64:FF9B::193.45.5.1 or 64:FF9B::C12D:501 address.

4.1.3.2.3    Stateless or Stateful NAT64

The packet from the source is routed to the NAT64 box using the normal IPv6 routing. The NAT64 box translates the IPv6 packet to an IPv4 packet and sends it to the target. It also performs the opposite when the answer comes back from the IPv4 host.
NAT64 can be stateless (see RFC6052) or stateful (see RFC6145, RFC6146 and RFC6052). Stateless means that an IPv4 address is needed for each translated IPv6 address. Stateful is required if multiple IPv6 addresses must map to the same IPv4 address.

4.1.4      IPv4 to IPv4 Translation: Double NAT or NAT444

NAT at the CPE has already permitted IPv4 to last for 20 more years, and now the ISPs are starting to use NAT one more time at the next level with NAT444. NAT444 refers to double NAT, where NAT44 is performed a first time by the CPE at the customer’s site and then a second time by the service provider. Carrier-grade NAT (CGN) and large-scale NAT (LSN) refer to NAT running at the service provider instead of the CPE.

Figure 1. NAT 444

A device in a customer network might send a packet to an Internet destination with a source address of 10.1.1.1. The CPE NAT translates the source address to, for example, 172.16.1.1 with accompanying port mapping. At the LSN, the source address is translated to the public IPv4 address; say 201.15.83.1 again with port mapping, and the packet is routed to the destination. Responding packets to 201.15.83.1 are routed to the service provider’s aggregate IPv4 address, then to the appropriate LSN, which translates the destination address back to 172.16.0.1 and forwards the packet to the corresponding CPE NAT, which translates the destination address to 10.1.1.1.

This looks simple, but this design is not without many issues.

A major issue is scalability. Behind the CPE, the customer may be running many devices. Each device may generate many data streams. There is not yet enough production experience to know the upper boundaries of how many customer networks a single LSN can manage, either in terms of performance or in terms of mapping steams to a single public IPv4 address.  It will be very difficult to manage these LSN and provide enough resource where needed in term of CPU or memory because nobody could predict how many real users will sit behind an address. These devices will require a very close monitoring for capacity planning to upgrade the devices before the performances drop or before there will be no more resource for new translation isolating some parts of the network.

And this LSN is a single point of failure. If the device restarts and looses all the states, many users sessions will have to get restarted.

Also with NAT444 it is no longer possible to track a user with its address. If an application needs an ALG, the SP must install the ALG. It is no longer possible for the user who wants to run a server to configure some static translation to allow it.

This will not be a solution for enterprises, which will need public addresses, but only for the consumers with some service degradation anyway. And why the consumers may need IPv4 addresses? Answer: Only to access some IPv4 content because all the platforms now run IPv6 by default. When enough servers will have migrated to IPv6 there will be no more point for consumers to get an IPv4 address.

But let us see other issues with this design:

A severe risk is the possibility of address overlaps between the customer’s network and the private addresses used by the service provider. For example, if the provider uses addresses out of the 172.16.0.0/12 block between the LSN and the CPE NAT, and the customer addresses his network out of the same block, uniqueness between the two zones is lost and packets might be misrouted. Insuring that customers use non-conflicting address ranges can be an administrative headache for the provider.

               

Figure 2. Firewall Blocks Packets with Private Source Address

Yet another issue occurs when a customer wants to send packets to another customer behind the same LSN. Filtering policies in firewalls, router ACLs, and even servers often block packets from outside the network that have private source addresses. To circumvent this problem, packets must pass through the LSN so that their source addresses can be translated to a public address and then switched back through the LSN to the destination. LSN resources are consumed even though the packets are not going to a destination beyond the LSN.

A proposed solution for some of these problems is to reserve a block of the remaining public IPv4 space as an “ISP shared address” space. Because the address block would be reserved for use in NAT444 architectures, the same addresses can be used behind different LSNs the same way RFC1918 addresses are used for private networks. Because the address would not be RFC1918 addresses, they would not conflict with the private addresses in any customer network. Also because they are not RFC1918 addresses, filtering policies will not block them. Packet flows between customers behind the same LSN will not have to pass through the LSN.

Another solution for the same problems is to use IPv6 on the CPE NAT to LSN link; this is NAT464. It is a good first step in providing IPv6 between the customer and the service provider.

4.1.4.1     NAT464

A problem with this design is that now the CPE must perform NAT46 address translation instead of NAT44. This design will require upgrading all the CPEs, which is an expensive solution.

 

Figure 3. NAT464

5 Tunneling

There are a few choices for encapsulating IPv4 in IPv6, IPv6 in IPv4, or IPv6 in MPLS IPv4.

5.1      IPv4 in IPv6 Tunneling

When a SP has migrated to IPv6, it may still have to support any kind of IPv4 sites including enterprises or consumers.  We have many options to support IPv4 sites.
For the consumers market, the tunneling may be followed by LSN at the SP. There is also an option to share an IPv4 address among many users without using NAT by using some bits of the source port.

5.1.1      IPv4 in IPv6 Tunneling: 4rd

4rd allows some IPv4 sites to have access to the SP over IPv6 connection through tunnels.
With 4rd you have the option of not running NAT for an enterprise IPv4 site that uses a public address or you can run NAT at the CPE, as it is the case with most IPv4 home users.

5.1.2      IPv4 in IPv6 Tunneling + LSN: DS-Lite

To support the RFC1918 IPv4 home users, we also have Dual Stack Lite (DS-Lite) which provides IPv4 in IPv6 tunneling and LSN (AFTR) to make the most of the available public IPv4 addresses.
DS-Lite uses the IPv6 source address of the tunnel with the IPv4 source address and the source port number to identify each tunnel source endpoint. Without this, there would be no way to differentiate two overlapping customers using the same RFC1918 private address.

DS-Lite is a method to deal with IPv4 address depletion. It also gives the customer and the service provider a chance to start their migration to IPv6. When the customer is ready to switch to IPv6, the service provider can provide the service.

Running NAT at the SP allows more address sharing but it is also going to be a single point of failure as it is for any LSN based solution. If a router, which keeps all the LSN states, has to reboot for some reasons, all the sessions of all the customers behind the LSN box will be restarted. And again this solution cannot help an enterprise that will need public addresses.
FT ORANGE uses DS-Lite in their transition to IPv6 process.


Figure 4. DS-Lite IPv4 in IPv6 Tunnel




Figure 5. DS-Lite = IPv4 in IPv6 Tunnel + LSN

Figure 7. IPv6 Routed Directly. IPv4 Routed to LSN.

5.1.3      IPv4 Tunneling and Address Sharing: A+P (Experimental rfc6346)

A+P proposes to use some bits of the IPv4 source ports to multiplex an IPv4 address with many users without using NAT. It connects IPv4 sites using any tunnels: IPv6, IPv4 or Layer 2.  A+P can be running from the hosts or from the CPEs. If the hosts are not upgraded the CPEs will do some translation for the hosts which still think they have all the source ports available where it is no longer the case as each site may have a range of allowed source ports.

A+P also needs some signaling to request the available source port for a given user.

A+P is an interesting option since it does not have all the issues of LSN/CGN while still providing Address Sharing.

A+P has many benefits over the LSN based solutions like DS-Lite as it does not have the scalability issue of LSN, does not require any ALG. It does not break the end to end model of the Internet and it is still possible to track a user from its IPv4 source address and its source port.

A+P also comes with some restrictions compared to the current IPv4 model. For instance, all the ports are no longer available for any application that may require a specific port. ICMP also needs some particular processing has it does not have a port. It is also required to reassemble the fragments, as we need the port information in each packet.

Again A+P is just a tool to help the transition and buy some time for the consumers. It is not a long-term solution and will not help the enterprises which will requires public addresses without any port restrictions.

A+P is still in development process, most of the signaling protocols have the status “Work In Progress” and it may seem a bit strange to keep investing in IPv4, a protocol that is now End Of Life!

FT Orange supports A+P. For implementation see ORANGE Beijing Lab web page:
http://opensourceaplusp.weebly.com/index.html

5.2      IPv6 in IPv4 Tunneling

IPv6 in IPv4 was the first overlay tunnel used during the transition to IPv6. The first experimental IPv6 network, the 6BONE, was created from overlay tunnels connecting IPv6 islands across the IPv4 Internet.
IPv6 in IPv4 tunnels can be statically or automatically configured.

5.2.1      IPv6 in IPv4 Static Tunnels

For IPv6 in IPv4 static tunnels or 6in4 static, you must configure the tunnel source and destination IPv4 addresses. This is the least unsecure option as you can control the source and destination of the tunnel. If possible, use IPSec to secure these tunnels.

5.2.2      IPv6 in IPv4 Automatic Tunnels

With automatic tunnels, you don’t need to configure the IPv4 destination of the tunnel. Automatic tunnels also provide IPv6 addressing. Teredo and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) automatic tunnels are not intended for service providers and are not discussed here.

5.2.2.1     6to4: The Origin (RFC3056)

The first popular automatic tunnels were 6to4. These tunnels solved two problems: IPv6 addressing and automatic destination tunnel configuration. They provided the reserved IPv6 prefix—2002::/16. Following this prefix was the 6to4 gateway public IPv4 address.  This way, the destination IPv4 address of the tunnel was coded in the destination IPv6 address. For instance, if a 6to4 gateway public IPv4 address was 193.2.4.5, the IPv6 site that would be reachable from this 6to4 gateway would use the prefix 2002:193.2.4.5::/48 or 2002:c102:405::/48.

Microsoft provided 6to4 relays on the Internet using the IPv4 anycast address 192.88.99.1 for anyone using 6to4 to have access to the IPv6 Internet from IPv4.

For ISPs, the biggest problem with 6to4 is the lack of flexibility due to the fixed 2002::/16 prefix. 6to4 also lacks basic security features (RFC3964).
6to4 is now deprecated.

5.2.2.2     6rd: The Next Generation (RFC5969)

Free Telecom, a French ISP, customized the code of a 6to4 platform to accept any ISP prefix instead of 2002::/16 and provided instant IPv6 access to their customers. They provided the relays to access the IPv6 Internet and called this 6rd for IPv6 Rapid Deployment as the deployment only took a few weeks.
6rd became the de facto standard for service providers with an IPv4 backbone to provide an IPv6 service to their customers.

6rd was implemented in Cisco IOS Software Release 15.1(3)T and is documented in RFC5969.

Figure 6. 6rd, 6to4 with a Customized Prefix

5.3      IPv6 in IPv4 MPLS Tunneling

For service providers with an IPv4 MPLS backbone, the transition methods are IPv6 Provider Edge Router (6PE) and IPv6 VPN Provider Edge Router (6VPE).

6PE is for the transport of IPv6 on top of MPLS IPv4. 6VPE adds the support of IPv6 in MPLS-VPN. The VRF can be dual-stack. Both are stable, efficient, and scalable methods to provide IPv6 services over an IPv4 MPLS backbone.

6PE and 6VPE were used by most service providers as a first step in the process of transition to IPv6.
While 6PE and 6VPE are important transition methods for service providers, they are not discussed in this white paper.

6  Carrier Grade IPv6 (CGv6)

CGv6 is the Cisco solution to support the service providers during the transition to IPv6. CGv6 runs on a dedicated carrier-grade service engine on the CRS-1. CGv6 is available on the Cisco ASR 9000 with IOS-XR Software and the Cisco ASR 1000 with Cisco IOS-XE Software.

6.1      Network Address Translation

CGv6 supports double NAT444 where NAT44 is performed at the CPE and again at the service provider. CGv6 also supports Address Family Translation or IVI, which represents the Roman numerals for 4 (IV) and 6 (VI); in other words, NAT46 and NAT64.

6.2      Tunneling.

CGv6 supports 6rd and will support DS-Lite in the future.
For more information about the Cisco CGv6 solution, visit http://www.cisco.com/go/cgv6 and http://www.ccmi.com/IPv6/Cisco_CGv6.pdf







Fred BOVY, ccie #3013
fred@fredbovy.com