Comcast 6RD configuration?

Answered Question
Feb 27th, 2011

Hi,

I have a new 881 router loaded with the latest 15.1.3T software, and I'm trying to get it connected to the Comcast 6RD IPv6 routers.  (I'm on a Comcast cable modem.)

I've been trying to follow the directions from these links:

http://docwiki.cisco.com/wiki/6rd_Configuration_Example
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel.html

I am getting a delegated prefix from Comcast, so I know I'm connecting to their BR routers.

RouterA-new#sho tun 6rd pref 69.252.80.66 tu6
Interface: Tunnel6
Destination: 69.252.80.66
6RD Prefix: 2001:55C:45FC:5042::

But, that doesn't seem to be properly following the general-prefix on the tunnel (it's missing the ::45FC:5042::):

RouterA-new#sho ipv int brie tun 6
Tunnel6                    [up/up]
    FE80::A14:DE01
    2001:55C:A14:DE01::A14:DE01

I think the problem is just some stupid wrong/missing config in my tunnel setup.  Or an ipv6 noob issue.  This is the current state of what I have so far, cobbled from the links above, and with several shotgun troubleshooting tweaks:

ipv6 general-prefix Comcast6RD 6rd Tunnel6


interface Tunnel6
description Comcast 6RD IPv6 tunnel.
no ip address
no ip redirects
ipv6 address Comcast6RD ::/64 eui-64
ipv6 enable
tunnel source Vlan1
tunnel mode ipv6ip 6rd
tunnel 6rd prefix 2001:55C::/32
tunnel 6rd br 69.252.80.66

interface Vlan1
description Inside$FW_INSIDE$
ip address 10.20.222.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security in-zone
ip tcp adjust-mss 1452
ipv6 enable

I've tried putting the ipv6 address on the Vlan1 interface, as in the docwiki link, but then I get the overlapping address error listed in the link.  But, when I try just putting the 'ipv6 enable' command on the tunnel, then I don't get any 2001:55C:: addresses assigned.

Feb 28 04:16:38.622: %IPV6_ADDRESS-3-ADDRESS_CFG: 2001:55C:A14:DE01::/64 can not be configured on Vlan1, 2001:55C:A14:DE01::/64 is overlapping with 2001:55C:A14:DE01::/128 on Tunnel6

So, does anyone have a working 6RD config for Comcast?  Or can you point out what I'm doing wrong?

Thanks.

I have this problem too.
0 votes
Correct Answer by wzhang about 3 years 1 month ago

Hi, Greg:

I think the problem is with your default v6 route - "ipv6 route ::/0 Tunnel6". You are basically telling the CE that everything is directly connected to the 6rd network, so it assumes whatever comes after the 6rd prefix is the embedded ipv4 address for the destination. Could you try to remove this line, and replace it with "ipv6 route ::/0 Tunnel6  2001:55C:45FC:5042::"? This should tell the CE to send everything else to the BR instead. Give it a try and see if that helps any.

You are correct that by not configuring "tunnel 6rd ipv4 prefix-len", it defaults to a prefix length of 0, which means the CE ipv4 addresses cannot be aggregated and therefore all 32 bits will be used. So with a 6rd prefix of 32 bits and 32 bits of ipv4, your delegated prefix is 64 bits (longest allowed by the 6rd spec), which implies you won't be able to subnet within that delegated prefix.

Hope this helps.

Thanks,

Wen

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (4 ratings)
Andrew Yourtchenko Tue, 03/01/2011 - 04:42

Can you try  removing the "ipv6 address Comcast6RD ::/64 eui-64" from the tunnel interface and putting that precise config line under "Vlan1" interface ?

In my lab that configures the inner ethernet interface with the right IPv6 address.

Phillip Remaker Tue, 03/01/2011 - 07:16

I think the magic to remove the IPv6 address from the tunnel interface, at least for now.  The 6rd code will insert the appropriate /128 into routing.  As Andrew noted, you want the /64 set up on the (v)LAN interface.

glgersc Tue, 03/01/2011 - 21:44

Hi,

OK, I've moved the 'ipv6 address Comcast6RD  ::/64 eui-64' command to the internal Vlan1 interface.  That did not  work before.  But, after bouncing the tunnel interface, it finally came  to life and I have usable ipv6 address.  RA is spreading it to my  Windows boxes on the internal lan.

