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.

  • 9
    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. – Michael Hampton Aug 18 '15 at 4:04
  • 5
    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. – Michael Hampton Aug 18 '15 at 6:14
  • 2
    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. – Kevin Keane Aug 18 '15 at 6:24
  • 4
    Don't count on IPv4 mess like NAT to work properly with IPv6. NAT was a hack, not a feature... – Sander Steffann Aug 18 '15 at 7:03
  • 3
    @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 '15 at 8:52
up vote 26 down vote accepted

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.

Subnetting

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

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? – Kevin Keane Aug 18 '15 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. – Kevin Keane Aug 18 '15 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 '15 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? – Kevin Keane Aug 18 '15 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 '16 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. – Kevin Keane Aug 18 '15 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 '15 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. – Kevin Keane Aug 18 '15 at 6:04
  • 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 '15 at 15:01
  • @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 '15 at 8:40

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.