Mailing List Archive

I have encountered this problem before, however www.python.org works
fine on ipv6 for me. Many cases where things fail is because DNS
resolves the AAAA record, but the ISP/upstream providers don't have IPv6
connectivity to the site.

Can you post a traceroute -6 www.python.org ?

Regards,

Tom


gummay@gummay ~ $ traceroute -6 www.python.org
traceroute to www.python.org (2001:888:2000:d::a2), 30 hops max, 80 byte
packets
1 2001:44b8:62:120::1 (2001:44b8:62:120::1) 0.545 ms 0.534 ms 0.665 ms
2 2001:44b8:61::38 (2001:44b8:61::38) 41.691 ms 44.181 ms 45.319 ms
3 vl67.cor1.adl6.internode.on.net (2001:44b8:8060:8000::1) 46.238 ms
48.241 ms 49.140 ms
4 gi0-0.bdr1.adl6.internode.on.net (2001:44b8:8060:14::1) 50.099 ms * *
5 pos3-1.cor1.per1.internode.on.net (2001:44b8:8060:17::1) 85.518 ms
86.254 ms 87.498 ms
6 pos1-0.bdr1.sin1.internode.on.net (2001:44b8:f0c0:1::1) 136.581 ms
134.181 ms 136.971 ms
7 pos2-0.bdr1.hkg1.internode.on.net (2001:44b8:f0c0:2::1) 173.361 ms
146.103 ms 146.240 ms
8 2001:7fa:0:1::ca28:a116 (2001:7fa:0:1::ca28:a116) 150.657 ms
152.182 ms 153.212 ms
9 so-3-0-0-bcr1.tok.cw.net (2001:5000:0:12b::1) 229.245 ms 228.674
ms 230.268 ms
10 so-6-0-0-ecr1.sfo.cw.net (2001:5000:0:c2::1) 295.898 ms 297.402 ms
299.065 ms
11 so-4-2-0-dcr1.nyk.cw.net (2001:5000:0:2f::1) 362.469 ms 364.008 ms
338.077 ms
12 xe-0-0-0.xcr1.nyk.cw.net (2001:5000:0:112::1) 319.072 ms 318.671
ms xe-7-2-0.xcr1.nyk.cw.net (2001:5000:0:14b::2) 350.301 ms
13 xe-7-0-0.xcr1.lsw.cw.net (2001:5000:0:149::2) 426.384 ms 426.860
ms 425.766 ms
14 xe-11-2-0.xcr1.amd.cw.net (2001:5000:0:130::2) 436.763 ms
xe-11-1-0.xcr1.amd.cw.net (2001:5000:0:12f::2) 438.084 ms
xe-11-2-0.xcr1.amd.cw.net (2001:5000:0:130::2) 435.584 ms
15 xe-0-1-0.xcr1.amd.cw.net (2001:5000:0:11d::1) 427.150 ms
xe-0-2-0.xcr1.amd.cw.net (2001:5000:0:11e::1) 426.011 ms 403.879 ms
16 ge-6-0-0.dcr1.fra.cw.net (2001:5000:0:10d::2) 475.073 ms
ge-2-0-0.dcr1.fra.cw.net (2001:5000:0:10e::2) 468.561 ms 437.742 ms
17 so-3-0-0-zcr2.muc.cw.net (2001:5000:0:cd::2) 443.292 ms 444.370 ms
so-5-0-0-zcr2.muc.cw.net (2001:5000:0:63::2) 443.197 ms
18 ge-1-0-0-200-gar1.muc.cw.net (2001:5000:0:4::5) 444.125 ms 442.912
ms ge-0-0-0-100-gar1.muc.cw.net (2001:5000:0:3::5) 444.174 ms
19 mchn-s2-rou-1030.DE.eurorings.net (2001:5001:100:15::2) 424.237 ms
424.956 ms 425.794 ms
20 asd2-rou-1030.eurorings.net (2001:680::134:222:86:48) 448.829 ms
448.465 ms 448.624 ms
21 2001:680:0:800f::32 (2001:680:0:800f::32) 454.279 ms 453.855 ms
449.562 ms
22 te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2) 424.238 ms
434.206 ms 430.882 ms
23 vlan5.swcolo2.3d12.xs4all.net (2001:888:0:3101::2) 567.259 ms
563.464 ms 551.640 ms
24 dinsdale.python.org (2001:888:2000:d::a2) 461.020 ms 460.998 ms
501.074 ms