However, there is still a problem.  The  6RD prefix I'm getting does not appear to be valid.  And I am unable to  get any ipv6 connectivity beyond my router.

This is the prefix I'm getting:  2001:55C:A14:DE01::/64

I  don't think the bolded :A14:DE01: local bit is correct.  That matches  my internal 10.20.222.1 address.  Based on bits I've read, that part is  supposed to match my outside DHCP address.  In my case, 24.118.231.197

So, where is the internal :A14:DE01: coming from?  Why  isn't the 6RD tunnel prefix properly reflecting my outside address?  I  really doubt the internal will route back to me properly.

I have all of the current ipv6 related config below.  Also the output of the 'show tunnel 6rd tunnel6' command.

Any thoughts?

Thx,

Greg

btw,  Yes, I read that Comcast will be closing their 6RD trial in a few  months.  But until then, based on what I've read, 6RD is better behaved  than 6to4, so I thought I would start my ipv6 experimenting with that  first.

------------------------------------

ipv6 general-prefix Comcast6RD 6rd Tunnel6
ipv6 unicast-routing
ipv6 cef

interface Tunnel6
  description Comcast 6RD IPv6 tunnel.
  ip address 10.20.6.1 255.255.255.0
  no ip redirects
  ipv6 enable
  tunnel source Vlan1
  tunnel mode ipv6ip 6rd
  tunnel 6rd prefix 2001:55C::/32
  tunnel 6rd br 69.252.80.66

interface FastEthernet4
  description Internet-Outside$FW_OUTSIDE$
  ip address dhcp client-id FastEthernet4
  ip access-group FirstPass in
  ip nat outside
  ip virtual-reassembly in
  load-interval 30
  duplex auto
  speed auto
!
interface Vlan1
  description Inside$FW_INSIDE$
  ip address 10.20.222.1 255.255.255.0
  ip flow ingress
  ip nat inside
  ip virtual-reassembly in
  ip tcp adjust-mss 1452
  ipv6 address Comcast6RD ::/64 eui-64
  ipv6 enable

ipv6 route 2001:55C::/32 Tunnel6
ipv6 route ::/0 Tunnel6

-----------------

RouterA-new#show tunnel 6rd tunnel6
Interface Tunnel6:
   Tunnel Source: 10.20.222.1
   6RD: Operational, V6 Prefix: 2001:55C::/32
        V4 Prefix, Length: 0, Value: 0.0.0.0
        V4 Suffix, Length: 0, Value: 0.0.0.0
        Border Relay address: 69.252.80.66
   General Prefix: 2001:55C:A14:DE01::/64

---------------------

RouterA-new#show ipv6 interface brief
 
Tunnel6                    [up/up]
     FE80::A14:DE01
Vlan1                      [up/up]
     FE80::523D:E5FF:FE98:E0CE
     2001:55C:A14:DE01:523D:E5FF:FE98:E0CE

--------------

glgersc Tue, 03/01/2011 - 21:55

Hmm, OK, after reviewing my config, I decided to point the
tunnel source to the outside interface.  So, the Tunnel6 interface now looks like this:

interface Tunnel6
description Comcast 6RD IPv6 tunnel.
ip address 10.20.6.1 255.255.255.0
no ip redirects
ipv6 enable
tunnel source FastEthernet4
tunnel mode ipv6ip 6rd
tunnel 6rd prefix 2001:55C::/32
tunnel 6rd br 69.252.80.66
end

That seems screwy, as any tunnels I've done before would point to the inside interface.  (But my tunnel experience is weak.)

I now get an outside public IP referenced prefix for my ipv6 address.

RouterA-new#sho tunnel 6rd tun6
Interface Tunnel6:
  Tunnel Source: 24.118.231.197
  6RD: Operational, V6 Prefix: 2001:55C::/32
       V4 Prefix, Length: 0, Value: 0.0.0.0
       V4 Suffix, Length: 0, Value: 0.0.0.0
       Border Relay address: 69.252.80.66
  General Prefix: 2001:55C:1876:E7C5::/64

But it still doesn't work. No connectivity beyond the router.

I've also removed all firewall config and screening ACL's to make sure I don't have any issue there.  (Temporarily.)

