dhcpd responding to unicast?

[sthaug at nethelp.no]

> > With IPv6 devices can have many IP addresses. When clients have
> > predefined private IPs (ULA) they can communicate with each other. But
> > these IPs are not routable in the Internet. We want to use DHCPv6 to
> > assign dynamic public IPs.
> 
> You missed the question. How does the unconfigured client know the address of the server ?

The DHCPv6 specification (RFC 3315) is very clear that a regular
4-message exchange (when the client doesn't know the server) starts with
the client sending to a specific multicast address - see

https://tools.ietf.org/html/rfc3315#section-1.3

"To request the assignment of one or more IPv6 addresses, a client first
locates a DHCP server and then requests the assignment of addresses and
other configuration information from the server.  The client sends a
Solicit message to the All_DHCP_Relay_Agents_and_Servers address to find
available DHCP servers."

As far as I can see this is the *only* way to obtain an address using
DHCPv6 (the 2-message exchange, RFC 3315 section 1.2, is meant for
situations "When a DHCP client does not need to have a DHCP server
assign it IP addresses...").

> > I am/was assuming that implementing unicast-only support should be easy.
> > For what reason does the dhcpd not accept unicast traffic for initial
> > requests? In which situations is this a problem?

RFC 3315 explicitly prohibits it:

https://tools.ietf.org/html/rfc3315#section-15

"A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address."

A client can only send unicast messages to the server if it has
received a Server Unicast option from the server:

https://tools.ietf.org/html/rfc3315#section-16

"When a client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option from that server), the source
address in the header of the IP datagram ..."

and https://tools.ietf.org/html/rfc3315#section-18.1

"If the client has a source address of sufficient scope that can be used
by the server as a return address, and the client has received a Server
Unicast option (section 22.12) from the server, the client SHOULD
unicast any Request, Renew, Release and Decline messages to the server."

Furthermore, in sections 18.2.1 - 18.2.7 there is very explicit language
of the form "When the server receives a XXX message via unicast from a
client to which the server has not sent a unicast option, the server
discards the XXX message and responds with a Reply message containing a
Status Code option with the value UseMulticast ..."

So - my reading of RFC 3315 is that DHCPv6 is only meant to use unicast
in very limited circumstances.

The RELNOTES documentation for ISC DHCP 4.3.3 says

"The server will now reject unicast Request, Renew, Decline, and Release
messages from a client unless the server would have sent that client the
dhcp6.unicast option.  This behavior is in compliance with paragraph 1
in each of the sections 18.2,1, 18.2.3, 18.2.6, and 18.2.7 of RFC
3315. Prior to this, the server would simply accept the messages.  Now,
in order for the server to accept such a message, the server
configuration must include the dhcp6.unicast option either globally or
within the shared network to which the requested lease belongs."

So that's how you can get ISC DHCP to support DHCPv6 unicast messages.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no