Description of problem: There are certain layer 2-1/2 bridges that are known to scribble on DHCP packets, in particular replacing the source MAC address with their own. This is common in--but not limited to--Wifi, Docsis, and ADSL bridged environments. To disambiguate multiple clients behind the same bridge, the client-identifier (which won't be modified) should be used instead. Version-Release number of selected component (if applicable): 4.1.0p1-17 How reproducible: Put a Fedora workstation on Ethernet behind a Windows 7 workstation, with the latter's Ethernet and Wifi connections joined in an NDIS miniport bridge. The bridge will send forwarded Ethernet packets with the original MAC source address having been replaced with the Win7 bridge's own Wifi MAC address. This will cause the Fedora workstation to not receive the DHCP responses. Steps to Reproduce: 1. As above. 2. 3. Actual results: Dhclient never receives response. Expected results: Dhclient receives response (lease). Additional info:
Recommend the package (or an optional subpackage) include the following as the file /etc/dhcp/dhclient.conf: # required in environments where a bridge might be clobbering the forwarded # packet's MAC address (common in Wifi, Docsis, or ADSL bridging scenarios) send dhcp-client-identifier = hardware;
At this moment I think this is doable (it shouldn't break anything). Although probably the best solution is to send client identifier as defined in RFC 4361. Additional info: see `man 5 dhcp-options` for setting option values using expressions see `man 5 dhcp-eval` for hardware data expression section 2 of RFC 2131, page 9 says: ... the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field ... section 4.2 of RFC 2131, page 26 says: If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the 'client identifier' option. section 9.14 of RFC 2132 says: The client identifier MAY consist of type-value pairs similar to the 'htype'/'chaddr' fields. For instance, it MAY consist of a hardware type and hardware address. For correct identification of clients, each client's client-identifier MUST be unique among the client-identifiers used on the subnet to which the client is attached. Vendors and system administrators are responsible for choosing client-identifiers that meet this requirement for uniqueness. section 5 of RFC 4361 says: In order to satisfy all but the last of these requirements, we need to construct a DHCPv4 client identifier out of two parts. One part must be unique to the host on which the client is running. The other must be unique to the network identity being presented. The DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) specified in RFC 3315 satisfy these requirements. In order to satisfy the last requirement, we must use the DUID to identify the DHCPv4 client. So, taking all the requirements together, the DUID and IAID described in RFC 3315 are the only possible solution.
So... send dhcp-client-identifier = concat(03:00:01, suffix(hardware, 6)); then in the case of Ethernet. We probably need a new function in the data-expr eval that returns the RFC-826 ar$hrd value (ARP-hardware type) for an Interface as an enum (which we could then manipulate as encode-int(XXX, 2) to turn it into a 16-bit field.
(In reply to comment #3) > So... > > send dhcp-client-identifier = concat(03:00:01, suffix(hardware, 6)); > > then in the case of Ethernet. > > We probably need a new function in the data-expr eval that returns the RFC-826 > ar$hrd value (ARP-hardware type) for an Interface as an enum (which we could > then manipulate as encode-int(XXX, 2) to turn it into a 16-bit field. Actually, you could also use: send dhcp-client-identifier = concat(03:00, substring(hardware, 0, 1), suffix(hardware, 6)); although I wonder: given how long RFC-3315 has been out (6.5 years, as of today) no one really seems to be using it. Do we want to "go it alone" and adopt a standard that no one else has? Won't that cause interoperability issues?
RFC 3315 defines DHCP for IPv6 (DHCPv6). When you run 'dhclient -6' and 'dhcpd -6' you are running DHCPv6, which is implemented according to RFC 3315. 'dhclient -6' and 'dhcpd -6' uses for identifying each other DUID_LLT. 'dhcpd (-4)' uses for client identification dhcp-client-identifier (if it's defined) or chaddr (client's link-layer address) field in DHCP message. RFC 4361 specifies how to encode DHCPv4 client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. And I think such defined identifiers would solve your problem. But implementation of RFC 4361 is task for upstream.
Well, I still think catching up from RFC-826 to RFC-3315 is worthwhile, while we're waiting for upstream to get around to RFC-4361.
So... how about going with the original proposal then: send dhcp-client-identifier = hardware; Just trying to get an additional config file into the BOM, so it shouldn't take too much effort I'm hoping...
(In reply to comment #7) > So... how about going with the original proposal then: > send dhcp-client-identifier = hardware; Yes, I think we should try the simplest way first. There's now default /etc/dhcp/dhclient.conf shipped with dhclient in Rawhide (dhcp-4.2.0-24.P2.fc15). And sorry for not taking action so long.
Actually, I don't like the "default /etc/dhcp/dhclient.conf" solution. - It's there only because of this bug. - It's used only by network service. Most of the people use NetworkManager nowadays (which creates its own conf file for dhclient). - Somebody can become confused when editing /etc/dhcp/dhclient.conf while using NM. See bug #723374. So I'm probably going to remove it again. Reassigning this BZ to NM. Jirka, Dan: would it be possible to add the send dhcp-client-identifier = hardware; line to /var/run/nm-dhclient-<iface>.conf ? See the description of this BZ.
(In reply to comment #9) > Actually, I don't like the "default /etc/dhcp/dhclient.conf" solution. > - It's there only because of this bug. > - It's used only by network service. Most of the people use NetworkManager > nowadays (which creates its own conf file for dhclient). > - Somebody can become confused when editing /etc/dhcp/dhclient.conf while using > NM. See bug #723374. So I'm probably going to remove it again. > > > Reassigning this BZ to NM. > Jirka, Dan: would it be possible to add the > > send dhcp-client-identifier = hardware; > > line to /var/run/nm-dhclient-<iface>.conf ? > See the description of this BZ. Not everyone uses NetworkManager: I have a bunch of headless servers that don't have a way to run a GUI. I'd really like to have this bug wrapped up in less than 2 years if we could...
On an unrelated note, I noticed that after I updated from F15 to F16, the file: /etc/dhcp/dhclient-p6p1.conf contains the contents of "uname -r" but from F15, not from F16.
The lack of a dhcp-client-identifier causes problems when Kickstarting, too. In that case, it is impossible (without building your own initrd) to change the parameters before NetworkManager/dhclient runs. The issue is that ISC dhcpd will grant a dynamic IP address to the BIOS and PXE client which is coupled to the client-id. When Anaconda/NM/dhclient later asks for an IP address, ISC dhcpd will *not* reuse the lease, since it considers a non-existent client-id a different value from a given client-id, even if the hardware address is the same. The consequence of this is that each kickstarting server will consume 2 IP addresses from the pool, and it is slightly inconvenient to find out which one is actually active since both IP addresses are valid as far as the DHCP server is concerned. Ideally I would like to see dhclient changed (upstream) to behave better by default, but failing that, please change the default configuration shipped with RedHat.
Anyone? This bug is 2+ years old...
(In reply to comment #9) > Actually, I don't like the "default /etc/dhcp/dhclient.conf" solution. > - It's there only because of this bug. > - It's used only by network service. Most of the people use NetworkManager > nowadays (which creates its own conf file for dhclient). > - Somebody can become confused when editing /etc/dhcp/dhclient.conf while using > NM. See bug #723374. So I'm probably going to remove it again. > > > Reassigning this BZ to NM. > Jirka, Dan: would it be possible to add the > > send dhcp-client-identifier = hardware; > > line to /var/run/nm-dhclient-<iface>.conf ? > See the description of this BZ. NM will send whatever the user wants it to send if the "DHCP Client ID" field is populated in nm-connection-editor. That GUI field pulls directly from DHCP_CLIENT_ID in the ifcfg file, so if you're not using a GUI, adding that key to the ifcfg file for that interface should cause NM to write the ID to /var/run/nm-dhclient-<iface>.conf as well.
Is there any reason to use UUID_LLT when UUID_LL is available through the first embedded interface?
From dhclient(8): By default, DHCPv6 dhclient creates an identifier based on the link-layer address (DUID-LL) if it is running in stateless mode (with -S, not requesting an address), or it creates an identifier based on the link-layer address plus a timestamp (DUID-LLT) if it is running in stateful mode (without -S, requesting an address).
What's the reason not to use DUID-LL all the time?
(In reply to comment #17) > What's the reason not to use DUID-LL all the time? I agree. There are low-end devices that don't have persistent (battery backed up) RTC's (like printers, scanners, NAS, etc) that won't have a reliable time-of-day until after they've acquired an address and synchronized via NTP. Having a mixed network of DUID-LL and DUID-LLT seems onerous.
> There are low-end devices that don't have persistent (battery backed up) > RTC's (like printers, scanners, NAS, etc) that won't have a reliable > time-of-day until after they've acquired an address and synchronized via NTP. The time thing is there only to get some more unique bits. > Having a mixed network of DUID-LL and DUID-LLT seems onerous. It's not a problem per se. But DUID-LL has the great property of stability accross reboots and reinstalls without the need to actually save it on the disk.
(In reply to comment #19) > It's not a problem per se. But DUID-LL has the great property of stability > accross reboots and reinstalls without the need to actually save it on the > disk. So it seems like we all agree that DUID-LL is the way to go...
> So it seems like we all agree that DUID-LL is the way to go... AFAIK even the RFC agrees :).
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
I would like to add my support for an option that works equally well with NM as well as with the more traditional ifup/ifdown mechanisms since our headless servers tend to not use NM. Comment !4 seems to indicate that DHCP_CLIENT_ID in the ifcfg-$iface file already works for NM. I couldn't find any evidence that it works for traditional ifup/ifdown though. Maybe I'm wrong. Somebody please correct me if I am.
If we're talking IPv4 only, does the following make it work with initscripts? --- /etc/sysconfig/network-scripts/ifup-eth.bak 2013-10-25 15:37:30.086338774 -0500 +++ /etc/sysconfig/network-scripts/ifup-eth 2013-10-25 15:38:10.694831098 -0500 @@ -160,7 +160,7 @@ fi; generate_config_file_name generate_lease_file_name - DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ${ONESHOT} -q ${DHCLIENTCONF} -lf ${LEASEFILE} -pf /var/run/dhclient-${DEVICE}.pid" + DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ${ONESHOT} ${DHCP_CLIENT_ID:+-I $DHCP_CLIENT_ID} -q ${DHCLIENTCONF} -lf ${LEASEFILE} -pf /var/run/dhclient-${DEVICE}.pid" echo echo -n $"Determining IP information for ${DEVICE}..." if [[ "${PERSISTENT_DHCLIENT}" != [yY1]* ]] && check_link_down ${DEVICE}; then (my shell-fu is weak, so I'm not quite sure that's the right notation for "print nothing if $DHCP_CLIENT_ID is not defined")
(In reply to Dan Williams from comment #24) > (my shell-fu is weak, so I'm not quite sure that's the right notation for > "print nothing if $DHCP_CLIENT_ID is not defined") from bash(1): ${parameter:+word} Use Alternate Value. If parameter is null or unset, nothing is sub‐ stituted, otherwise the expansion of word is substituted.
Hard to believe I opened this bug almost 4 years ago. Can we please move this to closure?
(In reply to Dan Williams from comment #24) > If we're talking IPv4 only, does the following make it work with initscripts? > [...] That would require each user manually configuring DHCP_CLIENT_ID when not using NM. It also means that it would work differently for plug-n-play devices. For instance, if I have a laptop and 2 docking stations, the MAC address will come from the docking station itself. Similarly, if I have a laptop with both Wifi and Ethernet, it would use the same client-id for both devices. This may or may not be desirable. There's much less convenience and a lot more unintended consequences from this patch.
Changing the component as this needs to work whether NM is being used or not.
OK, /etc/dhcp/dhclient.conf (send dhcp-client-identifier = hardware;) strikes back.
dhcp-4.2.5-26.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dhcp-4.2.5-26.fc20
Package dhcp-4.2.5-26.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dhcp-4.2.5-26.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20396/dhcp-4.2.5-26.fc20 then log in and leave karma (feedback).
dhcp-4.2.5-26.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Philip Prindeville from comment #1) > Recommend the package (or an optional subpackage) include the following as > the file /etc/dhcp/dhclient.conf: > > # required in environments where a bridge might be clobbering the forwarded > # packet's MAC address (common in Wifi, Docsis, or ADSL bridging scenarios) > send dhcp-client-identifier = hardware; This is broken. In dhcp config file parlance, hardware == the single byte value of the hardware type. For Ethernet, this is 10. For InfiniBand IPoIB, this is 32. That's *all* that this config line causes to get put into the client identifier field. This means that *every* computer behind the windows Ethernet/wifi bridge will all have the exact same client id of 10. That obviously violates the requirements as listed in comment #3 that this value must be unique. For reference though, there is a long standing history that InfiniBand IPoIB interfaces already send 0xff:<GUID> as their client id, so when you fix this bug properly, it needs to differentiation what hardware you are on, and on hardware type 32, we need to replace 32 with 255 and then append the GUID. For Ethernet, hardware type 10 with an append of the MAC address should work.
(In reply to Doug Ledford from comment #33) > For reference though, there is a long standing history that InfiniBand IPoIB > interfaces already send 0xff:<GUID> as their client id, so when you fix this > bug properly, it needs to differentiation what hardware you are on, and on > hardware type 32, we need to replace 32 with 255 and then append the GUID. > For Ethernet, hardware type 10 with an append of the MAC address should work. This is an over simplification of what we do with InfiniBand at the moment. And I should point out that there are quite a lot of InfiniBand dhcp clients that will break if we change this. I would look in the source code to see what we do here. And it may require that this bug be fixed in the source code as I'm not sure the config file will present you with a suitable programming construct to differentiate between IPoIB and Ethernet and program the client id differently between the two.
Further clarification, the problem here is that the hardware keyword only works properly on certain hardware types. IPoIB is not one of those types. It should work as expected on Ethernet. I'm trying this now to see if it solves my problem: if not hardware = 32 { send dhcp-client-identifier = hardware; }
The config file change in my previous comment fixes infiniband IPoIB interfaces by causing us to fall back to the internal client ID that dhclient already produces on those interfaces. I'm not sure if this change is really right though in that the hardware option only works on certain hardware, it seems we should limit this config file option to hardware where it works, not just exclude IPoIB from the list. But I'll leave that up to the dhclient maintainer to sort out.
*** Bug 1064029 has been marked as a duplicate of this bug. ***
(In reply to Doug Ledford from comment #33) > For reference though, there is a long standing history that InfiniBand IPoIB > interfaces already send 0xff:<GUID> as their client id Correct, that's RFC 4390 (DHCP over IPoIB). > so when you fix this > bug properly, it needs to differentiation what hardware you are on, and on > hardware type 32, we need to replace 32 with 255 and then append the GUID. > For Ethernet, hardware type 10 with an append of the MAC address should work. I'm not sure the 'hardware' expression needs any change, it behaves per RFC4390, which says that (for IPoIB): - hw type must be 32 - hw len must be 0 - hw add must be zeroed (In reply to Doug Ledford from comment #35) > if not hardware = 32 { > send dhcp-client-identifier = hardware; > } Thank you ! (In reply to Doug Ledford from comment #36) > it seems we should limit this config file option to hardware where > it works, not just exclude IPoIB from the list. I actually like this solution. I'm fine with excluding IPoIB, because it's a special case. I don't know about any other similar case, if you do, let me know so I can change my mind.
(In reply to Doug Ledford from comment #35) > if not hardware = 32 { > send dhcp-client-identifier = hardware; > } Added in dhcp-4.2.6-2.fc20 http://koji.fedoraproject.org/koji/taskinfo?taskID=6530814
(In reply to Jiri Popelka from comment #2) > Although probably the best solution would be to send client identifier as defined in RFC 4361. This starts to becoming reality with dhcp-4.3 in rawhide/F21. dhclient(8): " -i Use a DUID with DHCPv4 clients. If no DUID is available in the lease file one will be constructed and saved. The DUID will be used to construct a RFC4361 style client id that will be included in the client's messages." This DUID should have the same format as DUID used by DHCPv6 or the one we already create for IPoIB. The only problem I see is in using the '-i' options to turn this on. I'm thinking about turning this on in code by default, because it seems it's possible to redefine or turn it off in dhclient.conf with send dhcp-client-identifier = "better identifier" or send dhcp-client-identifier = "" And I also need to make sure IPoIB still works with it ;)
*** Bug 1065675 has been marked as a duplicate of this bug. ***
(In reply to Doug Ledford from comment #35) > if not hardware = 32 { > send dhcp-client-identifier = hardware; > } (In reply to Doug Ledford from comment #36) > The config file change in my previous comment fixes infiniband IPoIB > interfaces by causing us to fall back to the internal client ID that > dhclient already produces on those interfaces. Actually it "fixes" the problem on IPoIB because the conditional behaviour seems to not work as expected. I've tried to make it work somehow but with no luck so far - the only explanation I have is from dhcp-eval(5): "... provide the ability to perform conditional behavior depending on the contents of packets they *receive*." So for now I tend to remove the sending of dhcp-client-identifier at all from F20 so we don't break IPoIB and will hopefully fix it in F21 as described in comment #40.
(In reply to Jiri Popelka from comment #42) > So for now I tend to remove the sending of dhcp-client-identifier at all > from F20 so we don't break IPoIB done, dhcp-4.2.6-3.fc20 https://koji.fedoraproject.org/koji/buildinfo?buildID=498806 > and will hopefully fix it in F21 as described in comment #40. done, dhcp-4.3.0-3.fc21 https://koji.fedoraproject.org/koji/buildinfo?buildID=498829 (tested with IB hw and looks good)
(In reply to Jiri Popelka from comment #42) > So for now I tend to remove the sending of dhcp-client-identifier at all > from F20 so we don't break IPoIB and will hopefully fix it in F21 as > described in comment #40. I think, I've changed my mind. I probably don't want to do such changes in already released Fedora. I'm sure sending of dhcp-client-identifier breaks IPoIB, but hey, how many machines out there with IPoIB is running Fedora ? I'm closing this bug as the original problem should be fixed in F20/F21 and we can continue with the IPoIB problem in newly created bug #1109860
Even sending client identifier as defined in RFC 4361 isn't without problems, see bug #1154200 - it seems that some DHCP servers (e.g. Cisco RV320 Router) when configured to do static allocation (assign IP according to MAC) search client's MAC address in client identifier (when specified) instead of in chaddr field of DHCP packet. The problem does not appear when there's no client identifier or the client identifier is equal to client's MAC. So what now ? Not sending client identifier causes this bug. Sending client identifier = MAC causes bug #1109860. Sending client identifier per RFC 4361 causes bug #1154200.
(In reply to Jiri Popelka from comment #45) > Even sending client identifier as defined in RFC 4361 isn't without > problems, see bug #1154200 - it seems that some DHCP servers (e.g. Cisco > RV320 Router) when configured to do static allocation (assign IP according > to MAC) search client's MAC address in client identifier (when specified) > instead of in chaddr field of DHCP packet. The problem does not appear when > there's no client identifier or the client identifier is equal to client's > MAC. > > So what now ? > Not sending client identifier causes this bug. > Sending client identifier = MAC causes bug #1109860. > Sending client identifier per RFC 4361 causes bug #1154200. I wouldn't let the fact that someone doesn't handle it correctly: it will get fixed eventually by "the other guy" (as someone who spent 5 years at Cisco fixing IOS bugs and being "the other guy"). Do what you think is the truest/most correct interpretation of the RFCs. IPoIB is a bit of a corner case. For IB, setting the client-identifier to "" seems to be a viable workaround.
Oh, an for what it's worth I'm not a fan of "implicit" configurations nor of changing the way a package behaves in a distro from how it behaves upstream.
I would follow the RFC. As pointed out, if something else breaks when we are RFC compliant, it's the other thing's time to be fixed.
(In reply to Doug Ledford from comment #48) > I would follow the RFC. As pointed out, if something else breaks when we > are RFC compliant, it's the other thing's time to be fixed. Agreed. If everyone refused to fix anything because they were "blocking" on someone else's bug, then nothing would ever get fixed because we'd be in a permanent Mexican standoff.
Thank you guys ! Let's keep sending DUID (per RFC 4361) as client-id then. (In reply to Philip Prindeville from comment #46) > IPoIB is a bit of a corner case. For IB, setting the client-identifier to "" > seems to be a viable workaround. This is fortunately needed only in F20 (bug #1109860), where we send client-id = MAC. Since F21 we send DUID (per RFC 4361) as client-id and even RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I tested it back then and it worked nicely.
Now I see I've never replied to the following question: (In reply to Pavel Šimerda (pavlix) from comment #17) > What's the reason not to use DUID-LL all the time? Because 6.1. of RFC 4361 [1] says, that: "DHCPv4 clients MUST NOT use client identifiers based solely on layer two addresses that are hard-wired to the layer two device (e.g., the ethernet MAC address) as suggested in RFC 2131, except as allowed in section 9.2 of RFC 3315." Section 9.2 of RFC 3315, refers [2] to DUID-LLT [1] https://tools.ietf.org/html/rfc4361#section-6.1 [2] https://tools.ietf.org/html/rfc3315#section-9.2
(In reply to Jiri Popelka from comment #51) > Because 6.1. of RFC 4361 [1] says, that: > "DHCPv4 clients MUST NOT use client identifiers based solely on layer two > addresses that are hard-wired to the layer two device (e.g., the > ethernet MAC address) as suggested in RFC 2131, except as allowed in > section 9.2 of RFC 3315." And quoting RFC 3315, section 9.2: "Clients and servers that use this DUID SHOULD attempt to configure the time prior to generating the DUID, if that is possible, and MUST use some sort of time source (for example, a real-time clock) in generating the DUID, even if that time source could not be configured prior to generating the DUID. The use of a time source makes it unlikely that two identical DUID-LLTs will be generated if the network interface is removed from the client and another client then uses the same network interface to generate a DUID-LLT." A lot of embedded devices (like my pcEngines Alix-2c firewall, or my Sipura 942 desk phone) are SBC's where the NIC is onboard, same as everything else. There's no chance of the network interface being put anywhere else. Also, many of those same devices don't have battery backed up (CMOS) Time-of-day clocks, so they don't know the time on boot... and need to DHCP and acquire an IP address before they can learn the time via (S)NTP. Thus creating a circular dependency that this RFC doesn't acknowledge exists.
Actually, RFC-3315 is all kinds of confused. For instance, section 9.4: "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. For example, a host that has a network interface implemented in a chip that is unlikely to be removed and used elsewhere could use a DUID-LL. [...] "The choice of network interface can be completely arbitrary, as long as that interface provides a unique link-layer address and is permanently attached to the device on which the DUID-LL is being generated. The same DUID-LL SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID." That last sentence is particularly problematic if all of the routers are using dhcp-relays because then the DHCP server will be presented with the same DUID regardless of which interface on a multi-homed device (router or host) is requesting the assignment. In that case additional attributes would be required to further disambiguate the request (such as the IP address of the interface that the dhcp-relay received the request on).
(In reply to Philip Prindeville from comment #53) > That last sentence is particularly problematic if all of the routers are > using dhcp-relays because then the DHCP server will be presented with the > same DUID regardless of which interface on a multi-homed device (router or > host) is requesting the assignment. No matter how exactly DUID is generated and stored, it identifies a single node. Any expectations regarding interface identification in DUID are misguided.
(In reply to Jiri Popelka from comment #50) > Thank you guys ! > Let's keep sending DUID (per RFC 4361) as client-id then. > > (In reply to Philip Prindeville from comment #46) > > IPoIB is a bit of a corner case. For IB, setting the client-identifier to "" > > seems to be a viable workaround. > > This is fortunately needed only in F20 (bug #1109860), where we send > client-id = MAC. Since F21 we send DUID (per RFC 4361) as client-id and even > RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I > tested it back then and it worked nicely. Is this intended to interoperate at all with DHCP servers that aren't configured for this? I ask because the recent Fedora installs won't get an IP address from a DHCP server over InfiniBand. Not a static, nor a dynamic address. In fact, a rhel7 DHCP server considers the Fedora 23/rawhide DHCP request to be malformed and simply ignores it.
Yes, and I'm sure I tested it with IB. Need to take another look then.
Let me know if you need machines to test on. I have server/client machines already to go that I can get you a login too.
(In reply to Doug Ledford from comment #55) > (In reply to Jiri Popelka from comment #50) > > Since F21 we send DUID (per RFC 4361) as client-id and even > > RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I > > tested it back then and it worked nicely. > > Is this intended to interoperate at all with DHCP servers that aren't > configured for this? Well, the fixed-address allocation using client-identifier (cid) needs to be amended as the cid has been different since F21. The original (prior to F21) implementation (from Mellanox) of RFC4390 (DHCP over IB) was sending cid in form of 0xff + default_prefix (00:00:00:00:00:02:00:00:02:c9:00:00) + low 8B of iface LL address => for example: ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:71 While since F21 it's had a form (per RFC4361) of 0xff + IAID (low 4B of LL addr) + UUID (2B duid_type + 2B htype (+ 4B current_time in case of DUID_LLT type)) + low 8B of iface LL addr => fox example: ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71 > I ask because the recent Fedora installs won't get an > IP address from a DHCP server over InfiniBand. Not a static, nor a dynamic > address. In fact, a rhel7 DHCP server considers the Fedora 23/rawhide DHCP > request to be malformed and simply ignores it. There's actually no dynamic allocation (no range statement) in your config and fixed-address allocations use the old (pre F21) cid. I can see DHCPDISCOVER from ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71 via <iface>: network <subnet>.0/24: no free leases in log, so it's not considered malformed - the server just doesn't have any dynamic/fixed address to offer. I tested it again and dynamic allocation works out-of-the-box and for fixed-address allocation something like the following works for me on RHEL7 server as well: host name { fixed-address <address>; hardware infiniband 00:11:75:00:00:6f:33:71; option dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71; }
(In reply to Jiri Popelka from comment #58) > (In reply to Doug Ledford from comment #55) > > (In reply to Jiri Popelka from comment #50) > > > Since F21 we send DUID (per RFC 4361) as client-id and even > > > RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I > > > tested it back then and it worked nicely. > > > > Is this intended to interoperate at all with DHCP servers that aren't > > configured for this? > > Well, the fixed-address allocation using client-identifier (cid) needs to be > amended as the cid has been different since F21. > The original (prior to F21) implementation (from Mellanox) of RFC4390 (DHCP > over IB) was sending cid in form of 0xff + default_prefix > (00:00:00:00:00:02:00:00:02:c9:00:00) + low 8B of iface LL address => for > example: > ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:71 > > While since F21 it's had a form (per RFC4361) of 0xff + IAID (low 4B of LL > addr) + UUID (2B duid_type + 2B htype (+ 4B current_time in case of DUID_LLT > type)) + low 8B of iface LL addr => fox example: > ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71 My question is this: since f21 does the new cid work out to be static? If not, it's very hard to use it as a client identifier. The whole "may use current_time" is worrisome. > > I ask because the recent Fedora installs won't get an > > IP address from a DHCP server over InfiniBand. Not a static, nor a dynamic > > address. In fact, a rhel7 DHCP server considers the Fedora 23/rawhide DHCP > > request to be malformed and simply ignores it. > > There's actually no dynamic allocation (no range statement) in your config Sorry, that's an oversight introduced by commit c5b16d0 dated Mon Oct 19 23:29:46 2015 in my internal config script git repo. Thanks for pointing it out, it's been fixed. > and fixed-address allocations use the old (pre F21) cid. I can see > DHCPDISCOVER from > ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71 via <iface>: > network <subnet>.0/24: no free leases > in log, so it's not considered malformed - the server just doesn't have any > dynamic/fixed address to offer. > > I tested it again and dynamic allocation works out-of-the-box and for > fixed-address allocation something like the following works for me on RHEL7 > server as well: > > host name { > fixed-address <address>; > hardware infiniband 00:11:75:00:00:6f:33:71; Does this option even do anything? > option > dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00: > 6f:33:71; > } I'll have to create different stanzas, one for the old cid format and one for the new, in order to support both f21+ and rhel7- installs with static dhcp addresses.
(In reply to Doug Ledford from comment #59) > (In reply to Jiri Popelka from comment #58) > My question is this: since f21 does the new cid work out to be static? It must me "static" once generated. > If not, it's very hard to use it as a client identifier. The whole "may use > current_time" is worrisome. I see your point. Then we might go one step further and implement RFC 6355 (DUID-UUID) [1]. That one is supposed to be "really static" - I mean, even when you delete the dhclient's leases file and let it generate new DUID - it should be the same as previously. It also addresses comment #51 (DUID-LL), because it's not based *solely* on LL address. Since dhcp-4.3.3-9.fc24 I've been using [2] /etc/machine-id (man machine-id) to generate RFC 4122 compliant UUID to be used in DUID-UUID. The DUID-UUID has form of: 0xff + IAID (low 4B of MAC) + 2B duid_type (4) + 16B UUID. For example in my case where (ethernet) MAC = xx:xx:28:c2:d7:11 /etc/machine-id = 9942ebb9c4a8495fbb51e98cb2b481d7 results in DUID-UUID (client-identifier): ff:28:c2:d7:11:00:04:99:42:eb:b9:c4:a8:49:5f:bb:51:e9:8c:b2:b4:81:d7 [1] https://tools.ietf.org/html/rfc6355 [2] http://pkgs.fedoraproject.org/cgit/dhcp.git/tree/dhcp-duid_uuid.patch > > I tested it again and dynamic allocation works out-of-the-box and for > > fixed-address allocation something like the following works for me on RHEL7 > > server as well: > > > > host name { > > fixed-address <address>; > > hardware infiniband 00:11:75:00:00:6f:33:71; > > Does this option even do anything? Not sure what you are actually asking as I've seen it in your config too. I had tried whether it works (when I commented the line below) and it does so I wanted to point out that you can use either 'hardware infiniband ...' or 'option dhcp-client-identifier=...' to identify the IB clients. > > option > > dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00: > > 6f:33:71; > > } > > I'll have to create different stanzas, one for the old cid format and one > for the new, in order to support both f21+ and rhel7- installs with static > dhcp addresses. I see, but I hope we are now RFCs compliant.
(In reply to Jiri Popelka from comment #60) > (In reply to Doug Ledford from comment #59) > > (In reply to Jiri Popelka from comment #58) > > My question is this: since f21 does the new cid work out to be static? > > It must me "static" once generated. For f21 through the most recent change, how can I generate the proper entry for a host entry in the dhcpd.conf file? Here's the list I have so far based upon the comments in this bug: I need an RFC4390 entry for all releases through rhel7/f20 I need an RFC4361 entry for f21+ until dhcp-4.3.3-9.fc24 I need an RFC4122 entry for f24+ I need an RFC6355 entry possibly in the future. My install scripts in the test lab generate the necessary dhcpd.conf host entries needed to satisfy all possible requests from a machine no matter what OS the machine is installed with. So, I now have to generate all of those IDs on each install. I know how to generate the first (static element plus GID of device) and third (machine ID plus part of GID), but how do I generate the second or fourth? > > > host name { > > > fixed-address <address>; > > > hardware infiniband 00:11:75:00:00:6f:33:71; > > > > Does this option even do anything? > > Not sure what you are actually asking as I've seen it in your config too. No, I don't have any hardware infiniband entries. Last I knew, they weren't supported on rhel7 dhcpd and just fail. No, what you saw was host stanzas that have a complete list of possible IP addresses that are valid for this host across all of its Ethernet and InfiniBand devices combined with one hardware Ethernet and one client identifier element per host. It would make my life easier if dhcpd would accept more than one hardware ethernet and one client identifier entry per host stanza as I could consolidate things then. Instead, because I have machines with things like two different InfiniBand devices plus two different Ethernet devices, I have to split things up like this: host rdma-storage-02.0 { fixed-address 172.31.0.102,172.31.2.102,172.31.4.102,172.31.6.102,172.31.1.102,172.31.3.102,172.31.5.102,172.31.7.102,172.31.40.102,172.31.43.102,172.31.45.102,172.31.50.102; hardware ethernet 00:90:fa:88:5b:56; option dhcp-client-identifier=ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:70; } host rdma-storage-02.1 { fixed-address 172.31.0.102,172.31.2.102,172.31.4.102,172.31.6.102,172.31.1.102,172.31.3.102,172.31.5.102,172.31.7.102,172.31.40.102,172.31.43.102,172.31.45.102,172.31.50.102; hardware ethernet 00:07:43:2e:c4:90; option dhcp-client-identifier=ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:71; } If I split my ethernet entries and IB entries into different stanzas, I would have sometimes exactly twice as many host stanzas to deal with. Of course, now, because of all of the different client identifiers I might have to support, my number of stanzas is going to blow up anyway ;-) > I had tried whether it works (when I commented the line below) and it does > so I wanted to point out that you can use either 'hardware infiniband ...' > or 'option dhcp-client-identifier=...' to identify the IB clients. As mentioned above, I believe you are mistaken in that I've never used hardware infiniband (it wasn't supported when I tried). On rdma-master where I keep all of the individual host stanzas for generating the dhcpd.conf file: [root@rdma-master hosts.d]$ ls rdma-dev-00.dhcp.0 rdma-dev-12.dhcp.0 rdma-qe-13.dhcp.0 rdma-dev-00.dhcp.1 rdma-dev-13.dhcp.0 rdma-qe-14.dhcp.0 rdma-dev-01.dhcp.0 rdma-dev-16.dhcp.0 rdma-qe-15.dhcp.0 rdma-dev-01.dhcp.1 rdma-perf-00.dhcp.0 rdma-storage-01.dhcp.0 rdma-dev-02.dhcp.0 rdma-perf-01.dhcp.0 rdma-storage-01.dhcp.1 rdma-dev-02.dhcp.1 rdma-perf-02.dhcp.0 rdma-storage-02.dhcp.0 rdma-dev-03.dhcp.0 rdma-perf-02.dhcp.1 rdma-storage-02.dhcp.1 rdma-dev-03.dhcp.1 rdma-perf-03.dhcp.0 rdma-storage-03.dhcp.0 rdma-dev-04.dhcp.0 rdma-perf-03.dhcp.1 rdma-storage-03.dhcp.1 rdma-dev-04.dhcp.1 rdma-qe-04.dhcp.0 rdma-storage-04.dhcp.0 rdma-dev-05.dhcp.0 rdma-qe-05.dhcp.0 rdma-storage-04.dhcp.1 rdma-dev-05.dhcp.1 rdma-qe-06.dhcp.0 rdma-virt-00.dhcp.0 rdma-dev-06.dhcp.0 rdma-qe-06.dhcp.1 rdma-virt-00.dhcp.1 rdma-dev-06.dhcp.1 rdma-qe-07.dhcp.0 rdma-virt-01.dhcp.0 rdma-dev-07.dhcp.0 rdma-qe-07.dhcp.1 rdma-virt-01.dhcp.1 rdma-dev-07.dhcp.1 rdma-qe-08.dhcp.0 rdma-virt-02.dhcp.0 rdma-dev-08.dhcp.0 rdma-qe-08.dhcp.1 rdma-virt-02.dhcp.1 rdma-dev-09.dhcp.0 rdma-qe-09.dhcp.0 rdma-virt-03.dhcp.0 rdma-dev-10.dhcp.0 rdma-qe-09.dhcp.1 rdma-virt-03.dhcp.1 rdma-dev-10.dhcp.1 rdma-qe-10.dhcp.0 rdma-vr5-master.dhcp.0 rdma-dev-11.dhcp.0 rdma-qe-11.dhcp.0 rdma-vr6-master.dhcp.0 rdma-dev-11.dhcp.1 rdma-qe-12.dhcp.0 rdma-vr7-master.dhcp.0 [root@rdma-master hosts.d]$ grep infiniband * [root@rdma-master hosts.d]$ > > > option > > > dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00: > > > 6f:33:71; > > > } > > > > I'll have to create different stanzas, one for the old cid format and one > > for the new, in order to support both f21+ and rhel7- installs with static > > dhcp addresses. > > I see, but I hope we are now RFCs compliant.
(In reply to Doug Ledford from comment #61) > (In reply to Jiri Popelka from comment #60) > > (In reply to Doug Ledford from comment #59) > > > (In reply to Jiri Popelka from comment #58) > > > My question is this: since f21 does the new cid work out to be static? > > > > It must me "static" once generated. > > For f21 through the most recent change, how can I generate the proper entry > for a host entry in the dhcpd.conf file? Here's the list I have so far > based upon the comments in this bug: > > I need an RFC4390 entry for all releases through rhel7/f20 It's not RFC4390, but some Mellanox created UID type AFAIK not specified in any RFC and even contradicting RFC4361 (because the variable part is based solely on LL address). > I need an RFC4361 entry for f21+ until dhcp-4.3.3-9.fc24 Yes, DUID-LLT to be specific. > I need an RFC4122 entry for f24+ > I need an RFC6355 entry possibly in the future. These two are the same. RFC6355 specifies DUID-UUID, which embeds UUID as defined in RFC4122. > My install scripts in the test lab generate the necessary dhcpd.conf host > entries needed to satisfy all possible requests from a machine no matter > what OS the machine is installed with. So, I now have to generate all of > those IDs on each install. I know how to generate the first (static element > plus GID of device) and third (machine ID plus part of GID), but how do I > generate the second or fourth? Fourth and third are the same (DUID-UUID) and regarding the second (DUID-LLT) - that's why I've implemented RFC6355 (DUID-UUID) - because one cannot predict the DUID-LLT before the client generates it for the first time. After the client sends it (DUID-LLT), you can find it either in dhcpd log or in /var/lib/dhcpd/dhcpd.leases (if the client got a lease). It's a terrible idea, but I don't have any better. > > > > host name { > > > > fixed-address <address>; > > > > hardware infiniband 00:11:75:00:00:6f:33:71; > > > > > > Does this option even do anything? > > > > Not sure what you are actually asking as I've seen it in your config too. > > No, I don't have any hardware infiniband entries. Last I knew, they weren't > supported on rhel7 dhcpd and just fail. I meant I had seen 'hardware' statement in you config so I didn't understood what you meant with 'does it do anything ?'. It seemed to work for me, but it might had been some specific case - I hadn't tested it thoroughly.
(In reply to Jiri Popelka from comment #62) > (In reply to Doug Ledford from comment #61) > > > I need an RFC4390 entry for all releases through rhel7/f20 > > It's not RFC4390, but some Mellanox created UID type AFAIK not specified in > any RFC and even contradicting RFC4361 (because the variable part is based > solely on LL address). Fair enough, it's not an RFC compliant UID, but it is what I need for those releases ;-) > > I need an RFC4361 entry for f21+ until dhcp-4.3.3-9.fc24 > > Yes, DUID-LLT to be specific. Got that working. > > I need an RFC4122 entry for f24+ > > I need an RFC6355 entry possibly in the future. > > These two are the same. RFC6355 specifies DUID-UUID, which embeds UUID as > defined in RFC4122. OK. > > My install scripts in the test lab generate the necessary dhcpd.conf host > > entries needed to satisfy all possible requests from a machine no matter > > what OS the machine is installed with. So, I now have to generate all of > > those IDs on each install. I know how to generate the first (static element > > plus GID of device) and third (machine ID plus part of GID), but how do I > > generate the second or fourth? > > Fourth and third are the same (DUID-UUID) and regarding the second > (DUID-LLT) - that's why I've implemented RFC6355 (DUID-UUID) - because one > cannot predict the DUID-LLT before the client generates it for the first > time. > After the client sends it (DUID-LLT), you can find it either in dhcpd log or > in /var/lib/dhcpd/dhcpd.leases (if the client got a lease). > It's a terrible idea, but I don't have any better. OK, this presents a problem. Most often, the InfiniBand interfaces are not brought up during the install, so my %post scripts have no means of working this out. That means the interfaces can't come up with a predictable address after the install completes and the admin must take manual action to get the interfaces to a predictable address. Would it be possible to update the f21-f23 dhcp client to switch them to the DUID-LLT for new interfaces but preserve the existing value for known interfaces? > > > > > host name { > > > > > fixed-address <address>; > > > > > hardware infiniband 00:11:75:00:00:6f:33:71; > > > > > > > > Does this option even do anything? > > > > > > Not sure what you are actually asking as I've seen it in your config too. > > > > No, I don't have any hardware infiniband entries. Last I knew, they weren't > > supported on rhel7 dhcpd and just fail. > > I meant I had seen 'hardware' statement in you config so I didn't understood > what you meant with 'does it do anything ?'. Well, back in the rhel6/rhel7 days, the dhclient did not ever pass a hardware infiniband to the server, so it was a wasted option. It seems the latest dhclient passes both the hardware infiniband as well as the client-id. So even in some cases where the client-id can't be figured out, it's possible that a hardware infiniband entry can work. So, I've added hardware infiniband entries into the matrix of ids I create for each host.
(In reply to Doug Ledford from comment #63) > Would it be possible to update > the f21-f23 dhcp client to switch them to the DUID-LLT for new interfaces not sure what 'switch to' means as they already send it > but preserve the existing value for known interfaces? no idea what do you have in mind with this
(In reply to Jiri Popelka from comment #64) > (In reply to Doug Ledford from comment #63) > > Would it be possible to update > > the f21-f23 dhcp client to switch them to the DUID-LLT for new interfaces > > not sure what 'switch to' means as they already send it Sorry, too many acronyms. f21-f23 use DUID-LLT, which, as you said before, can't be predicted until the first attempt to get an IP address. The DUID-UUID was added in f24. My comment was meant to be: Would it be possible to switch the f21-f23 distros to a dhcp client that, if a device is previously unknown, uses DUID-UUID, but if a leases file exists with a previously used DUID-LLT then continue to use it? That would keep the update from breaking working systems, but allow new systems/interfaces to have a reliable ID. > > but preserve the existing value for known interfaces? > > no idea what do you have in mind with this
(In reply to Doug Ledford from comment #65) > Would it be > possible to switch the f21-f23 distros to a dhcp client that, if a device is > previously unknown, uses DUID-UUID, but if a leases file exists with a > previously used DUID-LLT then continue to use it? Got it. That's how F24 works now actually. I can't do anything with f21 as that one has already reached End-Of-Life. And regarding f22+f23: I'm afraid my answer would be no as I've learned not to do any such changes in already released versions, even I think it shouldn't break anything - let me think about it some more.