[PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[Juha-Matti Tapio]

Skip the prefix length matching in source address selection for
orchid -> non-orchid addresses.

Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
2001:10::/28) are currenty not globally reachable. Without this
check a host with an ORCHID address can end up preferring those over
regular addresses when talking to other regular hosts in the 2001::/16
range thus breaking non-orchid connections.

Signed-off-by: Juha-Matti Tapio <jmtapio@verkkotelakka.net>
---
 include/net/ipv6.h  |   10 ++++++++++
 net/ipv6/addrconf.c |    5 +++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index c0c019f..67e024a 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -384,6 +384,16 @@ static inline int ipv6_addr_v4mapped(const struct in6_addr *a)
 }
 
 /*
+ * Check for a RFC 4843 ORCHID address 
+ * (Overlay Routable Cryptographic Hash Identifiers)
+ */
+static inline int ipv6_addr_orchid(const struct in6_addr *a)
+{
+	return ((a->s6_addr32[0] & htonl(0xfffffff0))
+		== htonl(0x20010010));
+}
+
+/*
  * find the first different bit between two addresses
  * length of address must be a multiple of 32bits
  */
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e40213d..2474d20 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1125,6 +1125,11 @@ int ipv6_dev_get_saddr(struct net_device *daddr_dev,
 			if (hiscore.rule < 7)
 				hiscore.rule++;
 #endif
+
+			/* Skip rule 8 for orchid -> non-orchid address pairs. */
+			if (ipv6_addr_orchid(&ifa->addr) && !ipv6_addr_orchid(daddr))
+				continue;
+
 			/* Rule 8: Use longest matching prefix */
 			if (hiscore.rule < 8) {
 				hiscore.matchlen = ipv6_addr_diff(&ifa_result->addr, daddr);
-- 
1.5.3.8

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[David Miller]

From: Juha-Matti Tapio <jmtapio@verkkotelakka.net>
Date: Thu, 21 Feb 2008 12:08:42 +0200

> Skip the prefix length matching in source address selection for
> orchid -> non-orchid addresses.
> 
> Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
> 2001:10::/28) are currenty not globally reachable. Without this
> check a host with an ORCHID address can end up preferring those over
> regular addresses when talking to other regular hosts in the 2001::/16
> range thus breaking non-orchid connections.
> 
> Signed-off-by: Juha-Matti Tapio <jmtapio@verkkotelakka.net>

Also applied to net-2.6.26, thanks.

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20080221100842.GA24905@verkkotelakka.net> (at Thu, 21 Feb 2008 12:08:42 +0200), Juha-Matti Tapio <jmtapio@verkkotelakka.net> says:

> Skip the prefix length matching in source address selection for
> orchid -> non-orchid addresses.
> 
> Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
> 2001:10::/28) are currenty not globally reachable. Without this
> check a host with an ORCHID address can end up preferring those over
> regular addresses when talking to other regular hosts in the 2001::/16
> range thus breaking non-orchid connections.
> 
> Signed-off-by: Juha-Matti Tapio <jmtapio@verkkotelakka.net>

Is this really required?
I believe address labels (rule 6) should work, no?

--yoshfuji

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[Juha-Matti Tapio]

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

On Sun, Mar 02, 2008 at 09:39:02PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <20080221100842.GA24905@verkkotelakka.net> (at Thu, 21 Feb 2008 12:08:42 +0200), Juha-Matti Tapio <jmtapio@verkkotelakka.net> says:
> > Skip the prefix length matching in source address selection for
> > orchid -> non-orchid addresses.
> > 
> > Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
> > 2001:10::/28) are currenty not globally reachable. Without this
> > check a host with an ORCHID address can end up preferring those over
> > regular addresses when talking to other regular hosts in the 2001::/16
> > range thus breaking non-orchid connections.
> > 
> > Signed-off-by: Juha-Matti Tapio <jmtapio@verkkotelakka.net>
> 
> Is this really required?
> I believe address labels (rule 6) should work, no?

The corner case that I run into was like this (using HIPL):

$ ip -6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
    inet6 2002:4fab:e944:1100::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2c0:4fff:fe17:ecd9/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qlen 100
    inet6 fe80::2/64 scope link
       valid_lft forever preferred_lft forever
8: dummy0: <BROADCAST,NOARP,UP,10000> mtu 1500
    inet6 2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52/28 scope global
       valid_lft forever preferred_lft forever
[...]

$ ip -6 route
2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52 dev dummy0  metric 1024  expires 8567991sec mtu 1500 advmss 1440 hoplimit 4294967295
[...]
2002:4fab:e944:1100::/64 dev eth0  metric 256  expires 8211503sec mtu 1500 advmss 1440 hoplimit 4294967295
[...]
default via fe80::1 dev tun0  metric 512  expires 8211512sec mtu 1500 advmss 1440 hoplimit 4294967295
[...]

