Major problem with DHCPv6 static mappings

JKnott

Here's a screen capture of my DHCP IPv4 mappings. I don't use DHCPv6 on the LAN. Are you saying that you don't get different IPv6 addresses Also, what operating system? In my experience with Windows, when the Ethernet cable is connected, the WiFi interface is not reachable, so it should make no difference if it has the same address as Ethernet. In Linux, both interfaces would be active and reachable.

BTW, those addresses are secret, so don't tell anyone.

ChrisJenk

@jknott With DHCP address reservations, which is what you are showing in your screenshot, the IP address is reserved based on the MAC address of the interface, so different interfaces on the same host can be assigned different IP addresses. That's all fine and I also do this and it works just fine.

DHCPv6 is different. It identifies hosts via a unique ID called DUID (DHCP Unique Identifier). Sadly, thsi identifier is unique only to a host, not to a specific interface. So every interface on a host requests a DHCPv6 address using the same DUID. Now, there is a second component, the IAID (Identity Association Identifier) which the client also includes in the request. The combination of DUID/IAID is unique to a specific host interface. So for dynamically assigned addresses DHCPv6 will always give each hist interface a unique address.

Unfortunately, when setting up a DHCPv6 static mapping (equivalent to a DHCP reservation) on pfSense you can only specify the DUID (even if you create the mapping from an existing dynamic allocation). Hence when any interface on that host asks for an address it gets the one in the static mapping. That's fine if there is only ever one interface active on the host at any time, but this is rarely the case. If multiple interfaces are active (and connected to the same network, also very common) then both get assigned the same IPv6 address which is of course very, very bad.

There is a long discussion of this here: https://forum.netgate.com/topic/43438/dhcpv6-and-iaid-duid-or-other-means-of-selecting-ips-by-interface/35

But that was in 2012 and it seems nothing has changed. This is very poor!

And to answer your other question, on macOS the WiFi and Ethernet are both active together, similar to Linux. You can set an 'order of preference' so that outbound traffic always uses Ethernet if it is available.

JKnott

@chrisjenk said in Major problem with DHCPv6 static mappings:

And to answer your other question, on macOS the WiFi and Ethernet are both active together, similar to Linux. You can set an 'order of preference' so that outbound traffic always uses Ethernet if it is available.

Both Linux and macOS are based on *nix and can route between interfaces, which is why they can have both interfaces working. I don't recall any such setting in Linux, but Ethernet is always preferred, when connected to the same network. There's something called metric which determines which interface will be used. Of course, both work when connected to different networks.

Regardless, what OS are you using? If Windows, this wouldn't be an issue. Also, do you need DHCPv6? Android devices won't work with it. You can thank some "genius" at Google for that one.

ChrisJenk

@jknott Yes, I am well aware of the heritage of macOS and Linux. My server systems are a combination of macOS and Synology NAS. My clients are mainly macOS and iOS with a couple of Windows and Linux systems.

Yes, I need DHCPv6 as I want to assign known but dynamic addresses to a significant subset of my client population.

awebster

@chrisjenk Your problem piqued my curiosity... I do have IPv6 implemented in a few networks, and while I've yet to into the problem you describe, I did test out your claim, and indeed, my windows 10 laptop has a DUID that is the same on all interfaces (one wired, and two wireless), only the IAD differs, so it appears to be a legitimate concern. Of note, a similar problem arises when machines are cloned from a golden image, they all end up with the same DUID!
According to the spec, the DUID is generated ONCE, at machine creation, and never changed again. Windows uses DUID-LLT which includes time (when windows was installed) and the mac address of one interface. Different OS vendors may of course implement this different ways.

Ultimately though, the problem appears to lie within the ISC DHCP server that is used in pfSense.
On the surface it seems that ISC's DHCPv6 implementation has neglected a way to specify the IAID part in a reservation. Your specific use case does come up in a handful of hits while searching for this, but it appears to be by no means common, either that or very few people are aware, or are using windows server's DHCP6 implementation which supports IAID.

RFC3315 makes it clear that a IAID,DUID tuple is needed to >>uniquely<< identify an interface of a client. Link here

DHCPv4 reservations have worked well for most use case scenarios, and in comparison, one gets the feeling that the DHCPv6 reservations mechanism was over-engineered to cover just about any imaginable use case, and consequently is confusing.

