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.
    

     
     

     
     

     
     

Comcast and 6rd: Ruminations.

Ok, a little thought experiment. 

Comcast’s IPv6 assignment is 2001:558::/31. (Meaningless juvenile comment: “Ha, those scalawags at Verizon only snagged a /32!”) This gives Comcast north of 8 billion /64’s to hand out. If Comcast decided to dedicate a full 32 bit IPv4 address in their 6rd addressing scheme, that would consume half of their address space, leaving a little north of 4 billion /64’s to use outside of their 6rd deployment. They would be dividing their IPv6 space into two categories, “6rd”, and “other”. Of course, at some point the 6rd address space would be reclaimed, but trying to think of when makes my head hurt. Comcast would, in this scenario, be limited to handing out a /64 (no subnets) to their 6rd customers.

 Free, the French ISP, had the luxury of a /26 IPv6 address space. They used 2 bits to divide their address space into 4 categories, assigned 1 category to their 6rd deployment, and managed to pass out a /60 to their 6rd customers (nice!).

 I suspect Comcast may try to aggregate their IPv4 space, thus using less than a full 32 bits of IPv4 address in the 6rd addresses. This would conserve their IPv6 space for use outside 6rd and would potentially make it possible to hand out subnet-able prefixes to their 6rd customers. However, I haven’t really thought about how feasible this aggregation would be.

Ruminations on Comcast’s IPv6 Trials (6rd at Comcast)

Comcast has announced upcoming IPv6 trials, and has provided some helpful information at their www.comcast6.net web site (which, encouraging enough, is accessible via IPv6). They are undertaking a multi-pronged approach to IPv6, but it appears that a major focus for residential IPv6 access will be via the 6rd mechanism.

 
 

The French ISP, Free, was able to roll out IPv6 access in a rapid manner using 6rd. They had the advantage of control over the customer equipment (CE), and it is my understanding that they used their ability to modify the CE firmware to facilitate their support of 6rd.

 
 

I suspect that Comcast, in the initial 6rd trials, may also rely on a custom CE to support their IPv6 trial. Note that to support 6rd a special cable modem is not required…any functioning cable modem in the Comcast environment should work , unless I’m overlooking something. Certainly 6to4 works fine without any special cable modem support, and thus, 6rd, as an extension of 6to4, should work without any special modem requirement.

 
 

A question that arises is: what special requirements are necessary at the CE to support Comcast’s 6rd trials? And is it possible to configure, possibly manually, a generic router (say, for example something as generic as a computer running windows) to operate within Comcast’s 6rd environment? We don’t know the exact details of Comcast’s 6rd environment, so what follows is speculative.

 
 

For 6rd support, each CE must be configured with the following configuration elements. (Presumably this configuration information will be provisioned by the “option_6rd” extension to DHCPv4, but that’s just a guess.):

1. 6rdPrefix
   1. The IPv6 prefix for a given 6rd domain.
2. 6rdPrefixLen
   1. The length of the 6rd IPv6 prefix for a given 6rd domain.
3. IPv4MaskLen
   1. The number of high-order bits that are identical (aggregateable) across all CE IPv4 addresses within a given 6rd domain.
4. 6rdBRIPv4Address
   1. The IPv4 address for the 6rd Border Relay (BR) for a given 6rd domain.

    
    

Armed with this information, a CE would configure a 6to4 (6rd) tunnel with the following characteristics:

1. The tunnel address:
   [6rdPrefix/6rdPrefixLen]:[IPv4 public address of the CE/IPv4MaskLen]:[subnet id, if any/64-(6rdPrefixLen + IPv4MaskLen)]:[32-bits of zeros]:[IPv4 public address of CE]
   Note we are assuming the interface ID of the tunnel would be [32-bits of zeros]:[full IPv4 public address of CE]. This assumption is not central to the discussion.
2. A default gateway for the tunnel (and default route in the routing table) of
   [6rdPrefx/6rdPrefixLen]:[6rd BR IPv4 public address (possibly an IPv4 anycast address)]::[6rd BR IPv4 public address]

 
 

Given this configuration, would a generic 6to4 Tunnel implementation, such as is supported in Vista, Windows 7, and DD-WRT equipped routers, among others, function in this 6rd environment? If such was the case, participation in the IPv6 trial would not require anything special other than the knowledge of how to properly configure a 6to4 Tunnel. Note that the 6rd configuration elements are all long-lived. Once manually configured, it would be rare that a change was necessary.

 
 

Two possible problems are immediately apparent:

1. 6to4 Tunneling mechanisms expect their tunnels to have an IPv6 address of the following form:
   2002: [IPv4 public address of the Tunnel host]
   1. In particular standard 6to4 tunnels expect a “2002” initial prefix and a full 32 bit IPv4 address.
   2. Will they be confused by an initial prefix other than “2002” and potentially greater than 16 bits in length?
   3. Will they be confused by an IPv4 component in their IPv6 address that is less than 32 bits?
   4. The speculative answer to these questions is, possibly not. The CE tunnel doesn’t do any special processing with it’s own IPv6 address. That is, it doesn’t have to parse its IPv6 address into its constituent parts. It is up to the 6RD BR to parse the address, which it does to tunnel IPv6 packets coming from outside the ISP and destined to the CE. As far as the CE is concerned, its IPv6 tunnel address is just a source IPv6 that it needs to place in outgoing protocol 41 encapsulated packets.
2. 6to4 tunneling mechanisms do need to parse the default gateway address.
   1. In particular, they expect a 16 bit prefix (2002), followed by a full 32-bit public IPv4 address of the BR. If the 6rdPrefixLen is different than 16 bits, then the generic 6to4 tunnel mechanism will be looking in the wrong place for the public IPv4 address of the BR.
   2. This problem probably means that a generic 6to4 tunnel implementation would not work with a standard 6rd configuration in Comcast’s 6rd environment.
   3. This problem could potentially be mitigated if the Comcast 6rd BR also advertised and responded to the 6to4 equivalent IPv6 address: [2002]:[IPv4 public address of the BR]::[IPv4 public address of the BR]. In actuality, it may be enough to just configure the CE tunnel with the standard 6to4 address ([2002]:[IPv4 public address of the BR]) of the 6rd BR.

 
 

Comments?