61
19.1 Legacy Series / Re: Dual WAN IPV6 DHCP is broken
« on: May 23, 2019, 04:49:23 pm »
Well, that's one solution to the "How do I do multihome with IPV6". Perhaps we should add it to the list at RFC7157
In seriousness, I've been digging and investigating. I wondered if there was a hint in the dhclient code - but nope, it looks like it relies on the SO_BINDTODEVICE on linux and is generally considered broken elsewhere. Except, it's not really.
One of the tricks they use in the dhclient code is that they rebind once they have an address. Perhaps that's the solution here, too? Once an interface gets an address, it's dhcp6c client reopens the socket, bound to it (this seems to be what dhclient does). I'm not 100% familiar with everything DHCP, but I think it should work, maybe? Is there a reason to keep listening on the wildcard interface, after you have an assigned address?
The only other solution I can think of is some sort of multiplexing - either rewrite the dhcp6c code to support managing multiple interfaces simultaneously (that looks like a complicated mess), or else write a proxy dispatcher that somehow can route to the right dhcp6c instance (that looks almost as complicated. Hmmm).
One thing I saw mention of, is that BSD has a concept of "routing table" per process instance. Perhaps that might be another solution as well - I'm not familiar with BSD specific network programming, so I don't have much insight, other than what I can google up.
Of course, all of these solutions are probably a significant development effort, so I completely understand why it's unlikely to be fixed anytime soon.
One super janky solution I thought of was to just kill the "younger" process off occasionally. I'm presuming dhcp6 is pretty fault tolerant. So perhaps every hour or so, just kill the one with the lower pid, which seems to be the one getting the traffic. Does OPNSense restart a killed dhcp6c process?
In seriousness, I've been digging and investigating. I wondered if there was a hint in the dhclient code - but nope, it looks like it relies on the SO_BINDTODEVICE on linux and is generally considered broken elsewhere. Except, it's not really.
One of the tricks they use in the dhclient code is that they rebind once they have an address. Perhaps that's the solution here, too? Once an interface gets an address, it's dhcp6c client reopens the socket, bound to it (this seems to be what dhclient does). I'm not 100% familiar with everything DHCP, but I think it should work, maybe? Is there a reason to keep listening on the wildcard interface, after you have an assigned address?
The only other solution I can think of is some sort of multiplexing - either rewrite the dhcp6c code to support managing multiple interfaces simultaneously (that looks like a complicated mess), or else write a proxy dispatcher that somehow can route to the right dhcp6c instance (that looks almost as complicated. Hmmm).
One thing I saw mention of, is that BSD has a concept of "routing table" per process instance. Perhaps that might be another solution as well - I'm not familiar with BSD specific network programming, so I don't have much insight, other than what I can google up.
Of course, all of these solutions are probably a significant development effort, so I completely understand why it's unlikely to be fixed anytime soon.
One super janky solution I thought of was to just kill the "younger" process off occasionally. I'm presuming dhcp6 is pretty fault tolerant. So perhaps every hour or so, just kill the one with the lower pid, which seems to be the one getting the traffic. Does OPNSense restart a killed dhcp6c process?