3

According to RFC3315:

Each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified.

[...]

Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs.

For IPv4 it's very common for a DHCP server to allocate fixed addresses to clients based on, for example, MAC addresses. So for IPv6 how does the DHCPv6 server allocate fixed IPv6 addresses?

SF.express
  • 364
  • 1
  • 10
  • 2
    RFC3315 is obsoleted by RFC8415. 8415 modifies "MUST NOT ... interpret" to "SHOULD NOT ... interpret". – Ben Jul 07 '21 at 08:26
  • Valid reasons to interpret the DUID include for example, logging and diagnostic purposes, forensic investigation and so forth. – Ben Jul 07 '21 at 08:31
  • By comparing them for equality, as it says? – user253751 Jul 07 '21 at 08:52
  • 1
    @user253751 by doing whatever you happen to find useful to solve whatever problem you have. RFCs are not infallible holy writ. There is no RFC Inquisition. If you violate a "MUST" you are no longer following the RFC. Maybe you have interoperability problems. But if you don't have problems, or it solves a problem then go ahead. – Ben Jul 08 '21 at 11:01

2 Answers2

6

You're reading it wrong. They're allowed to compare if DUID's are equal to a stored value. They should not try to interpret the content of it in any other way, e.g. to try to retrieve the MAC address or similar shenanigans.

It should be treated as an opaque value, that is a number sequence without any known meaning. They should not try to deduce the meaning of the sequence, but it's fine to compare it against a stored value to check if they're equal. No meaning can be read into the sequence as per the RFC.

vidarlo
  • 3,775
  • 1
  • 12
  • 25
  • the issue is the client DUID may change, for example, when it's using the "DUID Based on Link-layer Address Plus Time" and the OS is reinstalled. it's not practically acceptable (?) to maintain the DHCPv6 server conf in such way compared to DHCPv4. – SF.express Jul 06 '21 at 09:19
  • 3
    @SF.express If that is your real concern, you should ask about that. The question you posted has little or no relevance to that. – Michael Hampton Jul 06 '21 at 12:18
  • sorry i've never touched a real dhcpv6 server so not sure if it's really allocating ip addr solely based on the duid. – SF.express Jul 06 '21 at 12:22
  • 2
    @SF.express The client's MAC address may also change, for example, if the network card fails and has to be replaced. If that happens, it's no different than a changed DUID in v6, you just need to update the DHCP server with the new MAC/DUID and away you go. – HiddenWindshield Jul 06 '21 at 17:37
4

A client should not change its DUID between reboots, so once you have assigned a specific IPv6 address to a client it should get the configured address every time.

The advantage of the DUID is that it stays the same even when the client uses a different network adapter with a different MAC address. The downside is that you have no idea in advance which DUID the client will use (unless you have some out-of-band provisioning to force the client to use a specific DUID).

RFC6939 specifies an option that DHCPv6 relays can use to tell the DHCPv6 server what the MAC address of the client is. DHCPv6 servers can use that to identify the client. Officially DHCPv6 servers shouldn't use the MAC address of the client or try to decode the DUID, but they can cheat of course :) This happens quite often.

Sander Steffann
  • 7,572
  • 18
  • 29
  • the issue is the client DUID may change, for example, when it's using the "DUID Based on Link-layer Address Plus Time" and the OS is reinstalled. it's not practically acceptable (?) to maintain the DHCPv6 server conf in such way compared to DHCPv4. – SF.express Jul 06 '21 at 09:22
  • @SF.express That's a quite different question to the one posted above. You should consider making a separate post. – Michael Hampton Jul 06 '21 at 12:20
  • @mich ok. if the dhcpv6 server is allocating ip addr based on the duid without interpreting it then i can conclude that when a client's duid has changed the end user has to give his new duid to the sysadmin who in turn will update the dhcp server conf. – SF.express Jul 06 '21 at 12:32
  • I'd argue that if end user systems require fixed IP's you're doing things wrong on a lot of levels. FWIW, DNS is a thing. DHCP(v6) can automatically map DNS to addresses it hands out. Active Directory is based around DNS. For servers: is it strictly speaking the same server after a re-install? If so; the admin can always copy the DUID to the new system... Or reconfigure DNS. Or reconfigure DHCP. – vidarlo Jul 06 '21 at 12:42
  • 1
    @vida for a reinstalled server you can say its a new server since the duid has changed but in practice the server still wants to use its previously assigned fixed ip. or ipv6 servers prefer using manually configured static ipv6 addr? – SF.express Jul 06 '21 at 13:53
  • I have no idea where you're going with this... – vidarlo Jul 06 '21 at 14:01
  • "they can cheat of course" - this explains a lot. found redhat's [dhcpv6 conf example](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-dhcp_for_ipv6_dhcpv6) and the dhcp server can assign fixed ip addr based on client's MAC addr which is much easier to maintain in practice than DUID. – SF.express Jul 07 '21 at 01:24
  • I disagree that MAC's easier than DUID. But people are used to IPv4 and messing about with dated ways of doing things. DUID's are alien, and people lack the relevant skills. Half assed solutions is the result. – vidarlo Jul 07 '21 at 07:20