pfSense's DHCP server doesn't pretend to be all things to all users, in the end, you may need to run a separate DHCP server to get around the issue.

Lastly, when digging around for info on this issue, I did see that ISC has developed a new, more modern, DHCP server, called KEA. It does appear to support IAIDs, at least for prefixes, or that's what I could find in the format of ipv6prefix@iaid. Maybe it also works for single IPs. Anyway, a moot point since that's not what is in pfSense.

ChrisJenk

@awebster Thanks for confirming my suspicion. This is quite disappointing given how good pfSense seems to be in most other areas. I could as you say try to run a separate DHCPv6 server butt frankly one of the reasons I bought my SG-3100 was to consolidate all of the network management stuff into a single 'best pf breed' appliance. I don't want to have to start downloading/building/maintaining another piece of software to overcome this one shortcoming.

I guess I need to find out how to log a bug / feature request against pfSense.

Bob.Dig

@jknott said in Major problem with DHCPv6 static mappings:

Also, do you need DHCPv6? Android devices won't work with it. You can thank some "genius" at Google for that one.

What do you mean by that?

Bob.Dig

@chrisjenk said in Major problem with DHCPv6 static mappings:

That's fine if there is only ever one interface active on the host at any time, but this is rarely the case.

Is it though? I would say it is the overwhelming case.
But you are right, if you got two on the same network, then DHCPv6 is only working for one.

ChrisJenk

@bob-dig As I explained, it isn't the overwhelming case at all in some scenarios; here at home for example it is the common case. Probably less so in a more enterprisey setup. Also, even in this case DHCPv6 works fine unless you use static mappings. Sadly, I really want to use static mappings for a segment of my client population.

This is clearly a deficiency in pfSense DHCPv6 support (one might call it a bug).

JKnott

@bob-dig said in Major problem with DHCPv6 static mappings:

What do you mean by that?

Android devices don't support DHCPv6. This was a decision by someone on the Android team at Google.

NogBadTheBad

Don’t most operating systems disable wifi if ethernet is enabled and on the same subnet.

Bob.Dig

@jknott said in Major problem with DHCPv6 static mappings:

Android devices don't support DHCPv6. This was a decision by someone on the Android team at Google.

You're right. Should have my phone checked first.

ChrisJenk

@nogbadthebad If by 'most' you mean Windows then yes (so I am informed). Neither Linux nor macOS do so however. There is no reason to do so after all (unless your DHCP server has incorrectly handed out the same IP address to both interfaces!).

JKnott

@nogbadthebad said in Major problem with DHCPv6 static mappings:

Don’t most operating systems disable wifi if ethernet is enabled and on the same subnet.

No, *nix use "metric" to decide. The lowest metric is selected. For example, my ThinkPad is connected via both Ethernet and WiFi to my LAN. Here's what it shows:

ip route show
default via 172.16.0.1 dev eth0 proto dhcp metric 100
default via 172.16.0.1 dev wlan0 proto dhcp metric 600
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.42 metric 100
172.16.0.0/24 dev wlan0 proto kernel scope link src 172.16.0.40 metric 600

Since Ethernet has a 100 metric and WiFi 600, Ethernet will be used.

This is basic routing and all the routing protocols use a metric for the the routes to pick the best one. For example, the obsolete Routing Information Protocol (RIP) used hop count. So a single hop would have a lower metric than a 2 hop route and be selected. More sophisticated routing protocols, such as OSPF or EIGRP use more advanced metrics that can also include things like bandwidth and more.

A bit of history, IP was created on BSD Unix, at University of California, Berkeley and the Internet is pretty much built on various Unix, including Linux, variants and even Cisco has used Unix or Linux in routers.

NogBadTheBad

@jknott

A bit of history, IP was created on BSD Unix, at University of California, Berkeley and the Internet is pretty much built on various Unix, including Linux, variants and even Cisco has used Unix or Linux in routers.

Yup I’m old enough to remember installing the Unipalm TCP IP stack onto DOS PCs as well as Windows.

JKnott

@nogbadthebad

I never had occasion to use IP on DOS. Back in those days, we had Netware at work and I recall modifying config.sys and autoexec.bat to run it. NET3 & NETX come to mind. I didn't deal with IP until I got my own connection and was running OS/2. Then, at IBM, I worked with IP, SNA and NetBIOS on token ring.