I configured a simple router that should provide IPv6 connectivity to machines that are on LAN behind it. The router has 2 network interfaces (eth0, eth1), machines have 1 (eth0).

On router's eth0 is access only to local network, on eth1 is access to internet. I configured all kernel parameters, that works ok.

IP of router is fd00::1, I installed dhcpd on router and configured range fd00::100 - fd00::fffe.

When I start up some machine on this network it gets assigned IP from dhcpd, for example fd00::fffa, but is unable to access internet for obvious reasons - it is missing the route.

When I add route by hand sudo route -6 add 2000::/3 gw fd00::1 the machine starts having access to internet until I reboot it.

I can add this route by hand into init script of every machine, but I would rather have it autoconfigure so that when I start up a machine on this network it gets access to IPv6 internet with no need for anything else.

Based on some suggestions I installed also radvd on router and inserted this option:

route 2000::/3 {};

It's most likely wrong, but I couldn't find any documentation or examples. It doesn't work. Using radvd instead of dhcpd for assigning IPv6 addresses doesn't work at all, if I disable dhcpd machines autoconfigure some random IPv6 addresses and don't even see each other, neither they can ping router.

How do I setup my LAN to autoconfigure IPv6 for all machines on it?

Note: I don't need neither I want each machine to have public IPv6, NAT is just fine.

With DHCPv4/IPv4 communications (which I realize is not what you're asking about, but is likely similar), the routing information (including the "default gateway") may be more optional; directions may depend on what software is being used. It sounds like your router is assigning addresses with DHCPv6. Why don't you share with us the router you're using? Also, what operating system are you using (presumably Unix-ish, since you mention sudo), and what DHCP client (e.g. ISC DHCP dhclient, or dhcpcd?) These details may be needed if you want specific and applicable directions.
– TOOGAMMay 20 '15 at 10:41

It's just a linux box with 2 interfaces, that should be enough for a router, I suppose :)
– PetrMay 20 '15 at 10:55

1 Answer
1

I immediately spot two problems with your configuration. RFC 4193 addresses are not globally routable. That means those addresses won't be able to communicate with the outside world.

Sure you can use NAT, but NAT is known to cause numerous problems. NAT is a workaround intended to temporarily address the shortage of IP addresses. IPv6 solves that problem. All other problems people have attempted to solve using NAT has a better solution which does not involve NAT.

Additionally your prefix was clearly not generated according to the spec in RFC 4193. Relevant quote:

Locally assigned Global IDs MUST be generated with a pseudo-random algorithm

Whether these two problems in the network configuration prevent clients from communicating externally you will only find out by testing it. There exist software, which attempts to detect suboptimal IPv6 configuration and completely avoid using IPv6 if any is detected. It is quite plausible that some client software will refuse to use the IPv6 connection in your setup.

That said it is not impossible to get clients to communicate externally using RFC 4193 addresses. Here is a radvd.conf file, which I have used briefly in the past. With this configuration some clients did attempt to communicate externally using their assigned RFC 4193 addresses.

This configuration however does not work with all clients. I tested it again with a client running Android. The phone did get an IPv6 address configured, but it did not attempt to use IPv6 for external communication.

I then changed the prefix to be 2001:db8:dca3::/64, at which point the phone did start sending IPv6 packets to the gateway. So Android is one example of a platform which refuse to use RFC 4193 addresses in this way.

I don't see how this is not a valid range, even pseudo random generator could in theory generate prefix that consist only of zeroes, so if some software has hardcoded that such address is not valid it's a bug in that software. Moreover as I said the machines are able to connect to internet using these addresses, but only if I add a route, which perfectly makes sense. I was just wondering if it's possible to announce this route somehow so that every machine autoconfigure it.
– PetrMay 21 '15 at 7:01

@Petr Sure a random number generator could generate that range. But I know that some people violate the RFC and chose from a much smaller subset of the valid prefixes. From this information I reach the conclusion, that it is much more likely for fd00::/48 to come up due to an RFC violation, than due to random chance in an RFC compliant implementation. That doesn't mean that it would make any sense for client software to try to detect non-random prefixes and refuse to use them because of that.
– kasperdMay 21 '15 at 7:12

@Petr The reason a non-random prefix can cause problems is due to much higher risk of collisions. It is perfectly valid for a network to have multiple pieces of software which on their own generated random prefixes to be used for some purpose. They would be extremely unlikely to collide. But it only takes two incorrectly chosen prefixes to produce a collision with high probability. So whenever I see an RFC 4193 prefix that does not look random, I know this means a collision is much more likely that it should have been, and hence that is one possible source of problems to investigate.
– kasperdMay 21 '15 at 7:15

@Petr What would make sense for clients to reject is the use of RFC 4193 prefixes in general. Since those are intended for local use only, there is no guarantee, that they would work externally. Under those circumstances software vendors may expect using IPv4-only to be more reliable if the only IPv6 addresses are RFC 4193 addresses. I don't know of any specific examples of software rejecting RFC 4193 addresses, I do however know that Chromium rejects Teredo addresses for the exact same reason.
– kasperdMay 21 '15 at 7:19

@Petr I don't know for a fact whether any auto configuration software will accept RFC 4193 addresses but refuse to auto-configure a default gateway in that case. Given that RFC 4193 addresses are not supposed to be used globally, it is an idea I could easily imagine a developer coming up with. Developers sometimes do implement such restrictions without carefully thinking through the implications, but OTOH it is also possible that somebody did so after having identified at least one good reason for doing it. If anybody did this, then manually adding the route would address the issue.
– kasperdMay 21 '15 at 7:24