In IPv6, you are not supposed to subnet to anything smaller than a /64 (RFC 5375). Among other things, SLAAC does not work with smaller subnets, and apparently also some other features will break.

What are the workarounds for situations where ISPs will only give you a single /64 but you need multiple subnets internally? The common advice seems to be to just find another ISP who will hand out a /56 or /48. In some parts of the world, that may work, but in our area (USA), that's not feasible due to a lack of competition. Most of my clients are lucky if they have a single ISP serving their area. Many people here are still on dial-up.

My clients won't qualify for their own /48 from ARIN.

  • 12
    I would not attempt to deploy IPv6 in that scenario. Continue pressuring the ISP to provide proper connectivity. Make their mistakes highly visible and public, if necessary. Quote chapter and verse from RFC 6177. Of course, you should first make sure that it is their mistake, and that your equipment is requesting a larger subnet. Aug 18, 2015 at 4:04
  • 8
    That's also bad advice. Given all its advantages, most people should deploy IPv6 at the first available opportunity. Unfortunately many ISPs have made a complete dog's breakfast of their IPv6 service, making it unwise to use. Aug 18, 2015 at 6:14
  • 3
    We could argue all day long whether it's the ISPs making a dog's breakfast out of it (which they certainly did!), or whether the IPv6 designers were unrealistic in their assumption that ISPs wouldn't do that. Of course, I don't tell my clients to stay away from IPv6 forever, just until the dust has settled. I'm sure five years from now, or even earlier, there will be an SLAAC 2.0 that supports smaller subnets, along with NAT (many routers already implement it anyway), and everything else needed to make IPv6 work in the face of adversity. I was more looking for right-now solutions, though. Aug 18, 2015 at 6:24
  • 5
    Don't count on IPv4 mess like NAT to work properly with IPv6. NAT was a hack, not a feature... Aug 18, 2015 at 7:03
  • 5
    @KevinKeane NAT always was a hack and always will be. Every problem people have tried to solve using NAT has a real solution which does not involve NAT - but likely it does involve IPv6. The vast majority of breakage of which you speak can be attributed to NAT or incomplete IPv6 deployments.
    – kasperd
    Aug 18, 2015 at 8:52

3 Answers 3


If the ISP won't give you more than a /64, then that ISP sucks. If it is any relief I can tell you that I have to deal with ISPs that suck even more than that. Around here it is perfectly normal to take public IPv4 addresses away from customers and put them behind a CGN. And if you ask them for IPv6 addresses, they will tell you that they are not offering IPv6 because there is no shortage of IPv4 addresses yet, and as long as there are servers without IPv6 support they won't offer IPv6 because it is impossible for a dual stack client to connect to an IPv4-only server.

If any ISP would give me what you have, I would take it because it sucks less than what I have been able to get so far.

Moving forward there are two approaches I recommend that you pursue in parallel.

Put pressure on the ISP

Put as much pressure on the ISP as you can. That includes contacting other ISPs and possibly switching if any other ISP can offer you a better deal.

Make sure that you do test what happens if your router requests a delegated /48, /52, /56, or /60 through DHCPv6 on the WAN. I would test all four prefix lengths just in case the DHCPv6 server for some reason will only hand out a specific prefix length and ignores requests for other prefix lengths.

Make the best of what you have

Given that you are probably going to have to live with some hacks moving forward, you have to ask yourself which sucks less IPv4 with hacks or IPv6 with hacks.

There are a few hacks you can use to stretch a single /64 to a lot of hosts.

Turning a link prefix into a routed prefix

If you have a single /64 on the WAN link but no prefix routed to your LAN, you can turn that /64 into a routed prefix with a few steps. Configure the WAN interface on your router as a /126 rather than a /64. Install a neighbor advertisement daemon (such as ndppd) on the router to advertise its own MAC address for every address in the /64 except from the 4 addresses in the /126. With those two steps you will have a routed /64 which you can use on your LAN with the exception of the 4 addresses used for the WAN link.

A modified version of this hack can share the link /64 across multiple routers. The link prefix will then have to be a bit shorter than /126 to accommodate for an IP address to each router, a /120 would be short enough to allow for up to 254 routers.

