Testing 6to4 and 6rd IPv6 Islands with CDRouter

The world has spent a long time on the road to native IPv6. Fortunately, protocol advancements have mitigated the arduous task of deploying the next generation Internet.

Essentially the software counterpart to the last-mile problem, deploying IPv6 to the CPE is “the last 90%” of the work. The core Service Provider networks have always been easier, and thus earlier, to receive both hardware and software upgrades.

One idea that has gained momentum is to use the IPv4 Internet as a point-to-point network connecting IPv6 “islands” through stateless, automatic tunnels. Two very related protocols, 6to4 and the newer 6rd, provide exactly this.

What is 6to4, and how is 6rd an improvement?

RFC 3056 (6to4) and RFC 5969 (6rd) are extremely similar in design. They each allow a local IPv6 network (an “island”) to self-generate a global IPv6 prefix from the IPv4 WAN address, and to then either directly send IPv6 packets to neighboring 6to4/6rd nodes, or to the IPv6 Internet using the help of a dual-stack relay server. The IPv6 packets are always tunneled inside an IPv4 encapsulation packet.

6to4

6to4 was invented first. The IANA allocated the 2002::/16 subnet for automatic 6to4 addressing. Any address with this 16 bit prefix is 6to4. Nodes (routers and standalone hosts) with public IPv4 addresses can use 6to4 to algorithmically assign themselves a 48 bit 6to4 prefix: The 2002::/16 prefix plus the 32 bits of the IPv4 WAN address. Since the default IPv6 subnet size is /64 (which IPv6 Autoconfiguration requires), 16 bits are left to the device for arbitrary subnets. Often these bits are set to 0 or 1, but any value through FFFF is valid.

If a node is acting as a router, the router can configure itself to forward packets from the LAN, and to provide the 6to4 prefix to the LAN via Router Advertisements for Autoconfiguration. Any IPv6 capable LAN client can then forward packets to the IPv6 Internet.

There are two general paths for a 6to4 IPv6 packet. If the destination address is another 6to4 address, i.e. a 2002::/16 address, the 6to4 node can simply use the inverse operation on the IPv6 destination address to determine the IPv4 destination. In this case, the IPv6 packet is encapsulated in an IPv4 packet marked with the 0x29 type payload. When the destination 6to4 node receives the packet, it strips the IPv4 headers off and processes the IPv6 packet normally.

In the more likely case that the destination is not a 6to4 node, but connected to the native IPv6 Internet, a special relay server must be used which has access to both IPv4 and IPv6. The relay server is a dual-stack router, announcing routes for both 192.88.99.0/24 and 2002::/16. Since these addresses are special anycast addresses, any random 6to4 relay, whichever is ‘closest’, will receive the packet, based on BGP routing algorithms. The 6to4 node sourcing the IPv6 packet encapsulates it as before, but with 192.88.99.1 set as the IPv4 destination. Similarly, packets originating from the native IPv6 Internet are randomly sent to the 2002::/16 interface of a relay server, in which the packets are encapsulated using the address of the embedded IPv4 address.

The 6to4 Operational Domain is outside the control of a Service Provider

The benefits of using anycast addresses on the 6to4 relay servers is also its drawback. There is no manner for a Service Provider to ensure that an incoming packet will pass through a properly configured 6to4 relay server. The operational domain of 6to4 is beyond the domain of the Service Provider, and so 6to4 takes on a “best-effort” quality of service. A 6to4 relay server must accept any 6to4 packet. Unfortunately, it could be misconfigured; perhaps it is partially connected to the Internet and cannot reach some IPv4 hosts. Or perhaps a prefix longer than 2002::/16 might be configured upstream – any packets that were not part of the Service Provider’s prefix could be dropped. Clearly there are motivations to move the operational domain of this mechanism to be completely within that of a Service Provider’s.

6rd

6rd (for “rapid deployment”) is an extension of 6to4 that addresses this issue. Instead of the 6to4 2002::/16 network, a Service Provider is provisioned with its own unique prefix. The Service Provider can then route packets from the Internet into its own relay server. The operational domain of 6rd is inside the Service Provider’s control, and thus ‘production quality’ IPv6 deployment is possible.

6rd clients need to be configured with the 6rd prefix assigned to the ISP, the length of the ISP prefix, and the 6rd relay address. The prefix may be no longer than 32 bits long. The 6rd client configures itself as ISP Prefix + IPv4 WAN Address + Subnet ID::/64.

