Our future IPv6 access control problems due to non-DHCP6 machines

September 6, 2018

Back almost two years ago, I wrote about how I suspected a lot of IPv6 hosts wouldn't have reverse DNS because they would be using stateless address autoconfiguration (SLAAC) where they essentially assign themselves one or more random IPv6 addresses when they show up on your network. For us, this presents a problem much larger than just DNS, because control over what hosts DHCP will give addresses to (and what addresses it will assign) are how we force machines to be registered on our laptop network and our wireless network before we give them network access.

The specific driver of IPv6 SLAAC is Android devices, which don't do DHCP6 at all; unfortunately this also includes ChromeOS, which means Chromebooks. But once you enable SLAAC on your network, any number of things may decide to grab themselves SLAAC addresses and then use them, even if they also do DHCP6 and so get whatever address you give them there (this is the iOS behavior I observed a couple of years ago; I don't know how Windows, macOS, and so on behave here). If the IPv6 address and routing they get via DHCP6 doesn't seem to work, I suspect that quite a lot of devices will be perfectly happy to route via their SLAAC address and route, and if that doesn't work, well, the Android and ChromeOS devices aren't getting on the Internet.

There are a number of approaches I can think of. One possible brute force answer is to simply not do SLAAC, only DHCP6 and (IPv4) DHCP. This would mean that SLAAC-only devices would only get IPv4 addresses, but that's not likely to be a practical problem for a long time to come. I think this is our most likely short term answer, because it's the easiest approach and we can always get more complicated later. The other brute force approach is some sort of MAC filtering on our firewalls, but we use OpenBSD and my understanding is that there are a number of issues around MAC filtering in OpenBSD PF.

The officially approved answer is probably to move to IEEE 802.1X on our networks that require this sort of access control. This is infeasible for multiple reasons, including that I believe it would require a wholesale replacement of our network switches on the affected networks. For extra bonus points we don't even run much of the infrastructure that provides our wireless network, which is one of the networks we need this access control on (this is not as crazy as it sounds, but that's another entry).

All of this is yet another reason why any migration to IPv6 will be neither fast nor easy for us, and thus why we still haven't done more than vaguely look in the direction of IPv6. Someday, maybe, when IPv6 appears to actually be important for something.

(And when we do start doing IPv6, it's highly likely to start out being only for a few servers with static IP addresses. Extending it to people's own 'client' devices is likely to be one of the last things we get around to.)

(I was reminded of all of this today by cweiske's question on my old entry.)

Comments on this page:

By James (trs80) at 2018-09-07 06:53:42:

Do your switches support MAC-based authentication? PacketFence is worth a look if so. And if your central IT can identify devices on the wireless that they should query you for (a distinct SSID?) then they can forward the EAP RADIUS requests to your PacketFence server for authorisation.

By Arnaud Gomes at 2018-09-08 18:25:33:

If I may venture one piece of advice from someone who has been running static/SLAAC-only IPv6 networks for the last 15 years: don't even try to regulate access with DHCP. At best it will be useless, at worst it will break all sort of things and annoy your users.

We have been running client machines on a DHCPv6-enabled network for a few months at work (said network is operated by a big French hoster); we have reverted to IPv4 only for those machines, as we have not been able to make things work reliably even by doing everything by the book.

I know it is a pain in the ass in your situation, but your access control belongs in layer 2. I have had some success with Cisco switches (Catalysts, not the Small Business pieces of junk) and cheap wireless access points running OpenWRT and a locally patched hostapd (I think), but I have not kept current with this side of things for a few years so I don't know what works in large scale networks nowadays.

By cks at 2018-09-08 20:11:14:

Unfortunately I believe that our switches are much too low end to support even things like MAC-based authentication. Perhaps we could hack up a solution by buying a few switches that supported (a lot of) MAC-based authentication and then running them at relatively central points in our laptop/bring your own device network, for example as the top level switches in each building or building area.

(We're extremely unlikely to engage in a wholescale switch upgrade in order to support IPv6 on our laptop network unless supporting IPv6 becomes critical, and I just don't see that happening.)

Written on 06 September 2018.
« Some views on the Go 2 Error Inspection early draft proposal
I've slowly been improving my web experience by trusting uMatrix more »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Sep 6 00:00:52 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.