Router Advertisement
-
Hi,
I have questions regarding pfSense RAs. It is safe to say that the pfSense box will be a (the) gateway on a given link. It may not be the DHCPv6 server, however. In fact, it may be a DHCPv6 client on internal as well as external networks. Why is RA enablement under DHCP6 Server setup? It is necessary that the pfSense box announce its availability as a router/gateway to the link even if it is not serving as the DHCPv6 server for said link. Having the RA option on the DHCPv6 Server page also prevents the RA from propagating on links where the interface IPv6 address is assigned by DHCPv6. The RA is necessary not only to provide clients on the link with the gateway address but also to tell them to use stateful (DHCPv6) configuration by setting the Managed and Other flags (the case where pfSense is the gateway but another host on the link is a DHCPv6 server or relay).
It seems to me that the RA and M and O flag enablement (for that matter, ALL configurable rtadvd.conf parameters) should be separated from DHCPv6 Server options and be independent of the method by which the interface was assigned its IPv6 address.
Just a thought… If I'm missing something, let me know.
Mike Pugh -
It was put there (at least for now) because logically that is where people, especially those with little IPv6 knowledge), would go if they wanted to control how the firewall hands out information to clients.
It is controlled independently from DHCPv6, it's just on the same page.
As the options stat:
Select the Operating Mode for the router advertisement Daemon. Use "Router Only" to only advertise the router, "Unmanaged" for Router Advertising with Stateless Autoconfig, "Managed" for DHCPv6 only with router advertisements, "Assisted" for DHCPv6 Combined with Stateless Autoconfig
So DHCPv6 would only be used for Managed or Assisted, and I believe those can still be set even if you have DHCPv6 disabled, which would imply that DHCPv6 is happening elsewhere on your LAN.
-
I realize I may have convoluted the issue a little, but the more I thought about it, the more it seemed like the issue was a little bigger than the one that started the train rolling. I do indeed have a DHCPv6 server on the link other than the pfSense box. I want the router to get its internal IPv6 addresses from this server (pfSense is a DHCPv6 client internally AND externally). I can't find anything in the RFCs that would specifically prohibit this, and it's already set up this way for IPv4. Anyway, since an interface cannot act as both a DHCPv6 server AND client, the tabs for internal DHCPv6 client interfaces are not available on the DHCPv6 Server page. Hence, the RA options are not available for these interfaces. However, since DHCPv6 does not (yet, anyway) provide an option to distribute the gateway address to clients on the link, it is absolutely necessary that the router be able to advertise itself–even on links with interface IPv6 addresses provided by DHCPv6. Also, it's the router advertisement that tells the clients to use DHCPv6 by setting the M (and possibly O) flag and potentially disables autoconfiguration by resetting that flag. There's a catch 22 here: DHCPv6 relies on RAs to provide clients with gateway addresses (and instructions to use DHCPv6) and, if the pfSense box is itself a DHCPv6 client on a link, it cannot announce itself or provide instructions in an RA for that link--but only because the RA functionality is presently tied in with DHCPv6 server functionality. I hope this is somewhat clearer.
Thanks,
Mike Pugh -
I see a network hack 101
You can only run 1 dhcp6 client on pfSense so this would not work either way.
You run a DHCP6 client on the WAN, a static config on the LAN.
You can run a DHCP6 client with prefix delegation on the LAN.But your suggestion is just mad hatters work.
You are free to set the router advertisements on the LAN to Managed and let another DHCP6 server manage the addresses.
Router advertisements always send the link-local address of the router. But you can only announce the prefix if you know what it GUA prefix is.
-
I'm not sure what you mean in your second sentence. I already have pfSense sending DHCPv6 Solicit messages on two LANs without any hacking–just standard WUI configuration. Granted, I'm not getting Advertisements back from the server, but that's a WIDE issue that I'm trying to resolve separately, and the fact remains that pfSense is acting as a DHCPv6 client on internal interfaces (assuming it will make the assignments when it does get the proper replies from the server--again, a WIDE issue).
Let's begin with the assumption that the router (pfSense) and the DHCPv6 server are two distinct machines. Also assume we wish to disable SLAAC and enable DHCPv6 for stateful configuration in our RAs. Microsoft's DHCPv6 server requires that the 64-bit scope prefix be entered manually. Therefore, prefix delegation won't work automatically in this scenario anyway; that is, the DHCPv6 server does NOT automatically designate its prefix based on information obtained from the router. (DHCPv6 could be used solely for unique local address assignment, for example.)
Forget about the (A)utonomous, (M)anaged and O(ther) flags for the time being. Since DHCPv6 does not advertise the router address, the router MUST advertise itself on the LAN (regardless of how its LAN interface obtains its non-link-local address–statically or dynamically); otherwise, other LAN hosts can't send/receive messages beyond the local link. In pfSense, the router can only send RAs to the LAN if the LAN interface has a static non-link-local address and, since the router is NOT also acting as the DHCPv6 server per our assumption, there is no reason why this should be necessary. The fact that the router uses its link-local address in the RA further reinforces my position because the router advertisement does NOT depend on or advertise the non-link-local address assigned to the interface regardless of how it is assigned.
I used italics to emphasize that these two systems–Router Advertisement and DHCPv6--while often acting in concert are, in fact, independent of each other (with one glaring exception: the A, M and O flags we chose to ignore, which are needed to tell hosts on the LAN not to use SLAAC and to use DHCPv6). I have exactly the functionality I have described working on FreeBSD machines (save the apparent incompatibility between Microsoft and WIDE DHCPv6). I would also have it running identically in pfSense if I could send RAs out on a LAN interface that has a dynamically assigned non-link-local address and I can't think of one logical reason not to allow this.
I could actually provide several reasons why you should allow it, but this issue is getting needlessly complicated again and it should suffice just to say, "Two independent systems deserve two independent configuration pages." Again, just a thought...
-
On another related note after further reflection, there will be an issue with prefix delegation if the router and DHCPv6 server are two distinct machines. The router must either request and be granted the preferred prefix (the one manually entered as a scope into the DHCPv6 server) from an upstream delegating router (no guarantees here) or it must notify the DHCPv6 server that there is a new prefix. Is there even a mechanism for this? A router advertisement seems like an obvious candidate, but I know the MS DHCPv6 won't change its scope automatically.
So, here's another catch 22: no NAT with IPv6 so all our addresses must be globally routable for Internet access, but even with 232 times as many globally unique prefixes as we previously had globally unique addresses (and 264 addresses for each prefix), we still must rely on our ISP to dynamically assign the prefix. Huh? A statically assigned prefix would solve the delegation problem hands down and you can't tell me there aren't enough to go around (and you could always assign longer prefixes with fewer addresses). Am I missing something? Isn't this how the IPv4 address space was initially distributed?
-
the wide client only supports one socket, so the 1st client wins.
That would explain why it fails to work. Good luck.
-
Two sets of questions:
How would having only one socket manifest itself? I got pfSense to get DHCPv6 addresses from W2k8, but it will only TRY to get one at a time; that is, it will only send a Solicit on one interface if more than one is configured as a DHCPv6 client. This seems odd because my FreeBSD machines send Solicits on all interfaces so configured. Also (and if anybody knows the answer to this, I'd just about pay for it), pfSense is getting Advertise and Reply messages, whereas my plain old FreeBSD machines are not. What have I forgotten to configure on the FreeBSD boxes that pfSense evidently automatically configures?
By the way, I altered the code in /etc/inc/interfaces.inc to read IAIDs in from files named <interfacename>.iaid in the /var/etc directory and it's producing /var/etc/dhcp6c_<interfacename>.conf files correctly so that DHCPv6 reservations work as planned. This should make it easy to test an IAID field if you still plan to add one. Now, if I can just figure out the one socket business. I figured once one address was assigned by DHCPv6, the second, third, etc. would not be assigned and I can't test this on the FreeBSD machines until I succeed in getting an Advertise and Reply back. But the pfSense box doesn't even send a Solicit on the second, third, etc. links even if it has yet to be assigned an address on the first.
The second part of my questions has to do with the RA itself. What is the difference between Managed and Assisted modes? From the description, I assumed that the Autonomous flag would be reset for Managed and set for Assisted, but as far as I can tell, it is set for both. Also, there is no option to set only the Other flag (Managed flag reset), which you would use if you wanted to use SLAAC to get the address and DHCPv6 for DNS, NTP, SIP addresses, etc., i.e. "information only" requests. I thought maybe this is what you meant by Assisted, but again, AFAICT the L, A, M, and O flags are all set for both the Managed and Assisted Modes. This is yet another reason to support the RA configuration section being fully and independently configurable (I really hope you will eventually reconsider this).
I realize that DHCP6 functionality may not be near the top of the list of things you guys are actively working on for the next stable release, but I do think it will require very little effort to have this working and I don't mind helping at all. Only the socket issue, which, if I understand you correctly, is going to require fixing the WIDE code, may be an obstacle. I don't think it would be difficult to fix the WIDE code (I've looked at it), I just don't know if you would consider that your purview. Still, it would be nice to have this in full conformance with the RFCs. I'm assuming, of course, that Windows, Linux, or BSD boxes should have identical functionality where the protocol is concerned and should be interchangeable in both server and client roles.</interfacename></interfacename>
-
there is a bug in the current ra config mode where it does not set the right mode. That is still open for fixing.
The IAID will have to be saved into the config.xml to make sure it persists, not sure why it needs another file unless the clients needs to have it that way.
Also, I will likely pull the wide client and move to the ISC dhcp6 client at some point. Atleast before 2.1 is released.
That client supports configuring a "pretty" ipv6 address on a prefix delegated. e.g. <prefix>::1
It's not that dhcp6 server is not a priority, but I'd rather get cascading prefix delegation working.</prefix>
