dhcpd responding to unicast?

Martin Garbe monomartin at opennet-initiative.de
Wed Nov 11 09:35:15 UTC 2015

Hello Steinar,

thanks for this very detailed explanation. That makes the situation
perfectly clear.

Thanks you very much,

On 11/11/2015 09:36 AM, sthaug at nethelp.no wrote:
>>> 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
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

More information about the dhcp-users mailing list