Bug 708685

Summary: autoconfigure EUI64 IPv6 address often bound as source address in outgoing connections when static address is present
Product: Red Hat Enterprise Linux 5 Reporter: starlight
Component: initscriptsAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.6CC: initscripts-maint-list, vpavlin
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-12 11:47:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
example script that prefers static IPv6 addresses over dynamic ones
none
example script that prefers static IPv6 addresses over dynamic ones none

Description starlight 2011-05-28 20:29:01 UTC
Created attachment 501521 [details]
example script that prefers static IPv6 addresses over dynamic ones

Description of problem:

The autoconfigure EUI64 IPv6 address will often be chosen rather than a static IPv6 address assignment when the latter is present.

Version-Release number of selected component (if applicable):

initscripts-8.45.33-1.el5

How reproducible:

Configure a static IPv6 address in /etc/sysconfig/network-scripts/ifcfg-ethX with a IPV6ADDR= value and enable 'radvd' or another RA (router advertisement) entity on the LAN.

View interface addresses, e.g.

$ ip -6 addr list dev eth0
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 10000
    inet6 2001:470:885c:87:2e0:81ff:fe5e:e96d/64 scope global dynamic
       valid_lft 2591918sec preferred_lft 604718sec
    inet6 2001:470:885c:87::19/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:81ff:fe5e:e96d/64 scope link
       valid_lft forever preferred_lft forever

Establish outgoing connection to another system.  This works best if the system is on another routed subnet.  It's necessary that the autoconf address be more recently added than the static address (i.e. earlier in the "ip addr list" output).  This typically occurs without intervention.

$ nc6 2001:470:885c:79::2 22

Observe that the EUI64-derived IPv6 address is selected as the source address.

$ netstat -nt
Proto Recv-Q Send-Q Local Address               Foreign Address             Sta
tcp        0      0 2001:470:885c:87:2e0::59121 2001:470:885c:79::2:22      ESTABLISHED

$ netstat -t
Proto Recv-Q Send-Q Local Address               Foreign Address             Sta
tcp        0      0 [UNKNOWN]:35730             asa5505-ipv6:ssh            ESTABLISHED

Then add a RFC 3484 address preference that assigns the EUI64-derived address a lower priority than the static address with a command similar to

# ip addrlabel add prefix 2001:470:885c:87:2e0:81ff:fe5e:e96d/128 label 100

and establish an connection again.  Observe how the static address is bound this time as the source.

# netstat -nt
Proto Recv-Q Send-Q Local Address               Foreign Address             Sta
tcp        0      0 2001:470:885c:87::19:38055  2001:470:885c:79::2:22      ESTABLISHED


# netstat -t
Proto Recv-Q Send-Q Local Address               Foreign Address             Sta
tcp        0      0 siobhan-ipv6:38055          asa5505-ipv6:ssh            ESTABLISHED

Additional info:

We find it desirable that static-assignement addresses be preferred when connections are established, but also want router autoconfiguration active and want to leave autoconfiguration enabled in 'sysctl' on systems.  Believe that this should be the default behavior and suggest that the network scripts be adjusted to support it.  Have attached an example that configures this behavior when 'ifup' is run on an interface.

Comment 1 starlight 2011-05-28 21:57:23 UTC
Looked at 'ipv6_get_saddr_eval()' in 'kernel/net/ipv6/addrconf.c' to understand this better.  RFC3484 label precedence does not come into play here.  Just simple label matching in Source Address Selection Rule 6 of the RFC.  The "if addrlabel" entry's purpose then is to exclude the EUI64 addresses from label "1" where most other IPv6 addresses usually reside.  The attached-script comment mentioning precedence is inaccurate.

Possibly this approach is not sufficiently generic since the it is possible for the destination IP and both candidate source IPs to have different labels, and for the source addresses to end up in a tie once again.  Have seen it suggested that the address lifetime be used as a final tie-breaker when selecting a source address.  That would be a change in the kernel and might be controversial as the RFC does not specify it.  On the other hand such a rule would not change the behavior specified in the RFC, only change a random tied-address selection into a deterministic one.

Comment 2 starlight 2011-05-29 01:01:43 UTC
Created attachment 501551 [details]
example script that prefers static IPv6 addresses over dynamic ones

corrected comments

Comment 3 Václav Pavlín 2013-03-12 11:47:50 UTC
Hi, although it sounds reasonable, I don't think we should change the behaviour like this in the last release of RHEL5. Closing as wontfix.