I have two 512 Linodes with Debian Wheezy installed. I'm trying to configure IPv6 addresses assigned from a /64 pool.

It seems that IPv6 auto-configuration is working. Both machines get addresses and using ip addr I see a scope link address and a scope global dynamic address on each machine.

Both machines can reach the other using these global addresses using ping6 and the link addresses using ping6 -I eth0. They can reach remote address as well (ping6 -c1 ipv6.google.com).

So my next step is to add addresses from my pool to each machine (x:x:x:x::/64 being the network assigned to me):

ip -6 addr add x:x:x:x::1/64 dev eth0

on one and this on the other

ip -6 addr add x:x:x:x::2/64 dev eth0

Both machines can ping their own address but are unable to reach each other.

Am I missing something here? I ran

tcpdump -t -n -i eth0 -s 512 -vv ip6 or proto ipv6

on one while pinging it from the other and ping is received by one but it doesn't appear that it can resolve how to respond.

The route table looks like this (x:x::/64 being the auto assigned and x:x:x:x::/64 as the pool):

x:x::/64 dev eth0  proto kernel  metric 256  expires 2591973sec
x:x:x:x::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::1 dev eth0  proto ra  metric 1024  expires 63sec

I've flushed the ip6tables during the test. Both Linodes show IPv6 as enabled and the Public IP Pools show the pool "routed to" the address that is being assigned to one of the Linodes.

Thanks for any assistance. I'm just trying to expand a little on how to use and configure these IPv6 pools.

There are currently restrictions in place on all Linodes which only allow them to see traffic to the Solicited Node Multicast Address that matches their main SLAAC address (or, if assigned, their /116). As a result, your Linodes are not seeing their Neighbor Discovery packets reach each other, and so can't figure out what their MAC addresses are.

To work around this for the time being, use the addresses that would be generated by SLAAC for communicating within your routed /64, as that would use the same Solicited Node Multicast address. In other words, if your Linode's main address is something like 2600:3c00:f03c:91ff:fe11:2233, and your assigned /64 is 2600:3c00:e000:0001::/64, then use 2600:3c00:e000:0001:f03c:91ff:fe11:2233 for the communication on the /64. Realistically, you can use any address where the last 24 bits match your main address (the 11:2233 in this example), but using the SLAAC address is usually easier to remember, unless you zero out all the other bits.

One other option, which would likely get a little messy, but would allow you to use any address within your /64, would be to tunnel the IPv6 communications over the IPv4 private network, using a 6in4 tunnel, also known as IP protocol 41. The part where it gets messy is when you start adding multiple Linodes, as you'd either need to specify a route on all the other Linodes, or create a tunnel interface on each Linode for each of the other Linodes. With 2 Linodes this isn't bad, but I'm sure you can see how this wouldn't scale.

I understand that this can be painful, and we've already noted support for using any of your addresses in routed subnets between Linodes in the same datacenter as a feature request. If you have any questions, I'd be happy to help. Moving forward, though, I would recommend not censoring your addresses, so that we can provide more useful information that is specific to your setup.

Thanks. Sorry -- I meant to post this to General or Networking, I suppose.

If I understand what you're saying, I should add a route for the /64 network and point it to the address I'm being assigned.

