Bug 553804

Summary: DHCPv6-assigned addresses deconfigured on "service network restart"
Product: [Fedora] Fedora Reporter: Darren Gamble <darren.gamble>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: jpopelka
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-06 10:32:28 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Darren Gamble 2010-01-08 17:24:17 EST
Description of problem:
Network interfaces configured via DHCPv6 will be deconfigured if the interface is brought down/up via control scripts


Version-Release number of selected component (if applicable):
dhcp-4.1.0p1-13.fc12

How reproducible:
Always

Steps to Reproduce:
1. Enable DHCPc6 on interface.
2. Bring up interface to invoke dhclient
3. Run "service network restart" to bring the interface back down and back up again


Actual results:
The interface will no longer be addressed with a v6 address.

Expected results:
The interface should be addressed with the same v6 address before the restart.

Additional info:
The issue is a logic failure in the /sbin/dhclient-script file.  When the interface is first brought up, dhclient passes the "reason" as BOUND6, causing it to configure the interface.  When the interface is "restart"ed, dhclient renews the address and passes REBIND6 as the reason.  However for the REBIND6 reason the script assumes that the address is already configured and does not attempt to (re)configure the interface.  The script should instead use similar logic to how it processes IPv4 leases.

Note that to even -get- DHCPv6 support in Fedora 12 means both fixing the control scripts (detailed in bug #531769) and getting the latest "dhcp" package update (Bug #531997) which provides the semifunctional /sbin/dhclient script.
Comment 1 Jiri Popelka 2010-04-22 06:16:12 EDT
Hi Darren,

thanks for the report and sorry for my delayed response.

First, you are right that to even -get- DHCPv6 support in Fedora 12 means fixing the control scripts (initscripts).
Because this initscripts problem is (and will be) not fixed in Fedora 12 (bug #531769) but first in Fedora 13 (bug #553017) I want you to test your problem again in Fedora 13 (when you get to it).

I have different experiences with the dhcpv6 functionality
when bringing the interface down and back up.

When I restart the interface either with 'service network restart' or ifdown/ifup, dhclient initiates Confirm/Reply message exchange to know
whether it can use the old address. When the server confirms it,
dhclient passes the BOUND6 reason to dhclient-script and the interface
is configured with the old address.

RENEW6/REBIND6 reasons are passed to dhclient-script when client renews/rebinds (see [1]) its lease. This happens when time T1/T2 (see [1]) is reached and is not related to restarting of interface.
When client is renewing/rebinding its lease he's still using the old address during the process of renewing/rebindig so there's no reason to (re)configure the interface.
The only situation I have in mind where it (configure the interface in RENEW6/REBIND6) is imaginable is when the client has one address in IA and during the renewing/rebinding the server sends Reply message with more than one address (the old one + some now address(es)).
In this case the client have to (re)configure the interface to also use the additional address(es).
This situation is bug #578097 about.

To sum this up:
Please try it again in Fedora 13 where your "Steps to Reproduce" give your "Expected results" to me.
If you have still the same problem with F13 we can solve it against F13,
because in F12 we need to hack initscripts to get dhcpv6 working.
That's why I'm changing the version from F12 to F13 now.

Additional info:
[1] RFC 3315
      18.1.3. Creation and Transmission of Renew Messages
      18.1.4. Creation and Transmission of Rebind Messages