02-14-2014 5:49 AM
So AT&T has done it again it would seem - After loosing my ipv6 tunnel to hurricane electric via the 2wire firmware mess, It would seem now the NVG589 modems are affected. I've not yet been able to tell if its the firmware or just AT&T internally dropping protocol 41 packets not bound to their rd endpoint, but either way it would seem that any ipv6 tunnels not sanctioned by AT&T are down for me. Has anyone else seen this, and have a clue if theres any workaround? At this point, even in the light of the potential comcast merger, I think Time Warner would be a better solution than this.
02-18-2014 10:03 AM
@my thoughts wrote:
Meaning no RG currently has access to protocol 41, ...
This is still not true. Our 6in4 tunnels were working fine until Friday February 14th at around 1am. My Hurricane Electric tunnel had been up and working fine for the 6+ months I'd had U-verse service.
In addition, as I already explained, the gateway is using protocol 41 right now for AT&T's Rapid Deployment, confirmed by the contents of the NAT sessions table.
It was apparently known before that 2Wire gateways weren't allowing protocol 41 traffic through (I never had a 2Wire gateway, unlike others in this thread who switched to the NVG589 just for this purpose), but this is now clearly being filtered further inside AT&T's network, not at the gateway.
@my thoughts wrote:
For example, while extending IPv6 capabilities through a software update made to U-verse gateway devices, we discovered an issue with the software code that temporarily prevents us from continuing our IPv6 deployment for those devices and may disrupt third party IPv6 tunneling capabilities for some U-verse customers until we are able to update the software. Our IPv4 routing is unaffected and the deployment of IPv6 functionality will resume as soon as the corrective measures have been deployed.
Um. Huh? This seems to say that you know you broke it, and you're going to stop moving forward until you fix it. ...?
02-18-2014 10:11 AM
agree with tdd, while this might be the best reason you can come up with, its still not acceptable. The security concerns outlined in the referenced RFC are:
a) vague (i.e. not actionable)
b) affect endpoints only, not intermediate transport networks
c) are not in any way timely (i.e. that rfc was written 7 years ago), but our tunnels only stopped working last week.
So, to summarize your statement, you found some flimsy RFC citing vague security concerns regarding tunnels, that anyone who has the wherewithall to support their own tunnel already knows about, and used it as an excuse to disable private tunnels entirely, while convieniently excempting your own 6rd tunnels from those same security concerns. You've broken our networks in the guise of saving us from ourselves, without providing us any additional security. Thats unacceptable. Please provide us with a contact point to lodge an official complaint regarding this behavior.
02-18-2014 1:06 PM
When someone from AT&T called me about my FCC complaint regarding this, they used the same "security vulnerability" excuse. Specifically, they said that by using an IPv6 tunnel we're being allocated a static IPv6 address by a third party that allows access back into our home network, bypassing any security controls AT&T has in place. It's obviously a weak argument, since that's the entire point of PPTP, GRE, OpenVPN, IPSEC, or any other VPN technology that isn't also being banned.
Someone on dslreports.com said that since people are filing FCC complaints about this issue, AT&T has to respond with a "valid" reason for breaking our tunnels. "Security" is likely just the fastest way to get there.
02-18-2014 1:25 PM
I filed my complaint before the Verizon ruling that heralded the beginning of the end of the open Internet (I am so dramatic!), but I filled out the online form under Broadband, Billing/Service/Availability.
A large portion of the form is dedicated to billing disputes, so I left those blank and filled in item (5) with some text about how AT&T's behavior is a clear violation of the "no blocking" open Internet rules, as set forth here:
02-18-2014 2:20 PM
Done, thank you, I've filed an FCC complaint there, I'll keep everyone apprised of how that turns out.
- edited 02-19-2014 8:08 AM
So the story goes like this...Last year on my home network I lost IPv6 Internet connectivity due to a firmware upgraded to my Motorola 3800 RG (ISP supplied router) which was filtering Protocol 41. In order to continue service with my ISP I upgraded my connection to a new 45Mbit "Power Tier" which came with a new Motorola NVG589 RG that no longer filtered Protocol 41. Great! Since the upgrade (about 3-4 months) I have been operating 2 IPv6 tunnels dual homed to SixXS and HE and have not had anymore interuption until Feburay 14th when once again my IPv6 access was disabled. This time its not a firmware upgrade of my RG but rather a filter of some sort on the upstream provider (AT&T Uverse). My only choice now is to change my ISP or wait out my FCC complaint to be resolved I wonder which will happen first...CAN YOU HEAR ME NOW AT&T!?!?
04-25-2014 4:11 PM
My story is exactly the same as just about everybody elses. I upgraded to the "power" service (for more money) when it became available in my neighborhood last week. I got the shiny new NVG589 that I promptly put into cascade mode and sent my static /29 to a Cisco 2901 on my home network. Net result? It's faster (when line 1 and line 2 will bond properly, which is iffy), but still no gif tunnel to OCCAID for my IPv6 tunnel. I am not going to subject myself to the pain of dealing with AT&T for anything more technical than a billing problem, so I have gone straight to the FCC complaint site as well. We'll see what happens.
Meanwhile, the "security" excuse is terminally laughable.
04-27-2014 1:49 PM
I've since given up. AT&T is just useless here. They have no interest in fixing this. I've dropped my service with them and filed an FCC complaint. I'm using Time Warner Cables 50 Mb/s service now for the time being. Its shared media, so latency jitter is a bit higher than AT&T was, but nothing is blocked which is great. In a year I'll let go of TWC as Google fiber is coming to my area.
05-04-2014 2:19 AM
Update: Confirmed with OCCAID that the gif tunnel is up and they can see my ping6 echos. The ping6 replies are not making it back to me however, which suggests the 6to4 is being either filtered or intercepted in the AT&T network in only one direction.
Does anybody from AT&T want to step up to acknowledge this and provide info on a remedy? You people have a lot of hacked off customers out here.
05-26-2014 7:44 PM
Those who are more knowledgeable than myself may step in and comment / correct me but, if the ATTs network were being stressed by supporting U-verse TV – perhaps due to bandwidth limitations? – would shutting down IPv6 traffic buy them some time to upgrade or ovoid the cost of upgrading equipment?
05-27-2014 3:42 AM
Thats a fair question, but the answer is no, since they didn't shutdown ipv6 traffic, they only shutdown ipv6 traffic being routed by ipv6 tunnels that they didn't own. The ipv6 service that is natively offered by AT&T still works just fine. That fact also makes their argument about blocking non-AT&T ipv6 tunnels due to security risks patently false.
01-05-2015 9:21 PM
So I think I have the same issue going on. I had a complete outage of u-verse and as part of the fix among other things, they gave me a new NVG589. I thought we had one of these before the outage, but I'm not sure. All I know is I was running OpenVPN fine before for business and now it won't work. It appears that no packets are being returned on attempting to connect.
Could this be the same ipv6 issue you're describing here? Thanks for the reply.
01-06-2015 4:35 AM
Almost certainly. AT&T doesn't want to fix this problem. By the end I was reasonably confident they were doing it intentionally, either to make their lives easier by only having 6-in-4 traffic on their netwrok for tunnels they own, or so they could charge for upgraded ipv6 service more easily. I recommend just droping AT&T alltogether.
Visit these related resourcesView New Device Help!
|04-15-2015 5:32 AM|
|01-25-2017 8:30 PM|
|10-18-2017 11:34 AM|
|05-27-2014 10:12 AM|
|08-07-2016 2:06 PM|