Try using ipv4_end.php in your URL that you are fetching, like the other posts pointed out.

"ipv4_update.php" is not for the automated scripts, but rather the interactive website.

The ipv4 return-path to that first IP before your unlisted hop #1 goes through C&W, and seems to spike once C&W hands off to CPRM:

 1  gige-g2-20.core1.ams1.he.net (216.66.84.45)  3.828 ms  10.633 ms  0.722 ms
 2  amsix.xcr1.amd.cw.net (195.69.145.144)  0.283 ms  0.278 ms  0.287 ms
 3  xe-0-1-0.xcr1.lsw.cw.net (195.2.25.101)  7.889 ms
 4  xe-4-1-0.xcr1.lnd.cw.net (195.2.25.54)  7.582 ms  8.029 ms  7.599 ms
 5  ge-5-0-0.dcr2.lnd.cw.net (195.2.25.6)  8.184 ms  8.174 ms  8.184 ms
 6  so-7-0-0-dcr1.esx.cw.net (195.2.9.146)  31.142 ms
 7  so-2-0-0-dcr1.mad.cw.net (195.2.9.121)  31.428 ms  31.431 ms  31.439 ms
 8  ge-3-1-0-zcr1.mad.cw.net (195.2.11.202)  31.288 ms
 9  lis1-cr1-te0-0-0-0.cprm.net (195.8.0.77)  130.851 ms  130.726 ms  130.880 ms
10  lis2-cr1-te-0-0-1-0.cprm.net (195.8.30.145)  131.411 ms  131.300 ms  131.172 ms
11  telepac2.cprm.net (195.8.30.146)  130.587 ms  130.553 ms  130.753 ms
12  194.65.12.49 (194.65.12.49)  130.596 ms  130.996 ms  131.029 ms
13  213.13.135.174 (213.13.135.174)  130.730 ms  130.197 ms  130.150 ms
14  213.13.135.157 (213.13.135.157)  131.177 ms  130.726 ms  131.036 ms
15  * * *
16  * * *
(etc.)

Maybe they have saturation on their peering/transit (whatever that connection is).

I can see if CPRM has peering information in EU and is at a mutual exchange. If you have any, we can try and use it.

Tracing to funet.fi from the tunnel-server seems pretty clean, so must be the overhead of that (possibly) saturated connection:

traceroute6 to 2001:708:10:9::20:1 (2001:708:10:9::20:1), 64 hops max, 12 byte packets
 1  gige-g2-20.core1.ams1.he.net  0.355 ms  6.213 ms  0.137 ms
 2  dk-ore.nordu.net  11.984 ms  11.819 ms  11.832 ms
 3  se-fre.nordu.net  21.634 ms dk-uni.nordu.net  12.840 ms se-fre.nordu.net  21.623 ms
 4  se-tug.nordu.net  25.419 ms se-tug.nordu.net  25.570 ms se-tug.nordu.net  25.566 ms
 5  helsinki0-rtr.funet.fi  32.146 ms  32.148 ms  28.656 ms
 6  csc4-g3100-helsinki0.ipv6.funet.fi  32.460 ms  29.204 ms  28.951 ms
 7  ftp.funet.fi  35.970 ms  32.442 ms  35.817 ms

If you control the HN (Host Node, the actual platform server that hosts all of the virtual servers) and can't get native IPv6 connectivity, you can still get it with a tunnel.

Configure the HN to have the tunnel terminate on it. Make sure that you've got the following in the file: /etc/sysctl.conf

Code:

net.ipv6.conf.all.forwarding = 1

Edit /etc/vz/vz.conf (or wherever your OpenVZ configuration file is) and enable IPv6:

Code:

## Enable IPv6
IPV6="yes"

Then you can add IPv6 addresses out of your routed allocation using either the vzctl command, or edit the VE's configuration file by hand.
So the steps are (and I'll use one of my testing tunnels' information)

1) create tunnel interface with commands on the HN:

Code:

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::66.220.18.42
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:c:29::2/64
route -A inet6 add ::/0 dev sit1

2) add ipv6 packet forwarding (edit /etc/sysctl.conf for permanent setting):

Code:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

3) using vzctl, add an IPv6 address out of your routed allocation (lets just say the /64) to the running configuration of a VE:

Code:

vzctl set 1001 --ipadd 2001:470:d:29::2 --save

4) test connectivity from inside the VE:

Code:

[root@vps0010 ~]# vzctl enter 1001
root@testve:/# traceroute6 -n ipv6.google.com
traceroute to ipv6.google.com (2001:4860:0:2001::68), 30 hops max, 40 byte packets
 1  2001:470:c:29::2  0.091 ms  0.032 ms  0.019 ms
 2  2001:470:0:9d::1  10.832 ms  10.909 ms  10.986 ms
 3  2001:470:0:3a::2  42.412 ms  42.374 ms  42.418 ms
 4  2001:470:0:3b::2  77.478 ms  77.435 ms  77.520 ms
 5  2001:504:0:2:0:1:5169:1  78.224 ms !X  78.172 ms !X  78.382 ms !X

You'll see that the HN will appear as the first hop in the trace, since the /64 is routed behind it.

Have you tried updating the firmware?

This appears to be ARIN's application:

http://www.arin.net/registration/templates/experimental.txt

And this is more information on their program:

http://www.arin.net/billing/fee_schedule.html#experiment

[ROUTED]

Couple of notes regarding the updated web interface:

1) To update your tunnel's IPv4 endpoint, click on the tunnel for the details page, then click on your listed IPv4 endpoint. This will open a new page where you enter your new IPv4 endpoint address, and click submit to make the change.

2) To update rDNS server entires for your ROUTED /64 & /48 blocks, again go to the tunnel's details page and click on the link which will either be "none" if you haven't set any yet, or whatever you currently have set. This will take you to a page to update the rDNS server entires.

3) To allocate a routed /48, again go to the tunnel's details page and click on "Allocate". This will allocate and statically route a single /48 through your side of the IPv6 tunnel.

4) To merge tunnels from multiple accounts into a single, each tunnel should have a "Claim code". Pick the account you want to have as a master account, and ignore it's claim code. Log in as your other accounts, and copy down their claim codes. Under that master account, you'll see "Combine Tunnels" which you will click, and follow the directions on screen. Once you've claimed a second tunnel or simply created one, that master account will no longer have a claim code associated with it. Any account that you've used a claim code from, will be deactivated and no longer able to log in.

Good to hear

It is gone.

Instead you click on your ipv4 endpoint under tunnel details, which will load a page to change it, enter new endpoint, click submit, and it will update the endpoint on the tunnel server.

Maintenance has completed.

There are some new features we are able to provide now:

• Multiple tunnels per account
• Ability to combine tunnels from other accounts into a single account
• Help Balloons on Tunnel Details page

Again, if you are experiencing any problems, please email ipv6@he.net right away.

Tomorrow we will be migrating the website to new hardware and an updated platform.

We are starting around 12PM Pacific, and we expect to be completed at the VERY latest by 5PM Pacific.

Please report any bugs you encounter to ipv6@he.net and not on the forums (that way we get them emailed to us directly!)

[*REMINDER*]

The Frankfurt BGP tunnel-server is now live and available to choose when creating a tunnel. Again if you would like your existing account to use one of the new tunnel-servers, please delete your existing tunnel then pick the new location to create your tunnel on.

*REMINDER* - Deleting your old tunnel means deallocating your IPv6 blocks, and you will be assigned NEW allocations based on the tunnel server you pick.

Give rDNS about 10-15 minutes then please retest.

[*REMINDER*]

The London BGP tunnel-server is now live and available to choose when creating a tunnel. Again if you would like your existing account to use one of the new tunnel-servers, please delete your existing tunnel then pick the new location to create your tunnel on.

*REMINDER* - Deleting your old tunnel means deallocating your IPv6 blocks, and you will be assigned NEW allocations based on the tunnel server you pick.

Frankfurt's BGP tunnel-server should be live later this week, we are still waiting on the facility to rack the equipment.

Also no you don't need to run BGP. I set up a similar test network up several times a week without issue, except I don't try and hardcode the address on the client, I just RADVD advertise and the systems pick everything up.  The basic radvd config I use is:

interface eth0
{
AdvSendAdvert on;
AdvHomeAgentFlag off;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2001:470:A:B::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};

sorry its late and im not reading everything. you dont need to make tunnel interfaces on the clients that want to use the routed /64. if they have ipv6 enabled they should get the address from radvd. unless you are creating sit interfaces for the clients on the linux box, using their tunnel interfaces won't work.

Basically:

1) configure tunnel on linux machine.
2) configure first usable IP of routed range on the interface that faces the LAN (in your case eth2)
3) configure radvd to advertise that range over that interface
4) configure client machines on the LAN to support IPv6, and after 30 seconds they should automatically assign an address

XP/2000/2003 will require an IPv4 nameserver connection for DNS resolution, Vista/2008 won't.
Mac/Linux/BSD are generally already IPv6 enabled and will get an address.

make sure you've enabled ipv6 forwarding in sysctl?