dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
76
share rss forum feed

EZJohnson

join:2004-02-11
reply to ConstantineM

Re: 6rd is long as live on at&t!

I can confirm this is working on a 2wire with a linux box plugged in on DMZ.

ip tunnel add 6rd mode sit local 99.52.xx.xx ttl 64
ip tunnel 6rd dev 6rd 6rd-prefix 2602:300::/32
ip addr add 2602:306:334b:xxxx::1/60 dev 6rd
ip link set 6rd up
ip route add ::/0 via ::12.83.49.81 dev 6rd

I'm able to pull down the full 24mbps over ipv6 so no more 64kbps 6to4 tunnels for me



mackey

join:2007-08-20
kudos:6

said by EZJohnson:

ip tunnel 6rd dev 6rd 6rd-prefix 2602:300::/32

Hmmm, you may have some trouble if you try to access other sites also tunnelling. That line should be:
ip tunnel 6rd dev 6rd 6rd-prefix 2602:300::/28

What you have will work fine for accessing non-tunnelled sites though

/M

The Chef

join:2003-12-09

1 recommendation

reply to EZJohnson

The 6rd (not 6RD BTW) settings are below:

• The 6rd service provider prefix is 2602:300::/28.
• The 6rd IPv4 mask length is 0.
• The 6rd border router (BR) IPv4 address is 12.83.49.81.
• The DNS IPv4 server addresses should be set to 99.99.99.53, 99.99.99.153.
• The DNS IPv6 server addresses should be set to 2001:1890:0FFF:0840::10, 2001:1890:0FFF:0841::10 (if needed)
• Enable sending all 6rd traffic to the 6rd BR



mackey

join:2007-08-20
kudos:6

1 edit

In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.

I can ping6 stuff just fine, ipv6.google.com loads just fine, but anything that actually transfers data doesn't work. hxxps:// hangs at 'connected', hxxp:// hangs at 'waiting for ...', all speedtests time out, and scp copies just hang. It looks like PMTU discovery is totally broken from the internet, and that's kinda important when tunnelling! Actually, it looks like ALL ICMP to/from the 6rd gateway is filtered...

I can run `ping6 -M do -c1 -s1440 2607:f878::xyz` from inside my network to my dedicated server and it correctly returns:
PING 2607:f878::xyz(2607:f878::xyz) 1440 data bytes
From 2602:306::zzz icmp_seq=1 Packet too big: mtu=1480

But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.

Can anyone using 6rd post a IPv6 speedtest?

/M

Edit: found a ipv6-only site big enough to not load: »ipv6.bjornerback.com/ . I can `wget` it from my server just fine, but nada from AT&T's connection. Does it work for anyone else?


ccjunk

join:2006-06-29
Austin, TX

said by mackey:

In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.

...
But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.

Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse).


mackey

join:2007-08-20
kudos:6

said by ccjunk:

Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse).

Both actually. I mainly use my own router, but what you posted is irrelevant - outgoing (which is what is affected by the interfaces' MTU) works just fine for all packet sizes, it's the INCOMING that's failing. I can run tcpdump on the WAN interface and see the tunnelled smaller packets coming in, but the big ones never make it that far.

/M

ccjunk

join:2006-06-29
Austin, TX

said by mackey:

said by ccjunk:

Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse).

