%% LyX 1.1 created this file. For more info, see http://www.lyx.org/. %% Do not edit unless you really know what you are doing. \documentclass[landscape,german]{article} \usepackage[T1]{fontenc} \usepackage[latin1]{inputenc} \usepackage{babel} \setlength\parskip{\medskipamount} \setlength\parindent{0pt} \usepackage{graphics} \IfFileExists{url.sty}{\usepackage{url}} {\newcommand{\url}{\texttt}} \makeatletter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands. \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@} \makeatother \begin{document} \vspace{30pt} {\centering {\large IPv6 Labor}\large \par} \vspace{30pt} {\centering \textbf{\Large IPv6 Gateways}\\ \textbf{\Large (TRT)}\Large \par} \vspace{30pt} {\centering {\large Stephan Uhlmann }\\ {\large 02.10.2002}\large \par} \vfill Copyright (c) 2002 Stephan Uhlmann {\footnotesize Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license can be obtained from \url{http://www.gnu.org/licenses/fdl.html}.}{\footnotesize \par} \clearpage \section{Motivation} In der Übergangsphase von IPv4 zu IPv6 wird es den Bedarf geben langsam zu migrieren. Netzwerke die schon mit IPv6 arbeiten möchten weiterhin mit Hosts kommunizieren, die noch mit IPv4 funktionieren und andersrum. Nicht alle Hosts sind Dual-Stack fähig oder sollen es sein, da z.B. IP-Adressen für beide Protokoll benötigt werden. Der beste Ansatzpunkt sind Router, denn so bieten diese Gateways eine Möglichkeit, transparent für ganze Subnetze eine Übersetzung ins jeweils andere Protokoll vorzunehmen. Es gibt verschiedene Modelle für solche Gateways. Speziell soll es hier um TRT gehen, welches sich besonders für die Anbindung von reinen IPv6 Hosts an IPv4 Netze eignet. \section{Modelle} \subsection{SOCKS64} SOCKS64 ist eine Erweiterung des schon bestehenden SOCKS Proxy Protokolls. Ein solches Gateway nimmt IPv4 Verbindungen an und leitet diese wahlweise als IPv4 oder IPv6 weiter. Vorteil ist, dass keine Modifikationen oder {}``Hacks'' am DNS gemacht werden müssen wie bei einigen der anderen Lösungen. Nachteil ist, dass die Client Applikationen SOCKS-fähig (socksified) sein müssen. SOCKS64 macht daher eher in solchen schon schon bestehenden Umgebungen Sinn. SOCKS64 ist in RFC 3089 (\url{http://www.ietf.org/rfc/rfc3089.txt}) beschrieben. \subsection{Application Layer Gateways (ALGs)} Bekannt aus heutigen Sicherheitslösungen sind sogenannte Application Layer Gateways. Dies sind Hosts auf denen für ein jeweiliges Protokoll eine Proxy-Software installiert ist. Anstatt direkt mit dem Server zu kommunizieren, werden Anfragen dieses Protokolls an den Proxy gestellt, welcher diese dann für den Client ausführt und entsprechend weiterleitet. Ist dieser Proxy-Host mit einem Dual-Stack ausgerüstet, dann können die Anfragen sowohl in IPv4 als auch in IPv6 weitergeleitet werden. Vorteil ist auch hier, dass keine besonderen Veränderungen am DNS notwendig sind. Nachteil ist, dass alle Clients umkonfiguriert werden müssen, wenn nicht schon vorher die Proxies benutzt wurden. Auch gibt es nicht für alle Protokolle entsprechende ALGs. \subsection{SIIT} Der Stateless IP/ICMP Translation Algorithm (SIIT) ist in RFC 2765 (\url{http://www.ietf.org/rfc/rfc2765.txt}) dargelegt und beschreibt eine allgemeine Methode zur Übersetzung von IPv4 und IPv6 Paketen in beide Richtungen. Durch die teilweise sehr unterschiedlichen Felder im IP-Header werden Probleme in der Übersetzung aufgeworfen, die dieser Algorithmus versucht möglichst elegant zu lösen. Informationsverlust, gerade bei der Übersetzung von IPv6 nach IPv4, kann jedoch nicht vermieden werden. SIIT ist die Grundlage für NAT-PT. \subsection{NAT-PT} (detailreicher siehe Vortrag von Andreas Liebert) NAT-PT bedeutet Network Address Translation / Protocol Translation. Es arbeitet wie die schon bekannten IPv4 NATs, fügt dem jedoch eine IPv4-IPv6 Protokollübersetzung auf Basis des SIIT hinzu. Ein Vorteil von NAT-PT ist, dass es sowohl IPv6 nach IPv4 als auch IPv4 nach IPv6 Kommunikation beherrscht. NAT-PT ist in RFC 2766 (\url{http://www.ietf.org/rfc/rfc2766.txt}) beschrieben. Eine Implementation ist {}``nat-pt'' des Electronics and Telecommunications Research Institute, Korea. \subsection{TRT} TRT ist grundsätzlich nur dafür gedacht, Kommunikation von IPv6 nach IPv4 zu unterstützen. Theoretisch wäre auch die Richtung IPv4 nach IPv6 möglich, jedoch ist dies generell sehr viel schwieriger, da DNS-Anfragen auf temporäre IPv4 Adressen abgebildet werden müssen. In der Praxis wird wohl auch viel eher die Anforderung bestehen, neue IPv6-only Hosts an das bestehende IPv4 Internet anzuschliessen. Wie auch bei NAT-PT werden IPv4 Adressen durch ein DNS ALG in IPv6 Adressen mit einem sogenannten {}``dummy Präfix'' umgewandelt. Jede Kommunikation mit Adressen dieses Präfix wird vom TRT abgefangen. Das TRT terminiert die Verbindung in Richtung Client, baut eine neue IPv4-Verbindung zum eigentlichen Ziel auf und leitet die Daten in beiden Richtungen entsprechend weiter. \vspace{0.3cm} {\centering \includegraphics{img1.eps} \par} \vspace{0.3cm} Die Umsetzung findet also auf der Transportschicht statt und nicht wie bei NAT-PT auf der Netzwerkschicht. Dies hat eine Reihe von Vorteilen. Dadurch, dass TRT nicht auf SIIT angewiesen ist, gibt es weniger Probleme bei der Path MTU discovery / Fragmentation, denn die IPv4 und IPv6 Teile können getrennt betrachtet werden. Ein TRT-System ist wesentlich einfacher zu implementieren und zu verstehen. Es werden zwar hier auch ALGs für NAT-unfreundliche Protokolle, die IP-Adressen in höheren Schichten transportieren, wie z.B.. FTP und DNS, benötigt, theoretisch könnte man diese aber auch gleich innerhalb des TRT implementieren. Modifikationen an den Hosts sind nicht notwendig. Dadurch, dass TRT {}``stateful'' ist muss die gesamte Kommunikation einer Verbindung über das gleiche TRT gehen. Dies könnte in der Praxis einen Single Point of Failure bilden. Wie beim SIIT gibt es auch hier einen Informationsverlust beim Übergang von IPv6 zu IPv4, so dass nicht alle Eigenschaften von IPv6 bei der Kommunikation zu IPv4 Hosts zur Verfügung stehen. Dies betrifft z.B. auch IPSec. Desweiteren werden nur bidirektionale Verbindungen unterstützt und keine unidirektionalen wie z.B. Multicast. TRT ist im RFC 3142 (\url{http://www.ietf.org/rfc/rfc3142.txt}) beschrieben. Implementationen sind {}``faith'' des KAME Projekts, welches jedoch nur unter BSD läuft und {}``pTRTd'' (Portable Transport Relay Translator Daemon) welches auch unter Linux läuft. \section{TRT in der Praxis} \subsection{pTRTd} pTRTd ist eine portable TRT-Implementation, da es seinen eigenen IPv6 Stack mitbringt und nicht auf Änderungen des IPv6 Stacks im Betriebssystem des Hosts angewiesen ist. In der default Einstellung benutzt es den Präfix fec0:0:0:ffff::/64, dies kann jedoch mit der Option -p geändert werden. Als externe Abhängigkeit benötigt pTRTd nur den TUN/TAP Gerätetreiber. Dieser lässt sich einfach mit den folgenden zwei Befehlen aktivieren. \texttt{\# mknod /dev/net/tun c 10 200}\\ \texttt{\# modprobe tun} Danach kann ptrtd problemlos gestartet werden. \subsection{totd} Der totd (Trick Or Treat Daemon) dient als DNS-Proxy. Er leitet alle Anfragen an ihn an einen anderen DNS-Server (Forwarder) weiter. Bevor er jedoch eine Antwort an den Client zurückgibt, wandelt er IPv4-Adressen in {}``fake'' IPv6-Adressen um. Dazu benutzt er einen konfigurierbaren Präfix, welcher natürlich der gleiche sein sollte, wie er vom TRT verwendet wird. Eine Anfrage an den auf {}``localhost'' (::1) auf Port 5005 laufenden Server sieht z.B. so aus: \texttt{\# dig @::1 -p 5005 www.google.com aaaa}~\\ \texttt{(...)}~\\ \texttt{;; ANSWER SECTION:}~\\ \texttt{www.google.com. 122 IN AAAA fec0::ffff:0:0:d8ef:2365}~\\ \texttt{(...)} \subsection{Erfahrungsbericht} Der totd funktioniert problemlos. pTRTd ist noch im Alpha-Stadium, arbeitet aber in seiner Grundfunktionalität zufriedenstellend. Ein Problem das auftauchte war, dass der default Präfix (fec0:0:0:ffff::/64) nicht funktionierte: \texttt{\# ping6 fec0::ffff:0:0:d8ef:2365}~\\ \texttt{connect: Cannot assign requested address} Der \texttt{connect()} Systemaufruf lieferte einen \texttt{EADDRNOTAVAIL} Fehler. Das Problem konnte aber durch Verwendung eines global scope Präfix behoben werden. Hier der Mitschnitt, wie ich mich per SSH auf den IPv4 Host lisa.cs.uni-potsdam.de einlogge: \texttt{\# ./totd -c totd.conf}~\\ \texttt{\# ./ptrtd -p 2001:7a0:101:888::}~\\ \texttt{\# ping6 2001:7a0:101:888::1} (zurückgepingt von ptrtd)\texttt{}~\\ \texttt{\# dig @::1 -p 5005 lisa.cs.uni-potsdam.de aaaa}~\\ \texttt{}~\\ \texttt{; ANSWER SECTION:}~\\ \texttt{lisa.cs.uni-potsdam.de. 172800 IN AAAA 2001:7a0:101:888::8d59:30de}~\\ \texttt{}~\\ \texttt{\# ssh -6 -l uhlmann 2001:7a0:101:888::8d59:30de}~\\ \texttt{uhlmann@lisa:\textasciitilde{} >} \section{Fazit} Ich kann TRT als Lösung für die Anbindung von IPv6-only Hosts an das IPv4 Internet empfehlen. Es geht das Problem auf einfache und damit leicht verständliche und implementierbare Weise an. Es hat für seinen Zweck eine gute Balance zwischen Vorteilen und Nachteilen. Die Nachteile sind in der Praxis für die Mehrheit der Anwender weniger relevant. Die Implementation pTRTd im Zusammenspiel mit totd ist lauffähig, müsste jedoch vor einem Produktiv-Einsatz weiter getestet werden. \section{Links} \begin{itemize} \item pTRTd: \url{http://www.litech.org/ptrtd/} \item totd: \url{http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html} \item Modellvergleich IPv6-IPv4-Gateways: \url{http://web.mit.edu/peilei/www/nats2.htm}\end{itemize} \end{document}