6RD Tunnel is a transition solution for service providers, enabling them to offer IPv6 connectivity over an IPv4 infrastructure while leveraging the ISP’s own IPv6 prefix. This approach facilitates IPv6 deployment without requiring immediate upgrades to the existing network infrastructure.
In this section, we will demonstrate a Cisco-based configuration example to showcase how 6RD can be implemented.
Table of Contents
IPv6 6RD Address Mapping
In 6RD, as with all multipoint VPN solutions, there must be a mapping between IPv4 and IPv6 addresses.
When traffic is sent to a destination IPv6 address, the corresponding IPv4 address is extracted from the IPv6 destination address. A dynamic point-to-point tunnel is then created using the extracted IPv4 destination address. This tunnel enables end-to-end IPv6 connectivity over the existing IPv4 infrastructure.
One of the key advantages of 6RD is its use of the ISP’s real IPv6 prefix for mapping. This provides flexibility and alignment with the ISP’s IPv6 addressing plan. In its simplest form, the IPv6 prefix could be 32 bits, with the customer’s CPE 32-bit IPv4 address appended to create customer /64 IPv6 prefix.
| ISP's IPv6 Prefix (32 bits) | + | Customer CPE IPv4 Address (32 bits) | --> | Customer IPv6 Prefix |
|---|---|---|---|---|
| 2001:db8::/32 | + | 192.0.2.1 | --> | 2001:db8:c000:0201::/64 |
However, within the ISP’s entire infrastructure, it is common to have a fixed IPv4 prefix or suffix.These fixed components can be omitted from the mapping process.
For example, if the ISP’s IPv4 prefix falls within a specific IPv4 range (e.g., 10.1.0.0/16) or if CPE addresses are consistently assigned a fixed suffix (e.g., .1, such as 10.1.x.1), these common components can be omitted from the mapping. In such cases, only the variable part of the IPv4 address (e.g., the third octet) would be used in the address mapping.
By doing so, the IPv6 address can still be correctly mapped to the IPv4 address without encoding the fixed prefix or suffix.
In this example taken from cisco website, assuming the ISP prefix is 2001:B000::/32, different customers will be addressed based on the third octet of their IPv4 address. The IPv6 prefixes would range from 2001:B000:0100::/40, 2001:B000:0200::/40, up to 2001:B000:FF00::/40.
IPv6 6RD demonstration
To better understand how 6RD tunneling works, I have prepared a configuration example. In this scenario, an ISP with an existing IPv4 infrastructure wants to provide IPv6 access to its customers without upgrading the entire infrastructure.
To achieve this, the ISP needs IPv6 internet connectivity and a 6RD relay that connects both the IPv6 internet and the IPv4 infrastructure. Customers who want to access the IPv6 internet must ensure that their CPE (Customer Premises Equipment) supports 6RD.
A multipoint 6RD tunnel will be set up on the 6RD relay, which will terminate all CPE IPv6-over-IPv4 tunnels and forward IPv6 traffic to the internet. Reverse IPv6 traffic will also be encapsulated in the 6RD tunnel and redirected to the corresponding customer’s CPE.
To correctly handle traffic between the CPE and the 6RD relay, an address mapping must be established for both the IPv4 and IPv6 addresses of each customer. In this example, the ISP’s IPv6 prefix is 2001:bebe::/32, and the third and fourth octets of the CPE’s IPv4 address will be mapped to the second 32 bits of the IPv6 prefix to create an /64 prefix. The first and second octets (e.g., “10.1.xx”) are common across all CPEs in the network.
For instance, a customer with a CPE address of “10.1.1.1” will be assigned the IPv6 prefix 2001:bebe:0101::/48, while a 6RD relay with the IPv4 address “10.1.2.1” will be assigned the IPv6 prefix 2001:bebe:0201::/48.
To implement 6RD, the first step is to configure a 6RD tunnel on the 6RD relay. The tunnel mode is set to “ipv6ip 6rd,” with the IPv6 address derived from the IPv4 address mapping as discussed. The 6RD prefix is configured as “2001:BEBE::/32,” and the 6RD IPv4 common prefix length is set to /16, which will not be encoded in the IPv6 address.
All IPv6 traffic with a destination within the “2001:BEBE::/32” range will be forwarded over the 6RD tunnel, while the IPv6 default route (::/0) will be forwarded to the internet.
!!! 6rd-Relay ipv6 unicast-routing ! ip cef ipv6 cef ! interface Tunnel0 no shutdown ipv6 address 2001:BEBE:201:1::1/64 tunnel source Ethernet0/0 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 16 tunnel 6rd prefix 2001:BEBE::/32 ! ip route 0.0.0.0 0.0.0.0 10.1.2.2 ! ipv6 route 2001:BEBE::/32 Tunnel0 ipv6 route ::/0 2001:1:1:1::1
Each CPE must also configure 6RD using the same method, but with the knowledge of the IPv4 address of the 6RD relay router. This is done by configuring the 6RD relay address with the command “tunnel 6rd br 10.1.2.1.”
Traffic destined for “2001:BEBE::/32” will be routed to the 6RD tunnel, while the IPv6 default route (::/0) will be routed to the 6RD relay router’s IPv6 address.
!!! CPE ipv6 unicast-routing ! ip cef ipv6 cef ! interface Tunnel0 no shutdown ipv6 address 2001:BEBE:101:1::1/64 tunnel source Ethernet0/0 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 16 tunnel 6rd prefix 2001:BEBE::/32 tunnel 6rd br 10.1.2.1 ! ip route 0.0.0.0 0.0.0.0 10.1.1.2 ! ipv6 route 2001:BEBE::/32 Tunnel0 ipv6 route ::/0 Tunnel0 2001:BEBE:201::
To check connectivity, we can ping from an IPv6 client to the IPv6 internet over the IPv4 infrastructure.
Client#ping 2001:1:1:1::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:1:1:1::1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/10 ms
Client#traceroute 2001:1:1:1::1 Type escape sequence to abort. Tracing the route to 2001:1:1:1::1 1 2001:BEBE:101::1 5 msec 5 msec 5 msec 2 2001:BEBE:201:1::1 5 msec 5 msec 5 msec 3 2001:1:1:1::1 6 msec 5 msec 5 msec