Send dhcp-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: dhcpd responding to unicast? (Martin Garbe)
2. Re: dhcpd responding to unicast? (Simon Hobson)
3. Re: dhcpd responding to unicast? ([email protected])
4. Re: dhcpd responding to unicast? (Martin Garbe)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Nov 2015 21:35:53 +0100
From: Martin Garbe <[email protected]>
To: [email protected]
Subject: Re: dhcpd responding to unicast?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 11/10/2015 11:07 AM, Simon Hobson wrote:
> Martin Garbe <[email protected]> wrote:
>
>> Once the client has determined the address of a server
>
> How does an unconfigured client know this ?
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.
>
>
>> , it may under
>> some circumstances send messages directly to the server using
>> unicast.
>> ------
>> Our scenario here is one of these "some circumstances".
>
> Actually, I don't think your situation is one of those circumstances
> envisaged.
>
> In the IPv4 world, once a client is configured (which requires broadcast
> packets), then it may unicast packets (eg to renew a lease) to the server -
> it knows the server address because it's part of the information supplied to
> it. I'm not familiar enough with IPv6 to say if this is (effectively) the
> same.
For IPv6 it is similar. Only broadcast is substituted by multicast.
It seems that the cited words from RFC can be interpreted in very
different ways. The usual syntax-semantic problem :)
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?
Kind regards,
Martin
------------------------------
Message: 2
Date: Tue, 10 Nov 2015 21:51:04 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: dhcpd responding to unicast?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Martin Garbe <[email protected]> wrote:
>>> Once the client has determined the address of a server
>>
>> How does an unconfigured client know this ?
>
> 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 ?
> 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?
I don't know that it doesn't, and I'd guess that it might actually accept
unicast traffic. But still, you have the problem that to send unicast to the
server you need to know it's address - and if you know its address then you are
half way to not needing DHCP anyway.
For sniffing traffic, my preferred tool is wireshark (or it's command line
twin, tshark)
------------------------------
Message: 3
Date: Wed, 11 Nov 2015 09:36:23 +0100 (CET)
From: [email protected]
To: [email protected]
Subject: Re: dhcpd responding to unicast?
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset=us-ascii
> > 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, [email protected]
------------------------------
Message: 4
Date: Wed, 11 Nov 2015 10:35:15 +0100
From: Martin Garbe <[email protected]>
To: [email protected]
Subject: Re: dhcpd responding to unicast?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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, [email protected] 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, [email protected]
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 85, Issue 12
******************************************