Both actually. I mainly use my own router, but what you posted is irrelevant - outgoing (which is what is affected by the interfaces' MTU) works just fine for all packet sizes, it's the INCOMING that's failing. I can run tcpdump on the WAN interface and see the tunnelled smaller packets coming in, but the big ones never make it that far.

/M

While not relevant to your ping tests, the outbound IPv6 MTU is relevant for TCP because the client will use it for setting its advertised MSS value which in turn will limit the packet size the Internet server sends. The client in your home network will set the TCP MSS to MTU-60B (IPv6+TCP overhead).

I just did a capture on a PC connected to the NVG510. In the IPv6 router advertisement from the NVG510 the MTU option is set to 1472 and my PC set the MSS in its TCP handshake to 1412. That forced the Internet v6 server to limit the IPv6 packets it sent to 1472B in size.

If you are doing IPv6 TCP and are having a problem with packet size, maybe your non-NGV510 router is not setting the MTU option (or is setting a value too large) in its router advertisements?


mackey

join:2007-08-20
kudos:6

said by ccjunk:

While not relevant to your ping tests, the outbound IPv6 MTU is relevant for TCP because the client will use it for setting its advertised MSS value which in turn will limit the packet size the Internet server sends. The client in your home network will set the TCP MSS to MTU-60B (IPv6+TCP overhead).

If you are doing IPv6 TCP and are having a problem with packet size, maybe your non-NGV510 router is not setting the MTU option (or is setting a value too large) in its router advertisements?

That is a hack at best, and it does absolutely nothing for non-TCP connections in addition to hurting LAN performance.

In other news, earlier I was able to get a 'Packet Too big' ICMP response from their router about every 6th packet, but tonight it's back to not responding at all. It looks like everyone is getting shoehorned through a single underpowered router after all.

/M

ConstantineM

join:2011-09-02
San Jose, CA
reply to The Chef

6rd DNS servers

said by The Chef:

• The DNS IPv4 server addresses should be set to 99.99.99.53, 99.99.99.153.

In my personal experience today, I very strongly advise against doing this, unless you're in Texas.

Using the default IPv4 DNS servers that my 2Wire PoS has (dnsr1.sbcglobal.net (68.94.156.1) and dnsr2.sbcglobal.net (68.94.157.1), instead of dns6rd1.sbcglobal.net and dns6rd2.sbcglobal.net as you suggest), but directly on OS X, instead of through 2Wire, works great for IPv6 and doesn't defeat the purpose of unicast CDNs.

dnsr1 and dnsr2 are probably anycast (within 3ms here), whereas dns6rd1 and dns6rd1 are back in Texas (44ms away). However, the IPv6 versions of dnsr{1,2} do seem to be very far away (46ms away), only IPv4 is a good anycast here in San Jose, CA.

ConstantineM

join:2011-09-02
San Jose, CA
reply to mackey

Re: 6rd is long as live on at&t!

said by mackey:

In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.

I can ping6 stuff just fine, ipv6.google.com loads just fine, but anything that actually transfers data doesn't work. hxxps:// hangs at 'connected', hxxp:// hangs at 'waiting for ...', all speedtests time out, and scp copies just hang. It looks like PMTU discovery is totally broken from the internet, and that's kinda important when tunnelling! Actually, it looks like ALL ICMP to/from the 6rd gateway is filtered...

I can run `ping6 -M do -c1 -s1440 2607:f878::xyz` from inside my network to my dedicated server and it correctly returns:
PING 2607:f878::xyz(2607:f878::xyz) 1440 data bytes
From 2602:306::zzz icmp_seq=1 Packet too big: mtu=1480

But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.

Can anyone using 6rd post a IPv6 speedtest?

/M

Edit: found a ipv6-only site big enough to not load: »ipv6.bjornerback.com/ . I can `wget` it from my server just fine, but nada from AT&T's connection. Does it work for anyone else?

Seems to work just fine from my Linode @ HE.net to U-verse. Perhaps your hoster's routers misbehave?

li16X-XXX:~# ping6 -M do -c4 -s1440 2602:306:37cY:YYY0::
PING 2602:306:37cY:YYY0::(2602:306:37cY:YYY0::) 1440 data bytes
From 2602:300:c533:1510::6 icmp_seq=1 Packet too big: mtu=1480
From 2600:3c01:e001:: icmp_seq=2 Packet too big: mtu=1480
From 2600:3c01:e001:: icmp_seq=2 Packet too big: mtu=1480
From 2600:3c01:e001:: icmp_seq=2 Packet too big: mtu=1480
 
--- 2602:306:37cY:YYY0:: ping statistics ---
1 packets transmitted, 0 received, +4 errors, 100% packet loss, time 1022ms
 
li16X-XXX:~# mtr -c60 --report{,-wide} 2602:306:37cY:YYY0:: ; date
HOST: li16X-XXX                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 2600:3c01:ffff:0:ca4c:75ff:fef5:d63f                         0.0%    60    0.9   1.2   0.5  23.6   3.0
  2. 10gigabitethernet2-3.core1.fmt1.he.net                       0.0%    60   10.7   6.4   0.4  56.4   9.0
  3. 10gigabitethernet7-3.core1.fmt2.he.net                       0.0%    60    0.5   3.1   0.4  11.5   4.0
  4. 10gigabitethernet6-4.core1.lax1.he.net                       0.0%    60    8.6  10.6   8.5  19.2   3.5
  5. 10gigabitethernet1-3.core1.lax2.he.net                       1.7%    60   14.6  11.7   8.5  19.4   3.5
  6. att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net  0.0%    60    9.0  12.5   8.8  55.9  10.8
  7. ???                                                         100.0    60    0.0   0.0   0.0   0.0   0.0
  8. 2001:1890:ff:ffff:12:122:85:37                               0.0%    60   10.7  12.7  10.5  77.0  10.7
  9. 2602:300:c533:1510::7                                        0.0%    60   10.5  10.5  10.4  11.0   0.1
 10. 2602:300:c533:1510::5                                        0.0%    60   22.8  23.0  22.7  29.0   0.8
 11. 2602:300:c533:1510::5                                       98.3%    60   23.7  23.7  23.7  23.7   0.0
 12. 2602:300:c533:1510::6                                       76.7%    60   23.9  24.9  23.7  27.8   1.6
 13. 2602:300:c533:1510::6                                       96.7%    60   23.5  23.6  23.5  23.7   0.1
 14. 2602:300:c533:1510::6                                       95.0%    60   23.5  23.7  23.3  24.2   0.5
 15. 2602:300:c533:1510::5                                        0.0%    60   23.7  23.9  23.6  24.8   0.2
 16. 2602:306:37cY:YYY0::                                         0.0%    60   23.9  23.9  23.7  24.2   0.1
Sat Mar 24 22:53:36 PDT 2012
li16X-XXX:~# 
 

Also, haven't had any problems with the aforementioned web-site, either.


mackey

join:2007-08-20
kudos:6

1 edit

said by ConstantineM:

Seems to work just fine from my Linode @ HE.net to U-verse. Perhaps your hoster's routers misbehave?

Possible, but I don't think so. I clearly get into AT&T's network before it dies. Also, your traceroute shows that you're going through different routers then I am.

First up, a normal, working traceroute:
traceroute to 2602:306:ce8a:YYY0::1 (2602:306:ce8a:YYY0::1), 30 hops max, 80 byte packets
 1  2607:f878:XYZ::1 (2607:f878:XYZ::1)  4.212 ms  4.559 ms  4.740 ms
 2  ec0-49.agg04.sctn01.hostnoc.net (2607:f878::1ec)  2.848 ms  3.057 ms  3.046 ms
 3  xe1-04.gwy02.sctn01.hostnoc.net (2607:f878::114)  3.032 ms  3.063 ms  3.278 ms
 4  10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1)  34.287 ms  34.275 ms  34.259 ms
 5  10gigabitethernet1-2.core1.nyc4.he.net (2001:470:0:36::2)  39.972 ms  39.856 ms  39.938 ms
 6  as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2)  17.521 ms  14.819 ms  14.698 ms
 7  cr1.n54ny.ip.att.net (::ffff:12.122.81.106)  39.124 ms  39.109 ms  39.072 ms
 8  cr2.cgcil.ip.att.net (::ffff:12.122.1.2)  36.626 ms  40.465 ms  55.627 ms
 9  2001:1890:ff:ffff:12:122:99:125 (2001:1890:ff:ffff:12:122:99:125)  43.729 ms  43.711 ms  43.787 ms
