Bug 199862

Summary: IPv6 setup: fix default IPv6 address to IPV6ADDR in case of IPV6ADDR_SECONDARIES are used
Product: Red Hat Enterprise Linux 4 Reporter: Peter Bieringer <pb>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: denis, gprakash.gps, pekkas, russ+bugzilla-redhat, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-06 21:48:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch which remove and readd IPV6ADDR in case of IPV6ADDR_SECONDARIES are defined
none
Patch which remove and readd IPV6ADDR in case of IPV6ADDR_SECONDARIES are defined
none
Alternative simple patch for RHEL4 none

Description Peter Bieringer 2006-07-23 12:25:23 UTC
Created attachment 132881 [details]
Patch which remove and readd IPV6ADDR in case of IPV6ADDR_SECONDARIES are defined

Comment 1 Peter Bieringer 2006-07-23 12:25:23 UTC
Description of problem:
If an additional IPv6 address is added to an interface, this address would be
the primary address for outgoing connections (if scope is proper).

Version-Release number of selected component (if applicable):
initscripts-7.93.24.EL
kernel-2.6.9-34.0.2.EL

How reproducible:
always after reboot

Steps to Reproduce:
1. extend interface configuration for IPv6 like:

/etc/sysconfig/network-scripts/ifcfg-eth0
...

# IPv6
IPV6INIT="yes"
IPV6ADDR="2001:db8:0:1::162:1/64"
IPV6ADDR_SECONDARIES="2001:db8:0:1::188:1/64 2001:db8:0:1::189:1/64
2001:db8:0:1::190:1/64"
IPV6_DEFAULTGW="2001:db8:0:1::1"
IPV6_AUTOCONF="no"

2. initializie network
3. telnet/ssh to an IPv6 enabled destination
  
Actual results:
outgoing source address would be 2001:db8:0:1::190:1

As described, the last one added 
# ip -6 addr show dev eth0 | grep inet6 | grep global
    inet6 2001:db8:0:1::190:1/64 scope global
    inet6 2001:db8:0:1::189:1/64 scope global
    inet6 2001:db8:0:1::188:1/64 scope global
    inet6 2001:db8:0:1::162:1/64 scope global


Expected results:
Use of 2001:db8:0:1::162:1 as primary address for outgoing connections.

Additional info:

A simple patch to ifup-ipv6 solves this issue. In case of IPV6ADDR_SECONDARIES
are defined, after applying the addresses, IPV6ADDR is removed and readded to
the interface. This causes that IPV6ADDR is now the first one in the list and
therefore used as primary address for outgoing connections.

Comment 2 Peter Bieringer 2006-07-23 19:18:40 UTC
Created attachment 132887 [details]
Patch which remove and readd IPV6ADDR in case of IPV6ADDR_SECONDARIES are defined

Improved patch which checks whether IPV6ADDR is really not the first one in
list after IPV6ADDR_SECONDARIES are added. If not, remove and readd it. This
patch should be safe for the future.

Comment 3 Bill Nottingham 2006-07-24 14:37:46 UTC
Can't you just set the secondary addresses with a specific scope when you add them?

Comment 4 Peter Bieringer 2006-07-24 15:52:26 UTC
Specific scope doesn't help, because all addresses are global scope (they are
alias addresses for specific services to move them more or less transparent to
another host).
Flag "primary" would help, but looks like not supported in IPv6 (never seen and
"ip" doesn't support it, too). 

Comment 5 Bill Nottingham 2006-07-24 16:08:14 UTC
Hm. You could also set the source address on the route itself...

Comment 6 Peter Bieringer 2006-07-24 16:19:26 UTC
"ip -6 route add" accepts "src <address>" but didn't show this in routing table
and it's also not working here.

 



Comment 7 Bill Nottingham 2006-07-24 16:47:01 UTC
Ugh. Add/remove just seems wrong. Is default *always* the last one added? Could
the order be reversed (add secondaries, then primary)?

Comment 8 Peter Bieringer 2006-07-24 22:37:26 UTC
Current behavior (don't know the reason, perhaps Pekka or better Alexey [if
still working on the IPv6 kernel part] have more information why kernel does
this), is, that for new (at least - UDP not tested) TCP connections, the first
one shown in list is used (ping6 has a different behavior here at least on FC5,
it always using the first added one - perhaps a local issue here...).