In this case if I try to connect to www.ripe.net alias
2001:610:240:11::c100:1319, there is no local source address that
matches the destination's label and the outgoing interface does not
have any public addresses. Therefore the 8th rule applies and the HIT
(2001:...) wins and the destination can not understand the source
address.

I'm not particularly happy with the above mentioned second patch, but
I could not come up with a more elegant fix.


-- 
Tmi Juha-Matti Tapio    Puh/Tel. +358-50-5419230
Y-tunnus 1911527-0      Fax      +358-9-34756631

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20080302165453.GP32279@verkkotelakka.net> (at Sun, 2 Mar 2008 18:54:53 +0200), Juha-Matti Tapio <jmtapio@verkkotelakka.net> says:

> > Is this really required?
> > I believe address labels (rule 6) should work, no?
> 
> The corner case that I run into was like this (using HIPL):
> 
> $ ip -6 addr
> 1: lo: <LOOPBACK,UP,10000> mtu 16436
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
>     inet6 2002:4fab:e944:1100::1/64 scope global
>        valid_lft forever preferred_lft forever
>     inet6 fe80::2c0:4fff:fe17:ecd9/64 scope link
>        valid_lft forever preferred_lft forever
> 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qlen 100
>     inet6 fe80::2/64 scope link
>        valid_lft forever preferred_lft forever
> 8: dummy0: <BROADCAST,NOARP,UP,10000> mtu 1500
>     inet6 2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52/28 scope global
>        valid_lft forever preferred_lft forever
> [...]
> 
> $ ip -6 route
> 2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52 dev dummy0  metric 1024  expires 8567991sec mtu 1500 advmss 1440 hoplimit 4294967295
> [...]
> 2002:4fab:e944:1100::/64 dev eth0  metric 256  expires 8211503sec mtu 1500 advmss 1440 hoplimit 4294967295
> [...]
> default via fe80::1 dev tun0  metric 512  expires 8211512sec mtu 1500 advmss 1440 hoplimit 4294967295
> [...]
> 
> In this case if I try to connect to www.ripe.net alias
> 2001:610:240:11::c100:1319, there is no local source address that
> matches the destination's label and the outgoing interface does not
> have any public addresses. Therefore the 8th rule applies and the HIT
> (2001:...) wins and the destination can not understand the source
> address.
> 
> I'm not particularly happy with the above mentioned second patch, but
> I could not come up with a more elegant fix.

And then, what address should you use? 6to4 address?

Then, what you should do is to appropriately configure your policy
(label) table via the addrlabel subsystem.

Or, if ORCHID address can never communicate with non-ORCHID
address, we could have it in the rule 0 (not 8 minus).

What do you think?

--yoshfuji

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[Juha-Matti Tapio]

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

On Mon, Mar 03, 2008 at 03:02:39AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <20080302165453.GP32279@verkkotelakka.net> (at Sun, 2 Mar 2008 18:54:53 +0200), Juha-Matti Tapio <jmtapio@verkkotelakka.net> says:
> > $ ip -6 route
> > 2001:1c:ed0f:6dda:e9c3:8921:2ee7:7a52 dev dummy0  metric 1024  expires 8567991sec mtu 1500 advmss 1440 hoplimit 4294967295
> > [...]
> > 2002:4fab:e944:1100::/64 dev eth0  metric 256  expires 8211503sec mtu 1500 advmss 1440 hoplimit 4294967295
> > [...]
> > default via fe80::1 dev tun0  metric 512  expires 8211512sec mtu 1500 advmss 1440 hoplimit 4294967295
> > [...]
> > 
> > In this case if I try to connect to www.ripe.net alias
> > 2001:610:240:11::c100:1319, there is no local source address that
> > matches the destination's label and the outgoing interface does not
> > have any public addresses. Therefore the 8th rule applies and the HIT
> > (2001:...) wins and the destination can not understand the source
> > address.
> > I'm not particularly happy with the above mentioned second patch, but
> > I could not come up with a more elegant fix.
> And then, what address should you use? 6to4 address?

Yes, 6to4 is in this scenario the only address that is globally
reachable from normal systems.

> Then, what you should do is to appropriately configure your policy
> (label) table via the addrlabel subsystem.

That would propably mean doing something like merging labels 1 (::/0),
2 (6to4) and 6 (Teredo) together? I suppose that could be possible,
since after all there is also the workaround of just getting separate
6to4 addresses for all the necessary interfaces. Those solutions feel
a bit awkward and I think they would need to be documented somewhere,
or alternatively the default table should be automatically adjusted
for the problematic scenarios (I fear that it would be messy).

> Or, if ORCHID address can never communicate with non-ORCHID
> address, we could have it in the rule 0 (not 8 minus).

I can think of ORCHID->ORCHID and non-ORCHID->ORCHID communications
but ORCHID->non-ORCHID does not feel useful, at least not with source
address selection. The RFC does not forbid it but at least with HIP it
does not make sense in my opinion. If the destination has ORCHID
capability, it can be identified by an ORCHID address instead of a
regular address, or the connection could be upgraded with something
like opportunistic HIP. If the destination does not have ORCHID
support, the connection pretty much fails. 