10  2602:300:c533:1510::4 (2602:300:c533:1510::4)  43.666 ms  52.258 ms  52.240 ms
11  2602:300:c533:1510::8 (2602:300:c533:1510::8)  104.807 ms  104.810 ms  104.682 ms
12  * * *
13  * * *
14  2602:300:c533:1510::8 (2602:300:c533:1510::8)  93.236 ms  92.806 ms  93.359 ms
15  2602:300:c533:1510::8 (2602:300:c533:1510::8)  101.654 ms  100.569 ms  107.818 ms
16  2602:306:ce8a:YYY0::1 (2602:306:ce8a:YYY0::1)  107.791 ms  107.778 ms  107.654 ms
 

Tonight it seems I'm not getting ANY 'Packet too big' responses with the ping -s 1440 command:
ping6 -c10 -s 1440 2602:306:ce8a:YYY0::1
PING 2602:306:ce8a:YYY0::1(2602:306:ce8a:YYY0::1) 1440 data bytes
 
--- 2602:306:ce8a:YYY0::1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 18999ms
 
ping6 -c20 -s 1440 2602:306:ce8a:YYY0::1
PING 2602:306:ce8a:YYY0::1(2602:306:ce8a:YYY0::1) 1440 data bytes
 
--- 2602:306:ce8a:YYY0::1 ping statistics ---
20 packets transmitted, 0 received, 100% packet loss, time 28999ms
 

