From: Marcin Siodelski Date: Tue, 23 Jun 2015 15:03:48 +0000 (+0200) Subject: [3740] Added section about issues with unicast responses to DHCPINFORM. X-Git-Tag: trac3771_base~5^2~3 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7a186d7beee327530371a3fdb1ad5b3fdc9c877b;p=thirdparty%2Fkea.git [3740] Added section about issues with unicast responses to DHCPINFORM. Updated User's Guide and the description of the log message pertaining to the DHCP message send. --- diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index d38bebe38d..b355c63065 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -570,6 +570,57 @@ temporarily override a list of interface names and listen on all interfaces. +
+ Issues with unicast responses to DHCPINFORM + The use of the UDP sockets has certain benefits in the deployments + where the server receives a relayed traffic only. These benefits are + mentioned in the . From + the administrator's perspective it is often desired to be able to + configure the system's firewall to filter out the unwanted traffic, and + the use of UDP sockets faciliates it. However, the administrator must + also be aware of the implications related to filtering certain types + of traffic as it my impair the DHCP server's operation. + + + In this section we are focusing on the case when the server + receives the DHCPINFORM message from the client via a relay. According + to the RFC 2131, + the server should unicast DHCPACK response to the address carried in + the 'ciaddr' field. When the UDP socket is in use, the DHCP server + relies on the low level functions of an operating system to build the + data link, IP and UDP layer of the outgoing message. Typically, the + OS will first use ARP to obtain the client's link layer address to be + inserted into the frame's header. When the ARP exchange is successful, + the DHCP message can be unicast to the client, using the address + obtained. + + + Some system administrators block ARP messages in their network, + which causes issues for the server when it responds to the + DHCPINFORM messages, because the server is unable to send the + DHCPACK if the preceding ARP communication fails. Since the OS is + entirely responsible for the ARP communication and then sending + the DHCP packet over the wire, the DHCP server has no means to + determine that the ARP exchange failed and the DHCP response message + was dropped. Thus, the server does not log any error messages when + the outgoing DHCP response is dropped. At the same time, all hooks + pertaining to the packet sending operation will be called, even + though the message never reaches its destination. + + + Note that the issue described in this section is not observed + when the raw sockets are in use, because, in this case, the DHCP server + builds all the layers of the outgoing message on its own and does not + use ARP. Instead, it inserts the value carried in the 'chaddr' field + of the DHCPINFORM message into the link layer. + + + The server administrators willing to support DHCPINFORM + messages via the relays should not block ARP traffic in their + networks or use the raw sockets instead of the UDP sockets. + +
+
IPv4 Subnet Identifier diff --git a/src/bin/dhcp4/dhcp4_messages.mes b/src/bin/dhcp4/dhcp4_messages.mes index 4671974d5d..2aae7fe4d6 100644 --- a/src/bin/dhcp4/dhcp4_messages.mes +++ b/src/bin/dhcp4/dhcp4_messages.mes @@ -427,11 +427,24 @@ respectively. The remaining arguments specify the source IPv4 address, destination IPv4 address and the name of the interface on which the message has been received. -% DHCP4_PACKET_SEND %1: sending packet %2 (type %3) from %4:%5 to %6:%7 on interface %8 -This debug message is issued when the server is sending the response to -the client. The arguments specify the client identification information -(HW address and client identifier), DHCP message name and type, source -IPv4 address and port, destination IPv4 address and port and the +% DHCP4_PACKET_SEND %1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8 +This debug message is issued when the server is trying to send the +response to the client. When the server is using the UDP socket +to send the packet there are cases when this operation may be +unsuccessful and no error message is displayed. One such situation +occurs when the server is unicasting response to the 'ciaddr' of +the DHCPINFORM message. This often requires broadcasting the ARP +message to obtain the link layer address of the unicast destination. +If broadcast ARP messages are blocked in the network, according to +the firewall policy, the ARP message will not be responded. +Consequently, the response to DHCPINFORM will not be sent. +Since the ARP communication is under the OS control, Kea is not +notified about the drop of the packet which it is trying to send +and it has no means to display the error message. + +The arguments specify the client identification information (HW address +and client identifier), DHCP message name and type, source IPv4 +address and port, destination IPv4 address and port and the interface name. % DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2