DHCPv6 on Track Interface
-
Separate issue, though related to DHCPv6 on Track Interface…
When making a change to interface settings on an interface with Track Interface and DHCPv6 server enabled, I receive an error that "DHCPv6 Server is active on this interface and can only be used with a static IPv6 configuration". Obviously that isn't true now, so that check may want to be modified to include Track Interface as a valid option for DHCPv6 server.
In fact... is DHCPv6 Server now available regardless of what method is used to configure the interface, or is it only for Track Interface and Static now?
-
@virgiliomi:
When making a change to interface settings on an interface with Track Interface and DHCPv6 server enabled, I receive an error that "DHCPv6 Server is active on this interface and can only be used with a static IPv6 configuration". Obviously that isn't true now, so that check may want to be modified to include Track Interface as a valid option for DHCPv6 server.
Thanks. That was missed in the process, I just fixed that.
@virgiliomi:
The PREFIXES for delegation obviously need to be within the /60 though. Also, there should probably be an example way to enter the prefixes for delegation, as it took me a bit of trial and error to get it to accept my entries.
Edit to add: If the prefix that has been delegated is just a /64, the Prefix Range boxes should probably be disabled, since there aren't other prefixes that could be sub-delegated.
That brings up a bit of a conundrum. edit: it wasn't implemented. But, you could be assigning PD to downstream hosts completely outside your PD-obtained subnet, could be something statically-routed for instance, or ULA for internal use only. As-is, it doesn't appear you can do that. That's probably something that'll need more consideration and input validation in the future.
-
Something new… I noticed that even though I had the DHCPv6 address range set to ::1000 to ::1FFF on both of my networks, I had hosts on both of them that were getting ::2000 addresses. So I dug into the dhcpdv6.conf file (/var/dhcpd/etc/dhcpdv6.conf) and sure enough, the settings in the file weren't what they should be.
subnet6 [prefix 0]::/64 {
range6 [prefix 0]::1000 [prefix 0]::2000;
do-forward-updates false;
option dhcp6.name-servers [prefix 0]:xxx:xxff:fexx:xxxx;
prefix6 [prefix]8:: [prefix]c:: /63;
option dhcp6.name-servers [prefix 0]:xxx:xxff:fexx:xxxx;
}range6 SHOULD BE [prefix 0]::1000 [prefix 0]::1FFF
prefix6 SHOULD BE [prefix]a:: [prefix]f:: /64The same range should apply to my other network using prefix 5, but there should be no prefix delegation there. So it doesn't look like it's changing the config file with the settings I'm specifying, though the prefix in the file is correct.
-
There is code in services.inc that seems to be using some hard-coded settings when the user has already enabled DHCPv6 and specified the settings.
That code should be executed when the user has NOT already enabled DHCPv6 on a track6 interface.I am not in a position to test, but I think this little change will help: https://github.com/pfsense/pfsense/pull/2701
-
Ah I didn't notice when cleaning up things that the code block there was now entirely unnecessary. I removed it in its entirety, and now your user-defined config will be in dhcpdv6.conf. Thanks for the hint Phil, that make it quicker to fix.
-
Close… :)
The range6 setting shows up just fine in the config file...
The prefix6 range isn't in the config file correctly though. It's not adding the prefix before what I've entered in the settings boxes. For example, I want to be able to delegate out /64 prefixes ending in A through F from my /60... so I put a:: and f:: in the start/end boxes for prefix delegation, expecting it to add the rest of the prefix before what I entered… but it didn't.
This will go back to the earlier conundrum over PD of PD, because there needs to be some kind of input validation to make sure that the values entered fall within the PD that has been received from the ISP... but doing that would prevent your scenario of delegating a different prefix that isn't within the PD received from the ISP.
Since sub-delegation isn't a big deal for me (after all, it is just me on my network), I'll happily forego that for now... but it would be nice to get it working so if I wanted to test another router through my LAN, I could give it a /64.
-
The prefix6 range isn't in the config file correctly though. It's not adding the prefix before what I've entered in the settings boxes. For example, I want to be able to delegate out /64 prefixes ending in A through F from my /60… so I put a:: and f:: in the start/end boxes for prefix delegation, expecting it to add the rest of the prefix before what I entered... but it didn't.
I don't see any code to add the upstream-delegated prefix to whatever you put in the prefixrange boxes.
If the upstream delegates with a bit count that is some multiple of 4 less than what you want to hand out downstream, then the code would be relatively easy (e.g. you get a /60 from upstream and give out /64) because you can just dump in some hex digit range in place of the first 0 after the top 60 bits.
But if upstream does something odd (e.g. like giving you a /61 ! ) then how does the system deal with that - you have 8 /64 to give out - might be 0 to 7 or 8 to f, depending on where the /61 starts.
So the thing needs some designing so that the user can say what relative range they want to use (e.g. 2 to 5 of an upstream that might be /61 in the dodgy example above) and then if the actual prefix coming from upstream is the 8 to f part, then the user-specified 2 to 5 would be 8+2=a to 8+5=d
As you mention, there is the problem of validation of user input - because after the user puts something in, the upstream provider might later issue a smaller delegation.
-
While we are at it I have noticed with the Services -> DHCPv6 Server & RA -> DHCPv6 Server main pool range when you have like a /60 subnetted to /64s and an opt1 interface pool range set (mine was from :: to ::ffff ) then try to change LAN's range say from :: - ::8fff to :: - ::ffff it tells you that it overlaps with another interface even though they are in different /64 subnets
It doesn't seem to do it with changing OPT1's range to overlap the LAN range for some reason.
The exact error is:
The following input errors were detected:
The DHCP range cannot overlap any static DHCP mappings.
-
I just fixed the mask on the DHCPv6 server page to use /64 for track6 interfaces, that should fix that overlap issue I believe. It wrongly was calculating things as if the entire PD was on one interface previously.
I don't see any code to add the upstream-delegated prefix to whatever you put in the prefixrange boxes.
If the upstream delegates with a bit count that is some multiple of 4 less than what you want to hand out downstream, then the code would be relatively easy (e.g. you get a /60 from upstream and give out /64) because you can just dump in some hex digit range in place of the first 0 after the top 60 bits.
But if upstream does something odd (e.g. like giving you a /61 ! ) then how does the system deal with that - you have 8 /64 to give out - might be 0 to 7 or 8 to f, depending on where the /61 starts.
So the thing needs some designing so that the user can say what relative range they want to use (e.g. 2 to 5 of an upstream that might be /61 in the dodgy example above) and then if the actual prefix coming from upstream is the 8 to f part, then the user-specified 2 to 5 would be 8+2=a to 8+5=d
As you mention, there is the problem of validation of user input - because after the user puts something in, the upstream provider might later issue a smaller delegation.
Yeah that wasn't handled at all, after looking at it again. There are certainly a bunch of potential caveats to that, like those you mentioned, and probably others we haven't thought of. Not sure that's something we'll be able to properly address in 2.3-REL. I'll take a closer look at it but probably end up creating a feature ticket for a future version.
-
We'll leave things as-is for prefix6 for 2.3-REL at least. I opened a feature for adding support.
https://redmine.pfsense.org/issues/5950The rest all looks good now, including multiple internal networks and static mappings.
-
The pool overlap issue is fixed for me, thanks a ton cmb!
my new dhcp pool: ::b00b:0 - ::b00b:f331