Let's see what traceroute's --mtu option gives us:
traceroute --mtu 2602:306:ce8a:YYY0::1
traceroute to 2602:306:ce8a:YYY0::1 (2602:306:ce8a:YYY0::1), 30 hops max, 65000 byte packets
 1  2607:f878:XYZ::1 (2607:f878:XYZ::1)  1.173 ms F=1500  1.434 ms  1.148 ms
 2  ec0-49.agg04.sctn01.hostnoc.net (2607:f878::1ec)  15.117 ms  18.470 ms  2.233 ms
 3  xe1-04.gwy02.sctn01.hostnoc.net (2607:f878::114)  1.643 ms  1.632 ms  1.516 ms
 4  10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1)  39.799 ms  30.858 ms  40.244 ms
 5  10gigabitethernet1-2.core1.nyc4.he.net (2001:470:0:36::2)  38.096 ms  38.237 ms  30.844 ms
 6  as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2)  12.885 ms  12.728 ms  13.088 ms
 7  cr1.n54ny.ip.att.net (::ffff:12.122.81.106)  38.688 ms  37.227 ms  35.391 ms
 8  cr2.cgcil.ip.att.net (::ffff:12.122.1.2)  37.070 ms  36.266 ms  35.698 ms
 9  2001:1890:ff:ffff:12:122:99:125 (2001:1890:ff:ffff:12:122:99:125)  34.288 ms  41.003 ms  33.794 ms
10  2602:300:c533:1510::4 (2602:300:c533:1510::4)  32.461 ms F=1492  32.784 ms  32.748 ms
11  2602:300:c533:1510::8 (2602:300:c533:1510::8)  91.307 ms  92.173 ms  97.795 ms
12  * * *
13  * * *
14  2602:300:c533:1510::8 (2602:300:c533:1510::8)  93.611 ms  93.414 ms  99.386 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
 
