dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
15984
sushiglob
join:2014-08-02

sushiglob

Member

Re: UVERSE IPv6 Problems

Update. So far so good on my end. I'm still on Native and IPv6 seems to be working so far.

I am experiencing issues with Google services though. Gmail doesn't load right sometimes and Google Music still pauses or fails to stream properly. Actually....those are the only sites I've had problems with since being on IPv6.

Not sure how to optimize it all though.

ILpt4U
Premium Member
join:2006-11-12
Saint Louis, MO
ARRIS TM822
Asus RT-N66

ILpt4U

Premium Member

My update: my IPv6 got worse, when I updated both the NVG589 and Asus to their latest firmwares

Going to have to play more with the MTU settings on the Asus, I think, or try alternate firmware other than Stock firmware

But yeah, I went and turned IPv6 off in the meantime -- was getting sick of only some websites working
xcrunner529
join:2010-08-05
Columbus, OH

xcrunner529 to sushiglob

Member

to sushiglob
I tried with the latest version of the ASUS merlin firmware, but native still doens't work. It is clearly the 3800HGV that just will not work in passthrough mode for IPv6. So annoying.
sushiglob
join:2014-08-02

2 edits

sushiglob

Member

Switched over to Google's DNS servers, both IPv4 and IPv6, to test out why Gmail and Google Music take forever to load. Gmail seems to load much faster, but Google Music isn't even loading now.

Anyways...everything seems a bit snappier using Google's DNS servers. Testing goes on...but what a serious mess. It really shouldn't be this difficult. The issues everyone is experiencing appears to be from very unfriendly IPv6 firmware on 3rd party routers.

EDIT: Using the same firmware that worked with Native, I'm attempting to get Tunnel 6rd to work properly. It seems smoother in the sense that Google Music loads and stream without issue and the Xfinity speed test completes rather than times out. Timing out seemed to be something that Native did with these two sites.

What I still don't understand, is why do I only get half speed when running Tunnel 6rd. Instead of getting 45Mbps during Xfinity speed testing, I only get 25Mbps. I can't get any faster speeds with IPv6 when doing Tunnel 6rd.

Once again though, it's probably firmware related.

Fast speeds with Native, but a bit buggy with some sites being unstable.
Slower speeds with Tunnel 6rd, but all sites seem to load without issue.
jimmyipv6
join:2013-01-04
Lilburn, GA

jimmyipv6 to sushiglob

Member

to sushiglob
I am having the same issue to with the 99.99.99.53 and 99.99.99.153 servers and I am directly connected to the gateway. Is anyone else having an issue with the test-ipv6.com not completing the test. Now it only shows 9/10 instead of 10/10. Please let me know if anyone else is having an issue as it wasn't having this problem before the configuration change. It seems like a DNS issue and core backend issue.
sushiglob
join:2014-08-02

sushiglob

Member

The latest Merlin 376.44 build is a no go for me on IPv6 as well. Not only does it not load sites properly (again), but my speed is back down from 45Mbps to just 25Mbps.

Junk.

I'll just roll back to the really old build that worked better: 374.35_4
benk016
join:2011-06-05
Owasso, OK

benk016 to sushiglob

Member

to sushiglob
I know most of you seem to have issues with this asus router, But I have a meraki access point, which is owned by cisco now. I have to disable IPv6 passthrough completely on this device. If I turn it on, all wireless devices will work for a few seconds and then the connections start timing out.

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

rolande to sushiglob

MVM,

to sushiglob
said by sushiglob:

but my speed is back down from 45Mbps to just 25Mbps.

I'm really beginning to wonder what is behind this reported slower performance with IPv6. It seems to be pretty consistent for most everyone that is using the AT&T 6rd tunnel. I've tested myself to Comcast's server from a number of different test locations and I can get 47-49Mbps over IPv4 and IPv6 reports ~25Mbps, as well. IPv6 does not incur that much overhead. I'm thinking there must be some sort of tunnel restriction on AT&T's 6rd border relay router that is to blame.

For me it isn't a huge deal. I've been using IPvFoo in Chrome and watching what is running v6 and for the most part it is Google, Yahoo, and Facebook stuff of which the vast majority is analytics and not primary content. I have noticed no performance difference with my normal browsing and application activity. I use quite a bit of Google Mail/Apps/Docs and everything just seems to run Business As Usual.

