Bug 709271

Summary:	net.ipv6.conf.default.dad_transmits has no effect on tentative IPv6 addresses
Product:	Red Hat Enterprise Linux 5	Reporter:	Jonathan Barber <jonathan.barber>
Component:	kernel	Assignee:	Jiri Benc <jbenc>
Status:	CLOSED ERRATA	QA Contact:	Petr Beňas <pbenas>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	5.4	CC:	davem, haliu, herbert.xu, jagiello.lukasz, pbenas, pstehlik, tgraf
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	kernel-2.6.18-296.el5	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-21 03:49:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jonathan Barber 2011-05-31 09:06:29 UTC

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.

Comment 1 Jiri Benc 2011-10-21 10:10:59 UTC

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.

Comment 4 RHEL Program Management 2011-11-01 18:10:36 UTC

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.

Comment 6 Jarod Wilson 2011-11-09 19:46:20 UTC

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.

Comment 11 Petr Beňas 2011-11-18 07:53:33 UTC

Reproduced in 2.6.18-295.el5 and verified in 2.6.18-296.el5.

Comment 12 errata-xmlrpc 2012-02-21 03:49:09 UTC

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