Anyway, my 2nd patch checks, whether IPV6ADDR is *not* the first one in list, if
so, it would be removed and readded.

If we add the secondaries before the primary address in an unconditional way,
and sometimes in the future the behavior of adding addresses would change, mean
order will be kept instead of stack-behavior (last added will be first in list),
we run into a problem. Because we currently cannot expect, which kernel version
act as current or not, but assuming first address in list is the primary, my
current patch would be the fail-safest one I think.



Comment 9 Bill Nottingham 2006-07-25 00:39:53 UTC
I don't like it; removing and readding addresses is just a bad hack. We should
find a scalable way to do this, by finding some way to set the address as primary.

I should probably try and track down a networking guru.

Comment 10 Peter Bieringer 2006-07-25 06:08:47 UTC
I agree, that this is a bad hack, but at time of writing the only method I know
about.

Comment 11 Peter Bieringer 2006-08-17 09:12:34 UTC
Do you get any news from the network gurus inbetween? 

Comment 12 Bill Nottingham 2006-08-17 13:58:56 UTC
Not as of yet.

Comment 13 Peter Bieringer 2006-08-22 05:49:18 UTC
I got response to a posting on netdev list:
http://www.mail-archive.com/netdev@vger.kernel.org/msg20021.html

It's an implementation decission and looks like this would be not changed. And
it looks like also that there is no flag to set a primary adddress.

What now? Implement my workaround in initscripts?

Comment 14 Bill Nottingham 2006-08-22 15:37:50 UTC
How about the policy table suggestion?

Comment 15 Peter Bieringer 2006-08-22 19:09:26 UTC
Do you know how it works? /etc/gai.conf is only working for destination
addresses as far as I understood, but we need a policy for the source address
(which can be of course from the same subnet, which makes selection sure more
difficult).

Comment 16 Peter Bieringer 2006-08-25 12:02:05 UTC
I still got no information how to select src address in Linux, no response to my
posting:
http://www.linux-ipv6.org/ml/usagi-users/msg03687.html

Can it be that Linux misses support at all for this issue.

BTW: my current workaround works fine on all my systems here.

We can't change it to: "if additional addresses are defined, add them first,
afterwards the primary" because if behavior of kernel changes, we run into the
same trouble like now.

Comment 17 Peter Bieringer 2007-08-05 17:59:37 UTC
See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250921, looks like
a  control for selecting the default address is missing at all.

We have now 2 cases:
- want to use autogenerated one, even if manual ones added
   => work also described in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250921#c3, before adding
any IPv6 address we have to save the autogenerated one and depending on a config
option, remove it an readd it after processing IPV6ADDR_SECONDARIES and IPV6ADDR.

- want to use the main manual added one (IPV6ADDR)
   => fix is available for initscripts

Comment 18 Bill Nottingham 2007-08-06 21:48:18 UTC
This is all just horribly, horribly, wrong. Moreover, the upstream state of this
seems to be crap:

1) there's no good way to set policy in the kernel
2) the 'policy' that's there could conceivably change randomly
3) when asked, all the information I see says that they're looking on moving it
to policy based routing... with no further follow up.

Pending anything appearing as in #3, closing WONTFIX.

Comment 19 Peter Bieringer 2007-08-11 10:17:16 UTC
Created attachment 161116 [details]
Alternative simple patch for RHEL4

Because kernel version of RHEL4 does not change, this simple patch will add
IPV6ADDR after IPV6ADDR_SECONDARIES to get sure being the latest added one and
therefore the default for outgoing used one.