I'll have to capture some test transfers and compare the TCP behavior to see what is throttling the traffic. My guess is I will see Delayed ACKs and window updates from AT&T's border relay that reduce the TCP throughput over IPv6.
benk016
join:2011-06-05
Owasso, OK

benk016

Member

I don't lose much speed on IPv6. However I don't have the power tier. My ping time does double though.



rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

rolande to benk016

MVM,

to benk016
said by benk016:

I have to disable IPv6 passthrough completely on this device.

An access point should just be bridging whatever is sent to it or received anyway, regardless if it is IPv6 or IPv4. I assume you are disabling IPv6 on the RG or your router interface facing towards that L2 segment your access point is on.

I'm curious what is really at the root of all these IPv6 issues I see being reported. Is it DNS related problems or local device firmware issues or what? I enabled mine months ago with DHCP-PD going to my Cisco 3825 and enabled it on my internal network and everything has been golden. Both of my Macbooks have full IPv6 connectivity and everything just works.
benk016
join:2011-06-05
Owasso, OK

benk016

Member

said by rolande:

I assume you are disabling IPv6 on the RG or your router interface facing towards that L2 segment your access point is on.

No, I'm disabling it on the Meraki.
The meraki dashboard says this
Meraki access points have IPv6 disabled by default for increased performance. Enabling this option will allow you to pass IPv6 traffic. Please note you will have to configure your SSID with bridge mode to pass IPv6 traffic.

And this network is setup with bridge mode:
Bridge mode: Make clients part of the LAN
Meraki devices operate transparently (no NAT or DHCP). Clients receive DHCP leases from the LAN or use static IPs. Use this for shared printers, file sharing, and wireless cameras.

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

rolande

MVM,

said by benk016:

Meraki access points have IPv6 disabled by default for increased performance.

That is odd. What does the Meraki do with the IPv6 traffic at L2 that bogs down performance? If anything, when disabling IPv6, it has to specifically identify IPv6 packets inside an Ethernet frame to drop them which I would think would actually take more hardware resources than just forwarding the frames to the destination MAC address by default. If you disable the router for IPv6, then the only IPv6 traffic would be basic link-local stuff for any enabled clients for which there would be very little traffic anyway by default.
sushiglob
join:2014-08-02

2 edits

sushiglob

Member

Came across some very old threads regarding IPv6 and slow downs with timeouts. Pretty much what we've been experiencing.

One person claimed to have found the fix. They simply set the MTU of the IPv6 protocol to match what was incoming.

Didn't work for me. So....back to the beginning.

EDIT: I'm going to see if I can speak with Merlin about this issue. Then again...it's not just the Asus routers having this issue.

EDIT: Scratch that. Just doing some searching, I can see Merlin also knows there are many issues with IPv6. His recommendation is to just turn it off as it brings little to no benefit right now. There probably is some truth to that. IPv6 is probably just not worth the hassle right now. Bugs in the firmware, bugs in the infrastructure of UVERSE. Maybe it's time to just let it be...?

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX

rolande

MVM,

I've tuned my router interface MTUs for 1480 to match the 6rd tunnel capacity and it is advertised properly. MTU mismatch should not cause that much slow down as it should just fragment the packets anyway.

dahan
join:2000-10-25
Leander, TX

dahan

Member

It's been a while, so I don't remember the details, but AT&T used to block fragmented packets: »Ping with large packet sizes does not work

Much of the discussion is about ping packets, but I do remember the reason I ran into the problem in the first place was that it seemed to be that no fragmented packets made it through--ping was just an easy way to test/demonstrate the issue. I was actually seeing the problem with an IPsec VPN tunnel.

As I said, I could be misremembering this, but at least back in 2010, AT&T's network would pass the first fragment of a packet, but the other fragments would be dropped. So it's important to set your local MTU low enough that packets won't need to be fragmented due to additional tunnel encapsulation overhead.
sushiglob
join:2014-08-02

sushiglob

Member

said by dahan:

So it's important to set your local MTU low enough that packets won't need to be fragmented due to additional tunnel encapsulation overhead.

How low is low though? I can see that IPv6 MTU is coming in at 1472, but regardless of what I set, there is no difference in speed.

dahan
join:2000-10-25
Leander, TX

dahan

Member

said by sushiglob:

How low is low though? I can see that IPv6 MTU is coming in at 1472, but regardless of what I set, there is no difference in speed.

Hmm, 1480 should be good enough... 6rd encapsulation is simply another IPv4 header, which is 20 bytes. So 20 bytes for 6rd + 1480 bytes of data = 1500, which can be sent over Ethernet without fragmentation. And 1472 would allow for PPPoE encapsulation, although U-verse doesn't use that, so I don't think you'd need to go that low.