I'm not finding any useful configuration examples on the Internet.  Everything seems to be lab based, using 10.x addresses, and not reflective of any actual deployment.  Comcast or otherwise.

Anyone have any other thoughts?  And again, has anyone had any luck getting 6RD to work on any Cisco router, in a typical home NAT DHCP deployment, with Comcast?

Thx,

Greg

bep Wed, 03/02/2011 - 10:47

I have 6rd running on my Linux server through a Comcast Business Internet connection.  The first hop router, however, is a Cisco ASA.  I had to put in specific rules to permit protocol 41 to be passed through the ASA.  Depending on what device is performing the NAT in your network, it might not permit protocol 41 or perhaps not NAT it.  Additionally, you need to have some route(s) that point to the tunnel as the destination for your IPv6 traffic.

Here is an example of 6rd set up to use a DHCP address for the tunnel source:

ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0
interface Dialer0
ip address dhcp  ! (10.0.0.10)
!
interface Tunnel0
tunnel source Dialer0
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 8
tunnel 6rd prefix 2001:db80::/28
tunnel 6rd br
ipv6 address DELEGATED_PREFIX ::/128 anycast
!
interface Ethernet0
ipv6 address DELEGATED_PREFIX ::/64 eui-64
!
ipv6 route 2001:db80::/28 Tunnel0
ipv6 route ::/0 Tunnel0, 2001:db80:a000:0010::
ipv6 route 2001:db80:0:A00::/52 Null0

Note there is a caveat in IOS today where it would reject overlapping  IPv6 addresses as configured above, ie., a /128 on the tunnel and /64  on the LAN interface, with the %IPV6_ADDRESS-3-ADDRESS_CFG error.  The workaround is to remove the IPv6 address configuration from the  Tunnel interface and use the command ipv6 enable to have a  link-local ipv6 address assigned to the Tunnel.

wzhang Wed, 03/02/2011 - 12:13

Hi,

Yes your tunnel source interface should be pointing to your WAN interface.

Do you have the correct ipv6 static routes configured? With 6rd, you'd typically want to have a default route, as well as the 6rd connected network pointing to the tunnel interface. If you are running pings from behind the 6rd router, you could also enable egress netflow on the FastE4 interface to see if ip protocol 41 traffic is leaving the router (it will show up as protocol 29 in hex). That will give you some ideas on whether the problem is with this router, or somewhere further upstream.

Thanks,

Wen

glgersc Thu, 03/03/2011 - 18:24

OK, the correct answer is that the tunnel interface should be linked to the outside interface, as Wen pointed out.  And as he also pointed out, it's time to actually look at the outside interface and see what's going on.  So, I rearranged some things, and have a sniffer on the outside interface.

The first thing I figured out is that I need to work on my ZFW rules/config.  But for testing, I've been disabling the ZFW config all along anyway, and it still didn't work.

The sniffer pointed out something really odd.

Here is the tunnel config:

interface Tunnel6
description Comcast 6RD IPv6 tunnel.
ip address 10.20.6.1 255.255.255.0
no ip redirects
ipv6 enable
tunnel source FastEthernet4
tunnel mode ipv6ip 6rd
tunnel 6rd prefix 2001:55C::/32
tunnel 6rd br 69.252.80.66
end

Notice the 6rd br address.  This is the IP for 6rd.comcast.net

And here is the output of the 'sho tun 6rd' command:
RouterA-new#sho tun 6rd tu6
Interface Tunnel6:
  Tunnel Source: 24.118.231.197
  6RD: Operational, V6 Prefix: 2001:55C::/32
       V4 Prefix, Length: 0, Value: 0.0.0.0
       V4 Suffix, Length: 0, Value: 0.0.0.0
       Border Relay address: 69.252.80.66
  General Prefix: 2001:55C:1876:E7C5::/64

The tunnel source and border relay address all show up properly configured.  And the prefix shows the proper hex conversion of the outside ipv4 address into the 3rd and 4th section of the ipv6 address.  (Hmm, what do you call an 'octet' in ipv6?)  So everything should be good.

But, this is what the sniffer shows leaving the outside interface:

  The ipv4 destination address is 128.15.0.0.   What the heck?

As Wen predicted, you can see that this is an 'ipv6 in v4' packet, on protocol 0x29 (41).  So the encapsulation is correct.  And the embedded ipv6 addresses and the rest of the ethernet and tcp protocol for this SYN packet are also correct.

