Description of problem: When an IPv6 address comes up but link is missing on the interface it's assigned to, the IPv6 address is marked tentative whilst the duplicate address detection process is pending - as per RFC4862. However, when the sysctl net.ipv6.conf.default.dad_transmits is set to 0 to disable DAD (as per section 5.4 of RFC4862) RHEL doesn't set the address to preferred and so the address effectively can't be used by the host until link is restored. This is a problem if a server comes up before the layer 2 link is established (e.g. powerloss in the datacenter takes out server + switch, and switch takes longer to boot than the server) because any services configured to bind to the IPv6 address will fail to start. It's possible that I've misunderstood the RFC, and that if an interface doesn't have link any addresses assigned to that interface shouldn't be usable, but this isn't expected behaviour to me. The following mailing list thread seems to suggest that disabling dad_transmits should work: http://lists.cluenet.de/pipermail/ipv6-ops/2011-March/005157.html Version-Release number of selected component (if applicable): Tested on RHEL5u4 with kernel-2.6.18-164.el5 and kernel-2.6.18-238.el5, iproute-2.6.18-10.el5 and iproute-2.6.18-11.el5. How reproducible: Always Steps to Reproduce: 1. Disconnect an interface 2. sysctl -w net.ipv6.conf.default.dad_transmits=0 3. sysctl -w net.ipv6.conf.all.dad_transmits=0 2. ip addr add 2a02:870:40:10::1/64 dev eth1 3. ip -6 addr show eth1 Actual results: 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qlen 1000 inet6 2a02:870:40:10::1/64 scope global tentative valid_lft forever preferred_lft forever Expected results: No "tentative" flag, ability to bind to and use the address. Additional info: # sysctl -a | grep dad_transmits net.ipv6.conf.eth1.dad_transmits = 0 net.ipv6.conf.eth0.dad_transmits = 0 net.ipv6.conf.default.dad_transmits = 0 net.ipv6.conf.all.dad_transmits = 0 net.ipv6.conf.lo.dad_transmits = 1 Setting the accept_dad sysctl's to 0 doesn't help either.
DAD is disabled by setting accept_dad to 0. However, it seems it doesn't work as expected in RHEL5, either. I'm looking into that.
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 release.
Patch(es) available in kernel-2.6.18-296.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Reproduced in 2.6.18-295.el5 and verified in 2.6.18-296.el5.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0150.html