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
net.ipv6.conf.all.forwarding = 1
Edit /etc/vz/vz.conf (or wherever your OpenVZ configuration file is) and enable IPv6:
## 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:
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):
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:
vzctl set 1001 --ipadd 2001:470:d:29::2 --save
4) test connectivity from inside the VE:
[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.
I wasn't able to test it yet, although seems great that we can finally have tunnelbroker and OpenVZ working together :)
Also, is there any way to assign to a VE a real IPv6 on our allocated /64, so we can reach the VE from the outside?
Quote from: myvps on August 02, 2008, 04:36:22 PM
I wasn't able to test it yet, although seems great that we can finally have tunnelbroker and OpenVZ working together :)
Also, is there any way to assign to a VE a real IPv6 on our allocated /64, so we can reach the VE from the outside?
Not sure I understood what you meant by "real IPv6" address. I used an IP out of that routed allocation on the VE, not from the point-to-point allocation. Notice the subtle difference in the /48 range the address is from. "C" is for the point-to-point, and "D" is that statically routed /64. If you meant from non-tunnelled, native IPv6 connectivity, then a working example would be:
- assigning ::2/64 to the HN's eth0
- setting ipv6 forwarding with sysctl like in the previous example
- assigning ::3 though the end of the /64 to all the VEs with the vzctl --ipadd command
I missed the point-to-point part ;D
I've tried to setup a HN with it although i'm getting 'Network unreachable' errors:
[root@ovz3 ~]# traceroute6 ipv6.he.net
traceroute to ipv6.he.net (2001:470:0:64::2), 30 hops max, 40 byte packets
connect: Network is unreachable
[root@ovz3 ~]# route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/96 :: U 256 0 0 sit0
2001:470:c:*::/64 :: U 256 3 0 sit1
2001:470:d:*::10/128 :: U 1024 0 0 venet0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: U 256 0 0 sit1
fe80::/64 :: U 256 0 0 venet0
::/0 :: U 1 0 0 sit1
::1/128 :: U 0 1 1 lo
::67.220.x.x/128 :: U 0 0 1 lo
::69.42.x.x/128 :: U 0 0 1 lo
::127.0.0.1/128 :: U 0 0 1 lo
2001:470:c:*::/128 :: U 0 0 1 lo
2001:470:c:*::2/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::1/128 :: U 0 0 1 lo
fe80::43dc:c184/128 :: U 0 0 1 lo
fe80::452a:dcb7/128 :: U 0 0 1 lo
fe80::230:48ff:fe5c:7e32/128 :: U 0 0 1 lo
fe80::230:48ff:fe5c:7e33/128 :: U 0 0 1 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sit1
ff00::/8 :: U 256 0 0 venet0
eth0 Link encap:Ethernet HWaddr 00:30:48:5C:7E:32
inet addr:69.42.x.x Bcast:69.42.x.x Mask:255.255.255.192
inet6 addr: fe80::230:48ff:fe5c:7e32/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112434 errors:0 dropped:0 overruns:0 frame:0
TX packets:99 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:139020780 (132.5 MiB) TX bytes:6630 (6.4 KiB)
Interrupt:193
eth1 Link encap:Ethernet HWaddr 00:30:48:5C:7E:33
inet addr:67.220.x.x Bcast:67.220.x.x Mask:255.255.255.240
inet6 addr: fe80::230:48ff:fe5c:7e33/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:932 errors:0 dropped:0 overruns:0 frame:0
TX packets:71328 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:87412 (85.3 KiB) TX bytes:8251762 (7.8 MiB)
Interrupt:201
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20529 errors:0 dropped:0 overruns:0 frame:0
TX packets:20529 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1992832 (1.9 MiB) TX bytes:1992832 (1.9 MiB)
sit0 Link encap:IPv6-in-IPv4
inet6 addr: ::69.42.x.x/96 Scope:Compat
inet6 addr: ::67.220.x.x/96 Scope:Compat
inet6 addr: ::127.0.0.1/96 Scope:Unknown
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2001:470:c:**::2/64 Scope:Global
inet6 addr: fe80::452a:dcb7/64 Scope:Link
inet6 addr: fe80::43dc:c184/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:248 (248.0 b)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::1/128 Scope:Link
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:68605 errors:0 dropped:0 overruns:0 frame:0
TX packets:103136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5729240 (5.4 MiB) TX bytes:136342690 (130.0 MiB)
[root@ovz3 ~]# cat /proc/sys/net/ipv6/conf/all/forwarding
1
Thank you in advance,
I see 2 unique tunnels under your account, which use IPv4 endpoints in the same range. I need to know which tunnel to diagnose the issue on :)
Can you ping our side of the tunnel? I'm unable to ping6 your side of either tunnel, although both of your ipv4 endpoints ping just fine.
Everything looks correct on the tunnel-server.
Ok, we seemed to get this working for you over AIM using the correct tunnel information, and the other option for default ipv6 route, 2000::/3
If you have any comments or want to post the steps you used, feel free :)
First of all, thank you broquea, for spending your time on weekend helping me ;D
Since i needed it to run on boot here are my configs
Automatically create the interface sit0
HOSTNAME=your_hostname
NETWORKING=yes
NETWORKING_IPV6=yes
IPV6_AUTOTUNNEL=yes
Create the interface sit1
DEVICE=sit1
BOOTPROTO=none
ONBOOT=yes
IPV6INIT=yes
IPV6TUNNELIPV4= Server_IPv4_address
IPV6TUNNELIPV4LOCAL=Client_IPv4_address # You'll need to specify your client IP if you've multiple NICs
IPV6ADDR=Client_IPv6_address
Create a static route
sit1 2000::/3 Server_IPv6_address
Restart network interfaces
/etc/init.d/network reboot
This setup was tested on Linux tunnel-he 2.6.18-92.1.1.el5.028stab057.2 #1 SMP Mon Jul 21 17:08:31 MSD 2008 x86_64 x86_64 x86_64 GNU/Linux
Ok, I've been handling a bunch of tickets opened by folks now trying to get OpenVZ or Virtuozzo set up. The common mistake being done is people trying to bring up the tunnel inside the virtualized server. You MUST set up the tunnel on the OS that runs the physical machine. Then you can assign IPv6 addresses to the virtualized servers from your routed allocations.
If you do not have access to the physical machine's OS, then ask your provider if they'd be willing to do it for you.