Bug in order of multiple IPv6 addresses per interface? Newest added one is preferred in difference to IPv4

Bug in order of multiple IPv6 addresses per interface? Newest added one is preferred in difference to IPv4

[Peter Bieringer]

Hi,

if I add an additional IPv4 address of the same subnet ("IP aliasing",
used for virtual hosting), it's added after the first one and also get
the flag "secondary":

# ip -4 addr show dev eth0 | grep -w inet
    inet 192.0.2.11/24 brd 192.0.2.255 scope global eth0

# ip -4 addr add 192.0.2.253/24 dev eth0

# ip -4 addr show dev eth0 | grep -w inet
    inet 192.0.2.11/24 brd 192.0.2.255 scope global eth0  <-  #1
    inet 192.0.2.253/24 scope global secondary eth0       <-  #2

The new added address is also *not* used for outgoing connections by
default.


In IPv6, the behavior is completly different:

# ip -6 addr show dev eth0  |grep -w inet6 |grep -w global
    inet6 2001:db8:0:1::11/64 scope global

# ip -6 addr add 2001:db8:0:1::253/64 dev eth0

# ip -6 addr show dev eth0  |grep -w inet6 |grep -w global
    inet6 2001:db8:0:1::253/64 scope global   <- #2 !!!!
    inet6 2001:db8:0:1::11/64 scope global    <- #1

So the last added on is now the first in list. Also, it gets no
"secondary" flag and "ip" doesn't even support this flag.

And the worse thing is that the first one in list (= last added one) is
now used as default for outgoing connections. Can be easily tested using
"ping6".


Is this a bug (I hope so) or a (undocumented?) feature?

How can I add additional IPv6 addresses from the same subnet to an
interface without changing implicit the default outgoing address.

Current workaround: adding new address, remove and readd primary IPv6
address (which is afterwards the first one in list again).


BTW: this can break at least initscripts, which support more than one
address per interface (a primary and some secondary ones), see also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199862 (a
workaround is described here)

Used versions:

kernel-2.6.17-1.2174_FC5 (happen also below, e.g. 2.6.9 from RHEL4)
iproute-2.6.15-1.2

Regards,
	Peter
-- 
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                       mailto:pb@bieringer.de
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/

Bug in order of multiple IPv6 addresses per interface? Newest added one is preferred in difference to IPv4

[Mark Smith]

Hi,

Sorry not to preserve the list/thread ID, I read the list via nntp/gmane, so please also CC' me directly for replies.

># ip -6 addr show dev eth0  |grep -w inet6 |grep -w global
    inet6 2001:db8:0:1::253/64 scope global   <- #2 !!!!
    inet6 2001:db8:0:1::11/64 scope global    <- #1

>So the last added on is now the first in list. Also, it gets no
>"secondary" flag and "ip" doesn't even support this flag.

>And the worse thing is that the first one in list (= last added one) is
>now used as default for outgoing connections. Can be easily tested using
>"ping6".


>Is this a bug (I hope so) or a (undocumented?) feature?

Could it be because the new address as a newer and therefore longer
preferred and valid lifetimes, and therefore becomes a more preferred
IPv6 source address to use for new connections ? 

Regards,
Mark.

Re: Bug in order of multiple IPv6 addresses per interface? Newest added one is preferred in difference to IPv4

[Peter Bieringer]

Mark Smith schrieb:
> Hi,
> 
> Sorry not to preserve the list/thread ID, I read the list via nntp/gmane, so please also CC' me directly for replies.
> 
>> # ip -6 addr show dev eth0  |grep -w inet6 |grep -w global
>     inet6 2001:db8:0:1::253/64 scope global   <- #2 !!!!
>     inet6 2001:db8:0:1::11/64 scope global    <- #1
> 
>> So the last added on is now the first in list. Also, it gets no
>> "secondary" flag and "ip" doesn't even support this flag.
> 
>> And the worse thing is that the first one in list (= last added one) is
>> now used as default for outgoing connections. Can be easily tested using
>> "ping6".
> 
> 
>> Is this a bug (I hope so) or a (undocumented?) feature?
> 
> Could it be because the new address as a newer and therefore longer
> preferred and valid lifetimes, and therefore becomes a more preferred
> IPv6 source address to use for new connections ? 

Hmm, both addresses have:
	valid_lft forever preferred_lft forever

	Peter
-- 
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                       mailto:pb@bieringer.de
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/
OpenBC                    http://www.openbc.com/hp/Peter_Bieringer/
Personal invitation to OpenBC  http://www.openbc.com/go/invita/3889

Re: Bug in order of multiple IPv6 addresses per interface? Newest added one is preferred in difference to IPv4

[YOSHIFUJI Hideaki / 吉藤英明]

Hello.

In article <44E94653.1040002@bieringer.de> (at Mon, 21 Aug 2006 07:36:19 +0200), Peter Bieringer <pb@bieringer.de> says:

> In IPv6, the behavior is completly different:
> 
> # ip -6 addr show dev eth0  |grep -w inet6 |grep -w global
>     inet6 2001:db8:0:1::11/64 scope global
> 
> # ip -6 addr add 2001:db8:0:1::253/64 dev eth0
> 
> # ip -6 addr show dev eth0  |grep -w inet6 |grep -w global
>     inet6 2001:db8:0:1::253/64 scope global   <- #2 !!!!
>     inet6 2001:db8:0:1::11/64 scope global    <- #1
> 
> So the last added on is now the first in list. Also, it gets no
> "secondary" flag and "ip" doesn't even support this flag.

IPv6 does not have secondary flag. We even reuse that for
IPv6 temporary addresses.

> And the worse thing is that the first one in list (= last added one) is
> now used as default for outgoing connections. Can be easily tested using
> "ping6".
:
> Is this a bug (I hope so) or a (undocumented?) feature?

An implementation decision.
I do not favor changing this so far.

--yoshfuji

Re: Bug in order of multiple IPv6 addresses per interface? Newest added one is preferred in difference to IPv4

[JINMEI Tatuya / 神明達哉]

>>>>> On Mon, 21 Aug 2006 12:47:36 +0200, 
>>>>> Peter Bieringer <pb@bieringer.de> said:

>> I do not favor changing this so far.

> Hmm, would it be possible to implement a primary flag in the future?

> BTW: Does anyone know about the behavior of *BSD for this issue?

As far as I know, BSD variants don't have the notion of *explicit*
'first/primary' or 'secondary' address.  But if your main concern is
to prefer particular addresses as the source address of outgoing
packets, you'd be able to achieve the goal by configuring appropriate
policy table entries (per RFC3484).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp