Thread (9 messages) 9 messages, 4 authors, 2008-03-03

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

From: Juha-Matti Tapio <hidden>
Date: 2008-03-02 16:54:56

On Sun, Mar 02, 2008 at 09:39:02PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
In article [ref] (at Thu, 21 Feb 2008 12:08:42 +0200), Juha-Matti Tapio [off-list ref] says:
quoted
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 <redacted>
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help