In the last two articles in the IPv6 tunneling series, we implemented the 6to4 tunneling mechanism which is a point-to-multipoint tunneling type that allows isolated IPv6 networks to communicate over an IPv4 infrastructure. We saw that 6to4 also supports communication with the native IPv6 Internet through the use of a relay router. Finally, we discussed some of the issues with 6to4 relating to the use of public relays.
CCNA Training – Resources (Intense)
In this article, we will be discussing a better alternative to 6to4 which is more like an extension of 6to4. This tunneling mechanism is known as IPv6 Rapid Deployment (6rd).
6rd is an extension to 6to4 that allows service providers to connect customer IPv6 networks with the native IPv6 Internet (and also with each other). The main differences between 6rd and 6to4 are:
6rd does not use a predefined prefix block like the 2002::/16 that 6to4 uses. Instead, the 6rd prefix is selected from the service provider’s own IPv6 prefix block. Therefore, 6rd provides near-native IPv6 connectivity and 6rd customers are not immediately distinguishable from other native IPv6 hosts by looking at their address.
Unlike 6-to-4 which uses the entire 32 bits of the IPv4 address to generate the 6-to-4 site prefix, 6rd does not have to use the entire 32 bits. Also, the position of the IPv4 address bits in the 6rd prefix is not fixed.
There are two basic components in a 6rd domain: 6rd customer edge (CE) routers and 6rd Border Relays (BR). The 6rd CE router connects the customer to the SP; the 6rd BR is similar to relay routers in 6to4 but is managed by the SP.
Operation of 6rd
To understand 6rd, we need to become familiar with at least two terms used in 6rd: 6rd prefix and 6rd delegated prefix. The 6rd prefix is the prefix chosen by the service provider for use within a 6rd domain. Remember that this prefix will be chosen from the SP’s own IPv6 prefix block. The 6rd delegated prefix is the prefix calculated by the CE and used within the customer site. It is calculated by combining the 6rd prefix with all or part of the CE’s IPv4 address (the IPv4 address between the CE and the SP).
The 6rd delegated prefix is worthy of more discussion. According to the RFC on 6rd, the format of a 6rd address is as shown below:
Before we continue, I want you to note something: Since the 6rd prefix is globally unique to the SP (therefore it is routable on the Internet), it means the IPv4 address portion does not have to be a public IPv4 address which was a requirement for 6to4. Therefore, for 6rd, the IPv4 address can be private or public.
As you can see from the format above, the 6rd prefix and the IPv4 address portion used to form the 6rd delegated prefix are variable. Let’s take an example to help clarify things. In a 6rd domain, there are two CE routers and one BR. CE1 has an IP address of 10.1.1.2; CE2 has an IP address of 10.2.2.2; and the BR has an IP address of 10.3.3.2. Now assume the SP has selected 2001:db8::/32 as the 6rd prefix. From the format above; therefore, it means n=32.
Now, we can see that all the devices in the 6rd domain begin with “10” (i.e. 8 bits); that means we can ignore that portion of the IP address and not use it to form the 6rd delegated prefix. Therefore, o=24 (i.e. an IPv4 address is 32 bits minus the 8 bits we are ignoring). It means our 6rd delegated prefix will be 32+24 bits = 56.
Note: The number of high-order bits that are identical across the 6rd domain (in our case the 8 bits) is called the IPv4 mask length.
So, the 6rd delegated prefix for CE1 will be 2001:db8:0101:0200::/56; the 6rd delegated prefix for CE2 will be 2001:db8:0202:0200::/56; and the 6rd delegated prefix for the BR will be 2001:db8:0303:0200::/56.
Hint: You have to convert the IPv4 address to hexadecimal and then combine it to the 6rd prefix. Keep in mind that each IPv4 decimal is made up of 8 bits not 4! For example, on CE1, the remaining part of the IP address is “1.1.2” which is “00000001 00000001 00000010” in binary. Converting to hex will give us “01 01 02” which is why we have the delegated prefix as 2001:db8:0101:0200::/56. Why do we have the extra zeros at the back of the 02? Remember we can’t write it as 2001:db8:0101:02::/56 because this will be 2001:0db8:0101:0002::/56 in expanded form which is wrong.
I have taken time to explain this concept of 6rd delegated prefix because it may come in handy for you someday, maybe in an SP environment.
There are times when you will have to use the entire 32 bits of the IPv4 address. In that case, if the SP chooses a /32 6rd prefix, it means the 6rd delegated prefix will be 64 bits long. This leaves no space for subnet ID (since it is recommended that the interface ID be 64 bits long). As such, there have been recommendations to allocate a /29 IPv6 prefix block to SPs providing IPv6 services through 6rd rather than the minimum allocation size of /32. With a /29, even if the SP selects a /30 to use for the 6rd prefix and the entire IPv4 address is used, there will still be 2 bits left for subnet ID resulting in 4 subnets. I know RIPE has implemented this recommendation.
Determining tunnel destination
The question now arises: If the entire IPv4 address does not have to be used meaning there is no fixed portion containing the IPv4 address (as there was in 6to4), how will a 6rd node calculate the correct tunnel destination for a particular IPv6 traffic? There are two scenarios that can occur:
Traffic destined to another 6rd node in the 6rd domain
For example, CE1 receives IPv6 traffic from its LAN interface destined to 2001:db8:0202:0200::1. It knows that this address falls within the range of its 6rd prefix (i.e. 2001:db8::/32). So, CE1 will determine how many bits of the IPv4 address are encoded in that address. This is calculated by subtracting the IPv4 mask length from 32. The IPv4 mask length is encoded on CE1 either manually or some other method like DHCP. In our case, the IPv4 mask length is 8; therefore there are 24 bits of IPv4 address contained in this address.
Next, CE1 will determine what portion of that IPv6 destination address contains the 24 bits of IPv4 address and extract those bits. For example, CE1 knows that the 6rd prefix is a /32 prefix and that there are 24 bits of IPv4 address contained in the destination address; therefore, it knows that the “0202:02” portion contains (part of) the IPv4 address. “020202” is “2.2.2” in decimal.
Finally, CE1 retrieves the IPv4 mask length bits from its own IPv4 address (i.e. “10” in decimal and appends the extracted IPv4 bits from the IPv6 destination). Thus, CE1 calculates the tunnel destination as 10.2.2.2 which is the IPv4 address of CE2.
Traffic destined to the native IPv6 Internet
The second scenario that can occur is IPv6 traffic that is destined to the native IPv6 Internet. For example, CE1 receives a packet destined for 2001:c034:adbf::1. It determines that this destination is not in its 6rd domain; therefore, it forwards the traffic to the 6rd Border Router which then forwards it to the appropriate destination (after some security checks).
Configuration options for 6rd CE routers
Considering that 6rd was initially developed for use by residential service providers, manual configuration of 6rd parameters on 6rd CE routers (e.g. residential gateway) would not have scaled properly. Therefore, several options for configuring these parameters are discussed in section 7.1 of RFC 5969. However, of note is the use of DHCP where 6rd parameters can be specified using DHCPv4 option 212. The format for this DHCPv4 option according to the RFC is as shown below:
Let us stop here for now since we have already discussed many theoretical concepts. In the next article, we will go into the configuration of 6rd. Note that if you will be configuring 6rd on Cisco routers, you will need at least IOS version 15.1(3)T because that is when Cisco starting supporting this feature.
I hope you have found this article informative and I look forward to the next article in the series.
References and further reading
RFC 5969: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification: http://tools.ietf.org/html/rfc5969
RFC 7059: A Comparison of IPv6-over-IPv4 Tunnel Mechanisms: http://tools.ietf.org/html/rfc7059
IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-665758.html