Hmmmm, hop 10 (which is inside AT&T's network) drops the MTU to 1492, but whichever router drops it to 1480 can't be bothered to tell us :'( Looking at the previous traceroute, it seems to be the 5th ::8 hop.

My mtr run:
mtr -c60 --report{,-wide} 2602:306:ce8a:YYY0::1 ; date
HOST: <snip>                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 2607:f878:XYZ::1                                   0.0%    60    2.0   2.5   0.8  13.3   3.5
  2. ec0-49.agg04.sctn01.hostnoc.net                    0.0%    60    0.8   2.5   0.7  77.9  10.0
  3. xe1-04.gwy02.sctn01.hostnoc.net                    0.0%    60    2.5  11.0   0.7 158.0  24.9
  4. 10gigabitethernet2-2.core1.ash1.he.net             0.0%    60   30.0  34.7  29.9  57.1   5.5
  5. 10gigabitethernet1-2.core1.nyc4.he.net             0.0%    60   36.8  32.0  29.4  40.8   3.4
  6. as7018-att.10gigabitethernet2-3.core1.nyc4.he.net  0.0%    60   16.6  24.8  11.2 131.0  27.6
  7. cr1.n54ny.ip.att.net                               0.0%    60   37.9  38.5  34.7  83.6   6.5
  8. cr2.cgcil.ip.att.net                               0.0%    60   37.1  37.9  33.3  56.8   4.3
  9. 2001:1890:ff:ffff:12:122:99:125                    1.7%    60   33.4  34.3  32.9  52.2   2.9
 10. 2602:300:c533:1510::4                              0.0%    60   31.8  32.7  31.4  48.2   3.0
 11. 2602:300:c533:1510::8                              5.0%    60   91.5  94.2  90.0 150.6   8.9
 12. 2602:300:c533:1510::8                             95.0%    60   94.0  92.6  91.6  94.0   1.2
 13. 2602:300:c533:1510::8                             88.3%    60   91.6  91.7  91.0  92.2   0.4
 14. 2602:300:c533:1510::8                             80.0%    60   93.3  93.7  93.0  97.4   1.2
 15. 2602:300:c533:1510::8                              3.3%    60  107.6 102.0  97.8 139.4   8.3
 16. 2602:306:ce8a:YYY0::1                              1.7%    60   98.0 101.3  97.6 143.1   7.2
Sun Mar 25 08:44:02 EDT 2012
 

And just for grins and giggles, one more traceroute with a few other options:
traceroute -q6 -A -T 2602:306:ce8a:YYY0::1
traceroute to 2602:306:ce8a:YYY0::1 (2602:306:ce8a:YYY0::1), 30 hops max, 80 byte packets
 1  2607:f878:XYZ::1 (2607:f878:1:a6a::1) [AS21788]  1.416 ms  1.828 ms  2.125 ms  2.403 ms  2.669 ms  2.956 ms
 2  ec0-49.agg04.sctn01.hostnoc.net (2607:f878::1ec) [AS21788]  3.224 ms  3.219 ms  3.211 ms  3.250 ms  3.244 ms  3.236 ms
 3  xe1-04.gwy02.sctn01.hostnoc.net (2607:f878::114) [AS21788]  3.112 ms  3.106 ms  3.146 ms  3.186 ms  0.879 ms  0.846 ms
 4  10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) [*]  36.937 ms  30.435 ms  30.410 ms  30.481 ms  36.825 ms  30.432 ms
 5  10gigabitethernet1-2.core1.nyc4.he.net (2001:470:0:36::2) [AS6939]  31.804 ms  34.790 ms  31.850 ms  34.734 ms  34.706 ms  31.669 ms
 6  as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2) [AS6939]  11.220 ms  11.982 ms  12.214 ms  12.020 ms  11.896 ms  11.218 ms
 7  cr1.n54ny.ip.att.net (::ffff:12.122.81.106) [*]  39.421 ms  39.396 ms  39.369 ms  36.917 ms  36.253 ms  38.947 ms
 8  cr2.cgcil.ip.att.net (::ffff:12.122.1.2) [*]  38.308 ms  38.281 ms  35.124 ms  35.097 ms  37.698 ms  37.668 ms
 9  2001:1890:ff:ffff:12:122:99:125 (2001:1890:ff:ffff:12:122:99:125) [AS7018]  33.548 ms  33.825 ms  33.702 ms  33.667 ms  33.743 ms  33.596 ms
10  2602:300:c533:1510::4 (2602:300:c533:1510::4) [AS7018]  31.663 ms  31.733 ms  31.607 ms  31.576 ms  32.087 ms  32.062 ms
11  2602:300:c533:1510::8 (2602:300:c533:1510::8) [AS7018]  90.611 ms  91.546 ms  91.695 ms  91.485 ms  91.451 ms *
12  * * * * * *
13  * * * * * *
14  * * * * * *
15  2602:300:c533:1510::8 (2602:300:c533:1510::8) [AS7018]  101.548 ms  101.528 ms  107.395 ms  107.389 ms  107.375 ms  107.395 ms
16  2602:306:ce8a:YYY0::1 (2602:306:ce8a:YYY0::1) [AS7018]  115.127 ms !X  115.236 ms !X  127.043 ms !X  107.334 ms !X  108.712 ms !X  126.996 ms !X
 

Edit:
I just ran the ping -s1440 command 2 more times. This time the router got back to me on the 11th and 59th packets:
ping6 -c100 -s 1440 2602:306:ce8a:YYY0::1
PING 2602:306:ce8a:YYY0::1(2602:306:ce8a:YYY0::1) 1440 data bytes
From 2602:300:c533:1510::8 icmp_seq=11 Packet too big: mtu=1480
 

ping6 -c100 -s 1440 -M do 2602:306:ce8a:YYY0::2
PING 2602:306:ce8a:YYY0::2(2602:306:ce8a:YYY0::2) 1440 data bytes
From 2602:300:c533:1510::8 icmp_seq=59 Packet too big: mtu=1480
From 2607:f878:XYZ::190 icmp_seq=60 Packet too big: mtu=1480
From 2607:f878:XYZ::190 icmp_seq=60 Packet too big: mtu=1480
From 2607:f878:XYZ::190 icmp_seq=60 Packet too big: mtu=1480
 
