ipv6 source address selection in addrconf.c (2.6.17)

ipv6 source address selection in addrconf.c (2.6.17)

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

Greetings.

net/ipv6/addrconf.c:971 is
/* Rule 2: Prefer appropriate scope */
if (hiscore.rule < 2) {
        hiscore.scope = __ipv6_addr_src_scope(hiscore.addr_type);
        hiscore.rule++;
}

I am afraid, that it does not make any sense for I find no place where a value
is assigned to hiscore.addr_type. There are some more references to
hiscore.addr_type below but the only assignment is when the whole structure is
cleaned with memset(3)

I found it when I was trying to figure out why when trying to connect to

2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net)

with two global addresses assigned to the ethernet card

fd24:6f44:46bd:face::254
2002:531f:d667:face::254

rule 8 does not work and the first address is chosen.


Please CC answers.
-- 
Było mi bardzo miło.                    Czwarta pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[patch] ipv6 source address selection in addrconf.c (2.6.17)

[Lukasz Stelmach]

[-- Attachment #1.1: Type: text/plain, Size: 1060 bytes --]

Lukasz Stelmach wrote:

> I found it when I was trying to figure out why when trying to connect to
> 
> 2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net)
> 
> with two global addresses assigned to the ethernet card
> 
> fd24:6f44:46bd:face::254
> 2002:531f:d667:face::254
> 
> rule 8 does not work and the first address is chosen.

The answer is that fc00::/7 matches 2001:: better because it gets the same
label (ipv6_saddr_label()). Although fc00::/7 addresses are defined as global
unicast IMHO they should be treated *slightly* different. This is the patch.
Since 6to4 has its own label I have decided to assign one to Teredo too.

However, I still haven't found any clue in referneces to unassigned value of
hiscore.addr_type.

-- 
Było mi bardzo miło.                    Czwarta pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


----------------------------------------------------------------------
Zobacz nowosci salonu moto w Madrycie >>> http://link.interia.pl/f1961

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: addrconf.diff --]
[-- Type: text/x-patch; name="addrconf.diff", Size: 575 bytes --]

--- /usr/src/linux/net/ipv6/addrconf.c~	2006-06-21 11:41:22.000000000 +0200
+++ /usr/src/linux/net/ipv6/addrconf.c	2006-06-21 15:33:26.000000000 +0200
@@ -862,6 +862,8 @@
   * 	2002::/16		2
   * 	::/96			3
   * 	::ffff:0:0/96		4
+  *	fc00::/7		5
+  * 	2001::/32		6
   */
 	if (type & IPV6_ADDR_LOOPBACK)
 		return 0;
@@ -871,6 +873,10 @@
 		return 4;
 	else if (addr->s6_addr16[0] == htons(0x2002))
 		return 2;
+	else if ((addr->s6_addr[0] & 0xfe) == 0xfc)
+		return 5;
+	else if (addr->s6_addr32[0] == htonl(0x20010000))
+		return 6;
 	return 1;
 }
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: ipv6 source address selection in addrconf.c (2.6.17)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <44986AE6.6090102@poczta.fm> (at Tue, 20 Jun 2006 23:38:46 +0200), Lukasz Stelmach <stlman@poczta.fm> says:

> Greetings.
> 
> net/ipv6/addrconf.c:971 is
> /* Rule 2: Prefer appropriate scope */
> if (hiscore.rule < 2) {
>         hiscore.scope = __ipv6_addr_src_scope(hiscore.addr_type);
>         hiscore.rule++;
> }
> 
> I am afraid, that it does not make any sense for I find no place where a value
> is assigned to hiscore.addr_type. There are some more references to
> hiscore.addr_type below but the only assignment is when the whole structure is
> cleaned with memset(3)

hiscore is copied from score.

--yoshfuji

Re: [patch] ipv6 source address selection in addrconf.c (2.6.17)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <44994CB3.6070302@poczta.fm> (at Wed, 21 Jun 2006 15:42:11 +0200), Lukasz Stelmach <stlman@poczta.fm> says:

