This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 498535 - DHCPv6 client doesn't form the DHCP REQUEST packets properly
DHCPv6 client doesn't form the DHCP REQUEST packets properly
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
4.8
All Linux
high Severity high
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-30 17:59 EDT by Bryan Mason
Modified: 2012-06-14 16:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 476974
Environment:
Last Closed: 2012-06-14 16:21:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (759 bytes, patch)
2009-04-30 18:53 EDT, Bryan Mason
no flags Details | Diff
Corrected patch (758 bytes, patch)
2009-04-30 20:12 EDT, Bryan Mason
no flags Details | Diff
dhcp6c with a RHEL 5.2 dhcp6s server (2.00 KB, application/octet-stream)
2009-05-04 10:13 EDT, Narendra K
no flags Details
dhcp6c with a windows dhcp6s server (1.14 KB, application/octet-stream)
2009-05-04 10:18 EDT, Narendra K
no flags Details
dhcp6c debug output and packet trace with a linux server only. (2.65 KB, application/gzip)
2009-06-18 09:39 EDT, Narendra K
no flags Details

  None (edit)
Description Bryan Mason 2009-04-30 17:59:40 EDT
Cloning RHEL 5 problem for RHEL 4:

+++ This bug was initially created as a clone of Bug #476974 +++

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.

--- Additional comment from dcantrell@redhat.com on 2008-12-19 21:31:38 EDT ---

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.

--- Additional comment from narendra_k@dell.com on 2009-02-03 02:18:10 EDT ---

I used Windows Server 2008 DHCPv6 server.
Comment 1 Bryan Mason 2009-04-30 18:53:59 EDT
Created attachment 342020 [details]
Proposed patch

It looks like this was fixed with the following upstream commits:

https://fedorahosted.org/dhcpv6/changeset/95e3fd53cf8487b6426d8f81bfdf9890275cb2e8
https://fedorahosted.org/dhcpv6/changeset/1155a69e9456e5883885175598731ba12de49c05

Is this correct?  If so, then the attached patch is my attempt to backport these to RHEL 4 (other than line numbers, the only change I made was to change

    dhcp6_copy_list(&ia->addr_list, &request_list);

to

    dhcp6_copy_list(&optinfo->addr_list, &request_list);

in the patch).
Comment 2 Bryan Mason 2009-04-30 20:12:17 EDT
Created attachment 342024 [details]
Corrected patch
Comment 3 Narendra K 2009-05-04 10:02:23 EDT
(In reply to comment #1)
> Created an attachment (id=342020) [details]
> Proposed patch
> 
> It looks like this was fixed with the following upstream commits:
> 
> https://fedorahosted.org/dhcpv6/changeset/95e3fd53cf8487b6426d8f81bfdf9890275cb2e8
> https://fedorahosted.org/dhcpv6/changeset/1155a69e9456e5883885175598731ba12de49c05
> 
> Is this correct?  If so, then the attached patch is my attempt to backport
> these to RHEL 4 (other than line numbers, the only change I made was to change
> 
>     dhcp6_copy_list(&ia->addr_list, &request_list);
> 
> to
> 
>     dhcp6_copy_list(&optinfo->addr_list, &request_list);
> 
> in the patch).  

This indeed looks like the patch which fixes this issue. I have two observations after applying this patch -

1. I tested the fix with a windows dhcpv6 server. Now the client gets an IPv6 address.

2. With a Linux DHCPv6 ( RHEL 5.2 dhcpv6 server) server, the client initially sends the proper request ( With a IA field)  and gets a proper response, but immedielty after that repeats the whole process and this time the request is without a IA filed as advertised by the server. And the behaviour and result are as described in the problem description.

I have attached the protocol traces to this issue.
Comment 4 Narendra K 2009-05-04 10:13:54 EDT
Created attachment 342312 [details]
dhcp6c with a RHEL 5.2 dhcp6s server
Comment 5 Narendra K 2009-05-04 10:18:58 EDT
Created attachment 342314 [details]
dhcp6c with a windows dhcp6s server
Comment 6 Bryan Mason 2009-06-15 18:02:22 EDT
(In reply to comment #3)

> 2. With a Linux DHCPv6 ( RHEL 5.2 dhcpv6 server) server, the client initially
> sends the proper request ( With a IA field)  and gets a proper response, but
> immedielty after that repeats the whole process and this time the request is
> without a IA filed as advertised by the server. And the behaviour and result
> are as described in the problem description.

Does this mean that the Linux client was able to configure itself properly with an address from the Linux DHCPv6 server, but it just took an additional iteration?
Comment 7 Narendra K 2009-06-18 09:39:52 EDT
Created attachment 348461 [details]
dhcp6c debug output and packet trace with a linux server only.
Comment 8 Narendra K 2009-06-18 09:40:21 EDT
(In reply to comment #6)
> (In reply to comment #3)
> 
> > 2. With a Linux DHCPv6 ( RHEL 5.2 dhcpv6 server) server, the client initially
> > sends the proper request ( With a IA field)  and gets a proper response, but
> > immedielty after that repeats the whole process and this time the request is
> > without a IA filed as advertised by the server. And the behaviour and result
> > are as described in the problem description.
> 
> Does this mean that the Linux client was able to configure itself properly with
> an address from the Linux DHCPv6 server, but it just took an additional
> iteration?  

No. Not properly. The first iteration the behaviour is proper. The second iteration it doesn't include the advertised address in it's request to the server, so the server replies with a different address than it advertised. 

I am attching a packet capture file and debug output of dhcp6c to this issue.
Comment 9 David Cantrell 2009-06-24 20:49:44 EDT
The patch is fine by me for backporting to RHEL-4.  Keep in mind that the version of dhcpv6 in RHEL-4 and RHEL-5 differ by years.  The version in RHEL-5 is far more RFC compliant.  I mention that because if a customer continues down the road of using dhcpv6 in RHEL-4, they are likely to hit a lot of problems.  They would be much better off using RHEL-5 as that version of dhcpv6 has had significant improvements in order to improve RFC compliance and pass various IPv6 certifications.  Just something to think about if more issues are found with the version in RHEL-4.  I am not interested in backporting huge amounts of code to RHEL-4.

However, if the goal is to make the version in RHEL-4 simply work for customers, then this patch is probably adequate.
Comment 11 RHEL Product and Program Management 2010-10-22 14:58:32 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

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