--- 2602:306:ce8a:YYY0::2 ping statistics ---
59 packets transmitted, 0 received, +100 errors, 100% packet loss, time 59999ms
 

/M

ConstantineM

join:2011-09-02
San Jose, CA

1 recommendation

6rdBR — 2602:300:c533:1510::/60 (12.83.49.81)

Yeah, that 1492 mtu is kinda strange, I also seem to be getting similar results — the first 2602:300:c533:1510::/60 (12.83.49.81) IPv6 6rd hop also reports 1492, only the last one drops the mtu to 1480. Since, supposedly, all IPv6 traffic within 6rd should be limited to 1480 anyways, it really seemingly makes little sense to not drop mtu to 1480 right when the packet reaches the first at&t 6rdBR anycast (2602:300:c533:1510::/60).

Also, it's really annoying to be seeing all these 2602:300:c533:1510::/60 routers that have repeating and even looping-around addresses, WTF? Those also being rate-limited for ping is also obviously very annoying, as per usual.

li16X-XXX:~> traceroute6 --mtu 2602:306:37cY:YYY0::;date
traceroute to 2602:306:37cY:YYY0:: (2602:306:37cY:YYY0::), 30 hops max, 65000 byte packets
 1  2600:3c01:ffff:0:ca4c:75ff:fef5:d63f (2600:3c01:ffff:0:ca4c:75ff:fef5:d63f)  1.758 ms F=1500  0.740 ms  0.509 ms
 2  10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1)  0.484 ms  0.424 ms  0.366 ms
 3  10gigabitethernet7-3.core1.fmt2.he.net (2001:470:0:2d::2)  61.999 ms  1.982 ms  1.048 ms
 4  10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2)  8.568 ms  12.338 ms  8.537 ms
 5  10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2)  9.073 ms  8.807 ms  9.691 ms
 6  att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2)  9.329 ms  9.275 ms  9.288 ms
 7  * * *
 8  2001:1890:ff:ffff:12:122:85:37 (2001:1890:ff:ffff:12:122:85:37)  10.883 ms  10.364 ms  10.404 ms
 9  2602:300:c533:1510::7 (2602:300:c533:1510::7)  10.540 ms F=1492  10.434 ms  10.493 ms
10  2602:300:c533:1510::5 (2602:300:c533:1510::5)  23.072 ms  22.812 ms  22.765 ms
11  * * *
12  2602:300:c533:1510::6 (2602:300:c533:1510::6)  23.407 ms  23.060 ms  23.804 ms
13  * * *
14  * * 2602:300:c533:1510::6 (2602:300:c533:1510::6)  23.813 ms
15  2602:300:c533:1510::5 (2602:300:c533:1510::5)  25.287 ms F=1480  25.370 ms  25.570 ms
16  2602:306:37cY:YYY0:: (2602:306:37cY:YYY0::)  27.661 ms  27.499 ms  27.512 ms
Sun Mar 25 10:04:30 PDT 2012
 

So, oh well, 6rd MTU works for me, perhaps because 6rd is unsupported on my connection. ;-)

As for you, since 6rd is actually officially enabled (&supported?) for your connection, and, to the contrary of it being enabled/supported, it doesn't actually seem to be working properly for you (make sure you check this is reproducible with 6rd on Motorola), I would highly advise you to get in touch with some higher-tier at&t engineers to address this problem (don't forget to ask them about all those looping-around 6rdBR's in traceroute6's back to at&t). The last thing we want to have on 2012-06-06 is for at&t's 6rd to be broken for all those people for whom it is actually enabled by default and without their knowledge.

One can only wish at&t had a useful site about their IPv6 deployments…


mackey

join:2007-08-20
kudos:6

said by ConstantineM:

So, oh well, 6rd MTU works for me, perhaps because 6rd is unsupported on my connection. ;-)

As for you, since 6rd is actually officially enabled (&supported?) for your connection, and, to the contrary of it being enabled/supported, it doesn't actually seem to be working properly for you (make sure you check this is reproducible with 6rd on Motorola), I would highly advise you to get in touch with some higher-tier at&t engineers to address this problem (don't forget to ask them about all those looping-around 6rdBR's in traceroute6's back to at&t). The last thing we want to have on 2012-06-06 is for at&t's 6rd to be broken for all those people for whom it is actually enabled by default and without their knowledge.

