22.04.2013 Aufrufe

Workshop Teil 1 (PDF) - GeNUA

Workshop Teil 1 (PDF) - GeNUA

Workshop Teil 1 (PDF) - GeNUA

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!