Lindsay Haisley wrote:
> I'm having some problems reaching *.python.org with web browers here,
> and the problem appears to be related to ipv6 issues. My desktop system
> is connected to a Linux router which has an assigned /64 v6 block from
> freenet6. Firefox defaults to using ipv6 if there's an AAAA record for
> an address. This isn't a problem in most cases.
>
> If I access most v6 enabled web servers, e.g. www.kame.net or
> testmyipv6.com with firefox, no problem. I get back a page indicating
> that I"ve made a v6 connection to the web server. www.python.org also
> resolves with an aaaa record (2001:888:2000:d::a2), and I can ping6 the
> server, so I know that routing is OK. I can't, however, get a response
> from the server with a firefox, which just blocks trying to retrieve a
> page.
>
> If I disable the v6 address on the net IF on my desktop, firefox uses a
> v4 connection immediately and the connection is OK, same for lynx. But
> if the IF has a global v6 address both lynx and firefox block.
>
> My immediate guess was that www.python.org is running a v6 enabled box
> and has v6 routing to it, but that the web server there isn't v6
> enabled. This still may be the case, however I _can_ use (v6-enabled)
> lynx to get to the box from my router, and either something very strange
> is going on, or the fallback to v4 algorithm for lynx on the router is
> different from that on my desktop system. If I emerge lynx with
> USE="-ipv6" on my desktop system I have no trouble getting to
> www.python.org from that system with lynx.
>

On Sat, 2009-05-16 at 13:07 +1000, Tom Fifield wrote:
> I have encountered this problem before, however www.python.org works
> fine on ipv6 for me. Many cases where things fail is because DNS
> resolves the AAAA record, but the ISP/upstream providers don't have IPv6
> connectivity to the site.

I'm using a v6->v4 tunnel broker so my ISP is out the loop, what's more,
as I said,

> www.python.org also
> resolves with an aaaa record (2001:888:2000:d::a2), and I can ping6
> the server, so I know that routing is OK.

It looks as if the problem may be related to MTUs. I did a bit of
jiggery-pokery with MTUs, setting the MTU for the IF on my desktop
system slightly lower than the MTU on the LAN IF of my router, and it
appears that the problem is solved for now, at least.

I've seen network problems before with MTU issues, especially where UDP
packets are involved, as they may be with the tunnel broker.

--
Lindsay Haisley | "In an open world, | PGP public key
FMP Computer Services | who needs Windows | available at
512-259-1190 | or Gates" | http://pubkeys.fmp.com
http://www.fmp.com | |

My apologies for not reading your post carefully.

I see an MTU of 1280 to www.python.org at my end - ipv6 tun device on my
router is set to this, so I think it can deal with the 1500 MTU on my
local machine's interface. Nice spotting :)


Regards,

Tom

gummay ~ # tracepath6 www.python.org
1?: [LOCALHOST] pmtu 1500
1: 2001:44b8:62:120::1 0.695ms
1: 2001:44b8:62:120::1 0.630ms
2: 2001:44b8:62:120::1 0.691ms pmtu 1280
*snip*
24: dinsdale.python.org 460.627ms reached
Resume: pmtu 1280 hops 24 back 51