One can only wish at&t had a useful site about their IPv6 deployments…

That's probably it actually :lol:

I just reached around and plucked out a random number and came up with 199. Adding that to your prefix gives 99.124.199.199 . All my `ping -s1440` and `traceroute --mtu` tries to variations of 2602:306:37cc:7c70:: from my dedicated box are successful, immediately returning 'Packet too big: mtu=1480' on the first packet.
ping6 -c1 -s1440 2602:306:37cc:7c70::
PING 2602:306:37cc:7c70::(2602:306:37cc:7c70::) 1440 data bytes
From 2602:300:c533:1510::8 icmp_seq=1 Packet too big: mtu=1480
 
--- 2602:306:37cc:7c70:: ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 96ms
 

All ping attempts to my address are still failing of course :-/

Any idea on how to get ahold of these AT&T engineers?

/M

ConstantineM

join:2011-09-02
San Jose, CA

said by mackey:

I just reached around and plucked out a random number and came up with 199. Adding that to your prefix gives 99.124.199.199 . All my `ping -s1440` and `traceroute --mtu` tries to variations of 2602:306:37cc:7c70:: from my dedicated box are successful, immediately returning 'Packet too big: mtu=1480' on the first packet.

ping6 -c1 -s1440 2602:306:37cc:7c70::
PING 2602:306:37cc:7c70::(2602:306:37cc:7c70::) 1440 data bytes
From 2602:300:c533:1510::8 icmp_seq=1 Packet too big: mtu=1480
 
--- 2602:306:37cc:7c70:: ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 96ms
 

All ping attempts to my address are still failing of course :-/

Dunno, seems kinda random: I've tried pinging this random IPv6 address, and at first it didn't work. But then traceroute with --mtu did work as supposedly expected. Then after traceroute, ping also worked. However, I'm not a networks engineer, so I only have a vague clue on the effects here.

li1XX-XXX:~# ping6 -M do -c4 -s1440 2602:306:37cc:7c70::
PING 2602:306:37cc:7c70::(2602:306:37cc:7c70::) 1440 data bytes
^C
--- 2602:306:37cc:7c70:: ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
 
li1XX-XXX:~# traceroute6 --mtu 2602:306:37cc:7c70::
traceroute to 2602:306:37cc:7c70:: (2602:306:37cc:7c70::), 30 hops max, 65000 byte packets
 1  2600:3c01:ffff:0:ca4c:75ff:fef5:d63f (2600:3c01:ffff:0:ca4c:75ff:fef5:d63f)  0.533 ms F=1500  1.583 ms  0.559 ms
 2  10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1)  0.475 ms  0.784 ms  0.438 ms
 3  10gigabitethernet7-3.core1.fmt2.he.net (2001:470:0:2d::2)  0.453 ms  0.455 ms  12.179 ms
 4  10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2)  17.076 ms  14.825 ms  8.518 ms
 5  10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2)  8.654 ms  11.234 ms  8.580 ms
 6  att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2)  44.919 ms  88.465 ms  79.893 ms
 7  * * *
 8  2001:1890:ff:ffff:12:122:85:37 (2001:1890:ff:ffff:12:122:85:37)  10.567 ms  10.751 ms  10.549 ms
 9  2602:300:c533:1510::7 (2602:300:c533:1510::7)  10.716 ms F=1492  10.470 ms  10.451 ms
10  * * *
11  * * *
12  2602:300:c533:1510::7 (2602:300:c533:1510::7)  12.463 ms  12.243 ms  12.392 ms
13  * F=1480 * *
14  * * *
15  * *^C
li1XX-XXX:~# ping6 -M do -c4 -s1440 2602:306:37cc:7c70::
PING 2602:306:37cc:7c70::(2602:306:37cc:7c70::) 1440 data bytes
From 2600:3c01:e001:: icmp_seq=1 Packet too big: mtu=1480
From 2600:3c01:e001:: icmp_seq=1 Packet too big: mtu=1480
From 2600:3c01:e001:: icmp_seq=1 Packet too big: mtu=1480
From 2600:3c01:e001:: icmp_seq=1 Packet too big: mtu=1480
 
--- 2602:306:37cc:7c70:: ping statistics ---
0 packets transmitted, 0 received, +4 errors
 
