Posts Tagged ‘prefix delegation’

An Ipv6 Crash Course

Wednesday, November 30th, 2011


It’s only a matter of time until we will be forced to switch from ipv4 (aka simply ip nowadays) to ipv6. The v4 ips are exhausted as we speak. Because we haven’t made a smooth transition until now (thank you big ISPs) we will probably be forced to move pretty quickly during the next few years. Major ISPs have already started deploying ipv6 to the mass market so far optionally and under the “testing” label. I expect the trend to get massive proportions next year (2012). So the internet as we know it today will change forever pretty soon.

The news didn’t reach the mass media so far but the technical media has been bombarded with such messages for quite some time. So in the technical world nowadays everybody knows that ipv6 means more numbers than ipv4 and thus allows everybody to have an ip (or several); even your fridge can get it’s own ip. Everybody also knows that this time the numbers are usually in hex instead of decimal, grouped differently and separated by colons instead of dots. But if you want to get your own ipv6 you might want to know more.

My ISP has recently deployed testing ipv6 for opting-in customers. So I was very eager to get ipv6-enabled and be ready for the future. As usual I used the good old Google to find resources about ipv6 deployment and much to my surprise the resources are pretty limited. There are some tutorials and blog posts that describe ipv6 setups to some extent but they are pretty much concentrated on ipv6 tunneling with some standard tunnel providers and that didn’t help me much. My ISP offers dual stack (ipv4 and ipv6) and prefix delegation both over PPPoE on top on FTTB. In order to make the problem worse they provide dynamic ip (and prefix) allocation so the vast majority of tutorials that configure static ips were not so useful to me. I banged my head too much time to get this setup to work with my entire lan and with an already pretty customized setup. The documentation I could find on the internet failed to inform me of some basic things that could have get me going fast so I decided to write this post in order to help the others but also for me not to forget how it was and how to do it again.

Technical Background

There are more changes to ipv6 than numbering and you need to understand the basic principles of these changes before doing anything else.

  • Address scope – in the good old ipv4 you just had ips (routable or private) and net masks. In ipv6 you also have address scopes. I’m not going to repeat information that you can find elsewhere and which serves no real purpose to you get you going quickly. What you should know about this is that each interface should have a fe80 prefixed address (which is marked “scope link” in linux) and which is not accessible from the internet. If your interface is configured properly you will also get a “global” ip which is the address with which the interface is accessible from the internet.
  • Stateless and Stateful – In the good old days of ipv4 we used to have DHCP to get the ips assigned. In ipv6 you don’t have to use DHCP at all. All ipv6 equipment can be configured to use Router Advertisments (RA) which is called Stateless autoconfiguration. This means that the router periodically sends ICMPv6 messages to every host announcing prefixes that can be used by the client. This is a feature not a bug – so you can get any ipv6 client going with no dhcp at all; all you need to do is plug it in and it should get an ip and route. But you still have DHCPv6 which is entirely optional in ipv6. It can be used in stateless mode as well but it’s usually used in Stateful autoconfiguration which actually means that the DHCPv6 server provides additional information such as DNS servers, domain name, NTP servers etc. As you can see DHCPv6 can serve much more information than the v4 counterpart which only server ip, mask, gateway and dns.
  • Prefix Delegation (PD) – In ipv4 we usually had to use NAT to connect our local network. In ipv6 we have so many ips that we don’t have to use NAT anymore: everyone (everything actually) can get it’s own ip. As a matter of fact in standard ipv6 there is no NAT at all. But there must be a way of dynamically assigning the needed ipv6 subnets to the clients and this is called Prefix Delegation (PD). With PD the ISP assigns a subnet to the client so that each client interface (even the fridge) can get it’s own ip that is accessible over the entire internet. The client can also further split the assigned subnet into smaller subnets and thus have more LANs connected. The sky is the limit here: the client can do whatever he wants with his subnet. As far as I know IANA recommends that at least a /64 be provided to the client so each client can have an entire ipv4 private intenet (as a matter of fact internet x internet hosts).
  • Temporary Addresses – In ipv6 the traditional and simple way of automatically generating ips was based on using the MAC of the interface. Some privacy concerned people added the possibility of using somewhat more randomly generated ips. If you wish to have the latter you must configure linux with “net.ipv6.conf.eth0.use_tempaddr = 1” but the other ip will still be preferred. If you set it to “2” the temporary address will be preferred. If you have connectivity problems you might want to try to set it to 0.
  • Utilities – In the linux world we have the same set of utilities from ipv4 only that we have to add a 6. So we have: “ip -6”, “route -6”, “ip6tables”, “traceroute6”, “ping6” and so on. Ifconfig and mtr need no 6.

