With IPv4, hierarchies of networking can be set up by users who just plug routers in. (Yes, there is ugly NAT at each level, but the user doesn't care, at least not until they need to forward a port). I'm asking what Linux software there is that could be configured so that if it was on a router, an end user could plug the router in the same way as they did with IPv4+NAT and the router would look at the network around it and automatically set itself up.
To automate it as much as possible and make routers that "just work" in a variety of configurations, the best way to go when designing routers probably is to support as many of the possible approaches as possible, both upwards and downwards.
You can have a router that tries both RA and DHCPv6 on the WAN interface and go with whatever way it succeeds at getting an address. There is a bit of a challenge with how long prefixes to start out with. You might not know in advance how many levels will be beneath you, so neither the router needing a prefix or the router giving it will know the specific need. Give a too short prefix, and you will be wasting addresses, give a too long prefix and you will end up running out of addresses to hand out downwards. There are some principles that you can follow to maximize the probability that you will be able to squeeze in new allocations and that you will be able to expand previous allocations into free space if needed. That should reduce the need for renumbering or handing out multiple prefixes to the same downstream router. Those principles should be applicable both for manual and automatically assigned prefixes.
Once you add too many layers of these routers you will eventually have a router that will only be able to receive a single /64, at that point you have three options.
- Subdivide even further, with the consequence that SLAAC is not possible further down the hierarchy, and you will only be able to support clients that support DHCPv6
- Use that single /64 leaving no way to delegate prefixes downstream
- Generate a /48 according to RFC 4193 and start doing NAT
With too many layers you cannot keep subdividing, and eventually you will have a router that just cannot receive a delegated prefix, or one that receives a prefix that is too long to allow for the number of hosts you would want to use downstream of that router. At that point NAT would be the only option if none of the upstream routers can request shorter prefixes to accommodate for the need.
If at some point you start doing NAT, then you will be starting over with a /48 and will have 16 bit to subnet from before reaching /64 again. If you add at least 4 bits at a time those 16 bits will last for four levels. That would guarantee that you could do five levels without running into any case where you would be doing double NAT. Probably people won't use that many layers of auto configuring routers. If you add just two bits to the prefix per layer and go down to a /112 before considering NAT, you can do 25 levels within a /64 without any NAT.
The question then is, how long a prefix should the router have before you would rather do NAT than using the prefix. If you receive a /64, it is too early to consider NAT. A /64 is short enough that you could support SLAAC, and it is still possible for the next router down the hierarchy to do NAT. So doing NAT already when you have a /64 doesn't make much sense. That means if all you have is a /64 the third of the three options I listed doesn't seem to make sense.
Splitting the /64 doesn't seem to make much sense as rumours have it that some ISPs will only be giving a single /64 to their customers, and those customers are more likely to need SLAAC than to need two levels of routers within their /64. Effectively that reduces the sensible default to one option, which is for the router to just use the single /64 it received and not delegate prefixes if it couldn't get more than a single /64.
If a router found itself inside a /64 subnet where it can get an address using SLAAC, but it cannot get a prefix delegated in any way, it will have a few options.
- Do NAT, it can use SLAAC to acquire a small pool of external addresses such that it doesn't have to do NAT with only a single address
- Switch to bridging mode and behave like a switch instead of as a router
- Just give up and leave its LAN side without IPv6 access.
Which of the three to choose might depend on whether IPv4 access is available. If the LAN would be left without Internet connectivity, it could hijack connections and present an error message explaining the scenario.
The above almost implies that the default should never result in prefixes longer than /64 being delegated, but there are ways delegating prefixes longer than /64 could still make sense. If a router receives a /63 it could use a /64 for its LAN side and subdivide the other /64 for downstream delegations. If a router received only a single /64 it could still try to get another /64 if it needed to make downstream delegations. It could even have two MAC addresses on its WAN interface and get a /64 for each MAC address using one for the LAN and the other for downstream delegations.
If a router receives a prefix with a length in the range 65-100 there isn't much point in assigning the full range to the LAN side. It is too long for SLAAC, so it may as well use most of the addresses for delegations and only a few for the segment directly on the LAN side.
In short, there is a lot of ways it could be done. And it is possible to go a long way in making things just work with many layers of routers. In practice I think it is likely that something will break if you chain four routers from different vendors, and it is not going to be NAT or lack of addresses that breaks it, rather it will just be some of the vendors having cut corners on the quality assurance, and allowing some design stupidity to slip through.
They don't want to have to replace a lot of CPE equipment if they get in the IPv6 game too early and their way of doing it gets abandoned.
I think many ISPs will find them selves in a situation where they have to replace a lot of CPE equipment because they got into the game too late. Getting into the game early means you have a better chances of shaping the development towards your own needs. And it would have given you time to evaluate the CPE equipment to ensure that the equipment you deployed between 2005 and 2010 wouldn't need to be replaced in 2012 or 2013 because of insufficient IPv6 support.
I'm sure most ISPs have had enough customers asking for IPv6 that they would have been able to grow a base of dual stack customers at a rate that would give them sufficient time to evaluate CPE equipment early on. If you had deployed dual stack to the first dozen of customers who asked about it in 2005 and had doubled the base every time a quarter passed without any new issues being found, you could have had 100% dual stack before the IPv4 address pool ran out.