|
Source IP Subnet versus tunnel in recent Linux 2.6
![[gb]](/s/countries/gb.gif) Shadow Hawkins on Saturday, 19 April 2008 15:19:14
Hi,
I am trying to set up a system using Linux 2.6.18 with a sixxs tunnel, and subnet. I am trying to make the source IP of traffic leaving the machine be an IP in the subnet rather than the tunnel IP, https://noc.sixxs.net/forum/?msg=setup-432367 suggests that this can be done via ip -6 addr add and then a /128 within your subnet, however it seems the method Linux uses to select source IPs has changed so that it now uses closest common prefix rather than last added, reading changelogs I suspect this behaviour changed in 2.6.16, has anyone managed to make this work consistently with a recent Linux 2.6 kernel?
Thanks
David
Source IP Subnet versus tunnel in recent Linux 2.6
![[de]](/s/countries/de.gif) Shadow Hawkins on Saturday, 26 April 2008 05:54:03
I'm running kernel 2.6.18 from Debian which I compiled myself (the debian way) and it works just fine. The command I'm using is:
ip addr add YOUR-IPv6-ADDR-FROM-SUBNET dev sixxs
Jochen
Source IP Subnet versus tunnel in recent Linux 2.6
Shadow Hawkins on Monday, 28 April 2008 15:51:35
I find that only works when my tunnel endpoint address doesn't match the destination address more closely than my address assigned from my subnet.
To give a practical example:
Host 'stanley' has Goscomb as its endpoint. The sixxs interface has two IP addresses, one the tunnel endpoint, the other one assigned from the subnet (using 'ip -6 addr add 2a01:348:163::1/128 dev sixxs'):
% ip addr show sixxs
15: sixxs@NONE: <POINTOPOINT,NOARP,UP,10000> mtu 1280 qdisc noqueue
link/sit 0.0.0.0 peer 77.75.104.126
inet6 2a01:348:163::1/128 scope global
valid_lft forever preferred_lft forever
inet6 2a01:348:6:ce::2/64 scope global
valid_lft forever preferred_lft forever
(link-local addresses omitted for clarity)
Now, let's look at two different hosts: beeblebrox.ipv6.michaelhowe.org (2a01:348:15c::1, also on a subnet from a sixxs tunnel) and hedgehog.spiny.org.uk (2a01:348:0:6:4d4b:697b:0:1, colocated by Goscomb).
Note that stanley's subnet source address is closest to beeblebrox's (2a01:348:1 match, rather than 2a01:348). Both stanley's tunnel and subnet address match the 2a01:348 section of hedgehog's address, but :0006:00ce appears to be closer to :0000:0006 than :0163:000 is. So, packets to beeblebrox should originate from the subnet IP, but to hedgehog should be from the tunnel IP.
Traceroute confirms this (note the sources):
% traceroute6 hedgehog.spiny.org.uk
traceroute to hedgehog.spiny.org.uk (2a01:348:0:6:4d4b:697b:0:1) from 2a01:348:6:ce::2, 30 hops max, 16 byte packets
1 gw-207.lon-02.gb.sixxs.net (2a01:348:6:ce::1) 7.35 ms 7.572 ms 8.541 ms
% traceroute6 beeblebrox.ipv6.michaelhowe.org
traceroute to beeblebrox.ipv6.michaelhowe.org (2a01:348:15c::1) from 2a01:348:163::1, 30 hops max, 16 byte packets
1 gw-207.lon-02.gb.sixxs.net (2a01:348:6:ce::1) 7.692 ms 7.625 ms 7.63 ms
So, the real question is, is there a nice way to force the packets to hedgehog, whose IP matches more of the tunnel address than the subnet address, come from the subnet address?
Source IP Subnet versus tunnel in recent Linux 2.6
Shadow Hawkins on Monday, 28 April 2008 15:54:57
Oh, and both stanley and beeblebrox (and I believe hedgehog) are running Debian, with beeblebrox on 2.6.22, and stanley (and I believe hedgehog) on 2.6.18. The same issue (difficulty in forcing the source IP address) is also visible from beeblebrox.
Source IP Subnet versus tunnel in recent Linux 2.6
![[us]](/s/countries/us.gif) Shadow Hawkins on Wednesday, 30 April 2008 19:31:31
This issue isn't trivial to resolve without considering specific systems and applications.
The issue certainly isn't new to IPv6. However, it's much aggravated in IPv6 since IPv6 interfaces almost always have multiple addresses.
In IPv6 we have an address selection policy scheme, cf. RFC-3484, that has been or is being implemented in most kernels.
At the user level, MS Windows, FreeBSD, Solaris, and others close to BSD, have utilities to control the policies (ip6addrctl in BSD, ipaddrsel in Solaris, IPV6.exe/netsh... in Windows). Linux distros don't seem to have a standard utility yet. Under Windows and FreeBSD the command line utilities seemed to work in my limited experiments.
In IPv4 voip applications in Linux, I used to query the netlink routing socket for a appropriate source address for establishing a connection. I am not far enough along with IPv6 yet about how to do this best. It seems to me the mechanism to update or query source/destination address selection policy would be a good fit for the netlink IPC as well. The policies have certainly been in the Linux kernel module for a long time (probably from the USAGI project) but there are still updates applied regularly.
From a practical point of view for existing off-the-shelf applications, the mentioned longest common prefix criterion is certainly a common observation, but last-added-address can also occur frequently (seen even in the latest Linux kernels, so no change there). Problems with these approaches have been cited and this still seems to be work in progress in general discussions, cf. draft-fujikawa-ipv6-src-addr-selection-03.txt, for example.
So, the answer is, I think, that it really depends on the circumstances and the mechanisms used in your applications to make address selections.
Source IP Subnet versus tunnel in recent Linux 2.6
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Thursday, 01 May 2008 10:48:15
I've been toying around with ip6addrctl today, but I can't seem to get it working. On my systems where I don't need to use AICCU, I often do this:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet youraddr --> sixxs
inet6 theaddressinyoursubnetyouwant --> sixxstunneladdr prefixlen 128
inet6 yourtunneladdr prefixlen 128
This seems to work quite good.
Source IP Subnet versus tunnel in recent Linux 2.6
Shadow Hawkins on Thursday, 01 May 2008 11:28:29
I've created a patch for aiccu (only for FreeBSD!) which allows you to specify the local address in aiccu.conf.
Because I don't trust the whitespace handling for this forum, I've b64encoded it.
begin-base64 644 aiccu-localaddr.patch
LS0tIGNvbW1vbi9haWNjdS5jCisrKyBjb21tb24vYWljY3UuYwpAQCAtMjMsNiArMjMsNyBAQAog
CXsicHJvdG9jb2wiLAkJUExSVF9TVFJJTkcsCW9mZnNldG9mKHN0cnVjdCBBSUNDVV9jb25mLCBw
cm90b2NvbCl9LAogCXsic2VydmVyIiwJCVBMUlRfU1RSSU5HLAlvZmZzZXRvZihzdHJ1Y3QgQUlD
Q1VfY29uZiwgc2VydmVyKX0sCiAJeyJpcHY2X2ludGVyZmFjZSIsCVBMUlRfU1RSSU5HLAlvZmZz
ZXRvZihzdHJ1Y3QgQUlDQ1VfY29uZiwgaXB2Nl9pbnRlcmZhY2UpfSwKKwl7ImlwdjZfbG9jYWxh
ZGRyIiwJUExSVF9TVFJJTkcsCW9mZnNldG9mKHN0cnVjdCBBSUNDVV9jb25mLCBpcHY2X2xvY2Fs
YWRkcil9LAogCXsidHVubmVsX2lkIiwJCVBMUlRfU1RSSU5HLAlvZmZzZXRvZihzdHJ1Y3QgQUlD
Q1VfY29uZiwgdHVubmVsX2lkKX0sCiAJeyJsb2NhbF9pcHY0X292ZXJyaWRlIiwJUExSVF9TVFJJ
TkcsCW9mZnNldG9mKHN0cnVjdCBBSUNDVV9jb25mLCBsb2NhbF9pcHY0X292ZXJyaWRlKX0sCiAK
LS0tIGNvbW1vbi9haWNjdS5oCisrKyBjb21tb24vYWljY3UuaApAQCAtOTgsNiArOTgsNyBAQAog
CWNoYXIJCSpwcm90b2NvbDsJCS8qIFRJQy9UU1AvTDJUUCAqLwogCWNoYXIJCSpzZXJ2ZXI7CQkv
KiBUSUMvVFNQIGV0YyBzZXJ2ZXIgKi8KIAljaGFyCQkqaXB2Nl9pbnRlcmZhY2U7CS8qIElQdjYg
aW50ZXJmYWNlICh0dW5uZWwgaW50ZXJmYWNlOiBzaXQwLCB0dW4wIGV0YykgKi8KKwljaGFyCQkq
aXB2Nl9sb2NhbGFkZHI7CS8qIE92ZXJyaWRlIGxvY2FsIElQdjYgYWRkcmVzcyAqLwogCWNoYXIJ
CSp0dW5uZWxfaWQ7CQkvKiBJRCBvZiB0aGUgdHVubmVsIHRvIHVzZSAqLwogCWNoYXIJCSpsb2Nh
bF9pcHY0X292ZXJyaWRlOwkvKiBMb2NhbCBJUHY0IG92ZXJyaWRlLCBmb3IgYmVoaW5kLU5BVCBz
Y2VuYXJpbydzICovCiAJY2hhcgkJKnNldHVwc2NyaXB0OwkJLyogU2NyaXB0IHRvIHJ1biBhZnRl
ciBoYXZpbmcgc2V0IHVwIHRoZSB0dW5uZWwgKi8KLS0tIGNvbW1vbi9haWNjdV9rYW1lLmMKKysr
IGNvbW1vbi9haWNjdV9rYW1lLmMKQEAgLTUxLDExICs1MSwyMyBAQAogCX0KIAogCS8qIFB0UCBs
aW5rLCBzbyB3ZSBjYW4gdXNlIHRoZSBQdFAgc3ludGF4ICovCi0JYWljY3VfZXhlYygKLQkJImlm
Y29uZmlnICVzIGluZXQ2ICVzICVzIHByZWZpeGxlbiAxMjggYWxpYXMiLAotCQlnX2FpY2N1LT5p
cHY2X2ludGVyZmFjZSwKLQkJaFR1bm5lbC0+c0lQdjZfTG9jYWwsCi0JCWhUdW5uZWwtPnNJUHY2
X1BPUCk7CisJaWYgKGdfYWljY3UtPmlwdjZfbG9jYWxhZGRyKSB7CisJCWFpY2N1X2V4ZWMoCisJ
CQkiaWZjb25maWcgJXMgaW5ldDYgJXMgJXMgcHJlZml4bGVuIDEyOCBhbGlhcyIsCisJCQlnX2Fp
Y2N1LT5pcHY2X2ludGVyZmFjZSwKKwkJCWdfYWljY3UtPmlwdjZfbG9jYWxhZGRyLAorCQkJaFR1
bm5lbC0+c0lQdjZfUE9QKTsKKwkJYWljY3VfZXhlYygKKwkJCSJpZmNvbmZpZyAlcyBpbmV0NiAl
cyBwcmVmaXhsZW4gMTI4IGFsaWFzIiwKKwkJCWdfYWljY3UtPmlwdjZfaW50ZXJmYWNlLAorCQkJ
aFR1bm5lbC0+c0lQdjZfTG9jYWwpOworCX0gZWxzZSB7CisJCWFpY2N1X2V4ZWMoCisJCQkiaWZj
b25maWcgJXMgaW5ldDYgJXMgJXMgcHJlZml4bGVuIDEyOCBhbGlhcyIsCisJCQlnX2FpY2N1LT5p
cHY2X2ludGVyZmFjZSwKKwkJCWhUdW5uZWwtPnNJUHY2X0xvY2FsLAorCQkJaFR1bm5lbC0+c0lQ
djZfUE9QKTsKKwl9CiAKIAlpZiAoZ19haWNjdS0+ZGVmYXVsdHJvdXRlKQogCXsK
====
|
Posting is only allowed when you are