OVH Community, your new community space.

Getting IPv6 working on kimsufi


Myatu
18-01-2013, 19:04
Cheers for the clarification, kro.

Felix@OVH
18-01-2013, 14:39
Hi,

correct is: You get a /64 network, not a /56. Since you get the complete /64, the gw has to be outside this /64 range (else it wouldn't be complete).
To use this, you simply have to set 2 v6 routes:
- One to reach the default gw (ip -6 r a 2001:41d0:8:b9ff:ff:ff:ff:ff dev eth0)
- and one default route: ip -6 r a default via 2001:41d0:8:b9ff:ff:ff:ff:ff

When did you install your kimsufi? if it's fairly recent, the Ipv6 setup should already be done.
Else, here's how to do it by editing /etc/conf.d/net as follows:

Code:
config_eth0=( 
"YOUR_IPV4_ADDRESS/24"
"YOUR_IPV6_ADDRESS/64"
)
routes_eth0=( 
"default via YOUR_IPV4_GATEWAY" 
"2001:41d0:8:b9ff:ff:ff:ff:ff dev eth0"
"default via 2001:41d0:8:b9ff:ff:ff:ff:ff" 
)

Myatu
17-01-2013, 19:14
That's how it used to be, correct. My assumption is that this is the case once again, given the disabled nd ra. However, that has not been reflected in the OVH documentation. Whether that was an oversight because it was only a recent change, I am unsure of and would like to see an official update from the OVH staff on that matter. Nevertheless, that configuration method does work without issue.

TP2k
17-01-2013, 10:18
Thanks for the reply. If I understand you correctly, I'm allocated a block of IPv6 addresses the size of a /64, but it's on a shared network that's a /56?
Therefore I should configure my network settings as a /56 but only ever allocate IPs out of my /64 range.

Myatu
17-01-2013, 09:31
A few years ago, they specified you had to use /56 for your configuration instead of /64. This was changed to /64 when they used router advertisements.

They've recently announced that they would disable nd ra again (http://status.ovh.co.uk/?do=details&id=2858), so you'll have to specify the gateway manually again.

This will give some error message from autoconf, given the invalid mask, which I've simply disabled in sysctl as its not needed when you specify everything manually:

Code:
net.ipv6.conf.eth0.autoconf = 0

TP2k
17-01-2013, 01:12
Hi,

I'm also having trouble getting IPv6 routing correctly. The documentation at http://help.ovh.co.uk/Ipv4Ipv6 is not clear. If I blindly follow the instructions, it doesn't work. As already pointed out the gateway is at the top end of a /56 netmask and outside of my /64 subnet.

I believe OVH used to give out /56 subnets, I wondered if the documentation was out of date and my gateway should in fact be 2001:41d0:AAAA:BBBB:FF:FF:FF:FF/64. But this does not respond.
I have 2 possible working configurations, but both are fairly dirty:

1) Manual route to gateway:
Inspired by how you have to configure routing for IPv4 failover addresses, it's possible to configure a route for the gateway via the physical interface and it will send traffic down that interface even if it's outside your subnet, e.g.:

2001:41d0:aaaa:bbbb::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
2001:41d0:aaaa:bbff:ff:ff:ff:ff dev br0 metric 1024 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:41d0:aaaa:bbff:ff:ff:ff:ff dev br0 metric 1024 mtu 1500 advmss 1440 hoplimit 4294967295

While it works, it feels very dirty and involves custom post/pre-up commands in /etc/network/interfaces (on Debian like systems)

2) First hop via link-local:
Inspired by how clients are configured using SLAAC, the first hop goes via an address on the link local subnet, i.e. fe80::/64.
It's possible to find the router(s) link-local addresses by pining the "All routers on the local network segment" multicast address (ff02::2):

$ ping6 -c 1 -I br0 ff02::2
PING ff02::2(ff02::2) from fe80::222:15ff:feaa:b57a br0: 56 data bytes
64 bytes from fe80::21e:79ff:fe1e:d400: icmp_seq=1 ttl=64 time=15.0 ms
64 bytes from fe80::21e:79ff:fe1e:f000: icmp_seq=1 ttl=64 time=44.1 ms (DUP!)


