Red Hat Bugzilla – Bug 952126
Sending dhcpv6 reply to wrong port number
Last modified: 2013-11-21 02:43:50 EST
Description of problem: when a device does a DHCPv6 request from a random port number, the DHCPv6 service reply back to the random port number and not communicate back to the IPv6 standard port number. In the RFC they doesn't specify the source ports, thus you may send a request from a random port. The RFC specifies only the destination port. DHCPv6 standard (http://www.ietf.org/rfc/rfc3315.txt) Version-Release number of selected component (if applicable): - How reproducible: Always when sending a DCHPv6 request from a random port number. Steps to Reproduce: 1. The client sends a request from UDP port 49159 to all dhcpv6 services on the lan 2. The DHCPv6 services sending a replies back to the same port number 3. The client get a reply back on port number 49159 Actual results: the DHCPv6 service sends the reply to the wrong port number instead of UDP port 546 as was defined in Expected results: The DCHCPv6 service sends a reply back to UDP port 546 Additional info: When doing the same tests with a Microsoft 2008 R2 operating system. The client still sends request from a random port to the Windows 2008 DCHPv6 server, The DHCPv6 server sends it back to the UDP 546 port. The client accepts the message and configurate a dns server adress.
Created attachment 735836 [details] TCPdump
(In reply to comment #0) > 1. The client sends a request from UDP port 49159 to all dhcpv6 services on > the lan > 2. The DHCPv6 services sending a replies back to the same port number Reply [tech-list] from Neil Horman: Its not very well defined behavior to say the least. Arguments can be made both ways on this subject. But regardless, given that server behavior is varied on this front, certainly the most compatible thing for a client to do is simply send data on port 546.
(In reply to comment #3) > (In reply to comment #0) > > 1. The client sends a request from UDP port 49159 to all dhcpv6 services on > > the lan > > 2. The DHCPv6 services sending a replies back to the same port number > > Reply [tech-list] from Neil Horman: > Its not very well defined behavior to say the least. Arguments can be made > both > ways on this subject. But regardless, given that server behavior is varied > on > this front, certainly the most compatible thing for a client to do is simply > send data on port 546. The client is a dedicated device where it is not possible to change ports. I have contacted the manufacturer of the client with this problem, they said: 'We follow the RFC standard and the Red Hat DHCP server doesn't. They always need to follow international standards' In my opinion the most obvious solution is forcing the replies to the port as it was defined in the RFC standard.
You're right, it's a bug and has already been fixed upstream. From dhcp-4.1-ESV-R3 release notes: [ISC-Bugs #23196] - Modify the reply handling in the server code to send to a specified port rather than to the source port for the incoming message. Sending to the source port was test code that should have been removed. The previous functionality may be restored by defining REPLY_TO_SOURCE_PORT in the includes/site.h file. We suggest you don't enable this except for testing purposes.
Created attachment 738509 [details] patch
I have installed the test built packages, now the DHCPv6 service behave as prescribed in the RFC document. When can we expect this test built packages in a stable release of the Red Hat enterprise operating system ? Thanks
(In reply to Jiri Popelka from comment #6) > Created attachment 738509 [details] > patch I see it's too late to confirm.
Verified with dhcp-4.1.1-38.P1.el6.x86_64. dhcpd now sends response to standard dhcpv6-server port even if client uses non-standard port to query server.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1572.html