In any case, if setting your MTU to 1472 doesn't help, your speed issues probably aren't related to the MTU. You might try watching the connection with something like Wireshark and see if you (or someone else) can figure out where the slowdown is.

kode54
join:2003-09-19
Riverside, CA
Sercomm ES2251
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO

kode54

Member

From my experiments with ping6 -s targeting www.google.com from Mac OS X, I find that I can only send a packet size of 1232 successfully, which combines with the ICMP6 packet to 1280 bytes. Anything larger is summarily dropped.

Whereas any IPv4 ping -s with larger than 1472 bytes of data resulted in dropped traffic.

Unfortunately, I paid Apple $277 for the privilege of having a router that I can't set MTU on.

j1349705
Premium Member
join:2006-04-15
Holly Springs, NC

j1349705 to rolande

Premium Member

to rolande
said by rolande:

I've tuned my router interface MTUs for 1480 to match the 6rd tunnel capacity and it is advertised properly. MTU mismatch should not cause that much slow down as it should just fragment the packets anyway.

I agree that MTU mismatch shouldn't matter if Path MTU Discovery is working properly.

I suspect the issue is that in some cases, PMTUD isn't working reliably and is causing IPv6 traffic to be dropped since IPv6 routers don't fragment traffic.
taner
join:2000-12-25
San Diego, CA

1 edit

1 recommendation

taner to sushiglob

Member

to sushiglob
I'm almost certain that AT&T is BREAKING (hopefully unintentionally) PMTU on IPv6 (via their 6rd tunnels.

1) I have random, weird issues (sites hanging, sites not loading) if I leave my MTU default.
2) If I drop my MTU to 1430, everything is great!

I tried sniffing ICMP, watching for the ICMP FRAG REQUIRED packet, when I send large packets out -- but they never come. Sad panda.

Additionally:

AT&T needs to use more diverse 6rd endpoints! My endpoint is somewhere 50+ms away from me, so anything over IPv6 is automatically 50ms slower than IPv4.

And, perhaps worst of all:

My NVG589 has been crashing and rebooting often now, after having recently enabled IPv6. This evening had had enough, and I've completely shut off IPv6 on my network to verify this hypothesis.

[EDIT:] I just realized my firmware seems to have been updated in the last week or two (I'm now on 9.1.0h12d22) -- so I have no idea if that is the root cause of these reboots, or what.

That said, seeing crap like this in the RG logs (I mangled my v6 address) does not instill confidence:
P0000-00-00T00:00:51 L3 dhcpd[1574]: /var/etc/dhcp6d.leases line 10: no pool found for address 2602:306:cafe:babe::49
P0000-00-00T00:00:51 L3 dhcpd[1574]:   }
P0000-00-00T00:00:51 L3 dhcpd[1574]:    ^
P0000-00-00T00:00:51 L3 dhcpd[1574]: Corrupt lease file - possible data loss!
 

AT&T really needs to get their act together. Their network gear (either CPE or perhaps even core) does not seem to "working properly" when it comes to v6.

Honestly, they need to ditch 6rd and just run native (well, dual-stack) IPv6.

I need to see if I still know any of the neteng people at T... hmmm... :)

-Taner

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

1 recommendation

rolande

MVM,

said by taner:

AT&T needs to use more diverse 6rd endpoints! My endpoint is somewhere 50+ms away from me, so anything over IPv6 is automatically 50ms slower than IPv4.

The network isn't too bad to my particular 6rd border relay location which is likely in the same PoP in Richardson as my head end aggregation or within a couple milliseconds here in DFW. The latency to my upstream gateway is ~25-26 millisecond range and the latency to my border relay is ~26-27 milliseconds. That only adds 1-2 milliseconds to my overall latency for IPv6 traffic, not counting the encapsulation and decapsulation processing that has to occur on either end which probably adds a total of 10 microseconds in either direction.

Hop #6  12.83.49.81 (12.83.49.81)  25.909 ms  27.125 ms  26.155 ms
 

Are you sure you were only counting the unshared path latency or is that the overall average latency from your end to the border relay? You have to subtract the latency of the link from your house to the L3 head end PoP to establish a true relative difference in latency.

trparky
Premium Member
join:2000-05-24
Cleveland, OH
·AT&T U-Verse

1 recommendation

trparky

Premium Member