Each router will obviously only get a prefix which will be longer than /64. I recommend you make the prefix for each router as long as you can while still having enough IP addresses for the LAN on that router. A /112 or /120 for each router would likely be suitable. Each router responds with its own MAC address for neighbor discovery of anything within that router's prefix.

In this variant each router will have identical prefixes configured on their WAN side and will be responding to neighbor discovery requests for the prefix assigned to their LAN side. Obviously none of the LAN prefixes may overlap each other and none of them may overlap the prefix you configured on the WAN side.

So if the ISP router acting as your gateway is on address 2001:db8::1/64, then you can use 2001:db8::/120 as your WAN and you can assign 2001:db8::1:0/112 to the first router, 2001:db8::2:0/112 to the second router, etc.

On the LAN you can stretch a /64 to a lot of hosts either by subnetting or by bridging. You'll have to work out which of the two works best for you.


If you do subnet the /64 you may as well go to the longest prefixes which still have enough addresses for the hosts you need. Don't subnet into /80 prefixes, rather go with /116, /120, or /124 per subnet. Things that do break if you don't use /64 are unlikely to care and by going with /116 or longer you will reduce the impact of certain neighbor discovery DoS attacks (if present in any of your systems).

In such a subnetting configuration you will break SLAAC, so you need a DHCPv6 server to respond on each segment and static IPv6 addresses configured on all devices without DHCPv6 support.


Bridging is the other alternative. It essentially means you don't subnet but run your entire LAN as a single IPv6 segment with a /64 prefix. (Should you need to, that /64 can span both LAN and WAN.)

IPv6 is designed to allow bridges to recognize which of the bridged networks each anycast addresses need to be forwarded to. That way you avoid having to broadcast packets across every physical link on your LAN.

Bridges can also apply firewalls and protection against neighbor discovery spoofing on the LAN.

With sufficient intelligence on the bridges there is in principle no limit to how many switches you can bridge a single /64 across.

  • Thank you! That was exactly the type of answer I was looking for! I particularly like your idea of turning the /64 into a routed prefix. Can you elaborate a bit on that, please? First, I don't understand why you suggest a /126, rather than a /127? Which IP addresses are used where? Secondly, at one of my clients, I actually have three separate internal routers. In IPv4, they have three different public IPs in the /29 provided by the ISP. Would your scheme still work with these routers? Aug 18, 2015 at 8:15
  • Also, I'm not sure how to install a Neighbor Advertising Daemon on any of the routers. One router is Fortigate, one is Belkin, and I think the third is Linksys. Aug 18, 2015 at 8:16
  • @KevinKeane The reason I suggest a /126 is that you will often need at least three addresses within the prefix. On the ISP side the router may have the prefix configured as 2001:db8::1/64, which means 2001:db8:: is special and 2001:db8::1 is used by the ISP router. Your own router would usually be configured with 2001:db8::2, which means you have then used three addresses and a /127 will not be sufficient. A /127 could have worked if you hadn't used a hack with different prefix length configured on the two ends of the link.
    – kasperd
    Aug 18, 2015 at 8:19
  • thank you for explaining that! So when I have three routers serving three different internal networks, I should use a /125, and each router would advertise, via neighbor advertising, its own MAC only for those IPs in the corresponding subnet? Aug 18, 2015 at 8:24
  • 1
    There is an Informational RFC, RFC 7421, Analysis of the 64-bit Boundary in IPv6 Addressing, which has a complete discussion of the /64 subnet, and what my go wrong when not using it.
    – Ron Maupin
    Feb 26, 2016 at 19:47

Yes, pressuring your ISP to not suck is the preferred option. RIR allocation policies assume that the ISP is giving each customer a /48; there is absolutely zero reason for the ISP to not do that.

