IPv6 subnetting a /64 - what will break, and how to work around it?

Question

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.

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 04:04
Right now, that's pretty much my policy. I tell my clients to stay away from IPv6, but I would like to know my options rather than being "Mr. Negative". — Kevin Keane, Aug 18 '15 at 06:09
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 06:14
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 06:24
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 07:03
NAT wasn't a hack as much as a solution to some shortcomings in IPv4. In a perfect world, it wouldn't be needed any more in IPv6. In reality, the market has already spoken. Sure, initially some things may break with IPv6 NAT. Heck, many things are currently breaking with IPv6, period. All of those will be fixed. I just wish it had been standardized up front, instead of haphazardly being retrofitted. — Kevin Keane, Aug 18 '15 at 07:48
@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 08:52
@kasperd The key is the second part: incomplete implementations are a fact of life. Vendors (which includes not just ISPs, but also router manufacturers, especially in the consumer space, and others) have never in the history of IT been known to implement specs perfectly or completely, but IPv6 assumes perfect implementations. ISPs only handing out /64s, or even /128s (and getting away with it because they have a near monopoly) is one example. Consumer router makers implementing IPv6 with no firewalling whatsoever is another. "Mandatory" IPsec being left out is almost standard. — Kevin Keane, Aug 18 '15 at 09:10
@KevinKeane Sure you have to deal with bad implementations. The point where it becomes problematic is when certain people use other peoples bad implementation as an excuse for not doing their own part in making the situation better. As far as IPsec goes it was eventually made optional. A minimum implementation of IPsec according to the standard is more complicated than it should have been and useless because of features lacking. IPsec is not a meaningful reason to deploy IPv6 or refraining from doing so. — kasperd, Aug 18 '15 at 09:28
On revisiting this more than five years later, it looks like I was overly optimistic. No SLAAC 2.0 in sight, and IPv6 adoption is still, shall we say, lacking. — Kevin Keane, Jan 19 '21 at 06:19

kasperd · Accepted Answer · 2016-02-26T17:14:25.527

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 08: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 08: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 08: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 08:24
@KevinKeane I can't tell you how to configure it on specific routers. But I can tell you that the trick to "convert" a link /64 into a routed /64 can be modified to convert the link /64 into multiple routed prefixes (one for each router), which would then each have to be longer than a /64. I'll add that to my answer. — kasperd, Aug 18 '15 at 08:25
@KevinKeane Yes, with that number of routers a /125 would be sufficient. I would use a /124 though because I prefer subnetting on nibble boundaries when I don't have a particular reason to do otherwise. — kasperd, Aug 18 '15 at 08:33
There is an Informational RFC, [RFC 7421, Analysis of the 64-bit Boundary in IPv6 Addressing](https://tools.ietf.org/html/rfc7421), 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
ripe writes that "The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site)." - https://www.ripe.net/publications/docs/ripe-655#assignment_size - so the /64 seems valid, even if it it sucks, because it allows for only one subnet. — Simon, Sep 19 '17 at 14:25
The hack used to turn a link prefix into a routed prefix is probably seldom used. If IPv6 is used on the WAN side of your home router, then it probably means the ISP is routing the next prefix to your router. In this case, you can subnet the /64 and just have to worry about SLAAC being broken. Fortunately, running a DHCPV6 server on a little Raspberry Pi shouldn't be too hard. — explogx, Jul 04 '22 at 17:20

score 11 · Answer 2 · answered Aug 18 '15 at 05:02

11

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...

answered Aug 18 '15 at 05:02

womble

95,029
29
173
228

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 05: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 05: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 06: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: https://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 08:40

Weber K. · Answer 3 · 2021-11-28T14:46:56.673

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:

duid
option rapid_commit
nohook resolv.conf
background
timeout 30
noipv4ll
noipv6rs
reconfigure
allowinterfaces eth1,eth0
# WAN
interface eth1
ia_pd_mix
iaid 1
# LAN
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.

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? — Kevin Keane, Jan 19 '21 at 06:16
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 '21 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 '21 at 11:48

IPv6 subnetting a /64 - what will break, and how to work around it?

3 Answers3

Linked