Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( This makes accessing it from my desktop very annoying.
$ time wget -4 --quiet http://testbot.winehq.org/ real 0m2.150s user 0m0.000s sys 0m0.000s
$ time wget -6 --quiet http://testbot.winehq.org/ ... still stuck after 6+ minutes
$ telnet -6 testbot.winehq.org Trying 2001:888:2000:38:1000::2... ... same thing
According to http://test-ipv6.com/ my desktop is configured just fine and I only have trouble with the TestBot.
Could this be a firewall problem? (testbot exposing an IPv6 address but the firewall dropping any IPv6 packets)
In the mean time I'm going to use my laptop which is still IPv4 only :-/
On Wed, 14 Sep 2011, Francois Gouget wrote:
Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( This makes accessing it from my desktop very annoying.
Hmm, I guess I really have to use the feedback form on the website :-(
Hey,
On 09/14/2011 12:47 PM, Francois Gouget wrote:
Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( This makes accessing it from my desktop very annoying.
$ time wget -4 --quiet http://testbot.winehq.org/ real 0m2.150s user 0m0.000s sys 0m0.000s
$ time wget -6 --quiet http://testbot.winehq.org/ ... still stuck after 6+ minutes
$ telnet -6 testbot.winehq.org Trying 2001:888:2000:38:1000::2... ... same thing
According to http://test-ipv6.com/ my desktop is configured just fine and I only have trouble with the TestBot.
Could this be a firewall problem? (testbot exposing an IPv6 address but the firewall dropping any IPv6 packets)
In the mean time I'm going to use my laptop which is still IPv4 only :-/
That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping work?
~Maarten
On Thu, 22 Sep 2011, Maarten Lankhorst wrote: [...]
Could this be a firewall problem? (testbot exposing an IPv6 address but the firewall dropping any IPv6 packets)
In the mean time I'm going to use my laptop which is still IPv4 only :-/
That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping work?
Nope: --- $ PING testbot.winehq.org(2001:888:2000:38:1000::2) 56 data bytes --- (no output)
As I said, do you get what you expect if you run ip6tables -L as root on testbot?
On 22/09/2011 6:24 PM, Maarten Lankhorst wrote:
Hey,
On 09/14/2011 12:47 PM, Francois Gouget wrote:
Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( This makes accessing it from my desktop very annoying.
$ time wget -4 --quiet http://testbot.winehq.org/ real 0m2.150s user 0m0.000s sys 0m0.000s
$ time wget -6 --quiet http://testbot.winehq.org/ ... still stuck after 6+ minutes
$ telnet -6 testbot.winehq.org Trying 2001:888:2000:38:1000::2... ... same thing
According to http://test-ipv6.com/ my desktop is configured just fine and I only have trouble with the TestBot.
Could this be a firewall problem? (testbot exposing an IPv6 address but the firewall dropping any IPv6 packets)
In the mean time I'm going to use my laptop which is still IPv4 only :-/
That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping work?
~Maarten
# traceroute -4 -T -p80 testbot.winehq.org traceroute to testbot.winehq.org (82.94.219.252), 30 hops max, 60 byte packets ... 9 te5-4.swcolo1.3d12.xs4all.net (194.109.12.30) 159.889 ms 159.942 ms 159.868 ms 10 v2.gse.nl (82.94.219.252) 161.955 ms 159.354 ms 164.692 ms
# traceroute -6 -T -p80 testbot.winehq.org traceroute to testbot.winehq.org (2001:888:2000:38:1000::2), 30 hops max, 80 byte packets ... 11 te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2) 145.296 ms 145.109 ms 145.817 ms 12 * * * ... 30 * * *
Hey,
On 09/22/2011 11:25 AM, Ben Peddell wrote:
On 22/09/2011 6:24 PM, Maarten Lankhorst wrote:
Hey,
On 09/14/2011 12:47 PM, Francois Gouget wrote:
Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( This makes accessing it from my desktop very annoying.
$ time wget -4 --quiet http://testbot.winehq.org/ real 0m2.150s user 0m0.000s sys 0m0.000s
$ time wget -6 --quiet http://testbot.winehq.org/ ... still stuck after 6+ minutes
$ telnet -6 testbot.winehq.org Trying 2001:888:2000:38:1000::2... ... same thing
According to http://test-ipv6.com/ my desktop is configured just fine and I only have trouble with the TestBot.
Could this be a firewall problem? (testbot exposing an IPv6 address but the firewall dropping any IPv6 packets)
In the mean time I'm going to use my laptop which is still IPv4 only :-/
That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping work?
~Maarten
# traceroute -4 -T -p80 testbot.winehq.org traceroute to testbot.winehq.org (82.94.219.252), 30 hops max, 60 byte packets ... 9 te5-4.swcolo1.3d12.xs4all.net (194.109.12.30) 159.889 ms 159.942 ms 159.868 ms 10 v2.gse.nl (82.94.219.252) 161.955 ms 159.354 ms 164.692 ms
# traceroute -6 -T -p80 testbot.winehq.org traceroute to testbot.winehq.org (2001:888:2000:38:1000::2), 30 hops max, 80 byte packets ... 11 te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2) 145.296 ms 145.109 ms 145.817 ms 12 * * * ... 30 * * *
Testbot has 2 ips assigned to it:
inet6 addr: 2001:888:2000:38:1000::1/66 Scope:Global inet6 addr: 2001:888:2000:38:1000::2/66 Scope:Global
Does the ::1 work?
~Maarten
Maarten Lankhorst wrote:
Hey,
On 09/22/2011 11:25 AM, Ben Peddell wrote:
On 22/09/2011 6:24 PM, Maarten Lankhorst wrote:
Hey,
On 09/14/2011 12:47 PM, Francois Gouget wrote:
Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( This makes accessing it from my desktop very annoying.
$ time wget -4 --quiet http://testbot.winehq.org/ real 0m2.150s user 0m0.000s sys 0m0.000s
$ time wget -6 --quiet http://testbot.winehq.org/ ... still stuck after 6+ minutes
$ telnet -6 testbot.winehq.org Trying 2001:888:2000:38:1000::2... ... same thing
According to http://test-ipv6.com/ my desktop is configured just fine and I only have trouble with the TestBot.
Could this be a firewall problem? (testbot exposing an IPv6 address but the firewall dropping any IPv6 packets)
In the mean time I'm going to use my laptop which is still IPv4 only :-/
That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping work?
~Maarten
# traceroute -4 -T -p80 testbot.winehq.org traceroute to testbot.winehq.org (82.94.219.252), 30 hops max, 60 byte packets ... 9 te5-4.swcolo1.3d12.xs4all.net (194.109.12.30) 159.889 ms 159.942 ms 159.868 ms 10 v2.gse.nl (82.94.219.252) 161.955 ms 159.354 ms 164.692 ms
# traceroute -6 -T -p80 testbot.winehq.org traceroute to testbot.winehq.org (2001:888:2000:38:1000::2), 30 hops max, 80 byte packets ... 11 te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2) 145.296 ms 145.109 ms 145.817 ms 12 * * * ... 30 * * *
Testbot has 2 ips assigned to it:
inet6 addr: 2001:888:2000:38:1000::1/66 Scope:Global inet6 addr: 2001:888:2000:38:1000::2/66 Scope:Global
Wow! /66? And that works? While the standard allows for that you "should use /64" which everybody and his dog read it as that is the only thing that needs to work and the only thing that get tested. IPv6 brings back the class-full thinking which everybody has to painfully unlearn once IPv6 catches on...
"Safe" prefix length (especially if involving client devices) are: /64 - LAN /126 and /127 - point to point /128 - host routes
bye michael
22 sep 2011 kl. 12:14 skrev Michael Stefaniuc:
Wow! /66? And that works? While the standard allows for that you "should use /64" which everybody and his dog read it as that is the only thing that needs to work and the only thing that get tested. IPv6 brings back the class-full thinking which everybody has to painfully unlearn once IPv6 catches on...
"Safe" prefix length (especially if involving client devices) are: /64 - LAN /126 and /127 - point to point /128 - host routes
RFC3513 is quite more strict than "should":
All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
(2001:: has the binary prefix 001). So this might very well be the problem.
I've heard the reason for 64 bits is that it's what currently fits in most computer registers, but I don't know if it's true.
Regards,
On 22/09/2011 9:43 PM, Per Johansson wrote:
22 sep 2011 kl. 12:14 skrev Michael Stefaniuc:
Wow! /66? And that works? While the standard allows for that you "should use /64" which everybody and his dog read it as that is the only thing that needs to work and the only thing that get tested. IPv6 brings back the class-full thinking which everybody has to painfully unlearn once IPv6 catches on...
"Safe" prefix length (especially if involving client devices) are: /64 - LAN /126 and /127 - point to point /128 - host routes
RFC3513 is quite more strict than "should":
All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
(2001:: has the binary prefix 001). So this might very well be the problem.
If I understand that correctly, if the interface has a hardware address (48-bit MAC or 64-bit EUI), then the interface ID should be constructed from that address.
Of course, if you are the administrator of the 2001:888:2000:38::/64 block, then you can assign Scope-Local Interface IDs as you see fit, just as everyone else does, and as allowed in RFC3513 2.5.1 - however, the RFCs say the subnet mask needs to be /64.
Per Johansson wrote:
22 sep 2011 kl. 12:14 skrev Michael Stefaniuc:
Wow! /66? And that works? While the standard allows for that you "should use /64" which everybody and his dog read it as that is the only thing that needs to work and the only thing that get tested. IPv6 brings back the class-full thinking which everybody has to painfully unlearn once IPv6 catches on...
"Safe" prefix length (especially if involving client devices) are: /64 - LAN /126 and /127 - point to point /128 - host routes
RFC3513 is quite more strict than "should":
Which is obsoleted by RFC4291, but that seems to have kept this paragraph. Anyway the correct RFC term to make it mandatory is "must". And it isn't a "must". Also the RFC4291 is from 2006 which is *old*.
All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
(2001:: has the binary prefix 001). So this might very well be the problem.
The same RFC4291 says: Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address.
It might be the problem but not because of the RFC; it just might be a typo as it is a manually set IP.
I've heard the reason for 64 bits is that it's what currently fits in most computer registers, but I don't know if it's true.
What really helps to understand IPv6 is: - IPv6 is an old protocol >15 years. That predates the Internet taking over. - IPv6 was designed based on the assumption that it will make the Internet again a friendly, warm and cozy place; a big any to any network without barriers/firewalls. - IPv6 isn't better than IPv4, it is different. - IPv4 still outperforms IPv6 in the new feature development. IPv6 is trying to play catch up. A few things that were long ago deprecated in IPv4 are still mandatory for IPv6 to be "standards compliant". - Don't assume that if the IPv6 standard says something the implementations really follow that. Test, test, test.
So no, the /64 host part has nothing to do with current hosts having 64bit registers now. I'm pretty sure that they were hoping to have 128bit computers by now. It had more to do with thinking that a globally unique identifier for the host is a good think to have and the MAC address already provided that with 48bits. But 48 isn't a nice number so it was rounded up to 64 which makes for a nice "design" as it is half of the IPv6 address.
bye michael
Hey,
On 09/22/2011 04:54 PM, Michael Stefaniuc wrote:
Per Johansson wrote:
22 sep 2011 kl. 12:14 skrev Michael Stefaniuc:
Wow! /66? And that works? While the standard allows for that you "should use /64" which everybody and his dog read it as that is the only thing that needs to work and the only thing that get tested. IPv6 brings back the class-full thinking which everybody has to painfully unlearn once IPv6 catches on...
"Safe" prefix length (especially if involving client devices) are: /64 - LAN /126 and /127 - point to point /128 - host routes
RFC3513 is quite more strict than "should":
Which is obsoleted by RFC4291, but that seems to have kept this paragraph. Anyway the correct RFC term to make it mandatory is "must". And it isn't a "must". Also the RFC4291 is from 2006 which is *old*.
All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
(2001:: has the binary prefix 001). So this might very well be the problem.
The same RFC4291 says: Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address.
It might be the problem but not because of the RFC; it just might be a typo as it is a manually set IP.
I've heard the reason for 64 bits is that it's what currently fits in most computer registers, but I don't know if it's true.
What really helps to understand IPv6 is:
- IPv6 is an old protocol >15 years. That predates the Internet taking over.
- IPv6 was designed based on the assumption that it will make the
Internet again a friendly, warm and cozy place; a big any to any network without barriers/firewalls.
- IPv6 isn't better than IPv4, it is different.
- IPv4 still outperforms IPv6 in the new feature development. IPv6 is
trying to play catch up. A few things that were long ago deprecated in IPv4 are still mandatory for IPv6 to be "standards compliant".
- Don't assume that if the IPv6 standard says something the
implementations really follow that. Test, test, test.
So no, the /64 host part has nothing to do with current hosts having 64bit registers now. I'm pretty sure that they were hoping to have 128bit computers by now. It had more to do with thinking that a globally unique identifier for the host is a good think to have and the MAC address already provided that with 48bits. But 48 isn't a nice number so it was rounded up to 64 which makes for a nice "design" as it is half of the IPv6 address.
Discussion aside, seems that using /64 works, so I'm keeping that. With the change testbot.winehq.org works again when using ipv6. I am not sure why it was set to /66, so I just hope nothing breaks as a result of this change.
~Maarten
On 22/09/2011 7:56 PM, Maarten Lankhorst wrote:
Hey,
Testbot has 2 ips assigned to it:
inet6 addr: 2001:888:2000:38:1000::1/66 Scope:Global inet6 addr: 2001:888:2000:38:1000::2/66 Scope:GlobalDoes the ::1 work?
~Maarten
Nope.
# traceroute -6 -f 11 -m 15 -T -p443 2001:888:2000:38:1000::1 traceroute to 2001:888:2000:38:1000::1 (2001:888:2000:38:1000::1), 15 hops max, 80 byte packets 11 te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2) 146.532 ms 146.546 ms 146.717 ms 12 * * * 13 * * * 14 * * * 15 * * *
I know I had a little trouble getting ipv6 running on my VMs until I allowed ICMP6 router-advertisement, neighbour-solicitation and neighbour-advertisement in through ip6tables.
Does `/sbin/ip -6 route` or `/sbin/route --af inet6` show the proper routes?
-
Ben Peddell -
Ben Peddell -
Francois Gouget -
Maarten Lankhorst -
Michael Stefaniuc -
Per Johansson