Lindsay Haisley wrote:
> On Sat, 2009-05-16 at 13:07 +1000, Tom Fifield wrote:
>> I have encountered this problem before, however www.python.org works
>> fine on ipv6 for me. Many cases where things fail is because DNS
>> resolves the AAAA record, but the ISP/upstream providers don't have IPv6
>> connectivity to the site.
>
> I'm using a v6->v4 tunnel broker so my ISP is out the loop, what's more,
> as I said,
>
>> www.python.org also
>> resolves with an aaaa record (2001:888:2000:d::a2), and I can ping6
>> the server, so I know that routing is OK.
>
> It looks as if the problem may be related to MTUs. I did a bit of
> jiggery-pokery with MTUs, setting the MTU for the IF on my desktop
> system slightly lower than the MTU on the LAN IF of my router, and it
> appears that the problem is solved for now, at least.
>
> I've seen network problems before with MTU issues, especially where UDP
> packets are involved, as they may be with the tunnel broker.
>

Lindsay Haisley <fmouse-gentoo@fmp.com> posted
1242442935.27501.113.camel@vishnu.fmp.com, excerpted below, on Fri, 15
May 2009 22:02:15 -0500:

> I'm having some problems reaching *.python.org with web browers here,
> and the problem appears to be related to ipv6 issues. My desktop system
> is connected to a Linux router which has an assigned /64 v6 block from
> freenet6. Firefox defaults to using ipv6 if there's an AAAA record for
> an address. This isn't a problem in most cases.
>
> If I access most v6 enabled web servers, e.g. www.kame.net or
> testmyipv6.com with firefox, no problem. I get back a page indicating
> that I"ve made a v6 connection to the web server. www.python.org also
> resolves with an aaaa record (2001:888:2000:d::a2), and I can ping6 the
> server, so I know that routing is OK. I can't, however, get a response
> from the server with a firefox, which just blocks trying to retrieve a
> page.

Disclaimer: Note that I'm still entirely IPv4 and the following
suggestions, based on IPv4, simply assume IPv6 versions of the same thing
exist and work similarly.

In addition to Tom's suggestion, I'd add trying a(n IPv6) telnet session
to the web server as well. Very basic, just open the connection, then
type quit if you get one. You can of course do a get, etc, if desired,
but it's often not necessary or helpful. Sometimes the "raw" interface
is helpful at diagnosing errors that get hidden by the fancy browser
interface and that's all it takes. If you get a proper telnet connection
that equally properly quits when told to, you're most of the way there
already.

What about tcptraceroute? The manpages don't seem to indicate
tcptraceroute itself does IPv6, but standard traceroute does with -6, and
has -T to use TCP SYN packets for tracing (with -p to specify port
number). A run using TCP packets on the target port, contrasted with a
normal traceroute run (and contrasted further with a traceroute -I, ICMP
run, if desired), can be VERY helpful. Another nice thing about it is
that it usually allows seeing hops behind firewalls, since they obviously
must allow TCP SYN packets thru to that port or the web server wouldn't
work. If ping and a normal trace (the IPv6 versions in this case) are
getting thru but a tcptraceroute to the assigned port isn't, you know
it's a TCP specific issue and at what layer-4/IP hop it's happening.

mtr is IPv6 enabled (USE flag) and can be helpful for certain diagnostics
as well, altho it tends to be most useful at detecting levels of packet
loss and where, due to its continuous tracing functionality.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Sat, 2009-05-16 at 14:15 +1000, Tom Fifield wrote:
> I see an MTU of 1280 to www.python.org at my end - ipv6 tun device on my
> router is set to this, so I think it can deal with the 1500 MTU on my
> local machine's interface. Nice spotting :)

I set the MTU on the LAN IF of my desktop system to 1400, down from 1500
and everything worked OK. The LAN IF of my router is set to 1500 and
the sit1 v6->v4 IF has an MTU of 1280. The tunnel broker may not be
doing MTU discovery, or something else may be wonky. If it works, don't
fix it :-)

I've seen a similar problem on VPN tunnels using UDP packets.

--
Lindsay Haisley | "It is better to bite | PGP public key
FMP Computer Services | a single cannibal than | available at
512-259-1190 | to curse the doggies" | http://pubkeys.fmp.com
http://www.fmp.com | -- John Day |