li1XX-XXX:~# 
 

said by mackey:

Any idea on how to get ahold of these AT&T engineers?

Try calling the usual number and ask to speak with their level two tech support regarding your modem's 6rd not working properly?

As discussed privately, however, it does seem like I do get the correct "Packet too big" when pinging your IPv6 addresses, so the whole ordeal may be a bit random after all. However, I'm still a little unclear as to what specific applications of yours are affected? How could you have the nearly perfect speed tests, yet a single random IPv6 web-site doesn't work just for you?


mackey

join:2007-08-20
kudos:6

said by ConstantineM:

Dunno, seems kinda random: I've tried pinging this random IPv6 address, and at first it didn't work. But then traceroute with --mtu did work as supposedly expected. Then after traceroute, ping also worked. However, I'm not a networks engineer, so I only have a vague clue on the effects here.

It depends on what your definition of "worked" is. The first time you ran 'ping' does show some packet loss (at least 1 packet, may or may not be 2 depending on when it was ^C'd). It did respond to at least one of the traceroute packets, which the kernel cached allowing the 2nd 'ping' to "work."

I don't think there's actually a computer at that address. The tunnel gateway and intermediate routers don't know or care however and thus forward all traffic for it on to the next router. We don't care if it's there or not as it's the tunnel gateway we're testing - host up or not, it should still throw the 'packet too big' error.

said by ConstantineM:

However, I'm still a little unclear as to what specific applications of yours are affected? How could you have the nearly perfect speed tests, yet a single random IPv6 web-site doesn't work just for you?

That single random web-site DOES work, as does the speed test site, if I hack my network. If I undo the hack, the speed test will not even load. The hack is only good for TCP however, so anything that uses ICMP or UDP (VoIP, probably some games, etc) will still fail if they try to send a big packet.

/M

ConstantineM

join:2011-09-02
San Jose, CA

6rd mtu

It does seem fishy, but I'm not convinced (yet?) that setting mtu to 1480 on the default inet6 route (through 6rd) on the device doing 6rd is a hack. This hardly precludes you from having 1500 mtu on your local inet6 network. In fact, I think that's what your 6rd software is supposed to be doing anyways.

I've tried doing pings from my OS X to the internet with `ping6 -s1500` and above, and it all just works after several initial failures; of course, there's fragmentation going on, but it does work at the end of the day; it also seems that the mtu setting on the gif0 interface has not much effect — I've set it to 1500 and above, and IPv6 still works, all speed tests and such.



mackey

join:2007-08-20
kudos:6

said by ConstantineM:

It does seem fishy, but I'm not convinced (yet?) that setting mtu to 1480 on the default inet6 route (through 6rd) on the device doing 6rd is a hack. This hardly precludes you from having 1500 mtu on your local inet6 network. In fact, I think that's what your 6rd software is supposed to be doing anyways.

That's not the hack. Of course the device doing the 6rd tunnelling is going to have a mtu of 1480. The hack is forcing radvd to tell every computer on my network that the mtu for the local network is 1480. This in turn forces the operating system to set the TCP MSS to 1420 (instead of the 1440 used when the mtu is 1500) for ALL connections, even ones that stay on the local network. Even if the computers find out later that the MTU/MSS is much lower then initially thought, it's too late as the MSS is only negotiated on the very first SYN sent to set up the connection. Once the connection is established it's too late to change it.

OUTGOING pings/transfers work just fine as my local router correctly generates the packet-too-big responses. It's the far end trying to send a large reply which hangs and times out when AT&T's router doesn't send the packet-too-big response.

/M

EZJohnson

join:2004-02-11

I was able to fix most of my MTU path discovery issues (at least for tcp) by running this on all my ipv6 client devices:

ip -6 route change default via $(ip -6 route show default |cut -d " " -f 3) dev eth0 mtu 1480 advmss 1420



mackey

join:2007-08-20
kudos:6

1 edit

said by EZJohnson:

I was able to fix most of my MTU path discovery issues (at least for tcp) by running this on all my ipv6 client devices:

ip -6 route change default via $(ip -6 route show default |cut -d " " -f 3) dev eth0 mtu 1480 advmss 1420

I just changed radvd.conf and told it to advertise 1480 - problem solved for ALL devices! Though the intranet MTU is also limited to 1480...

Edit: removed dumb question

/M