So what is going on with the 128.15.0.0 destination address?  Where could it possibly be getting that IP from?

Anyone have any ideas?

Thx,

Greg

wzhang Fri, 03/04/2011 - 08:05

Hi, Greg:

Well 128.15.0.0 is 0x800f:0000 which is your ipv4 address after the 6rd prefix in your ipv6 destination address you are trying to get to . So it looks like the CE is treating this destination network as directly connected to 6rd. Could you send us your ipv6 routing table (show ipv6 route)?

Thanks,

Wen

glgersc Fri, 03/04/2011 - 18:04

Wen, excellent observation.  And it is tracking for other destinations.  This is what I get when I ping other destinations:

2001:4860:8888::55          136.136.0.0

2001:4810::110                 (nothing)

2001:4860:8888:4444::55    136.136.68.68

As you noticed, in each case, the ipv4 tunnel destination is the 3rd and 4th 'octet' of the ipv6 destination.

This is the output of my 'sho ipv6 route':

RouterA-new#sho ipv6 route
IPv6 Routing Table - default - 5 entries

S   ::/0 [1/0]
     via Tunnel6, directly connected
S   2001:55C::/32 [1/0]
     via Tunnel6, directly connected
C   2001:55C:1876:E7C5::/64 [0/0]
     via Vlan1, directly connected
L   2001:55C:1876:E7C5:523D:E5FF:FE98:E0CE/128 [0/0]
     via Vlan1, receive
L   FF00::/8 [0/0]
     via Null0, receive

These are the actual static routes in the config:

ipv6 route 2001:55C::/32 Tunnel6
ipv6 route ::/0 Tunnel6

I'm confused how the ipv6 routes might be affecting the ipv4 destination tunnel address, but maybe that's just one of the ipv6 things I have yet to learn.

I was also a bit confused by the static ipv6 routes in the CE portion of this reference:

http://docwiki.cisco.com/wiki/6rd_Configuration_Example

...and didn't implement all of the examples.  So maybe I'm missing something there.

I'm also wondering if maybe the 'tunnel 6rd ipv4 prefix-len' command might have something to do with it.  The Comcast directions say to set the "IPv4 Mask Length =0".  So I left the 'tunnel 6rd ipv4 prefix-len' command at it's default 0 setting.  Could that be related?

Correct Answer
wzhang Fri, 03/04/2011 - 19:59

Hi, Greg:

I think the problem is with your default v6 route - "ipv6 route ::/0 Tunnel6". You are basically telling the CE that everything is directly connected to the 6rd network, so it assumes whatever comes after the 6rd prefix is the embedded ipv4 address for the destination. Could you try to remove this line, and replace it with "ipv6 route ::/0 Tunnel6  2001:55C:45FC:5042::"? This should tell the CE to send everything else to the BR instead. Give it a try and see if that helps any.

You are correct that by not configuring "tunnel 6rd ipv4 prefix-len", it defaults to a prefix length of 0, which means the CE ipv4 addresses cannot be aggregated and therefore all 32 bits will be used. So with a 6rd prefix of 32 bits and 32 bits of ipv4, your delegated prefix is 64 bits (longest allowed by the 6rd spec), which implies you won't be able to subnet within that delegated prefix.

Hope this helps.

Thanks,

Wen

glgersc Fri, 03/04/2011 - 20:54

Eureka!

Wen, I was hoping to get this posted before you replied.  I was feeling proud of myself that I finally figured out what you were referring to, and I had the fix before you posted it.  What was missing was the next hop on the default route.

ipv6 route ::/0 Tunnel6 2001:55C:45FC:5042::

That's the magic line that fixed it.  '45FC:5042' being the hex equivalent of the destination of the tunnel: 69.252.80.66   aka 6rd.comcast.net

This is the resulting routing table:

RouterA-new#sho ipv6 route
IPv6 Routing Table - default - 4 entries

S   ::/0 [1/0]
     via 2001:55C:45FC:5042::, Tunnel6
C   2001:55C:1876:E7C5::/64 [0/0]
     via Vlan1, directly connected
L   2001:55C:1876:E7C5:523D:E5FF:FE98:E0CE/128 [0/0]
     via Vlan1, receive
L   FF00::/8 [0/0]
     via Null0, receive

