Print

[Azendale]

What linux DHCPv6 client can I set up so it requests a prefix on one interface and then on all the other interfaces it will give out addresses (or if requested, a smaller prefix delegation)? It would also need to set up the routes and router advertisements.

If there's not a way to do this, what is the IPv6 version of programming an IPv4 router to do NAT, wherever it is put? Basically, I'm trying to understand how a manufacturer would set up their IPv6 capable routers so a customer can plug them in and they would work.

[cholzhauer]

There is no NAT available for ipv6.  You'd need a combination of router advertisements and a dhcp server to do what you're talking about;  you just tell both of them what interface to operate on and what to do.

[Jim Whitby]

Use radvd.

Man radvd.
Man radvd.conf.

Having said that. Can you be more specific about what you are trying to do?
Provide ipv6 as an ISP? Corporate In-house? or ?

[kasperd]

Of the two approaches you suggest, both are technically possible. However the first approach with prefix delegation over DHCPv6 is much better than using NAT. I don't know how many levels of delegation will work well in practice. I also don't know if there exist software which will receive delegations and split it up into sub delegations, since such a feature would be required at any intermediate level, the lack of it would restrict you to one level of delegation. If you have routers that can do sub delegations you can in principle do as many levels as you have bits in the address. But I'd personally like to add at least 4 bits to the prefix at each level of delegation.

For the last level you can skip the DHCPv6 part and use router advertisements. When to use DHCPv6 and when to use router advertisements is a matter of taste. But AFAIK you still need to use DHCPv6 when you need delegation of prefixes, so you only have a choice on the last level.

Though NAT is possible with IPv6, it is not part of the standard, and it would still cause many of the problems that NAT causes with IPv4. Because of that you will probably find many routers that deliberately don't support NAT with IPv6.

Using NAT with IPv6 is not worse than doing so with IPv4. In fact some of the improvements from IPv4 to IPv6 solves some of the problems that NAT has been causing. One of the problems with NAT is that use of RFC 1918 address space can cause addressing conflicts. For IPv6 RFC 4193 solves the problems with conflicts. Another problem is handling of the IPID field. In IPv6 that field was moved from the IP header to an extension header. Having that field absent from most IPv6 packets reduces the amount of problems you would experience with IPID handling. In addition the IPID when present is twice as large as it was in IPv4, thus reducing the risk of collisions.

But even though NAT with IPv6 is slightly better than NAT with IPv4, it still isn't good. And since IPv6 gives you enough addresses, you should just avoid NAT altogether.

[Azendale]

EDIT: kasperd, I wrote this before you replied. I added another post responding to yours.

There is no NAT available for ipv6.  You'd need a combination of router advertisements and a dhcp server to do what you're talking about;  you just tell both of them what interface to operate on and what to do.