Getting It Going

With ipv6 it’s supposed to be simple. If you have an ipv6 provider all you have to do is accept his RAs and you should have an ip and a route. In linux you can enable or disable the acceptance of RAs for each interface either with sysctl or via /proc. With sysctl you have for example “net.ipv6.conf.eth0.accept_ra” which can be 1 or 0 and thus enables or disables receiving RAs on eth0. Instead of “eth0” you can have any other interface but also “all” or “default” which are pretty much self-explanatory. You can test your connection with “ping6”

Getting the Router and LAN Going

This is not as trivial as it seems unless you have an already configured or “web-interfaced” router that only has an “enable ipv6 routing and let me do my thing” switch. So if you’re the admin and you also happen to have a linux router and hosts you should consider the following:

  • You need a subnet assigned by your ISP that you can use with your own equipment. You do usually get a /64 or more subnet by RA from your ISP but this may NOT necessarily be the subnet delegated to you. This can actually happen to be just a single host ip for use with your computer or router external interface (connected to your ISP). The subnet in this case is the subnet formed by all routers and computers connected to that ISP router.
  • If your delegated subnet is assigned statically (always the same and guaranteed never to change) than things can be much simpler because you can manually assign static ips throughout your LAN(s).
  • If your delegated subnet is assigned dynamically you need to use PD. In order to use PD you MUST use DHCPv6. There are some few ipv6 enabled DHCP clients out there: ISC DHCP – doesn’t seem to support PPP interfaces; Dibbler – I couldn’t make it to generate radvd.conf nor to make it assign ips to other interfaces; Wide-DHPv6 – extensively used in Openwrt world but it seems quite outdated – anyway it works. After you get such a DHCPv6 client you must configure it to use the ISP connected interface and request PD
  • When you get your delegated prefix you must have some way to distribute it over to your hosts (or LANs). Again you can do this statically if you have a static prefix. but the preferred way is to generate your own RAs. The only linux utility that automatically sends RAs (as far as I know) is radvd. So get radvd, install it and configure it to use the delegated prefix and advertise on your LAN interface. On some configurations (eg: Openwrt with Wide-Dhcp6) you will see that radvd.conf is automatically generated by the DHCPv6 client and radvd might also be started by it. This is actually the heaven of autoconfiguration – otherwise you must get back to your own scripting skills. Either way don’t forget to configure host interfaces (or other routers) to accept RAs.
  • Everyone should now have it’s own ip from the ISP delegated subnet. But you also have to configure routing. With ipv6 it’s supposed to be easier than ever. All you have to do in linux is to enable forwarding for the needed interface. You can do this with sysctl or via /proc. With sysctl you have something like “net.ipv6.conf.eth0.forwarding” which must be 1. It’s the same as in the ipv4 world; the difference it’s that with ipv6 that’s all you need to do in order to get the router to route (there is no NAT anymore). Remember that you get such a setting for each interface (PPP or tunnels included) and you must set forwarding for the one that you need (or all 🙂 of them). Also remember that you also have “net.ipv6.conf.all.forwarding” and “net.ipv6.conf.default.forwarding”.
  • Last but not least don’t forget that you also have ip6tables. If you didn’t configure it you might want to do that as soon as possible. If you did configure it and you have connectivity problems maybe you configured it the wrong way. For instance in the ipv4 world Microsoft-minded people used to block everything they could including ICMP. In the ipv6 world RAs are ICMPv6 messages: you do the math.
  • RAs are forwarded as well if forwarding is configured appropriately. This is quite a feature if you have several routers in your LAN
  • You might get “unreachable” routes in your routing table. I’m not going to talk about what they are and why they appear. The important things to know are that they sometimes appear “out of the blue” and they might prevent an otherwise working environment from working. So if you have connectivity problems and you know you have done everything right you might want to check your routing table for “unreachable” routes and try to delete them