Join Log in
Score:3
SF.express avatar Server

How can DHCPv6 server allocate fixed IPv6 addresses to clients if it's not allowed to interpret DUID?

us flag
SF.express

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?

884
2 + 4
rfc
sh flag
Ben
RFC3315 is obsoleted by RFC8415. 8415 modifies "MUST NOT ... interpret" to "SHOULD NOT ... interpret".
2
Reply
sh flag
Ben
Valid reasons to interpret the DUID include for example, logging and diagnostic purposes, forensic investigation and so forth.
0
Reply
sa flag
user253751
By comparing them for equality, as it says?
0
Reply
sh flag
Ben
@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.
1
Reply
Score:6
vidarlo avatar Server
ar flag
vidarlo

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.

0 + 4
SF.express avatar
us flag
SF.express
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.
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
@SF.express If that is your real concern, you should ask about that. The question you posted has little or no relevance to that.
3
Reply
SF.express avatar
us flag
SF.express
sorry i've never touched a real dhcpv6 server so not sure if it's really allocating ip addr solely based on the duid.
0
Reply
HiddenWindshield avatar
cn flag
HiddenWindshield
@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.
2
Reply
Score:4
avatar Server
kr flag
Sander Steffann

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.

0 + 8
SF.express avatar
us flag
SF.express
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.
0
Reply
Michael Hampton avatar
cz flag
Michael Hampton
@SF.express That's a quite different question to the one posted above. You should consider making a separate post.
0
Reply
SF.express avatar
us flag
SF.express
@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.
0
Reply
vidarlo avatar
ar flag
vidarlo
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.
0
Reply
SF.express avatar
us flag
SF.express
@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?
1
Reply
vidarlo avatar
ar flag
vidarlo
I have no idea where you're going with this...
0
Reply
SF.express avatar
us flag
SF.express
"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.
0
Reply
vidarlo avatar
ar flag
vidarlo
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.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.