> --- /usr/src/linux/net/ipv6/addrconf.c~	2006-06-21 11:41:22.000000000 +0200
> +++ /usr/src/linux/net/ipv6/addrconf.c	2006-06-21 15:33:26.000000000 +0200
> @@ -862,6 +862,8 @@
>    * 	2002::/16		2
>    * 	::/96			3
>    * 	::ffff:0:0/96		4
> +  *	fc00::/7		5
> +  * 	2001::/32		6
>    */
>  	if (type & IPV6_ADDR_LOOPBACK)
>  		return 0;
> @@ -871,6 +873,10 @@
>  		return 4;
>  	else if (addr->s6_addr16[0] == htons(0x2002))
>  		return 2;
> +	else if ((addr->s6_addr[0] & 0xfe) == 0xfc)
> +		return 5;
> +	else if (addr->s6_addr32[0] == htonl(0x20010000))
> +		return 6;
>  	return 1;
>  }
>  

Please put the comparison for 2001::/32 before 2002::/16.
Otherwise, I'm fine with it.

In addition, give us your sign-off, please.

Regards,

-- 
YOSHIFUJI Hideaki @ USAGI Project  <yoshfuji@linux-ipv6.org>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [patch] ipv6 source address selection in addrconf.c (2.6.17)

[Lukasz Stelmach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


- --- linux/net/ipv6/addrconf.c.orig	2006-06-21 11:41:22.000000000 +0200
+++ linux/net/ipv6/addrconf.c	2006-06-21 17:18:56.000000000 +0200
@@ -862,6 +862,8 @@ static int inline ipv6_saddr_label(const
   * 	2002::/16		2
   * 	::/96			3
   * 	::ffff:0:0/96		4
+  *	fc00::/7		5
+  * 	2001::/32		6
   */
 	if (type & IPV6_ADDR_LOOPBACK)
 		return 0;
@@ -869,8 +871,12 @@ static int inline ipv6_saddr_label(const
 		return 3;
 	else if (type & IPV6_ADDR_MAPPED)
 		return 4;
+	else if (addr->s6_addr32[0] == htonl(0x20010000))
+		return 6;
 	else if (addr->s6_addr16[0] == htons(0x2002))
 		return 2;
+	else if ((addr->s6_addr[0] & 0xfe) == 0xfc)
+		return 5;
 	return 1;
 }

Two additional labels (RFC 3484, sec. 10.3) for IPv6 addreses
are defined to make a distinction between global unicast
addresses and Unique Local Addresses (fc00::/7, RFC 4193) and
Teredo (2001::/32, RFC 4380). It is necessary to avoid attempts
of connection that would either fail (eg. fec0:: to 2001:feed::)
or be sub-optimal (2001:0:: to 2001:feed::).

	Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD4DBQFEmW0LNdzY8sm9K9wRAjVGAKCOS1MVIro3bJ6szHzuAzaXXNaq/gCY4jfO
timfJc6SmrygMer36Tdqzg==
=Qzch
-----END PGP SIGNATURE-----

-- 
Było mi bardzo miło.                    Czwarta pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


----------------------------------------------------------------------
Zobacz nowosci salonu moto w Madrycie >>> http://link.interia.pl/f1961

Re: ipv6 source address selection in addrconf.c (2.6.17)

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

Lukasz Stelmach wrote:
> Lukasz Stelmach wrote:
> 
>> [...] when trying to connect to
>>
>> 2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net)
>>
>> with two global addresses assigned to the ethernet card
>>
>> fd24:6f44:46bd:face::254
>> 2002:531f:d667:face::254
>>
>> rule 8 does not work and the first address is chosen.
> 
> The answer is that fc00::/7 matches 2001:: better because it gets the same
> label (ipv6_saddr_label()). Although fc00::/7 addresses are defined as global
> unicast IMHO they should be treated *slightly* different. This is the patch.
> Since 6to4 has its own label I have decided to assign one to Teredo too.

There still, however, remains one issue. Aditional labels prevent kernel from
selecting fc00::/7 prematurly. But there is no way to stop it from selecting
it in rule 7. A wrong assumption has been taken that there is only one
"private" address per interface and it is always the best choice. If there are
four addresses on the interface:

fd24:6f44:46bd:face:EUI64 fd24:6f44:46bd:face:RANDOM
and
2002:531f:d667:face:EUI64 2002:531f:d667:face::RANDOM

there seem to be no way to prefere 2002:: over fc00:: in rule 7 and it will be
selected as long as it is before 2002:: on the list. I can see here that an
implicit assumption has been made that an interface either is multihomed or
"private". The seventh rule should not IMHO break the whole process of
selection but rather mark as selectable all "private" (random) addresses. And
it should rather be done before rule 6.

Yet another issue with privacy enhancement is how not to choose "private"
address (let's even forget for a moment about fc00::/7) when connecting to
certain hosts or networks. For example I would like to hide MAC adresses of my
client machines when connecting to some foreign servers but I want to see
permanent addresses in the logfiles of my servers. Maybe even use them to
create som ACLs. This is an interesting case.


Kind regards,
-- 
Było mi bardzo miło.                    Czwarta pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: ipv6 source address selection in addrconf.c (2.6.17)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <4499CEF4.2050308@poczta.fm> (at Thu, 22 Jun 2006 00:57:56 +0200), Lukasz Stelmach <stlman@poczta.fm> says:

> Lukasz Stelmach wrote:
> > Lukasz Stelmach wrote:
> > 
> >> [...] when trying to connect to
> >>
> >> 2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net)
> >>
> >> with two global addresses assigned to the ethernet card
> >>
> >> fd24:6f44:46bd:face::254
> >> 2002:531f:d667:face::254
> >>
> >> rule 8 does not work and the first address is chosen.
> > 
> > The answer is that fc00::/7 matches 2001:: better because it gets the same
> > label (ipv6_saddr_label()). Although fc00::/7 addresses are defined as global
> > unicast IMHO they should be treated *slightly* different. This is the patch.
> > Since 6to4 has its own label I have decided to assign one to Teredo too.
> 
> There still, however, remains one issue. Aditional labels prevent kernel from
> selecting fc00::/7 prematurly. But there is no way to stop it from selecting
> it in rule 7. A wrong assumption has been taken that there is only one
> "private" address per interface and it is always the best choice. If there are
> four addresses on the interface:
> 
> fd24:6f44:46bd:face:EUI64 fd24:6f44:46bd:face:RANDOM
> and
> 2002:531f:d667:face:EUI64 2002:531f:d667:face::RANDOM
> 
> there seem to be no way to prefere 2002:: over fc00:: in rule 7 and it will be
> selected as long as it is before 2002:: on the list. I can see here that an
> implicit assumption has been made that an interface either is multihomed or
> "private". The seventh rule should not IMHO break the whole process of
> selection but rather mark as selectable all "private" (random) addresses. And
> it should rather be done before rule 6.

Hmm? We do not have such intention.
In above case, when you connect to 2001:200:0:8002:203:47ff:fea5:3085,
either 2002:531f:d667:face:EUI64 or 2002:531f:d667:face::RANDOM
should be selected (depending on if use_tempaddr >= 2),
by the longest matching rule (Rule 8).

--yoshfuji

Re: [patch] ipv6 source address selection in addrconf.c (2.6.17)

[David Miller]

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 22 Jun 2006 01:12:57 +0900 (JST)

> I think it is trivial enough to push this to -stable as well.
> 
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Ok, done.

Thanks a lot!

Re: ipv6 source address selection in addrconf.c (2.6.17)

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <4499CEF4.2050308@poczta.fm> (at Thu, 22 Jun 2006 00:57:56 +0200), Lukasz Stelmach <stlman@poczta.fm> says:
> 
>> Lukasz Stelmach wrote:
>>> Lukasz Stelmach wrote:
[....]
>>
>> fd24:6f44:46bd:face:EUI64 fd24:6f44:46bd:face:RANDOM
>> and
>> 2002:531f:d667:face:EUI64 2002:531f:d667:face::RANDOM
>>
>> there seem to be no way to prefere 2002:: over fc00:: in rule 7 and it will be
>> selected as long as it is before 2002:: on the list. I can see here that an
>> implicit assumption has been made that an interface either is multihomed or
>> "private". The seventh rule should not IMHO break the whole process of
>> selection but rather mark as selectable all "private" (random) addresses. And
>> it should rather be done before rule 6.
> 
> Hmm? We do not have such intention.
> In above case, when you connect to 2001:200:0:8002:203:47ff:fea5:3085,
> either 2002:531f:d667:face:EUI64 or 2002:531f:d667:face::RANDOM
> should be selected (depending on if use_tempaddr >= 2),
> by the longest matching rule (Rule 8).

I've chewd the code line by line and it tastes like it should work the way you
say... OK I see the problem. I've used ifconfig which doesn't show
"deprecated" flag and "valid"/"prefered" times which, combined with "privacy",
*seem* to cause some problems . I don't know yet if it is a problem of proper
intervals in radvd.conf or is there still a bug in kernel. I'll let you know
when I learn it.

OK. That's enough for now. Let me get back to the real work ;-)


Best regards.
-- 
Było mi bardzo miło.                    Czwarta pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]