Bug 952126

Summary: Sending dhcpv6 reply to wrong port number
Product: Red Hat Enterprise Linux 6 Reporter: Vanboxtel <redhat-support>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED ERRATA QA Contact: Ladislav Jozsa <ljozsa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: ljozsa, lnovich, ovasik, psimerda, rupatel
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: dhcp-4.1.1-35.P1.el6 Doc Type: Bug Fix
Doc Text:
Cause: DHCPv6 request from DHCPv6 client came from a random port number instead of defined 546/udp. Consequence: DHCPv6 server sent reply back to the source port of the message instead of defined 546/udp. Fix: Reply handling in the DHCPv6 server code was modified. Result: Server sends reply to a 546/udp rather than to the source port for the incoming message.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 07:43:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
TCPdump
none
patch none

Description Vanboxtel 2013-04-15 09:06:06 UTC 
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.
Comment 1 Vanboxtel 2013-04-15 09:07:48 UTC 
Created attachment 735836 [details]
TCPdump
Comment 3 Jiri Popelka 2013-04-22 10:21:03 UTC 
(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.
Comment 4 Vanboxtel 2013-04-22 11:46:27 UTC 
(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.
Comment 5 Jiri Popelka 2013-04-22 12:28:37 UTC 
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.
Comment 6 Jiri Popelka 2013-04-22 12:29:52 UTC 
Created attachment 738509 [details]
patch
Comment 9 Vanboxtel 2013-04-23 13:59:04 UTC 
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
Comment 17 Pavel Šimerda (pavlix) 2013-09-10 19:15:28 UTC 
(In reply to Jiri Popelka from comment #6)
> Created attachment 738509 [details]
> patch

I see it's too late to confirm.
Comment 18 Ladislav Jozsa 2013-10-15 14:59:13 UTC 
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.
Comment 19 errata-xmlrpc 2013-11-21 07:43:50 UTC 
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