Workshop Teil 1 (PDF) - GeNUA
Workshop Teil 1 (PDF) - GeNUA
Workshop Teil 1 (PDF) - GeNUA
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
PRAXIS I <strong>Workshop</strong><br />
für die Implementierung zur Verfügung<br />
stehen würden, hatte dazu bewogen, weitere,<br />
neue Funktionalität aus den Vorschlägen<br />
mit in die Spezifikation aufzunehmen.<br />
So ist beispielsweise die Unterstützung<br />
für das Unterbringen von Optionen und<br />
Erweiterungen im Protokoll-Header im<br />
Gegensatz zu IPv4 modular aufgebaut.<br />
Ergänzungen verschiedener Typen können<br />
optional an den eigentlichen Paket-<br />
Header gehängt werden und diesen so erweitern.<br />
Für die Implementierung von<br />
Routern ist dies ein Segen. Der Haupt-<br />
Paket-Header ist immer gleich lang und<br />
die zur Weiterleitung des Pakets notwendigen<br />
Adressfelder sind immer an derselben<br />
Stelle zu finden und auf 64 Bit ausgerichtet<br />
(“64 bit aligned”). Darüber<br />
hinaus gibt es keine Prüfsumme mehr, die<br />
ausgewertet und modifiziert werden müsste.<br />
Pakete, die für das Routing relevante<br />
Zusatzinformationen mitführen, sind als<br />
solche einfach zu erkennen und können –<br />
sofern vom Router unterstützt und vom<br />
Betreiber gewollt – einer separaten Behandlung<br />
zugeführt werden. Für alle übrigen<br />
Pakete ist aber weder Speicherplatz<br />
dynamisch bereitzustellen, noch muss der<br />
bestehende Header aufwändigen Berechnungen<br />
unterzogen werden.<br />
Weniger erfreulich ist das neue Konzept für<br />
Firewall-Hersteller, deren Produkte jedes<br />
Paket sehr genau unter die Lupe nehmen<br />
müssen. Hier stellt die Möglichkeit, Paket-<br />
Header mit theoretisch beliebigen Erweiterungen<br />
zu versehen, einen Graus dar.Alle<br />
Ergänzungen zum Protokoll-Header<br />
müssen zunächst analysiert werden, um an<br />
der Firewall die Entscheidung treffen zu<br />
können, was mit dem vorliegenden Daten-<br />
Paket passieren soll. Das Interpretieren dieser<br />
Header-Listen ist bei Weitem komplizierter,<br />
als Bits oder Felder im (dafür<br />
größeren) IPv4-Protokoll-Header zu prüfen.<br />
Mehrere Entwickler aus dem Umfeld<br />
des OpenBSD-Betriebssystems sind der<br />
Meinung, dass IPv6 durch den Verzicht auf<br />
neue Funktionalität zwar nur das Adressraum-Problem<br />
gelöst, aber aufgrund seiner<br />
Einfachheit schneller Akzeptanz gefunden<br />
Bit<br />
0<br />
64<br />
128<br />
192<br />
256<br />
0 4<br />
Version<br />
Bild 3: Der Aufbau eines IPv6-Pakets<br />
Traffic Class Flow Label<br />
Payload Length Next Header<br />
hätte [6]. Stattdessen ist mehr als ein Jahrzehnt<br />
nach den ersten Schritten IPv6 noch<br />
immer nicht flächendeckend im Einsatz.<br />
IPv6 wird kommen<br />
Der Internet Engineering Task Force war<br />
bereits bei der Ausschreibung für den<br />
Nachfolger von IPv4 klar, dass ein Umstieg<br />
auf ein neues Internet-Protokoll ein<br />
schwieriger und komplexer Prozess sein<br />
würde. Im Anforderungskatalog für das<br />
neue Protokoll ist deshalb auch die Forderung<br />
nach einem Plan für die Übergangsphase<br />
enthalten.<br />
Anders als beim Wechsel des Internetprotokolls<br />
von NCP nach TCP/IP in grauer<br />
Vorzeit wurde für den Wechsel zu IPv6 eine<br />
ganze Reihe an Übersetzungsverfahren<br />
spezifiziert, die den Datenaustausch zwischen<br />
den beiden Netzwerkprotokollen<br />
ermöglichen sollten. Für die Migration von<br />
NCP zu TCP/IP wurde geplant, am 1. Januar<br />
1983 NCP endgültig zu deaktivieren<br />
(RFC 801).Wie aus den Fortschrittsberichten<br />
(RFC 832 bis RFC 839, RFC 842<br />
bis RFC 848 und RFC 876) ersichtlich<br />
ist, war das Internet aber erst ungefähr neun<br />
Monate später vollständig umgestellt.Auch<br />
deshalb hat die IETF davon abgesehen, ein<br />
Datum festzulegen, bis wann die Umstellung<br />
auf IPv6 abgeschlossen sein muss.Angesichts<br />
des zwischenzeitlich fast aufge-<br />
8 12 16 20 24 28 32<br />
Source Address<br />
Destination Address<br />
Hop Limit<br />
brauchten Adressraumes von IPv4 und den<br />
zur Verfügung stehenden Mitteln für eine<br />
sanfte Migration müsste das neue Protokoll<br />
eigentlich weit verbreitet sein. Die<br />
Wirklichkeit sieht anders aus:Wenn auch in<br />
den letzten Monaten endlich etwas Bewegung<br />
in die Verbreitung von IPv6 gekommen<br />
ist, so ist noch immer viel zu wenig<br />
davon spürbar.<br />
Die Ursache für die schleppende Verbreitung<br />
ist die Wechselwirkung zwischen<br />
Anbietern von Inhalten und den Zugangsprovidern.<br />
Inhalteanbieter erreichen<br />
durch die Aufschaltung ihrer Angebote<br />
auf IPv6 keinen größeren Kundenkreis.<br />
Es besteht sogar ein – wenn auch verschwindend<br />
kleines – Risiko, dass ihre<br />
Angebote danach weniger gut erreichbar<br />
sein werden. Zugangsanbieter andererseits<br />
sehen keine Notwendigkeit, ihren<br />
Kunden Zugang über IPv6 zum<br />
Internet anzubieten, solange darüber keine<br />
Inhalte abrufbar sind. Diese Situation<br />
wird sich nun aber sehr bald ändern.Voraussichtlich<br />
ab Oktober 2011 wird eine<br />
der fünf Regionalen Internet Registries<br />
(RIR) anfangen müssen,Anträge auf neue<br />
IP-Adressen abzuweisen. Spätestens ein<br />
Jahr darauf werden alle RIRs in dieser<br />
Lage sein. Hochrechnungen zufolge soll<br />
dann nämlich der letzte jetzt noch freie<br />
Adressblock aufgebraucht sein.<br />
4 Auszug aus IT-Administrator November 2010 www.it-administrator.de