So if Neighborhood Discovery is off, the instructions for configuring pool addresses (https://library.linode.com/networking/ipv6) seems to be broken? Since it says just add an assigned address and you're good to go. On one of the machines, the second one, adding the second address from the pool resulted in all IPv6 traffic to fail. I had to remove it (so only the one with autodiscover was left) for it to resume working.

Unfortunately, I don't have another easily available IPv6 machine to test these addresses from another location. I'll see if I can get the routing working.

The two machines in question have the following IPs:

alpha:
 2600:3c01::f03c:91ff:feae:674f
 2600:3c01:e000:4c::1
beta:
 2600:3c01::f03c:91ff:fe96:a40b
 2600:3c01:e000:4c::2

OK, so I guess it's not a route, but instead I do something like this. If my setup looks like:

alpha:
 2600:3c01::f03c:91ff:feae:674f
 2600:3c01:e000:4c::1
beta:
 2600:3c01::f03c:91ff:fe96:a40b
 2600:3c01:e000:4c::2

Instead, I removed the original addresses I'd added from the pool and added these new ones with the last 24 bits matching:

 alpha:
 2600:3c01::f03c:91ff:feae:674f
 2600:3c01:e000:4c::11ae:674f
beta:
 2600:3c01::f03c:91ff:fe96:a40b
 2600:3c01:e000:4c::2296:a40b

Making sure the last 6 digits match the primary address of each Linode.

I tested this and it appears to work. I can ping the new addresses from each side.

The instructions in the guide work, but only if the addresses you're bringing up will only be used on the Linode the pool is routed to, and only to communicate with the outside world, and not other Linodes in the same datacenter (as this is the only time that neighbor discovery protocol is not needed nor used). Your new setup looks good, though I'd recommend ensuring that beta can reach the outside world via IPv6, which you can do by simply ping6-ing linode.com. If it can't, run the following commands:

ip route del default via fe80::1 dev eth0
ip route add default via fe80::1 dev eth0 src 2600:3c01::f03c:91ff:fe96:a40b

I believe that part of the guide only applies to the 4096-pool address block, which in turn only depends on neighbor solicitation (e.g., IPV6's ARP) to work. It looks like the guide predates the availability of the larger blocks, which weren't first available until the end of 2011.

The /56 (and more recently /64) blocks are routed blocks and work differently, with more constraints if you try to use them outside of the routing they were established with.

I'm not sure if you have a particular reason to require the use of the routed /64, but if you are just looking for independent addresses to use with your Linodes you might find using the 4096-address pool a little easier.

-- David

Thanks, David. You were correct, alpha was working but beta was not able to connect outside the network.

As suggested, I removed the default route and added it back with the src address. Now both machines are connecting to the outside world. They also appear to be sourcing the pool addresses as their source IPs (which was what led me to test the IPv6 configuration in the first place).

One note, in Debian Wheezy you need to add -6 to the above commands, so I used:

ip -6 route del default via fe80::1 dev eth0
ip -6 route add default via fe80::1 dev eth0 src 2600:3c01::f03c:91ff:fe96:a40b

You are correct that the /64 is probably more than I need. Indeed, 4096 is also probably more than I need. I asked for the pool because I was having some issues connecting to certain sites (e.g. Google) using the provided IPv6 subnet.

Thanks for your assistance. I will continue testing this and hopefully someone else may also find this useful. The /64 routed blocks are definitely a more complicated setup.

The routed blocks of addresses (/64 & /56) aren't really meant for sharing amongst all of your Linodes. All traffic coming in for those addresses is routed to one Linode (whichever has the route destination address up) and that Linode would need to act as a router for all of your other Linodes. Due to the security filtering we do, however, Linodes can't easily act as routers.

If you want to have non-SLAAC addresses on all of your Linodes, just open a ticket and let us know. We'll be more than happy to add a /64 routed to each of your Linodes. If, however, you're trying to create some sort of private network, using globally routable addresses only makes the task more complicated. Personally, I'd recommend setting up IPSec between your Linodes using the addresses they already have assigned. Alternatively, you could configure tunnels between all of your Linodes and use unique local addresses inside those tunnels.

-James

Again, thanks for all the assistance. Just to be clear, I was trying to test why my IPv6 traffic was being blocked from Google searches. Which led me to the configuring IPv6 page. Which led me to request a pool of addresses.

It appears I requested a block that was too large since, contrary to the instructions, I couldn't assign an address from the pool on both Linodes and communicate. The site says:



But in any case, my main intention was to test the IPv6 configuration and also see if I could resolve the issue with Google. The recommendation I've seen on the forums (e.g. here) is to assign your Linode an address from the pool. I was setting up a test node to check the settings before applying them to production.

I'll keep testing this configuration but I suppose I will probably request a smaller subnet instead since it appears that is probably what I should have asked for in the first place.

It seems like the IPv6 policy is still evolving -- do you think it's the intent to start handing out these larger routed blocks by default? And is there any idea on how to handle the problems that arise from the default IPv6 network space that Linode is currently assigning getting blocked by Google and others.

Thanks,
Curtis

To fix the issue with Google blocking your traffic, the 4,096 address blocks are not going to help. Google is blocking the entire /64 and the 4,096 address blocks are part of that /64. Because of that, a /64 (or /56) routed to your Linode is the only way to get addresses that aren't part of the /64 Google is blocking. As for configuring them, you just need to bring them up on the Linode the route points to and they should just work.

The documentation appears to be out of date - which never should have happened and I'll look into getting it fixed - but we would actually prefer to give you a /64 for each Linode rather than a block of 4,096 addresses. Don't worry about wasting addresses or anything like that - we have far more /64s at this point than we're ever likely to need.

tl;dr - Just ask for more /64s. We'll be happy to route one to each of your Linodes.

-James

It would be nice if all of this was controllable in the Linode Manager and with the API instead of us having to send support tickets.

Allocate the /116 automatically when an account is deployed in a data centre. Give the account a /48 for routing additional address space automatically. Add something in the manager which allows us to change the routing for any sized subnet in the /48, add it to the API as well.

I find the 4,096-address "pools" substantially easier to work with than both the SLAAC addresses and routed /64's, because addresses inside the pool can be effortlessly moved between Linodes, which is really handy for moving services between Linodes (each service has its own address). Changing the Linode to which a /64 is routed requires opening a support ticket, and you have to move the entire /64 to the other Linode, so it's no good for migrating individual services.

Unfortunately, the pool addresses are in the same /64 as other customers, and I'm now concerned about being affected by overzealous blocking, such as what Google is doing. It would be great if Linode could give each customer an entire /64 pool of addresses that worked exactly like the current 4,096-address pools (i.e. non-routed, so addresses can be used on any Linode). These large pools would have the flexibility of the current pools but without the overzealous blocking problem.

That said, Linode should continue offering routed /64's and /56's as well, since they're useful for other use cases, such as running a VPN server. Linode's current flexibility with IPv6 is extremely powerful (and is unmatched in the industry) and I hope it stays that way!