I know there is no NAT for IPv6. (That's what I love about IPv6 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.  From what I understand, Router advertisments+DHCPv6+Prefix delegation should make this possible. I'm asking if there's software to do it. It would need to get a Prefix from the upstream port using DHCPv6+Prefix Delegation. Then it would need to for each downstream port: listen for address requests, listen for prefix delegation requests (to which it would give a smaller Prefix Delegation than it received from the upstream port), set up routes, and give out routing information (to all other clients when a Prefix is delegated on the same downstream port).

Use radvd.

Man radvd.
Man radvd.conf.

I currently use radvd and it works great to give out addresses to a client. The problem is when that client is a router that has a couple computers connected to its downstream ports. Then that router needs a block of addresses. And all the clients on the same link as the routers upstream port need to know they can reach that block of addresses through the router. SLAAC, (the standard radvd implements) only supports giving out a single address.

Having said that. Can you be more specific about what you are trying to do?
Provide ipv6 as an ISP? Corporate In-house? or ?

I'm a home user trying to test this out using a set of 7 Linux virtual machines.

The back story is that I just started working at an ISP who does not want to start giving IPv6 to their customers because they don't know how the CPE part of it will work. 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.

Hearing their reasons made me curious about how the CPE equipment should work. Since I'm familiar with Linux and they use some of the Linux firmwares (DD-WRT, Tomato), I figured I would start with Linux.

[Azendale]

Of the two approaches you suggest, both are technically possible. However the first approach with prefix delegation over DHCPv6 is much better than using NAT. I don't know how many levels of delegation will work well in practice. I also don't know if there exist software which will receive delegations and split it up into sub delegations, since such a feature would be required at any intermediate level, the lack of it would restrict you to one level of delegation. If you have routers that can do sub delegations you can in principle do as many levels as you have bits in the address. But I'd personally like to add at least 4 bits to the prefix at each level of delegation.

I would image that if a DHCPv6 server/prefix delegation client subdelegation software existed, it would let you set how many bits to give for each link for wiggle room. I have tested DHCPv6 just giving out addresses to Windows Vista/7 (and Ubuntu linux, too IIRC) with a smaller than /64 subnet (it was /112) and it worked. So I believe the "just /64" mantra is just for SLAAC, not DHCPv6.

For the last level you can skip the DHCPv6 part and use router advertisements. When to use DHCPv6 and when to use router advertisements is a matter of taste. But AFAIK you still need to use DHCPv6 when you need delegation of prefixes, so you only have a choice on the last level.

Agreed. But if you wanted one client setup that would work on any link, whether other clients needed Prefix Delegation or not, my understanding is that you would probably have to do DHCPv6. Or is it that the client could detect which one the link is doing based on the router advertisement flags?

Though NAT is possible with IPv6, it is not part of the standard, and it would still cause many of the problems that NAT causes with IPv4. Because of that you will probably find many routers that deliberately don't support NAT with IPv6

Using NAT with IPv6 is not worse than doing so with IPv4. In fact some of the improvements from IPv4 to IPv6 solves some of the problems that NAT has been causing. One of the problems with NAT is that use of RFC 1918 address space can cause addressing conflicts. For IPv6 RFC 4193 solves the problems with conflicts. Another problem is handling of the IPID field. In IPv6 that field was moved from the IP header to an extension header. Having that field absent from most IPv6 packets reduces the amount of problems you would experience with IPID handling. In addition the IPID when present is twice as large as it was in IPv4, thus reducing the risk of collisions.

But even though NAT with IPv6 is slightly better than NAT with IPv4, it still isn't good. And since IPv6 gives you enough addresses, you should just avoid NAT altogether.

After having spent two days once getting an IPv4 hairpin NAT to work, NAT going away can not come too soon! There are a lot of things on the internet like VOIP that don't work without a external server because of NAT. The reason I like IPv6 is that it has no NAT and has addresses that stay the same (even if you use DHCPv6).  I would probably also deliberately not support IPv6 NAT either (as in not giving customers IPv6 NAT capable devices.) That way, I can't be expected to support someone who turned on NAT on a box I gave them.

[kasperd]

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.

[kasperd]

I would image that if a DHCPv6 server/prefix delegation client subdelegation software existed, it would let you set how many bits to give for each link for wiggle room. I have tested DHCPv6 just giving out addresses to Windows Vista/7 (and Ubuntu linux, too IIRC) with a smaller than /64 subnet (it was /112) and it worked. So I believe the "just /64" mantra is just for SLAAC, not DHCPv6.

The IPv6 addressing architecture RFC specified /64 for all subnets. However I believe that was a mistake, and it is perfectly ok to use longer prefixes if you don't want/need SLAAC. Some people argue that prefixes should be configured as /120 to put a limit on the resources used for neighbour discovery.

The suggestion from those people is that you should allocate a /64 to each subnet, but only configure it as a /120. The 56 bits in between should be set to zero. So if you have 2001:db8:1111::/48, you could allocate 2001:db8:1111:2222::/64 to a subnet, but actually configure it as 2001:db8:1111:2222::/120. Packets to for example 2001:db8:1111:2222::100 would be routed all the way to the gateway of 2001:db8:1111:2222::/120 and then result in no route to host instead of spending resources on neighbour discovery.

This is said to work just fine with newer systems. It was however suggested that certain older systems didn't work in such configuration. I think one of the issues was certain operating systems supporting SLAAC, but not DHCPv6.

The resources for neighbour discovery isn't really an issue for your LAN at home, but it may be an issue on the WAN side of your router at home since that could be on a segment shared with other customers.

But if you wanted one client setup that would work on any link, whether other clients needed Prefix Delegation or not, my understanding is that you would probably have to do DHCPv6. Or is it that the client could detect which one the link is doing based on the router advertisement flags?

If you want to design a client, that will work on as many networks as possible, it should detect whether to use SLAAC or DHCPv6. If you want to design a router to work with as many clients as possible, you should support both SLAAC and DHCPv6 on the LAN side. You can of course only support SLAAC if the prefix is 64 bits. If you for some reason use a different prefix length, you could only support DHCPv6.

I would probably also deliberately not support IPv6 NAT either (as in not giving customers IPv6 NAT capable devices.) That way, I can't be expected to support someone who turned on NAT on a box I gave them.

What I have recently come to hate about NAT is how it is slowing IPv6 adoption. I have noticed three ways that manifest itself:
-NAT broke transition technologies. If NAT had not existed for IPv4, we wouldn't have needed both 6to4 and Teredo. Instead we could have had just one of the two, and it would have worked better than any of them can in presence of NAT.
-NAT delayed the transition by artificially reducing demand for IPv4 addresses giving people the false impression that the IPv4 pool would last forever (some people still believe that).
-NAT has caused a serious case of the Stockholm syndrome. You will find a lot of people who don't want to move to IPv6 because of the lack of NAT.

[Azendale]

So, it sounds like it it possible to follow the RFCs and do what I want. So the question is if there is software to do this.

[kasperd]

So the question is if there is software to do this.

Unfortunately, I don't know the answer to that question.

[k1mu]

So the question is if there is software to do this.

Unfortunately, I don't know the answer to that question.

Yes, and it's already been answered. Use radvd and dhcpdv6 on the internal network, giving out addresses on your routed /64.
I just use radvd and SLAAC since it's less work to set up.

[kasperd]

it's already been answered. Use radvd and dhcpdv6 on the internal network, giving out addresses on your routed /64.
I just use radvd and SLAAC since it's less work to set up.

I don't see any answer to the question, and from the documentation I found on radvd and dhcpdv6, it doesn't sound like either of those solve the problem either. I strongly suspect you haven't understood the question.

An ordinary DHCPv6 server with a static configuration would be suitable for the first level in the hierarchy. An ordinary DHCPv6 client and radvd would be suitable for the last level in the hierarchy. But the intermediate routers need to act both as a DHCPv6 client and a DHCPv6 server, and the prefixes handed out by the server need to be decided from what the client side received.

Anything requiring configuration is not an answer to the question. The goal is to be able to connect routers together in a hierarchy with the only requirement that you can tell the difference between the WAN port and a LAN port.

In other words assuming you have a lot of routers, and that the WAN port from one is connected to the LAN port on another, and after 2-5 steps of going out the WAN port you will eventually reach a segment with a DHCPv6 server with a static configuration. What software is needed on the intermediate routers to ensure that once they are all powered on with their default configuration, the prefixes handed out by the DHCPv6 server are subdivided such that every router eventually receives a /64?

Starting with a single router using a HE tunnel with a routed /48 and a DHCPv6 server handing out /52s or /56s would be suitable for the core of a test network to test the interaction of such routers. But I still have no idea what software to put on the intermediate routers to make it just work.

[Azendale]

So the question is if there is software to do this.

Unfortunately, I don't know the answer to that question.

It didn't sound like you knew of anything. I was just hoping to make it clear to other readers that this wasn't a "solved" question.

So the question is if there is software to do this.

Unfortunately, I don't know the answer to that question.

Yes, and it's already been answered. Use radvd and dhcpdv6 on the internal network, giving out addresses on your routed /64.
I just use radvd and SLAAC since it's less work to set up.

I don't think you understand my question. The goal is not necessarily easier, the goal is to be something that can be set up before hand and then just work for someone else, even if that someone else only knows the difference on the hardware between the upstream port and the downstream ones.

[k1mu]

What linux DHCPv6 client can I set up so it requests a prefix on one interface and then on all the other interfaces it will give out addresses (or if requested, a smaller prefix delegation)?

I see. I misread this, obviously. There's no single client that I know of that does that. You want dhclient bound to one interface and dhcpd/radvd bound to the others. Obviously, the issue is with the intermediate node figuring out what prefix to give out on the other interfaces. That's possible with manual configuration and multiple pieces of software, but that's not what you're looking for.

Sorry.

[Jim Whitby]

I didn't attempt to get into details, but check out isc.org and their dhcp stuff. I think it will do what you want.

Either as two processes ( server and client ) or possibly the dhcp-relay.