Friedemann Stoyan schrieb:
Ich frage mich gerade, welchen esoterischen Algorithmus die glibc
verwendet, um die Reihenfolge IPv6/IPv4 zu bestimmen. Konkret geht es um
[...]
$ telnet news.lab.swapon.de 120
Trying 192.168.17.119...
Trying 2001:6f8:12ec:10::119...
telnet: Unable to connect to remote host: Connection refused
vs.
$ telnet news.ipv46.swapon.de 120
Trying 2001:6f8:12ec::3...
Trying 81.169.139.143...
telnet: Unable to connect to remote host: Connection refused
Ich kann mich an ähnliches Verhalten von Ubuntu Edgy erinnern, dessen
getaddrinfo() zu Hause auch dauernd meinen dualstacked Heimserver über
IPv4 erreichen wollte. Wenn ich mich recht entsinne bin ich beim
Debuggen drauf gekommen, dass die Kiste zwar im Normalfall konsequent
IPv6 vor IPv4 präferiert (wie das Normalverhalten von glibc 2.3 ist),
aber anscheinend unter bestimmten Umständen direct-connected Routen
präferenziert.
Ich habe die meisten Kisten schon auf Ubuntu Feisty oder Debian testing
aktualisiert, aber mein Heimrouter zeigt das gleiche Verhalten (aelteres
Debian testing, libc6 2.3.6.ds1-13). Zum interaktiven Testen nutze ich
ganz gerne Python.
test1.iks4.birkenwald.de has address 172.16.2.1
test1.iks4.birkenwald.de has IPv6 address 2001:a60:f00c::1
test2.iks4.birkenwald.de has address 192.168.100.1
test2.iks4.birkenwald.de has IPv6 address 2001:a60:f00c::1
test3.iks4.birkenwald.de has address 141.1.1.1
test3.iks4.birkenwald.de has IPv6 address 2001:a60:f00c::1
>>> socket.getaddrinfo('test1.iks4.birkenwald.de', 0, 0,
socket.SOCK_STREAM)
[(2, 1, 6, '', ('172.16.2.1', 0)), (10, 1, 6, '', ('2001:a60:f00c::1',
0, 0, 0))]
>>> socket.getaddrinfo('test2.iks4.birkenwald.de', 0, 0,
socket.SOCK_STREAM)
[(10, 1, 6, '', ('2001:a60:f00c::1', 0, 0, 0)), (2, 1, 6, '',
('192.168.100.1', 0))]
>>> socket.getaddrinfo('test3.iks4.birkenwald.de', 0, 0,
socket.SOCK_STREAM)
[(10, 1, 6, '', ('2001:a60:f00c::1', 0, 0, 0)), (2, 1, 6, '',
('141.1.1.1', 0))]
Die RFC1918-Adresse von test1 wird vor IPv6 präferenziert, die von test2
nach IPv6. Der einzige Unterschied ist, dass zu der IPv4-Adresse von
test1 eine more-specific Route existiert, zu der von test2 nicht
172.16.1.254 dev iks4 proto kernel scope link src 172.16.1.253
172.16.2.0/24 via 172.16.1.254 dev iks4
(VPN-Tunnel zu einer anderen Location). Und Tatsache, führe ich
ip route add 192.168.100.1/32 via 172.16.1.254 dev iks4
aus wird auch test2 präferenziert
>>> socket.getaddrinfo('test2.iks4.birkenwald.de', 0, 0,
socket.SOCK_STREAM)
[(2, 1, 6, '', ('192.168.100.1', 0)), (10, 1, 6, '',
('2001:a60:f00c::1', 0, 0, 0))]
Das ganze funktioniert aber _nicht_ für non-RFC1918-Adressen, mache ich
das gleiche mit 141.1.1.1/32 hat das keinerlei Effekt auf test3.
So ganz hab ich das Verhalten noch nicht verstanden, es ist anscheinend
unabhängig davon wie "gross" die More-specific Route ist
ip route add 192.0.0.0/8 via 172.16.1.254 dev iks4
hat also den gleichen Effekt auf test2, nicht aber
ip route add 192.0.0.0/8 dev ppp0
was der Default-Route entsprechen würde.
Bernhard
--
ipv6 mailing list
[email protected]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