The 6rd specification allows for address compression of the IPv4 WAN address. The leading bits of the address, which are unlikely to be unique within a Service Provider, can be dropped by specifying a compression bit mask length. It is enabled in CDRouter by incrementing the ipv6rdIPv4MaskLen testvar above 0, indicating the number of leading bits to drop from the prefix.

The 6rd Operational Domain is inside the control of a Service Provider

A 6rd router can forward packets directly to other 6rd nodes within the same Service Provider, or forward the packets by default to the 6rd relay server. From the IPv6 Internet, there is no distinction between 6rd addresses and are functionally identical to native IPv6 nodes. Interoperability between 6rd and 6to4 is not affected.

Since 6to4 effectively is a subdomain of 6rd, a 6rd device can be configured using 6to4 parameters. The 6rd Service Provider prefix is simply set to 2002::/16, with the 192.88.99.1 relay server.

Using CDRouter to test 6to4 and 6rd CPEs

The configuration within CDRouter to test these protocols is very simple.

To configure a device as 6to4, set the testvar ipv6WanMode to ‘6to4’, and the testvar ipv6RelayServer must be set to ‘192.88.99.1’.

To configure a device as 6rd, set the testvar ipv6WanMode to ‘6rd’. The testvar ipv6RelayServer must be set to the IPv4 address of the 6rd relay server. The testvar ipv6rdPrefix is the Service Provider’s prefix, and testvar ipv6rdPrefixLen is the length of this prefix. The testvar ipv6rdIPv4MaskLen is set to the number of network bits to be dropped from the IPv4 WAN address.

Examples of 6to4 and 6rd Configuration in CDRouter

testvar ipv6WanMode           6to4
testvar ipv6RelayServer       192.88.99.1

6to4 is easy to visualize. Assuming the IPv4 WAN address is 92.168.200.2, the prefix expected to be announced on the LAN is 2002:5ca8:c802:0000::/64. It’s always 2002 + the IPv4 WAN address in hex, plus a user-configurable 16 bit subnet (often set to 0 or 1, but may be any value through FFFF).

testvar ipv6WanMode           6rd
testvar ipv6RelayServer       172.16.1.10
testvar ipv6rdPrefix          2009:F000
testvar ipv6rdPrefixLen       20
testvar ipv6rdIPv4MaskLen     0

Assuming the same WAN address as before, the prefix expected to be announced on the LAN is 2009:f5ca:8c80:2000::/64. Since we know the prefix length is 20 bits, the 2009:f are those 20 bits, followed by the next 32 bits 5ca:8c80:2 (again, the IPv4 WAN address in hex), and then 64-(20+32)=12 bits of subnet (000::).

#6rd draft configuration using address compression
testvar ipv6WanMode           6rd
testvar ipv6RelayServer       172.16.1.10
testvar ipv6rdPrefix          2009:F000
testvar ipv6rdPrefixLen       20
testvar ipv6rdIPv4MaskLen     8

The prefix expected to be announced on the LAN is 2009:fa8c:8020:0000::/64 after dropping the first 8 bits of the IPv4 WAN address. 2009:f is the 20 bit prefix, a8c:802 is the 24 bits that didn’t get masked out from the IPv4 WAN address, and then 0:0000 is available for subnet use.

Configuring the Expected Subnet Bits

For both 6to4 and 6rd, the remaining 64 bits of the prefix are chosen by the CPE (often user configurable) to generate the specific 64 bit prefix which will be advertised on the LAN. The length of the subnet is determined by subtracting the prefix bits used up from the 6to4 and 6rd prefixes. The 6to4 subnet must be 16 bits, but the 6rd subnet can be of arbitrary length, down to 0. If the configured subnet is shorter than the available subnet length, the leading bits are assumed to be set to zero. CDRouter can be told which bits to expect by setting the following ipv6LanSubnetId testvar, in hex:

testvar ipv6LanSubnetId f

This configuration indicates to CDRouter that the subnet should be all zeros except for the final four bits of the 64 bit prefix, which are set to ones.

If 6rd is used for the WAN and DHCPv6 is used for the LAN, there is no requirement that the subnet be strictly 64 bits, since Autoconfiguration, which requires 64 bit subnets, is not used.