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,
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:
Version-Release number of selected component (if applicable):
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 220.127.116.11 (18.104.22.168) from 22.214.171.124 eth1: 56(84) bytes of
--- 126.96.36.199 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms
, pipe 3
(188.8.131.52 here is the historical IPv4 default gateway AFAIR and
184.108.40.206 corresponds to the IPv4 address the host has last used on an
With the following interface flags, this works to some degree:
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=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
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".