Moving the check to rule 0 would be ok by me. I personally prefer this
option. Configuring the labels manually requires quite a lot of
knowledge about addresses from the admin.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHIDaddresses

[Remi Denis-Courmont]

On Sun, 2 Mar 2008 23:59:54 +0200, Juha-Matti Tapio
<jmtapio@verkkotelakka.net> wrote:
>> Then, what you should do is to appropriately configure your policy
>> (label) table via the addrlabel subsystem.
> 
> That would propably mean doing something like merging labels 1 (::/0),
> 2 (6to4) and 6 (Teredo) together? I suppose that could be possible,
> since after all there is also the workaround of just getting separate
> 6to4 addresses for all the necessary interfaces.

Please do NOT do this.

6to4 and Teredo have separate labels for a reason: 6to4-to-6to4 is
reliable, and Teredo-to-Teredo is fairly OK. 6to4-to-native often fails,
and Teredo-to-native very often fails due to missing, congested or even
mis-configured relays between the native IPv6 bone, and these two
transition mechanism.

These labels are there to try to force native-native, 6to4-6to4, IPv4-IPv4,
Teredo-Teredo (in that priority order) before trying mismatching pairs
(native/6to4, native/Teredo, 6to4/Teredo). The Linux kernel currently has
this settings basically _right_. Unfortunately, glibc has the settings
_wrong_ (IMHO): while it has the same labels has the kernel, the way glibc
does private IPv4 addresses scoping breaks at Rule 2, which bypasses the
IPv6 transition mechanism labels at Rule 5. And will also break the ORCHID
label when it is added :( That's a different story, but you may want to
make that is not where you problems are coming from.

> Moving the check to rule 0 would be ok by me. I personally prefer this
> option. Configuring the labels manually requires quite a lot of
> knowledge about addresses from the admin.

And worst, glibc does not sync its label table with the kernel, so you have
do replicate the settings.

-- 
Rémi Denis-Courmont
http://www.remlab.net

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHIDaddresses

[Juha-Matti Tapio]

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

On Mon, Mar 03, 2008 at 11:19:40AM +0100, Remi Denis-Courmont wrote:
> On Sun, 2 Mar 2008 23:59:54 +0200, Juha-Matti Tapio
> <jmtapio@verkkotelakka.net> wrote:
> >> Then, what you should do is to appropriately configure your policy
> >> (label) table via the addrlabel subsystem.
> > That would propably mean doing something like merging labels 1 (::/0),
> > 2 (6to4) and 6 (Teredo) together? I suppose that could be possible,
> > since after all there is also the workaround of just getting separate
> > 6to4 addresses for all the necessary interfaces.
> Please do NOT do this.
> 
> 6to4 and Teredo have separate labels for a reason: 6to4-to-6to4 is
> reliable, and Teredo-to-Teredo is fairly OK. 6to4-to-native often fails,
> and Teredo-to-native very often fails due to missing, congested or even
> mis-configured relays between the native IPv6 bone, and these two
> transition mechanism.

I meant merging them locally on the system where there are ORCHID and
6to4/Teredo addresses but not native global addresses. Merging the
generic default labels together would clearly break a lot of stuff.

Then again, I feel putting this configuration burden for the local
sysadmin is a bit too much as this is a complex matter.

> Unfortunately, glibc has the settings
> _wrong_ (IMHO): while it has the same labels has the kernel, the way glibc
> does private IPv4 addresses scoping breaks at Rule 2, which bypasses the
> IPv6 transition mechanism labels at Rule 5. And will also break the ORCHID
> label when it is added :( That's a different story, but you may want to
> make that is not where you problems are coming from.

I had not thought originally about glibc-issues, and I should look
into it a bit. But the kernel update alone was enough to fix my test
system. Besides, the bug I encountered is with source address
selection.

I'm not sure there even is a problem with destination address
selection and ORCHID. It propably is not a good idea to mix
native and ORCHID addresses in DNS for the same name because this
would break hosts without any ORCHID support.



-- 
Tmi Juha-Matti Tapio    Puh/Tel. +358-50-5419230
Y-tunnus 1911527-0

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

[Rémi Denis-Courmont]

	Moi,

Le Thursday 21 February 2008 12:08:42 Juha-Matti Tapio, vous avez écrit :
> Skip the prefix length matching in source address selection for
> orchid -> non-orchid addresses.
>
> Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
> 2001:10::/28) are currenty not globally reachable. Without this
> check a host with an ORCHID address can end up preferring those over
> regular addresses when talking to other regular hosts in the 2001::/16
> range thus breaking non-orchid connections.

This is not really a "kernel" issue, but did you consider fixing glibc as 
well, as it needs to replicate source address selection as well in 
getaddrinfo()? There you will not only have problems with Rule 8, but 
possibly also with Rule 2 as you will have to take IPv4 addresses into 
account: e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468801

-- 
Rémi Denis-Courmont
http://www.remlab.net/