|
6to4 und MTU
|
 Geschrieben von Beat Rubischon (Link) am
Montag, 20. Oktober 2008, 14:16
aus dem *DF-Flag* dept.
6to4 ist ein einfacher und netter Weg, in einem reinen IPv4 Netz einen IPv6 Zugang zu bekommen. Leider ist auch dieser Weg nicht immer ganz problemlos.
Vor vielleicht ein, zwei Monaten beschnitt mein ISP seinen ADSL Terminator auf eine 1492er MTU und machte damit den Vorteil meines PPPoAs zunichte. Mit einem Schlag kam ich in die Hölle der MTU Probleme.
Eines dieser Probleme war die Verbindung zu einem Server, welcher über 6to4 angebunden ist. Linux setzt einem sit Interface automatisch eine 1480er MTU (+20 Bytes IPv4 Header == 1500 Bytes MTU) und setzt das DF Flag bei den ausgehenden Paketen. Das, obwohl RFC3056 explizit davon abrät:
4. Maximum Transmission Unit
MTU size considerations are as described for tunnels in [MECH].
If the IPv6 MTU size proves to be too large for some intermediate
IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this
is not necessarily disastrous, unless the fragments are delivered to
different IPv4 destinations due to some form of IPv4 anycast. The
IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating
IPv4 header.
So lange der 6to4 Gateway auf einem Router läuft, klappt alles Prima: Der (Linux-)router bekommt die Packet too big Nachricht über IPv4 und signalisiert sie abzüglich des Tunnel Headers über IPv6 zurück an den Absender. Wurde die Verbindung aber direkt auf dem Gateway initiiert, kann der sit Treiber die ICMP Message niemandem schicken und sie versandet schlicht im Nirvana - die Verbindung hängt.
Leider erlaubt sit nicht, dieses Verhalten anzupassen - es ist in linux/net/ipv6/sit.c nicht vorgesehen.
Wie machen denn das andere Systeme?
Cisco setzt das DF Bit nicht, entsprechend kann ein Router auf dem Weg das Paket fragmentieren. FreeBSD oder MacOS X setzen die Minimal MTU für IPv6 von 1280 Bytes, damit sollten keine Probleme auftauchen.
Ich habe nun auch diesen Weg gewählt und gleich einer Anleitung im Netz den Debianischen Weg mit /etc/network/interfaces gewählt:
auto 6to4
iface 6to4 inet6 v4tunnel
address 2002:c3f2:8cab::1
netmask 16
endpoint any local 195.242.140.171
up ip link set 6to4 mtu 1280
up ip -6 route add default via ::192.88.99.1 dev 6to4 metric 1
down ip -6 route flush dev 6to4
ttl 64
Schön ist die Sache nicht, ich denke darüber nach, die Aufgabe des Servers und des Tunnelrouters zu trennen. Bis ich so weit bin, sollte die reduzierte MTU mein Leben wenigstens erträglich halten.
Permalink
|
|
|