To get the fix, I also went back to the docwiki link are looked at the examples again.  There are some typos in there, like a comma in the route config, that were confusing.  And some of the addresses are wrong as well.  But, with Wen's tip, I finally figured out that the default ipv6 route to the tunnel needed a next hop, which was the far side of the tunnel.

I probably still have some tuning to do (MTU, etc.), and I still need to figure out how to get the zone based firewall rules to apply to the tunnel and the IPV6 traffic.  (No NAT for basic protection on ipv6.)  When I get a fully proven config, and I'm sure I've cleaned the cruft out, I'll post a complete config here.

Thanks to all who provided useful tips, especially Wen.

wzhang Fri, 03/04/2011 - 21:20

Hi, Greg:

I'm glad you figured it out .

I've removed the comma in the example config. If you can tell me which addresses in that configuration are still wrong, I can help correct those as well. Note the example uses a somewhat not-so-intuitive prefix combination (28 bit 6rd and 8 bit ipv4), so the addresses do look a little stange at first glance. The current configuration in that example is slightly different from what the original author had initially, and I may have missed a couple things when I corrected it to make the prefixes more consistent.

Also, there is currently a problem with ZBF interoperating with ipv6 tunnels in the classification engine. If you see traffic dropped from self to the outside zone for the ipv4 tunnel traffic, try disable CEF.

Thanks,

Wen

Phillip Remaker Sat, 03/05/2011 - 06:49

Please feel free to post your complete Comcast sample config in the Documents Section of this community!

glgersc Sun, 03/06/2011 - 15:42

I've posted the example config, complete with diagrams and copious notes.

Please let me know if I've missed anything, or have details wrong.

glgersc Sun, 03/06/2011 - 17:49

Wen, on the 6RD docwiki link, I think the key thing that's still off is the IPv6 addresses in the picture.  The last chunk has too many zero's.

For example: 2001:db80:0000a:: /52

Also, if the BR IPv4 address is 10.0.0.1, shouldn't the CE default route next hop be '2001:db80:a000:001::' or maybe ''2001:db80:a000:1::' ?

Not '2001:db80:a000:0010::' ?

The next thing I'm working on is getting zone rules working.  I thought I had it.  Basically letting the tunnel traffic in/out from Self and Outside, and then creating a simple inspect rule set from Inside to Tunnel6.  Like this:

class-map type inspect match-any IPv6-Out-class
match protocol icmp
match protocol tcp
match protocol udp

policy-map type inspect IPv6-Out
class type inspect IPv6-Out-class
  inspect
class class-default
  drop log

zone security TunnelZone

zone-pair security Inside-to-Tunnel source in-zone destination TunnelZone
service-policy type inspect IPv6-Out

int tun 6
zone-member security TunnelZone

This worked great.  I was seeing the audit logs getting built for the outbound connections, and using an external scan tool, scans were getting properly blocked.

Worked, as in past tense.  24 hours later, the inspect operations appeared to have failed for IPv6.  (Still working/logging for IPv4.)  They are still passing traffic out, but the audit logs are no longer being created, and the packets are getting dropped on return due to no inbound path.  If the rule was completely dead/wrong, it shouldn't be able to pass traffic out at all.  The dynamic inspect return path is gone with the oubound logging. (I'm seeing this on a sniffer on the outside interface as well.)

I can create an inbound Tunnel-to-Inside pass rule, and get traffic flowing, but then I'm not blocking anymore.

I tried your tip about turning off IPv6 CEF, no luck.

I'm still learning about ZBF, and could have had this really boogered up and in a fragile state.  But it was working.

Does anyone have any working ZBF rules/configs for this type of tunneled IPv6 traffic?

  One step forward, two to the side.....

wzhang Sun, 03/06/2011 - 20:48

Hi, Greg:

>>Wen, on the 6RD docwiki link, I think the key thing that's still off is the IPv6 addresses in the picture.  The last chunk has too many zero's.

>>For example: 2001:db80:0000a:: /52

You are right, it should be 2001:db80:0000:a000::/52. Technically it's still correct, it just doesn't conform to the standard v6 address representation ;-)  The tricky part with this configuration is the 28 bit 6rd prefix, which means the ipv4 address that comes after won't fall on the full byte address boundary. I'd still argue it's a good ipv6 addressing exercise though :-)