I turned off IPv6 as well on my NVG589. With it on YouTube performance was epic fail, as soon as I turned off IPv6 support in the NVG589 YouTube performance shot through the roof.

I suspect that AT&T just doesn't have enough IPv6 endpoint support yet. I figure that until we go native IPv6 the performance of IPv6 on AT&T uVerse will always be an epic fail.

I personally can't wait until AT&T uVerse goes native dual-stack instead of this 6rd hack job.
taner
join:2000-12-25
San Diego, CA

1 edit

1 recommendation

taner to rolande

Member

to rolande
said by rolande:

Are you sure you were only counting the unshared path latency or is that the overall average latency from your end to the border relay? You have to subtract the latency of the link from your house to the L3 head end PoP to establish a true relative difference in latency.

Yes, definitely :-)

In fact, I can just ping the IP address that my RG lists as the 6rd endpoint, and I see (and this is now worse than the other day - my uplink is roughly +25ms, so we're at +60ms now):

--- 12.83.49.81 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 86.923/87.372/87.789/0.530 ms


And here's an end-to-end test (ping -c 5 host; ping6 -c 5 host) I did the other day (v6 is off now, so I can't quickly/easily do a new test), with the "50ms" difference -- which surely would be even worse now. The remote host is on native/dualstack v6:

a host, via v4:
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 34.456/34.867/35.249/0.356 ms


same host, via v6:
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 84.992/85.436/85.862/0.436 ms
sushiglob
join:2014-08-02

sushiglob to trparky

Member

to trparky
said by trparky:

I turned off IPv6 as well on my NVG589.

I turned it off too. I guess, I give up. Maybe ATT will fix some issues or maybe they'll even read this thread. Who knows, but for now, I think it's best to avoid IPv6.
taner
join:2000-12-25
San Diego, CA

taner

Member

said by taner:

My NVG589 has been crashing and rebooting often now, after having recently enabled IPv6. This evening had had enough, and I've completely shut off IPv6 on my network to verify this hypothesis.

So, just to follow up here: I've had no reboots in the last 4 days:

Time Since Last Reboot 04:12:48:09

which is ever since I turned off IPv6 on my internal network. (RG is running the latest firmware pushed by AT&T: 9.1.0h12d22)

This makes me sad :(

-Taner

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

1 recommendation

rolande

MVM,

said by taner:

which is ever since I turned off IPv6 on my internal network. (RG is running the latest firmware pushed by AT&T: 9.1.0h12d22)

That is either a coincidence or you have a bad NVG589 or when you enable IPv6, your equipment is not playing nicely in the sandbox. I have been running IPv6 on my 589 for the past 6 months, since prior to the last 2 firmware upgrades with my own Cisco router sitting behind it in IP Pass-through mode and with IPv6 Prefix Delegation and it has been working flawlessly.
greggmc
join:2014-08-27
Charleston, SC

1 edit

greggmc to sushiglob

Member

to sushiglob
Finally! I thought I was the only one with this issue. I don't use Facebook, but have the same issues with Google sites. I am using OpenWrt(Barrier Breaker) behind a NVG589.

mackey
Premium Member
join:2007-08-20

2 recommendations

mackey to taner

Premium Member

to taner
said by taner:

I'm almost certain that AT&T is BREAKING (hopefully unintentionally) PMTU on IPv6 (via their 6rd tunnels.

I AM certain AT&T is breaking PMTU. I discussed this 2 years ago. I did not have any luck with iptables' "clamp-mss" options or changing the MTU of the 6rd interface; the only thing which worked for me was telling radvd to advertise a MTU of 1480 to my LAN.

/M

sadperson
@107.223.175.x

sadperson

Anon

I have these exact same IPV6 issues. Facebook does seem like the largest culprit, especially on android. If the IPV6 config is set up as native on my Asus router, things freak.

IPv6 with U-verse seems to be a more complicated setup than Time Warner or Comcast setups I've experienced (separate modem vs RG might make a difference here?). Sucks.
sushiglob
join:2014-08-02

sushiglob

Member

Just in case anyone is looking for a solution (for the average user like myself), I've had to disable IPv6 on my Asus RT-N66U as well as disable it on my NVG589.

If you want to use IPV6, it's best to use the NVG589 without an external/separate router. However, I still experienced issues with IPV6 enabled on the NVG589 when I was connected directly to it.

What can I say? I think ATT Uverse has big time IPv6 issues. I've been running just fine with it disabled since I've posted this thread topic.