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,
Martin
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