Description of problem: If you bring your DHCPv4 laptop to a network which doesn't support IPv4, even if the laptop and the network is IPv6-enabled, interface configuration fails. This appears to be because dhclient is unable to get contact to DHCP servers and get IPv4 address, it shuts down the interface after a while. Dhclient and initscripts framework should be re-examined in the light of various different IPv4-IPv6 interoperability scenarios, for example: 1) ipv4-only network, with manual config 2) ipv4-only network, with dhcp config 3) ipv4/ipv6 dual stack network, ipv6 stateless autoconfiguration, ipv4 dhcp 4) ipv4/ipv6 dual stack network, ipv6 stateless autoconfiguration, dhcpv6 for DNS server information, ipv4 dhcp (to work in cases where ipv4 doesn't work) 5) ipv4/ipv6 dual stack network, dhcpv6 for address and DNS server information, ipv4 dhcp 6) ipv6-only network, with dhcpv6 for information, stateless for addresses 7) ipv6-only network, with dhcpv6 for addresses and information This was triggered by me participating in the IETF ipv6-only experiment: http://slashdot.org/article.pl?sid=08/03/14/1812223 Version-Release number of selected component (if applicable): RHEL 5.1. How reproducible: Insert interface configuration with BOOTPROTO=dhcp and IPv6 enabled to a network which has IPv6 but does not have a DHCPv4 server. The interface configuration fails after about 1-2 minutes after you bring the interface up (during which IPv6 can be used fine), with the following printed if you do ifup ethX on console:: PING 130.129.16.1 (130.129.16.1) from 130.129.20.83 eth1: 56(84) bytes of data. --- 130.129.16.1 ping statistics --- 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms , pipe 3 failed. (130.129.16.1 here is the historical IPv4 default gateway AFAIR and 130.129.20.83 corresponds to the IPv4 address the host has last used on an ipv4-enabled network.) Additional info: With the following interface flags, this works to some degree: PERSISTENT_DHCLIENT=yes DHCLIENT_ARGS="-nw" the first line instructs dhclient to keep running and not exit if it doesn't get address; -nw allows you to start using the system immediately rather than waiting for about 1 minute to get an IPv4 address. I'm not sure if these cause problems in some other environments though; I have not seen ill effects to date. One particular problem for which I could not figure out a solution for has been how you configure DNS information in various dual-stack or ipv6-only environments. DNS server configuration could be obtained using various ways (e.g. with PEERDNS=no|yes and DNS[12]=address, DHCPv4 and DHCPv6) and it does not necessarily correspond to to a working IP version; it's also not obvious what the precedence order of these configurations should be. These issues are discussed in RFC4477. Some solution is needed in this space but I don't know what would be the optimal solution.
Hm, your 'network down' issue is just another case of bug 491009, more or less. However, in this case it's dhclient behavior, and I don't think it's configurable. CC'ing dhclient maintainer.
Given that this is the behavior for a long time running, changing it in an update release would not be appropriate. Closing as WONTFIX for RHEL 5 and earlier.
dhclient that shipped in RHEL-5 doesn't support the DHCPv6 protocol. For that, you have to run dhcp6c (which is in RHEL-5).
David Cantrell: that's not the point. The point is, if you have "BOOTPROTO=dhcp" configured, and connect to a network that only provides IPv6, dhclient failing brings down the interface, even if you'd be running DHCPv6 or stateless address autoconfiguration. I.e., this is based on a (now) broken assumption that "if you can't get DHCPv4 response on an interface that has DHCPv4 enabled [e.g. laptops], you don't have usable connectivity and you should take the interface down".