Mitteilungen - DFN-Verein

Weitere Magazine

Empfehlungen

Info

DFN GRUNDLAGEN Offizielle IPv6-Adressen im DFN Adressvergabe hat begonnen – 80 Bit Adressraum für jeden Kunden Durch mehrjährige Mitwirkung im IPv6-Netzwerk 6bone hat sich der DFN-Verein über sein IPv6-Projekt JOIN frühzeitig für die Zuweisung von offiziellen IPv6-Adressen qualifiziert. Antragsgemäß haben wir vom RIPE NCC bereits vor einiger Zeit einen Bereich zugeordnet bekommen. In der Zwischenzeit wurden im Rahmen der internationalen Internet-Gemeinde unter tatkräftiger Mitwirkung des Internet Architecture Board (IAB) und der Internet Engineering Task Force (IETF) die Vergabemechanismen diskutiert und weiter verfeinert, so dass der DFN-Verein in der Lage ist, erste Unterbereiche an die Nutzer zu verteilen. Diese können für lokale Testnetze eingesetzt oder bei der Teilnahme am 6bone genutzt werden. Es ist damit noch kein IPv6- Dienst im G-WiN verbunden. DFN- Nutzer werden im Internet der Zukunft unter dem Präfix 2001:638::/35 zu adressieren sein. Der folgende Beitrag gibt einen Überblick über die Adress-Struktur von IPv6. Christian Müller-Böhm JOIN Projekt Team Westfälische- Wilhelms-Universität Zentrum für Informationsverarbeitung Röntgenstr. 9-13 48149 Münster Tel 0251/83-31639 bohmc@uni-muenster.de join@uni-muenster.de www.join.uni-muenster.de Jürgen Rauschenbach DFN-Verein Anhalter Strasse 1 D-10963 Berlin Tel 030-884299-49 Fax 030-884299-70 jrau@dfn.de www.dfn.de Das neue Internet-Protokoll Version 6 (IPv6) steht nach langer Entwicklungsphase in immer mehr Produkten zur Verfügung und wird neben dem Internet- Protokoll Version 4 (IPv4) etablieren. Mit den Mobilfunknetzen der dritten Generation gibt es erstmals einen wirklichen „Business Case“, der die Entwicklung voran treibt. Absehbar kaum noch Hersteller geben, die auf die Bereitstellung von IPv6 parallel zu IPv4 verzichten. Der Adressraum von IPv6 ist gewaltig: Gegenüber den 32 Bit bei IPv4 stehen beim neuen Protokoll 128 Bit zur Adressierung zur Verfügung. Um den Umfang fassen zu können, muss man sich der Einheiten der Atomphysik bedienen: Grob gerechnet können 7000 Adressen pro Quadrat-Ångstrøm (1 Ångstrøm = 10 -10 m) Erdoberfläche verteilt werden ... Diese theoretische Zahl veranschaulicht, dass bei IPv6 eine klar strukturierte Adressvergabe und der Aufbau von Routing-Hierarchien zu einem guten Ergebnis führen können. Vergabefehler wie zu Anfangszeiten des Internet werden vermieden, End-to-End Funktionalität zerstörende Hilfsmittel zur Überwindung der Adressknappheit in IPv4 wie Network Adress Translation (NAT) werden der Vergangenheit angehören. Eine klare Hierarchie beim Routing wird zur Reduzierung der Länge der Routing-Tabellen beitragen, in dem von Anfang an auf Aggregierung gesetzt wird. Der Adressaufbau von IPv6 Im Standard RFC2373 – IP Version 6 Addressing Architecture – ist der Aufbau der IPv6-Adressen sehr genau definiert. Die 128 Bit werden in zwei Teile aufgespalten, in 64 Bit für die Interface Adressierung (Interface-ID) und 64 Bit für das Routing. Die Interface-ID dient zur Identifizierung eines Hosts im lokalen Netzwerk, der Routing-Bereich ist noch einmal untergliedert und dient dem Aufbau von hierarchischen Routing- Strukturen. IPv6-Adresse: 128 Bit Routing: 64 Bit Interface-ID: 64 Bit Öffentliches Routing 48 Bit Site Routing 16 Bit Unterteilung der IPv6-Adressen in Routing- Bereich und Interface-Adressierung Die Grenze bei 64 Bit darf von keiner IPv6-Implementation verletzt werden. Alle Netzstrukturen müssen im Routing- Bereich abgebildet werden, der Bereich der Interface-ID darf nicht für eine weitere Unterteilung in Subnetze verwendet werden. Für jedes Subnetz stehen 64 Bit Adressraum für die Interface-Adressierung zur Verfügung. Damit können pro Subnetz theoretisch bis zu 2 64 Endsysteme adressiert werden. Bei vielen IPv6-Implementationen wird als Anfangswert für die Interface-ID ein von der MAC-Adresse abgeleiteter Wert (EUI-64 Format der IEEE ) eingetragen; es ist auch möglich die Interface-ID mittels DHCPv6 zuzuweisen oder nach eigenen Prinzipien zu vergeben. Was als Interface- ID eingetragen wird, liegt vollständig in der Verantwortung des lokalen Netzbetreibers. Der Routing-Bereich ist noch einmal unterteilt in einen öffentlichen und einen privaten Bereich. Der private Site-Routing- Bereich steht vollständig dem lokalen Netzwerkbetreiber zur Verfügung um eine lokale Routing-Struktur aufzubauen. Der dafür vorgesehenen 16-Bit Adressraum ermöglicht jeder Site bis zu 65536 Subnetze zu betreiben. Der öffentliche Routing-Bereich ist für die Strukturen bei den Internet-Service- Providern (ISP) und für das globale Routing zwischen den ISPs bestimmt. NLA – der Adressraum für eine Site Interface-ID 64 Bit Da der Site-Routing-Bereich vollständig dem Kunden zur Verfügung stehen muss, 16 DFN Mitteilungen 54 – 11/2000
Site Routing 16 Bit Interface-ID 64 Bit NLA-Adressraum: 80-Bit-Adressraum für jede Site ergibt sich daraus, dass der kleinste, dem Nutzer zur Verfügung stehende Adressraum 80 Bit umfasst. Dieser Adressraum, bestehend aus 16 Bit Site-Routing- Bereich und 64 Bit Interface-ID, wird NLA (Next Level Aggregator) genannt. Die Regeln zur Vergabe eines NLAs an einen Kunden sind einfach: Jede Site, die Subnetze betreibt, muss einen NLA zugewiesen bekommen. Wer auch immer IPv6-Adressraum verteilt, ist angehalten, diese Regel einzuhalten. Damit wird erreicht, dass bei einem Providerwechsel die gesamte lokal aufgebaute Struktur erhalten bleiben kann. Von der 128 Bit Adresse können die letzten 80 Bit vom Kunden selbst verwaltet werden. Die ersten 48-Bit der Adresse werden dem Kunden vom Provider vorgegeben. Man spricht hier von einem 48 Bit langen Adress-Präfix oder kurz ausgedrückt von einem /48. Alle Adressen einer Site beginnen mit diesem vom ISP vorgegebenen Präfix, d.h. für das Routing zu einer Site hin sind nur die ersten 48 Bit der Adresse ausschlaggebend. Mit einem NLA steht einer Site ein sehr großer Adressraum zur Verfügung, so dass am Anfang an alle Kunden des DFN- Vereins genau ein NLA zugeordnet wird. Mehr als ein NLA pro Einrichtung darf von den Lokalen Internet Registraturen (LIR) nicht ohne Bestätigung durch die Regionale Registratur, hier das RIPE NCC, zugewiesen werden. Daraus folgt, dass beim Antrag auf einen NLA auf komplizierte Begründungen zur Adressraumgröße verzichtet werden kann, nicht aber bei einer Erweiterung. Der Adressraum ist – wie schon bei IPv4 – bei einem Providerwechsel zurückzugeben. Routing-Hierarchie und Präfix-Routing In IPv6 wird konsequent und von Anfang an das Aggregierungsprinzipwie es auch in IPv4 seit einigen Jahren üblich ist (Classless Interdomain Routing) einge- FP TLA-ID sub TLA Res NLA-ID SLA-ID 3 13 Bit 13 Bit 6 13 Bit 16 Bit /3 /16 /29 /35 /48 Präfixlänge sTLA 2001:0638::/35 Aufteilung des Routing-Space in 3 Bereiche: führt, wobei mehrere Hierarchiestufen existieren. Durch den hierarchischen Aufbau können ganze Adressbereiche unter einem Präfix zusammengefasst werden. So können dann auch die Routen zu den verschiedenen Subnetzen alle zu einer Route zusammengefasst werden. Ein Beispiel: Alle Subnetze einer Site haben den gleichen /48-Präfix, für das Routing reicht dann dieser eindeutige Präfix aus, um die Pakete in die richtige Richtung zu routen. D.h. im Backbone des Providers muss nur diese eine Route geroutet werden, die internen Strukturen des lokalen Netzwerks des Kunden müssen lediglich in den Kunden-Routern bekannt sein. An Internet Service Provider (ISP) werden große Adressräume verteilt. Geplant ist auf Dauer die Vergabe von TLAs. Für die Startphase von IPv6 hat man sich auf Vergabe von subTLA (sTLA) beschränkt, um Fehler, wie sie bei der Zuweisung von Adressräumen in der Anfangsphase des Internets gemacht wurden zu vermeiden. Ein ISP muss strenge Kriterien erfüllen, um eine sTLA zugewiesen zu bekommen. Ein sTLA ist ein /29 Präfix mit 99 Bit Adressraum. Für den ISP bedeutet das, dass er für seine eigene Routing-Struktur 19 Bit zur Verfügung hat, da er einen NLA (also 80- Bit Adressraum) an seine Kunden weitergeben muss. Bei Ausschöpfung des sTLA kann auf einen TLA umgestellt werden. Alle Kunden eines Providers haben den selben Präfix. Somit können in der übergeordneten Routing-Ebene zwischen den ISPs widerrum alle Routen zu einem Provider zu einer Präfix-Route zu- GRUNDLAGEN Interface-ID • Top Level Aggregator TLA, bzw. subTLA in der Startphase (öffentliches Routing) • Next Level Aggregator NLA (öffentliche Routing) • Site Level Aggregator SLA (privates Site-routing) DFN sammengefasst werden. Für den DFN- Vereins bedeutet das, dass der sTLA 2001:638::/35 auf längere Zeit die einzige Route ist, die nach außen annoncieren wird. Damit baut sich eine Routing-Hierarchie auf, die trotz des übergroßen Adressraums ein effizientes Routing gewährleistet. Verteilung der NLAs im G-WiN Bei der Zuweisung des IPv6-Adressraumes an die LIR gibt es noch eine Besonderheit: 6 Bit zwischen NLA und sTLA sind reserviert. Das ist ebenfalls eine Regelung für die Startphase. Sobald Bedarf dafür besteht, kann der /35-Präfix 2001:638::/35 auf ein /29 Präfix verkürzt und damit der verfügbare Addressraum erweitert werden. Damit stehen dem DFN-Verein am Anfang 13-Bit Adressraum zur Verfügung, aus denen er die NLAs an die Kunden verteilen kann. 13-Bit entsprechen 8192 NLAs, bei der Verkürzung des Präfixes auf /29 stehen 19-Bit zur Verfügung, die einer Anzahl von 524.288 NLAs entsprechen. Da mit der Erweiterung auf 19-Bit fest zu rechnen ist, hat sich der DFN-Verein dazu entschieden, den 19-Bit NLA-Bereich noch einmal zu untergliedern, um so auch im Backbone des DFN-Netzes ein effizientes Präfix-Routing einsetzen zu können. Diese Gliederung orientiert sich an den Kernnetzstandorten des G-WiN. Die Vorbereitungen für die Verteilung von NLAs an die Nutzer sind nahezu abgeschlossen. Interessenten wenden sich an unsere LIR, die unter: hostmaster@dfn.de erreichbar ist. • DFN Mitteilungen 54 – 11/2000 17 NLA /48 SLA-ID /64 64 Bit Interface
Seite 1 und 2: ■ Anwendungen GigaMedia - Film +
Seite 3 und 4: VORWORT Vor einer neuen Generation
Seite 5 und 6: werk am Basisstandort angeliefert.
Seite 7 und 8: ANWENDUNGEN IM G-WIN Tele Coaching
Seite 9 und 10: Aufbauend auf den Ergebnissen einer
Seite 11 und 12: It works! Architektur des G-WiN Das
Seite 13 und 14: Für uns begann die Auseinandersetz
Seite 15: OSPF-Routing mischer Sicht ist dies
Seite 19 und 20: security needs and the interaction
Seite 21 und 22: the community and can be found at:
Seite 23 und 24: Zur Nutzung bereit Offizieller Star
Seite 25 und 26: Hamburg Bundesamt für Seeschiffahr
Seite 27 und 28: Nutzergruppen im DFN, ihre Sprecher

Mitteilungen - DFN-Verein

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?