>>Also, if the BR IPv4 address is 10.0.0.1, shouldn't the CE default route next hop be '2001:db80:a000:001::' or maybe ''2001:db80:a000:1::' ?

>>Not '2001:db80:a000:0010::' ?

Yes, the BR address is indeed wrong, it should be 2001:db80:0000:1000::. Note since the 6rd ipv4 prefix length is 8, only the last 3 octet of an ipv4 address is embedded in the ipv6 address (the first octet of 10 decimal is omitted). Thanks for catching these errors, I will get them corrected.

For the ZBF configuration, the problem that I had ran into had to do with ipv4 firewall inspection on the ipv4 traffic (prior to tunnel decapsulation) from the outside to the self zone. Since you are actually doing ipv6 inspection, it shouldn't apply. At first glance, your firewall config looks to be correct, so I'm inclined to agree with you that this looks like some sort of a bug. So when the problem happens, if you were to look at the firewall sessions for the inside-to-tunnel zone pair, do you see any active sessions at all? What about packets that matches the ipv6-out-class in the firewall stats?

Thanks,

Wen

glgersc Mon, 03/07/2011 - 21:29

OK, I'm going crazy here.  My outbound IPv6 inspect was working perfectly, and then stopped for no reason.  Packets still go out (watching on an external sniffer), but because the inspect rule was never built (as seen by the lack of log entry), they get dropped on return.  I figured I had just done something goofy and would start over.

But, I noticed something funky in the sniffer trace the next time I looked.  Two other PC's on my network are still working perfectly.  Outbound IPv6 builds/logs the inspect sessions, and traffic returns correctly.

Hmm.  Maybe the router was stuck.  Reload the router.  Still the same.

What would cause the router to skip building inspect sessions for one PC, but keep doing it for others on the same subnet?

I'm also thinking it might be time to move this thread over to the security/firewalling forum.  What's the etiquette for that here?

Any insight appreciated.

------------------------   update  ----------------------

Before posting this I tried one more thing.  I killed and restarted the IPv6 stack on my PC.  (running Vista 64)

Now it works.  The only difference is that I generated a new address.

The router still had both addresses in it's neighbor cache:

RouterA#sho ipv6 nei
IPv6 Address                              Age Link-layer Addr State Interface
2001:55C:1876:E7C5:3C8C:839C:5CC7:EE61      1 0050.8d9f.710c  STALE Vl1   !<==  Works great.
2001:55C:1876:E7C5:EC09:7D51:E508:D6CC      5 0050.8d9f.710c  STALE Vl1   !<==  Won't create an inspect rule.

And now that I think back, the only thing that did change between the rules working and not working is that I rebooted my PC, so again, getting a different address.

What on earth would make the router totally mishandle one IPv6 address on a host, and work perfectly for a different equally valid address on the same host?  This behavior survived a router reload, and several clearings of neighbors, CEF, etc., so it's unlikely to be memory related.

Any ideas?

wzhang Tue, 03/08/2011 - 20:00

Hi, Greg:

This looks like a bug with IOS. I tested your config in my lab and saw the same thing. It appears that if leading nibble in the interface-id is 0xE in the source ipv6 address, then the FW somehow will not create an inspect sessions for it. Strange indeed... as I can't quite see any significance in this half byte for an EUI-64 encoded interface-id. I'm going to try to do some research on this and see what I can find. Stay tuned...

Thanks,

Wen

glgersc Sun, 05/01/2011 - 16:31

Hi Wen,

Did you ever have any luck tracking this down as a new or existing bug?  Any bug ID I can track against?

I am still observing this behavior.

Thx,

Greg

wzhang Sun, 05/01/2011 - 18:26

Hi, Greg:

I apologize for not posting an update on this - had too many things going on. I was not able to find an existing defect for this issue, so I opened a new bug for this. See:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn84802

It's currently still under engineering investigation. You may want to open a Service Request and link it to the bug so that you can get a better idea on an ETA for the fix.

Thanks,

Wen

Actions

Login or Register to take actions

This Discussion

Posted February 27, 2011 at 9:10 PM
Stats:
Replies:22 Avg. Rating:5
Views:3165 Votes:0
Shares:0
Tags: ipv6, tunnel, comcast, 6rd
+

Related Content

Discussions Leaderboard