The double response is due to OVH having a dual router setup, with what I guess is a HSRP setup. The problem with picking one of these address as your gateway, is that they will not failover with HSRP in a router failure situation. It's also possible that these addresses could change.


I would appreciate any insight from others that have IPv6 working. I am currently baffled that there is just not a gateway for me to use within my /64 and I'm thinking I've missed something obvious.

Thanks,
Dan.

alex
05-01-2013, 01:29
I used the following settings and completely ignored the OVH docs:

/etc/sysconfig/network:
NETWORKING_IPV6=yes
IPV6FORWARDING=yes
IPV6_DEFAULTDEV=eth0
IPV6_DEFAULTGW=2000:77d0:2:b7FF:FF:FF:FF:FF
IPV6_AUTOCONF=no

/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=11.11.11.113
NETMASK=255.255.255.0
ONBOOT=yes
GATEWAY=11.11.11.254
IPV6INIT=yes
IPV6ADDR=2000:77d0:2:b767::1/56
IPV6ADDR_SECONDARIES="2000:77d0:2:b767::be29:a015/56"

/etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

the above IPv4 and IPv6 are not real just used to show example of my settings.

Myatu
03-01-2013, 15:43
Glad you got it to work, but I'd have to agree that its a bit odd that you had to use something different from what's specified (or the suggestion of Ubuntu, for that matter - it shouldn't matter what you use).

NeddySeagoon
02-01-2013, 23:23
The help I got from OVH was to use Ubuntu, not Gentoo.

Asking around on IRC, I was advised that the OVH IPv6 documentation may well be wrong and that the IPv6 router could be at 2001:41d0:8:b9ff:ff:ff:ff:fd rather than the documented 2001:41d0:8:b9ff:ff:ff:ff:ff.

The alternate address works for now but I don't know if the IPv6 router was deliberately set up this way, or if it was a typo that will get fixed and break my IPv6

NeddySeagoon
01-01-2013, 21:55
alex,

Thank you for your pointer to your thread. However, I can't ping my router IP from inside or outside OVH, so I suspect its not at the IP its supposed to be.

alex
01-01-2013, 21:32
A several posts available on these forums, I have posted one as I had similar issue.

NeddySeagoon
31-12-2012, 16:43
Myatu,

Thank you for the response. I had pretty much come to the same conclusion, that it was broken within OVH but it had not occured to me to ping the routers either side of mine.

I've emailed support - so its wait and see what they say now.

Myatu
31-12-2012, 04:19
The router should respond to a ping, but from my server I'm getting the same on that address. A traceroute stops at vss-9b-6k.fr.eu (2001:41d0::19c) with a host address error. Neighbouring IPs (ie., b8ff and baff) work OK. So I think it might be an issue at OVH's end.

NeddySeagoon
31-12-2012, 01:17
Hi team,

I'm in the process of migratings from a VPS elsewhere in the world to a kimsufi box in France.
Despite a few setbacks, the box it up and almost everything is the way I like it.
I just need to fix IPv6. My IPv6 subnet is 2001:41d0:8:b970::/64 and from reading these forums and the FAQ, it appears that the router will be at
2001:41d0:8:b9ff:ff:ff:ff:ff, only that doesn't work for several reasons.

a). its out of my subnet so by default, I cant't reach it.
b). using a hostmask of /56 (so its in the subnet fails too)
I can't say I like b) as its puts 256 users on their best behaviour to get the top 8 bits of their IPs right.

Anyway my # ip -6 ro sh
2001:41d0:8:b900::/56 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
ff00::/8 dev eth0 metric 256
default via 2001:41d0:8:b9ff:ff:ff:ff:ff dev eth0 metric 1024

gets me
ping6 2001:41d0:8:b9ff:ff:ff:ff:ff
PING 2001:41d0:8:b9ff:ff:ff:ff:ff(2001:41d0:8:b9ff:ff:f f:ff:ff) 56 data bytes
From 2001:41d0:8:b970::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:41d0:8:b970::2 icmp_seq=2 Destination unreachable: Address unreachable

Even if the router is not answering ping6, its not routing either, since I can't get to my VPS.

Any hints?
Oh, I'm a Gentoo user if that makes any difference