Bug 476974 - DHCPv6 client doesn't form the DHCP REQUEST packets properly
DHCPv6 client doesn't form the DHCP REQUEST packets properly
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
All Linux
high Severity high
: rc
: 5.5
Assigned To: Jiri Popelka
Alexander Todorov
Depends On:
Blocks: 557926
  Show dependency treegraph
Reported: 2008-12-18 07:09 EST by Adam Stokes
Modified: 2010-10-23 02:39 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 498535 (view as bug list)
Last Closed: 2010-03-30 04:03:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (813 bytes, patch)
2009-08-20 14:18 EDT, Bryan Mason
no flags Details | Diff

  None (edit)
Description Adam Stokes 2008-12-18 07:09:46 EST
Created attachment 327316 [details]

DHCPv6 client doesn't form the DHCP REQUEST packets properly. The sequence of events when the DHCPv6 client is run is :

1. Client sends a SOLICIT messge
2. Server responds with a ADVERTISE which has a IA_NA field. This field contains a IA Adress which contains the IPv6 address, which the server will send in a subsequent REPLY message.
3. The client forms a REQUEST packet which contains the address advertised by the Server. In RHEL 5.3 snapshot3 this is not happening. The IA_NA field of the Request packet doesn't contain the IA subfield ( which should contain the address advertised by server)
4. The Server sends the REPLY packet with the address it advertised. Here in RHEL 5.3 snapshot 3 the Reply packet conatins an address different than the advertised.

How reproducible: Always

Steps to Reproduce:
1. Configure a DHCPv6 server
2. From a client run a DHCPv6 client

dhcp6c -c /etc/dhcp6c.conf -dDf eth0

3. Capture these messages using wireshark
4. Observe the behaviour mentioned in the issue description.

Actual results: Below mentioned behaviour is not seen.

Expected results:DHCPv6 client Request packet should contain the IA subfield of IA_NA filed carrying the IPv6 address advertised by server.

Additional info:

1. This behaviour prevents RHEL 5.3 DHCPv6 client from getting response from a Windows DHCPv6 server.

2. This issue is fixed in a latest version of DHCPv6 package from upstream.( dhcpv6-1.0.22 from https://fedorahosted.org/releases/d/h/dhcpv6/ ). I experimented this on a OpenSuse 11.1 beta install which has this latest upstream version of dhcpv6.
Comment 2 David Cantrell 2008-12-18 14:39:57 EST
What is the NVR of the dhcpv6 package?  Also, why are these comments set to private?
Comment 3 Adam Stokes 2008-12-19 06:05:01 EST
NVR - 1.0.10-16, i didn't want the attachments to be made public is all.. sorry
Comment 4 David Cantrell 2008-12-19 21:31:38 EST
Fedora has the latest upstream release of dhcpv6, mostly because I am the upstream for dhcpv6.  Latest is 1.1.0.

I'm looking through the commit log and cannot find any particular commit where this issue was addressed, but I may skipping over it or it may have been an issue that was fixed when something else was fixed.  It's possible this was fixed with the multiple IA option code that was added.

At any rate, this report strikes me as a bit odd because dhcpv6 received an enormous amount of QA for 5.3 and underwent DoD IPv6 testing and certification.  The fact that a REQUEST packet is invalid from the client strikes me as odd.

I looked at your tcpdump logs and was wondering what you were using for the dhcpv6 server.
Comment 6 Narendra K 2009-02-03 02:18:10 EST
I used Windows Server 2008 DHCPv6 server.

Also i believe that the wireshark protocol traces that i have attached show the difference between the REQUEST packets of working version and REQUEST packets of non working version.
Comment 9 Bryan Mason 2009-04-30 18:48:18 EDT
It looks like this was fixed with the following upstream commits:


Is this correct?
Comment 15 Bryan Mason 2009-07-20 13:47:19 EDT
The test packages appear to have enabled the dhcpv6 client to interoperate properly with Windows.  However, the packages may have exposed an issue in the way the client works with the Linux dhcpv6 server.  Bug 511323 contains the details, but the short version is that if the server sends a NotOnLink in the REPLY to the client's REQEST, then the client restarts with a SOLICIT, but ignores the ADVERTISE.  The client eventually gets an address, but it's not the one sent in any of the ADVERTISE messages.  Bug 511323 contains a possible resolution to the issue.
Comment 16 Bryan Mason 2009-08-20 14:18:19 EDT
Created attachment 358143 [details]
Proposed patch
Comment 17 Bryan Mason 2009-08-20 14:21:03 EDT
We've resolved the issue with the NotOnLink errors (DHCPv6 server configuration issue), and verified that the patch in Comment #16 enables the DHCPv6 client to interoperate correctly with both Windows and Linux DHCPv6 servers.
Comment 18 David Cantrell 2009-08-22 00:44:35 EDT
Giving this a devel-ack because we have a patch and it has been tested in the field.
Comment 19 RHEL Product and Program Management 2009-09-25 13:41:22 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 29 errata-xmlrpc 2010-03-30 04:03:15 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.