IPv6 is not a fan of smaller subnets, however the only thing that is supposed to break, that I'm aware of, is SLAAC. You'll have problems with bugs and assumptions in some IPv6 stacks, which just blindly assume "/64 == subnet", but that's a bug, not a feature, and you can beat up on the vendor to fix it. Whether it gets fixed before your ISP gives you a /48, on the other hand...

  • I think some parts of the neighbor discovery protocol are also supposed to break. The RFC 5375 has a whole list of other things but I don't really know the practical implications. Only getting a /64 can sometimes simply be a matter of money. Your ISP may give home users only a /64, and give /48s only to business accounts. Just because you want to separate your home office or your WiFi from the rest of the home, or because you want a separate subnet to use for virtual machines? Sorry about the rant - I'm trying to deal with a problem here, not trying to change things I can't control. Aug 18, 2015 at 5:16
  • 2
    If your ISP wanted to be a total knobsocket about it, they'd hand out a /128 to each residential subscriber. I guess you can wave RFC 5375 at the ISP and tell 'em to give you IPv6, rather than IPv5.5...
    – womble
    Aug 18, 2015 at 5:43
  • As a matter of fact, at least one ISP I know of does that (Verizon Wireless). It's one of the reasons I argue that NAT is still needed in IPv6. But that's separate from my question, of course. Aug 18, 2015 at 6:04
  • 1
    The /48 recommendation from RFC 3177 is no longer valid, most RIRs now recommend a /56 for end sites as described in RFC 6177: tools.ietf.org/html/rfc6177
    – skrause
    Aug 23, 2015 at 15:01
  • 1
    @skrause Not that it makes a difference anyway. There are enough /48s that they are not going to run out. Even at an 80% HD ratio it would take 2^36 allocated /48s before IANA would have consumed all of 2000::/3. And unless your end site is a major data center, then a /56 has enough subnets for your end site.
    – kasperd
    Aug 24, 2015 at 8:40

The /64 prefix is more easy to deploy since the ISP will have only one route to maintain instead of two.

I receive a /64 prefix from my ISP and I wanted to put a firewall between ISP and my internal network. I've added ip6tables rules and enabled radvd. The machines got their IP, but they could not find an external route.

At first I wanted do divide my internal network. Instead of external /56 and internal /64 I could have external /64 and internal /80? Then I've come to this thread and got disappointed as well since SLAAC won't work in /80.

I've kept researching and found out how to put a firewall between ISP with an /64 prefix and internal network with SLAAC. If that's the reason why you wanted subnetting, then the setup described ahead can help, but without subnetting.

RFC 3633 was extended with RFC 6603 and Prefix Delegation Exclusion was created.

You will need a DHCPv6 client compatible with RFC 6603 and your ISP's DHCPv6 server must be compatible either.

WIDE-DHCPv6 works, but I am an Slackware linux user and it's not readly available. Then I've found dhcpcd. In the man page look for the option ia_pd for more details.

In my setup eth0 is connected to internal LAN and eth1 is connected to an external router in bridge mode.

ipv4 is configured by Network Manager. In Network Manager ipv6 method is ignore.

Here is my /etc/dhcpcd.conf:

option rapid_commit
nohook resolv.conf
timeout 30
allowinterfaces eth1,eth0
interface eth1
iaid 1
ia_pd 1/::/64 eth0/0/64

Here is my /etc/radvd.conf:

interface eth0
AdvSendAdvert on;
MinRtrAdvInterval 10;
MaxRtrAdvInterval 30;
prefix ::/64
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;

Then start dhcpcd and radvd.

Internal LAN clients are using Network Manager with ipv6 configured as automatic.

  • 1
    This doesn't appear to have any relevance to the question. Jan 18, 2021 at 6:22
  • 2
    I am somewhat confused. SLAAC works out of the box with a /64 prefix; there should be no special configuration necessary. Also, I'm not sure how DHCPv6 figures into the picture. The purpose of SLAAC is to avoid the need for DHCPv6 (except for distributing certain DHCP options, such as DNS servers). Can you elaborate? Jan 19, 2021 at 6:16
  • 1
    SLAAC don't work if you receive a /64 prefix and you put a linux box routing packets and filterirng as a firewall between the ISP and your internal network. That's why I also wanted to divide my network and why I search this topic. Then I found out that I could have a firewall and a /64 prefix using the setup above. Sorry if I misunderstood and guessed wrong... There are few information about this available, all I could find is "change your ISP" but I don't have this option available...
    – Weber K.
    Jan 19, 2021 at 11:13
  • I've edited the answer indicating why I answered this way and the relation. Thanks for pointing that and sorry if that's not what you wanted.
    – Weber K.
    Jan 19, 2021 at 11:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .