IPv6, 6RD, and a DD-WRT router with a 6to4 tunnel

I have repeated the 6to4/6RD interop experiment, this time using a DD-WRT router instead of a Windows 7 host. (The specific router was a Linksys WRT160n running DD-WRT v24-sp2 (01/02/10) std-nokaid-small, build 13575.) The outcome was positive for the DD-WRT router: it performed as theory would suggest: only minor configuration changes were necessary to turn the DD-WRT router into a working 6RD customer equipment host.

 
 

With two different IPv6 6to4 tunnel implementations we have had apparent success configuring the routers with only minor changes to enable deployment in a 6RD domain. It’s nice to actually see the expected behavior.

Further Ruminations on Comcast’s 6rd: a small experiment

I previously discussed the possibility of participating in a 6RD-based IPv6 deployment using only a router with a generic 6to4 implementation.

 
 

Since 6RD is based on 6to4, with a few enhancements for ISP configuration and management, there was some speculation that it would be possible to use a router with only a 6to4 implementation as part of a 6RD deployment. The details of that thought experiment are available here: https://tuketu.wordpress.com/2010/04/20/ruminations-on-comcasts-ipv6-trials-6rd-at-comcast/.

 
 

I have since performed an experiment to validate this thinking. The experiment, while not definitive, suggests that the thesis may be correct: it may be possible to use a generic 6to4 router as a participant in a 6RD-based IPv6 deployment. Certain experimental limitations prevent a more definitive answer.

 
 

In the experiment, a generic Windows 7 PC is used as the customer premises router. Windows 7 includes a 6to4 tunnel implementation. Indeed, by default, a Windows 7 PC with a public IPv4 address will automatically configure a 6to4 IPv6 tunnel based on the public IPv4 address.

 
 

In the experiment test-bed the Windows 7 PC is the 6RD customer equipment host (the 6RD host). The 6RD host is connected, over an IPv4-only network of routers, to a router that represents the ISP’s 6RD relay router. The 6RD relay router is connected over an IPv6-only network, to a host we call the IPv6 destination. The object is to successfully ping from the 6RD host to the IPv6 destination.

 
 

The following figure depicts the experiment test-bed:

 
 

 
 

 
 

 
 

The information necessary to configure a 6RD host for participation in a 6RD domain deployment is contained in the DHCPv4 option_6RD extension, and consists of:

1. IPv4MaskLen The number of high-order bits that are identical
   across all CE IPv4 addresses within a given 6rd
   domain. This may be any value between 0 and 32.
   Any value greater than 32 is invalid.
   
2. 6rdPrefixLen The IPv6 Prefix length of the SP’s 6rd IPv6
   prefix in number of bits. For the purpose of
   bounds checking by DHCP option processing, the
   sum of (32 – IPv4MaskLen) + 6rdPrefixLen MUST be
   less than or equal to 128.
   
3. 6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border
   Relay(s) for a given 6rd domain.
   
4. 6rdPrefix The Service Provider’s 6rd IPv6 prefix
   represented as a 16 octet IPv6 address. The bits
   after the 6rdPrefixlen number of bits in the
   prefix SHOULD be set to zero.
   

   Using the following values for the 6RD domain, we obtain the tunnel configurations specified in the figure. 

5. 6rdPrefix: 2001:558:: (this is Comcast’s actual IPv6 prefix).
   
