DHCPv6 request from DHCPv6 client came from a random port number instead of defined 546/udp.
DHCPv6 server sent reply back to the source port of the message instead of defined 546/udp.
Reply handling in the DHCPv6 server code was modified.
Server sends reply to a 546/udp rather than to the source port for the incoming message.
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):
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
the DHCPv6 service sends the reply to the wrong port number instead of UDP port 546 as was defined in
The DCHCPv6 service sends a reply back to UDP port 546
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]
(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
> ways on this subject. But regardless, given that server behavior is varied
> 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]
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]
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.