|
TRT
|
 Geschrieben von Beat Rubischon (Link) am
Donnerstag, 19. Februar 2009, 09:57
aus dem *einen-hab-ich-noch* dept.
Nebst NAT-PT gibt es noch einen zweiten Ansatz, den bestehenden IPv4 Addressraum in IPv6 zu mappen. Vom Konzept her durchdachter, jedoch einmal mehr genauso buggy implementiert.
TRT, siehe RFC3142 macht für den Benutzer absolut dasselbe. Der Gateway setzt jedoch nicht das Protokoll um, sondern nimmt die Verbindung über IPv6 entgegen und baut eine neue über IPv4 auf. Damit ist sichergestellt, dass bei einem allfälligen Crash des Gateways zwei "saubere" Verbindungen da sind, die abgebaut werden können. Bei NAT-PT hängen sie in der Luft.
Zwei Implementationen sind vorhanden. Unter *BSD gibt es den faithd, welcher mit dem faith Treiber zusammenarbeitet. Er unterstützt ausschliesslich TCP und bedingt gewisse Restriktionen, was offene Ports auf dem Gateway betreffen.
Die andere ist pTRTd, primär für Linux. Auf der IPv6 Seite setzt er ein TUN/TAP Interface auf und implementiert einen kleinen TCP/IP Stack in Userspace. Die Verbindungen auf der IPv4 Seite werden normal erstellt. pTRTd gatet TCP und UDP, ICMPv6 wird direkt von ihm beantwortet. ping ist also ein schlechter Test.
Die Standardkonfig ist nicht übel, ich benutze ein paar Parameter:
# ptrtd -i tun:trt -p fec0:0:0:ff00::
Daraufhin sind TCP wie UDP Verbindungen über den Gateway möglich. So zum Beispiel Google:
$ lynx "http://[fec0::ff00:0:0:d155:8163]/"
Die Webseite meint: pTRTd is still under development. Der Tarball ist jedoch vom April 2002. Das Projekt ist von daher wohl "fertig", auch wenn ich jetzt keinen pTRTd draussen laufen lassen möchte. Der Einsatz der mittlerweile als depricated eingestuften Site local Adressen ist daher durchaus gerechtfertigt.
Permalink
|
Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer
immer sie eingeschickt hat. Wir sind in keiner Weise für sie
verantwortlich.
|