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?