6. 6rdPrefixLen: 31 (Comcast is assigned a /31. The actual value used in their 6RD deployment may be larger.
   
7. IPv4MaskLen: 32
   
8. 6rdBRIPv4Address: 1.0.0.1
   

    
    

   The actual values for these parameters don’t particularly matter. However, the use of a prefix other than 6to4’s prefix of 2002::, and a prefix length different (longer) than 6to4’s prefix length of 16 is really what we want to test with the experiment. It would also be useful to test with a IPv4MaskLen less than 32, but the experiment did not test this configuration.

    
    

   In the first experiment we do the following:

9. First we configure the 6RD host according to the 6RD domain configuration.
   
   1. Configure the default gateway of the 6to4 tunnel according to the IPv4 address of the 6RD relay router (1.0.0.1).
      1. c:\> netsh interface ipv6 6to4 set relay 1.0.0.1 enabled
   2. Add an address to the 6to4 tunnel corresponding to the 6RD prefix, prefix length, and the 6RD host’s public IPv4 (1.0.1.2)
      1. c:\> netsh interface ipv4 add address interface=”6to4 Adapter” address=1001:558:200:204::100:102
         1. Note: we use the convention that the network interface portion of the IPv6 address for a tunnel is the IPv4 address.
   3. These are the only two changes necessary from the default 6to4 configuration.
10. We ping from the 6RD host to the IPv6 destination:
    
    1. c:\> ping 2001:558::3
11. By packet sniffing on the 6RD relay router, we observe the following:
    
    1. A packet leaves the 6RD host, goes over the 6to4 tunnel (over IPv4) to the 6RD pseudo relay router.
       1. This packet, when decapsulated from the tunnel, has a source address of 2001:558:200:204::100:102. The destination address is 2001:558::3. This is a correctly functioning configuration.
    2. The IPv6 destination sends back an ICMPv6 echo reply packet (normal behavior).
       1. This packet has a source address of 2001:558::3 and a destination address of 2001:558:200:204::100:102.
    3. The 6RD pseudo relay router doesn’t know how to route to 2001:558:200:204::100:102 and thus sends back to the IPv6 destination an ICMPv6 destination unreachable packet. Given the limitations of the test environment, in which we are using a 6to4 relay router to simulate the ISP’s 6RD relay router, this is expected behavior. The 6RD pseudo relay router in the experiment is just a configured 6to4 relay router, and as such it doesn’t properly deal with a packet addressed to 2001:558:200:204::100:102. It doesn’t know the proper bit boundaries to extract the IPv4 address of the 6RD host. In an actual 6RD deployment, the ISP’s 6RD relay router would know the proper bit boundaries to be able to determine the IPv4 address of the 6RD host from the IPv6 destination address of the echo reply packet.

        
        

    To better simulate the complete round-trip, we ran a second experiment in which we fudge things a bit by using an different 6RD domain specification. In the second experiment, we use a 6rdPrefixLength of 16, creating a bit-boundary at the same position as a normal 6to4 configuration. We continue to use 2001-based prefix. Therefore we do 2 things:

12. We use a 6RD domain specification of
    
    1. 6RD prefix of 2001::
    2. 6RD prefix length of 16
    3. IPv4 address of 1.0.1.2
    4. IPv4 mask length of 32
13. We add a new router table entry on the 6to4/pseudo 6rd relay router. This /128 route (for the 6rd host) specifies a next hop of the 6rd host’s 6to4 tunnel endpoint, over the 6to4 relay router’s 6to4 tunnel interface. This is just an experiment hack to tell the 6to4 relay router how to deal with incoming IPv6 packets that are addressed to the 6rd host: send them over the 6rd tunnel to the 6rd host.
    

     
     

    This 6rd domain specification results in an IPv6 address of 2001:100:102::100:102 on the 6rd host.

    We add this address to the 6to4 tunnel on the 6rd host.

     
     

    We now, from the 6rd host, ping the IPv6 destination.

     
     

14. c:\> : ping 2001:558::3
    
15. By packet sniffing on the 6RD relay router, we observe the following:
    
    1. The 6to4 relay router decapsulates an IPv6 packet, source address 2001:100:102::100:102, destination address 2001:558::3 from the 6to4 tunnel. The relay router forward this on to the IPv6 destination, which sends back an ICMPv6 echo reply, addressed to 2001:100:102::100:102.
    2. The 6to4 relay router encapsulates the ICMPv6 echo reply into an IPv4 packet and forwards it to the 6RD host using a tunnel over the IPv4 network. The packet in the tunnel has a destination address of 2001:100:102::100:102 and a source address of 2001:558::3.
    3. The 6rd host’s 6to4 tunnel decapsulates the IPv6 packet and delivers it to the ping process, which reports the ping reply. Everything works.

     
     

    Conclusion

    The experiments demonstrate that there is a good chance that a generic 6to4 IPv6 implementation may be able to participate in a 6RD-based IPv6 deployment.

     
     

    Possibilities for further research:

16. Replace the 6RD Pseudo relay router with an actual 6RD relay router implementation. This should provide a more-or-less definitive answer and allow testing with an IPv4MaskLen less than 32.
    
17. Experiment with other 6to4 router implementations, to determine if they function in a like manner. In particular, a consumer router device, say a DD-WRT equipped router, would be a good choice.