DHCP DUID file not preserved across reboots when "Use RAM Disks" is enabled
-
This is a good idea. My ISP does not delegate static prefixes, but they told me that as long as the DUID is consistent, they will make best effort to not change the prefix unless the gateway goes offline for an extended duration.
-
I'm very slightly annoyed… I submitted that as a bug, and it got marked as a duplicate of a feature request.
The RFC text is pretty unambiguous: "The DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server - that is, the DUID used by a client or server SHOULD NOT change over time if at all possible..."
So, if pfSense claims that it's a legit IPv6 DHCPv6 client, and knowingly changes the DUID when it would be trivial NOT to change it, isn't that a bug?
(It probably doesn't matter how it's classified in the bug tracker... well, it would to ME.. Professionally, I generally handle bugs before I handle feature requests (and any unfixed BUGS get documented while unhandled feature requests might get ignored.) Of course, with it being easy enough to work around the issue (https://forum.pfsense.org/index.php?topic=114390.0), I suppose a person could say it's a low priority bug. However, it's still a bug. ;)
-
I'm very slightly annoyed… I submitted that as a bug, and it got marked as a duplicate of a feature request.
The RFC text is pretty unambiguous: "The DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server - that is, the DUID used by a client or server SHOULD NOT change over time if at all possible..."
So, if pfSense claims that it's a legit IPv6 DHCPv6 client, and knowingly changes the DUID when it would be trivial NOT to change it, isn't that a bug?
(It probably doesn't matter how it's classified in the bug tracker... well, it would to ME.. Professionally, I generally handle bugs before I handle feature requests (and any unfixed BUGS get documented while unhandled feature requests might get ignored.) Of course, with it being easy enough to work around the issue (https://forum.pfsense.org/index.php?topic=114390.0), I suppose a person could say it's a low priority bug. However, it's still a bug. ;)
I think it's a "feature". It's not that it "knowingly changes the DUID", it just doesn't remember it. ;)
-
(It probably doesn't matter how it's classified in the bug tracker… well, it would to ME.. Professionally, I generally handle bugs before I handle feature requests (and any unfixed BUGS get documented while unhandled feature requests might get ignored.) Of course, with it being easy enough to work around the issue (https://forum.pfsense.org/index.php?topic=114390.0), I suppose a person could say it's a low priority bug. However, it's still a bug. ;)
I think it's a "feature". It's not that it "knowingly changes the DUID", it just doesn't remember it. ;)
True… but most likely anything they do to implement saving the DUID would likely also allow it to be knowingly changed by a user... if they make it part of the config file, you can edit the config file and you've changed the DUID.
As to the OP's comment about feature request vs bug... the feature request was only created as such because at the time the creator was looking for a way to be able to back up the DUID for transferring to a new device, or having to restore a config to pfSense after reloading, or whatever other reason it may have been needed. If anything, your bug - which was noted in the original feature request - may speed up work on the functionality. There might be other work that is tied to that existing feature request - there's been a field in the config for the past few version releases that has a variable name including DUID, but nothing is yet stored in it - which is why they want to keep it open, and thus marked yours as a duplicate.
-
@virgiliomi:
(It probably doesn't matter how it's classified in the bug tracker… well, it would to ME.. Professionally, I generally handle bugs before I handle feature requests (and any unfixed BUGS get documented while unhandled feature requests might get ignored.) Of course, with it being easy enough to work around the issue (https://forum.pfsense.org/index.php?topic=114390.0), I suppose a person could say it's a low priority bug. However, it's still a bug. ;)
I think it's a "feature". It's not that it "knowingly changes the DUID", it just doesn't remember it. ;)
True… but most likely anything they do to implement saving the DUID would likely also allow it to be knowingly changed by a user... if they make it part of the config file, you can edit the config file and you've changed the DUID.
As to the OP's comment about feature request vs bug... the feature request was only created as such because at the time the creator was looking for a way to be able to back up the DUID for transferring to a new device, or having to restore a config to pfSense after reloading, or whatever other reason it may have been needed. If anything, your bug - which was noted in the original feature request - may speed up work on the functionality. There might be other work that is tied to that existing feature request - there's been a field in the config for the past few version releases that has a variable name including DUID, but nothing is yet stored in it - which is why they want to keep it open, and thus marked yours as a duplicate.
I took a look at the RFCs where DUIDs are defined. In RFC 3315, three variants of DUID are defined (DUID-LLT, DUID-EN and DUID-LL). RFC 6355 adds a fourth, DUID-UUID. UUID is defined in RFC 4122. If pfSense is going to store the DUID, it should probably be able to generate and store multiple formats, depending on service provider requirements. When I asked my service provider about this, the response was UUID. (Presumably the intention was to say DUID-UUID. I just sent an email asking for clarification.)
-
I took a look at the RFCs where DUIDs are defined. In RFC 3315, three variants of DUID are defined (DUID-LLT, DUID-EN and DUID-LL). RFC 6355 adds a fourth, DUID-UUID. UUID is defined in RFC 4122. If pfSense is going to store the DUID, it should probably be able to generate and store multiple formats, depending on service provider requirements. When I asked my service provider about this, the response was UUID. (Presumably the intention was to say DUID-UUID. I just sent an email asking for clarification.)
Does the ISP say to the router "Please provide a DUID. I'd prefer type LLT"? My impression (which might be wrong) is that the ISP doesn't ask for any particular type of DUID.. it just asks for a DUID. I think the different RFC's are just different methods for machines (not interfaces) to determine how to create a DUID and how to form the actual data structure to indicate which method was used.
Despite my referencing the incorrect RFC in an earlier post, DHCPv6 is defined in rfc3315. Section 9 defines a DUID… That includes the following text:
The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server - that is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware.It then goes on to explain why there might be different types of DUID's (must be globally unique, must be easy to generate and some devices might not contain any persistent storage - so DUID retention is impossible.)
It's my understanding that pfSense uses the DUID-LLT type. The same RFC contains the following text in regards to DUID-LLT:
Clients and servers using this type of DUID MUST store the DUID-LLT
in stable storage, and MUST continue to use this DUID-LLT even if the
network interface used to generate the DUID-LLT is removed. Clients
and servers that do not have any stable storage MUST NOT use this
type of DUID.There isn't any leeway in this. If pfSense is using the LLT method, it MUST store the DUID in stable storage (which is does not do.) If pfSense doesn't have stable storage (or if stable storage isn't going to be used), then it shouldn't be using the LLT type.
Oh, and the RFC also specifically suggests using LLT for routers:
This method of DUID generation is recommended for all general purpose
computing devices such as desktop computers and laptop computers, and
also for devices such as printers, routers, and so on, that contain
some form of writable non-volatile storage.…. This RFC also defines the DUID-EN and DUID-LL types. The "EN" is basically a hard-coded number that will never change. For that one, it "MUST be assigned to the device at the time it is manufactured and stored in some form of non-volatile storage. The generated DUID SHOULD be recorded in non-erasable storage."
..and finally DUID-LL: "This type of DUID consists of two octets containing the DUID type 3, a two octet network hardware type code, followed by the link-layer address of any one network interface that is permanently connected to the client or server device." Again, this won't change because the machine reboots.
Moving on to RFC6355.. this is DUID-UUID. (This is the RFC I shouldn't have linked earlier.) Regardless, this RFC states: "DHCP UUIDs should be persistent across system restarts, system reconfiguration events, system software and operating system upgrades or reinstallation as well as be easily available to any part of the boot process that requires access to the DHCP UUID."
.....
Are there any other types of DUID? Searching out the RFC's can be painful...
In all the cases above (DUID-LLT, DUID-EN, DUID-LL, DUID-UUID), the related RFC clearly states that the DUID shouldn't change. Therefore, this is a BUG in pfSense. Not a feature request.
The "feature request" that my bug was linked to might fix the BUG as a side effect, but fixing the BUG doesn't imply that the feature request will be fulfilled.
-
I guess there's no way to remove the "duplicate" flag from that ticket? Should I enter a new ticket? Can someone from pfSense give me an idea what to do here?
-
I took a look at the RFCs where DUIDs are defined. In RFC 3315, three variants of DUID are defined (DUID-LLT, DUID-EN and DUID-LL). RFC 6355 adds a fourth, DUID-UUID. UUID is defined in RFC 4122. If pfSense is going to store the DUID, it should probably be able to generate and store multiple formats, depending on service provider requirements. When I asked my service provider about this, the response was UUID. (Presumably the intention was to say DUID-UUID. I just sent an email asking for clarification.)
Does the ISP say to the router "Please provide a DUID. I'd prefer type LLT"? My impression (which might be wrong) is that the ISP doesn't ask for any particular type of DUID.. it just asks for a DUID. I think the different RFC's are just different methods for machines (not interfaces) to determine how to create a DUID and how to form the actual data structure to indicate which method was used.
Despite my referencing the incorrect RFC in an earlier post, DHCPv6 is defined in rfc3315. Section 9 defines a DUID…
[[i]deletia]
In my case, which may or may not be the same as your case, when I asked about prefix persistence, the response was the following:
Your prefix should only really change if the UUID in the dhcp solicit changes, or if your device is offline for a long period of time (a few days) then it may change.
If you reboot your device, you should get the same prefix regardless of if you ask for it or not.
Note the reference to UUID. Presumably either DUID (in general) or DUID-UUID (specific) was intended. I sent an email this morning asking for clarification. Your reference to RFC 6635 isn't incorrect. It came after RFC 3315. As of RFC 6635, there are four valid formats for DUID. Whether one or all of them should be supported by pfSense is another matter.
-
Note the reference to UUID. Presumably either DUID (in general) or DUID-UUID (specific) was intended. I sent an email this morning asking for clarification. Your reference to RFC 6635 isn't incorrect. It came after RFC 3315. As of RFC 6635, there are four valid formats for DUID. Whether one or all of them should be supported by pfSense is another matter.
I think there's a misunderstanding about DUID support. (It might be me misunderstanding.) My impression is that a given machine should only support a single DUID type. Which type of DUID is supported depends on the type of device and it's capabilities. RFC 3315 gives suggestions when LLT, LL and EN should be used, and 6635 makes the case for when UUID should be used.
LL is used when there's no storage mechanism, but there's a known unique interface identifier (that won't change) similar to a MAC address. This, in theory, could be used for pfSense appliances.
EN is used when there's no choice but to simply hard-code it. (I don't know what kind of device has a network interface, but couldn't use LL. Perhaps if there weren't any computational resources to generate something, they could just hard-code it.)
UUID describes something about layers of booting or something that I didn't really take the time to understand. ;)
LLT is the best of all worlds (given the resources): you can generate it once and keep it forever… if you have writable persistent storage. (However, 3315 also states that LLT implementations provide a mechanism to cause the DUID to be regenerated if needed.)
-
Note the reference to UUID. Presumably either DUID (in general) or DUID-UUID (specific) was intended. I sent an email this morning asking for clarification. Your reference to RFC 6635 isn't incorrect. It came after RFC 3315. As of RFC 6635, there are four valid formats for DUID. Whether one or all of them should be supported by pfSense is another matter.
I think there's a misunderstanding about DUID support. (It might be me misunderstanding.) My impression is that a given machine should only support a single DUID type. Which type of DUID is supported depends on the type of device and it's capabilities. RFC 3315 gives suggestions when LLT, LL and EN should be used, and 6635 makes the case for when UUID should be used.
LL is used when there's no storage mechanism, but there's a known unique interface identifier (that won't change) similar to a MAC address. This, in theory, could be used for pfSense appliances.
EN is used when there's no choice but to simply hard-code it. (I don't know what kind of device has a network interface, but couldn't use LL. Perhaps if there weren't any computational resources to generate something, they could just hard-code it.)
UUID describes something about layers of booting or something that I didn't really take the time to understand. ;)
LLT is the best of all worlds (given the resources): you can generate it once and keep it forever… if you have writable persistent storage. (However, 3315 also states that LLT implementations provide a mechanism to cause the DUID to be regenerated if needed.)
I don't think it's quite so cut and dried. DUID-LL and DUID-LLT are the same except for the time stamp. DUID-EN is different altogether, usually used by equipment vendors. Here is an example of how different types could be used: https://www.juniper.net/techpubs/en_US/junose13.2/topics/concept/dhcp-unique-id-servers-clients-overview.html
I agree that LLT makes a lot of sense for this application. You can generate it and reuse it or if you need to make change, you can simply regenerate it with a new timestamp.
-
I contacted the engineer at my ISP for clarification about the "UUID". It was a typo. He said their gateways use LL, but they tested EN and LLT. I think having an option to preserve LLT and enable it to be entered as a configuration parameter would be useful for situations where preservation of prefix is based on consistent DUID.
