|
|
| Zeile 209: |
Zeile 209: |
| |} | | |} |
|
| |
|
| == Adress-Typen ==
| |
| === Unicast-Adressen ===
| |
| ; Kommunikation eines Netzknotens mit genau einem anderen Netzknoten
| |
|
| |
| ; Unicast-Adressen sind providerbasierte Adressen und gelten Weltweit
| |
| * Sie sind durch die ersten 3 Bit 010 gekennzeichnet.
| |
| * Anschließend folgen 5 Bit Registry-ID, die das Organ bezeichnen, das diese Adresse an den Provider vergeben hat, auf die wiederum eine Provider-ID folgt.
| |
| * Anschließend folgt die Subscriber-Id, die die Einrichtung bezeichnet, die von dem Provider die Adresse bezieht
| |
|
| |
| ; Subscriber kann sein Netz wiederum in verschiedene Unternetze gliedern
| |
| * die durch eine entsprechende ID gekennzeichnet sind
| |
| * Die letzten 48 Bit bilden schließlich die Interface-ID
| |
| * Da dies genau der Größe einer MAC-Adresse enstpricht, können sich damit Stationen im LAN automatisch konfigurieren, indem sie einfach ihre MAC-Adresse als Interface-ID verwenden
| |
|
| |
| ; Weitere Adressbereiche
| |
| * die den heutigen lokalen Adressbereichen entsprechen, und die nicht von einem Router geroutet werden
| |
| * Es sind dies verbindungsspezifische und standortspezifische lokale Adressen
| |
|
| |
| ==== Link-Local-Adressen ====
| |
| ; Sind nur innerhalb abgeschlossener Netzwerksegmente (link) gültig
| |
| * Netzwerksegment ist ein lokales Netz, gebildet mit Switches oder Hubs, bis zum ersten Router
| |
| * Link-Local-Adressen sind mit APIPA-Adressen im Netz 169.254.0.0/16 vergleichbar.
| |
|
| |
| ; Formatpräfix lautet <nowiki>fe80::/10</nowiki>
| |
| 10 Bit 54 Bit 64 Bit
| |
| 1111111010 0 Interface ID
| |
|
| |
| ; Verwendung
| |
| * Adressierung von Nodes in abgeschlossenen Netzwerksegmenten
| |
| * Autokonfiguration
| |
| * Neighbour-Discovery
| |
|
| |
| ; Vorteile
| |
| * In einem Netzwerksegment muss keinen DHCP-Server zur Adressvergabe konfigurieren werden
| |
|
| |
| ; Zone ID
| |
| * Soll ein Gerät mittels einer dieser Adressen kommunizieren, so muss die Zone ID mit angegeben werden
| |
| * eine Link-Lokale-Adresse kann auf einem Gerät mehrfach vorhanden sein
| |
|
| |
| ; Beispiele
| |
| fe80::7645:6de2:ff:1%1
| |
| fe80::7645:6de2:ff:1%eth0
| |
|
| |
| ==== Site Local Unicast (veraltet) ====
| |
| ; <nowiki> fec0::/10 </nowiki>
| |
| * <nowiki> fec0… bis feff… </nowiki>
| |
|
| |
| ; Standortlokale Adressen (site local addresses)
| |
| * Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x)
| |
| * Durften nur innerhalb der gleichen Organisation geroutet werden
| |
| * Die Wahl des verwendeten Adressraums innerhalb von fec0::/10 war beliebig
| |
|
| |
| ; Überschneidungen der Adressräume
| |
| * Es konnte zu Überschneidungen der Adressräume an unterschiedlichen Standorten kommen
| |
| ** Bei der Zusammenlegung von ehemals getrennten Organisationen
| |
| ** wenn eine VPN-Verbindung zwischen eigentlich getrennten mit Site Local Addresses nummerierten Netzwerken hergestellt wurde
| |
|
| |
| ; Deprecated (RFC 3879)
| |
| * Aus diesem und weiteren Gründen sind Site Local Addresses nach RFC 3879 veraltet
| |
| ** werden aus zukünftigen Standards verschwinden
| |
| * Neue Implementierungen müssen diesen Adressbereich als Global-Unicast-Adressen behandeln
| |
|
| |
| ; Nachfolger sind [[Unique Local Addresses]]
| |
|
| |
| ==== Unique Local Unicast (ULA) ====
| |
| ; <nowiki>fc00::/7 (fc00… bis fdff…)</nowiki>
| |
|
| |
| ; Für private Adressen gibt es die Unique Local Addresses (ULA)
| |
| * beschrieben in RFC 4193
| |
|
| |
| ; Präfix fd
| |
| * Derzeit ist nur das Präfix fd für lokal generierte ULA vorgesehen
| |
|
| |
| ; Präfix fc
| |
| * ist für global zugewiesene, eindeutige ULA reserviert
| |
|
| |
| ; Site-ID
| |
| * Auf das Präfix folgen 40 Bit, als eindeutige Site-ID
| |
|
| |
| ; Eindeutigkeit
| |
| * Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren und somit ''sehr wahrscheinlich eindeutig''
| |
| * Bei global vergebenen ULA jedoch auf jeden Fall eindeutig
| |
| ** RFC 4193 gibt jedoch keine konkrete Implementierung der Zuweisung von global eindeutigen Site-IDs an
| |
|
| |
| ; Subnet-ID
| |
| * Nach der Site-ID folgt eine 16-Bit-Subnet-ID, welche ein Netz innerhalb der Site angibt
| |
|
| |
| ; Beispiel
| |
| ;: <nowiki>fd9e:21a7:a92c:2323::1</nowiki>
| |
|
| |
| ; Hierbei ist
| |
| * fd das Präfix für lokal generierte ULAs
| |
| * 9e:21a7:a92c ein einmalig zufällig erzeugter 40-Bit-Wert
| |
| * 2323 eine willkürlich gewählte Subnet-ID
| |
| * ::1 die Host-ID
| |
|
| |
| ; Vorteil der Verwendung von wahrscheinlich eindeutigen Site-IDs
| |
| * Beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken sind Adresskollisionen sehr unwahrscheinlich
| |
| * Pakete, die an eine nicht erreichbare Site gesendet werden, laufen mit großer Wahrscheinlichkeit ins Leere, statt an einen lokalen Host gesendet zu werden, der zufällig die gleiche Adresse hat
| |
|
| |
| ; ULA-Central
| |
| * Es existiert ein proposed standard, welcher Richtlinien für Registrare (IANA, RIR) beschreibt, konkret deren Betrieb sowie die Adressvergabe-Regeln
| |
| * Allerdings ist eine derartige „ULA-Central“ bisher nicht gegründet
| |
| * Sowohl der RFC 4193 als auch der proposed standard sind identisch in Bezug auf das Adressformat und den Generierungs-Algorithmus
| |
|
| |
|
| |
| ==== Global Unicast ====
| |
| ; Alle anderen Adressen gelten als Global-Unicast-Adressen
| |
| ; Von diesen sind jedoch bisher nur die folgenden Bereiche zugewiesen
| |
|
| |
| ; <nowiki>::/96 (96 0-Bit)</nowiki>
| |
| Stand für IPv4-Kompatibilitätsadressen
| |
| * welche in den letzten 32 Bit die IPv4-Adresse enthielten
| |
| * dies galt nur für globale IPv4 Unicast-Adressen
| |
| * Diese waren für den Übergang definiert
| |
| * In RFC 4291 vom Februar 2006 als veraltet (engl. deprecated) gekennzeichnet
| |
|
| |
| ; <nowiki>0:0:0:0:0:ffff::/96 (80 0-Bit, gefolgt von 16 1-Bit)</nowiki>
| |
| Steht für IPv4 mapped (abgebildete) IPv6 Adressen
| |
| * Die letzten 32 Bit enthalten die IPv4-Adresse
| |
| * Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren
| |
| ** und so die neue mit der alten Welt verbinden
| |
|
| |
| ; <nowiki>2000::/3 (2000… bis 3fff…; was dem binären Präfix 001 entspricht)</nowiki>
| |
| * Stehen für die von der IANA vergebenen globalen Unicast-Adressen
| |
| * Routbare und weltweit einzigartige Adressen
| |
|
| |
| ===== Bildung einer Globalen Unicast Adresse =====
| |
| ; Unterteilung des Adressraumes in öffentlichen (TLA, NLA, SLA) und lokalen Bereich (64 Bit + 64 Bit)
| |
| [[File:ipv6Adressierung15.png|mini|600px]]
| |
| * Routing im öffentl. Bereich effizient durch hierarchische Netz-topologische Orientierung
| |
| * Routing im lokalen Bereich effizient durch festen „public-“ Teil der Adresse (64 Bit)
| |
|
| |
| ; Nur Top-Level Aggregation ID muss zentral verwaltet werden
| |
|
| |
| ; Adressvergabe erfolgt blockweise hierarchisch von oben nach unten
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Option !! Beschreibung
| |
| |-
| |
| | TLA ||Top Level Aggregation (z.B. Super-Provider,Exchange)
| |
| |-
| |
| | NLA || Next Level Aggregation (z.B. ISP)
| |
| |-
| |
| | SLA || Site Level Aggregation (z.B. Firma)
| |
| |}
| |
|
| |
| ; Global Unicast Adressen
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Option !! Beschreibung
| |
| |-
| |
| | 2001 2003, 240, 260, 261, 262, 280, 2a0, 2b0 || werden an Provider vergeben und 2c0
| |
| * die diese an ihre Kunden weiterverteilen
| |
| * werden von Regional Internet Registries (RIRs) vergeben
| |
| |-
| |
| | 2001::/32 || sind ihnen noch vollständig zugeteilt
| |
| * beginnend mit 2001:0:
| |
| * anders als 2001::/16
| |
| * Tunnelmechanismus Teredo 3ffe::/16
| |
| |-
| |
| | 2001:db8::/32 || Testnetzwerk 6Bone
| |
| * Dokumentationszwecke
| |
| * wurden gemäß RFC 3701 an die IANA
| |
| * keine tatsächlichen Netzteilnehmer zurückgegeben
| |
| |-
| |
| | 2002 64:ff9b::/96 || Adressen des Tunnelmechanismus 6to4
| |
| * Übersetzungsmechanismus NAT64 gemäß RFC 6146
| |
| |}
| |
|
| |
| === Multicast-Adressen ===
| |
| ; Multicast-Adressen sprechen eine ganze Gruppe von Rechnern an
| |
| * Das ist zum Beispiel für Video on Demand oder Fernunterricht nützlich und spart Bandbreite, da es bereits auf der IP-Schicht ausgewertet wird und mehrfache Übertragung von Paketen verhindert.
| |
| * Auch mehrere NTP-Server können einer Multicast-Gruppe angehören.
| |
|
| |
| ; Multicast-Adressen beginnen alle mit der Bitfolge 1111 1111
| |
| * Darauf folgen dei Felder Flag und Scope.
| |
| * Bisher ist allerdings nur das Flag T definiert, mit den Werten 1 für dauerhaft und 0 für temporär.
| |
|
| |
| ; Einer-zu-vielen-Kommunikation wird durch Multicast-Adressen abgebildet
| |
| [[File:ipv6Adressierung24.png|800px]]
| |
|
| |
| Typ: 0000 ... fest definiert (ANA), 0001 ... Adresse wurde „frei“ vergeben
| |
|
| |
| ; Scope: Gültigkeitsbereich 0001 nur lokales Endgerät
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Wert !! Scope
| |
| |-
| |
| | 0010 || Link lokal
| |
| |-
| |
| | 0101 || Site lokal
| |
| |-
| |
| | 1000 || Organisations-lokal
| |
| |-
| |
| | 1110 || Global
| |
| |}
| |
|
| |
| ; Regel
| |
| # FF02::1:FF00:0/104 zzgl. letzte 24 Bit der Unicast Adresse
| |
| # Link-Lokale MC Adresse des Endsystems (für Neighbor Discovery)
| |
|
| |
| ; Beispiele für Multicast-Adressen
| |
| FFO1::1 alle lokalen Interfaces FF02::1 alle Link-lokalen Interfaces
| |
| FF05::2 alle Site-Ilokalen Router FF0x::202 Sun RPC
| |
|
| |
| [[File:ipv6Adressierung24.png|800px]]
| |
|
| |
| ; <nowiki>Präfix ff00::/8 (ff…)</nowiki>
| |
|
| |
| stehen für Multicast-Adressen
| |
|
| |
| ; Nach dem Multicast-Präfix folgen
| |
| * 4 Bit für Flags
| |
| * 4 Bit für den Gültigkeitsbereich (Scope)
| |
|
| |
| ; Flags sind zurzeit in folgenden Kombinationen gültig
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Wert !! Bezeichnung !! Beschreibung
| |
| |-
| |
| | 0 || Permanent || definierte wohlbekannte Multicast-Adressen (von der IANA zugewiesen)
| |
| |-
| |
| | 1 || T-Bit gesetzt || Transient (vorübergehend) oder dynamisch zugewiesene Multicast-Adressen
| |
| |-
| |
| | 3 || P-Bit gesetzt, erzwingt das T-Bit || Unicast-Prefix-based Multicast-Adressen (RFC 3306)
| |
| |-
| |
| | 7 || R-Bit gesetzt, erzwingt P- und T-Bit || Multicast-Adressen, welche die Adresse des Rendezvous-Point enthalten (RFC 3956)
| |
| |}
| |
|
| |
| ===== Gültigkeitsbereiche =====
| |
| ; Die restlichen Bereiche sind nicht zugewiesen
| |
| * dürfen von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren.
| |
|
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Wert !! Scope !! Beschreibung
| |
| |-
| |
| | 1 || interfacelokal ||diese Pakete verlassen die Schnittstelle nie. (Loopback)
| |
| |-
| |
| | 2 || link-lokal || werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Teilnetz nicht verlassen.
| |
| |-
| |
| | 4 || adminlokal || der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss.
| |
| |-
| |
| | 5 || sitelokal || dürfen zwar geroutet werden, jedoch nicht von Border-Routern
| |
| |-
| |
| | 8 || organisationslokal || die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch „im Unternehmen“ (hierzu müssen seitens des Routing-Protokolls entsprechende Vorkehrungen getroffen werden).
| |
| |-
| |
| | e || globaler Multicast || darf überallhin geroutet werden
| |
| |-
| |
| | 0, 3, f || reservierte Bereiche ||
| |
| |}
| |
|
| |
| ; Beispiele für wohlbekannte Multicast-Adressen
| |
| * ff01::1, ff02::1: All Nodes Adressen. Entspricht dem Broadcast.
| |
| * ff01::2, ff02::2, ff05::2: All Routers Adressen, adressiert alle Router in einem Bereich.
| |
|
| |
| ==== Anycast Adressen ====
| |
| ; Verschiedene Endgeräte sind unter einer (Anycast-) Adresse erreichbar
| |
| * Auslieferung des Paketes normalerweise an das Interface des Endgerätes, welches (Netztopologie) Routing-mäßig das nächstliegende ist
| |
| * Unterscheidet sich nicht von normaler Unicast-Adresse 4 Anycast Funktionalität ist durch die Router und durch Konfiguration des Endgerätes zu realisieren
| |
| * Derzeit nur für Router oder Server zulässig (Änderung jedoch absehbar)
| |
|
| |
| ; Anwendungsbeispiele
| |
| * Dienste unter global gleicher Adresse effizient verfügbar (Routing zum PoP)
| |
| * Load Balancing
| |
| * erhöhte Stabilität durch mehrere Router gleicher Adresse
| |
| * Mobile IPv6 Home Agents Anycast (Anycast Id. 126 oder 7E)
| |
|
| |
| ; Mit Anycast-Adressen erreicht man genau einen aus einer Gruppe von Rechnern
| |
| * die die selbe Anycast-Adresse haben
| |
| ** Zum Beispiel einen aus einer Gruppe von Nameservern, oder von Routern bei einem Provider
| |
|
| |
|
| <noinclude> | | <noinclude> |
