|
|
(31 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
Zeile 1: |
Zeile 1: |
| | '''topic''' - Beschreibung |
| | |
| = IPv6 Adressen = | | = IPv6 Adressen = |
| == Adressaufbau von IPv6 ==
| | {{:IPv6/Adresse}} |
| ; IPv6-Adressen sind 128 Bit lang
| |
| * Präfix: Ersten 64 Bit
| |
| * Suffix: Letzten 64 Bit
| |
| ** Interface-Identifier
| |
| | |
| [[File:ipv6Adressierung02.png|600px]]
| |
| | |
| ; Netzwerkschnittstellen können unter mehreren IP-Adressen erreichbar sein
| |
| * link-lokalen Adresse
| |
| * global eindeutigen Adressen
| |
| | |
| ; Interface-Identifier
| |
| * Ein Interface-Identifier kann damit Teil mehrerer IPv6-Adressen sein
| |
| * welche mit verschiedenen Präfixen auf dieselbe Netzwerkkarte gebunden sind
| |
| * Insbesondere gilt dies auch für Präfixe möglicherweise verschiedener Provider
| |
| ** vereinfacht Multihoming
| |
| | |
| == Adressnotation ==
| |
| ; Binäre Darstellung einer IPv6-Adresse
| |
| 0010 0000 0000 0001 0000 1101 1011 1000
| |
| 0000 0000 0000 0000 0000 0000 0000 0000
| |
| 0000 0000 0000 0000 0000 0000 0000 0000
| |
| 0000 0000 0000 0000 0000 0000 0000 0001
| |
| | |
| ; Hexadezimalzahl Darstellung einer IPv6-Adresse
| |
| 2001:0DB8:0000:0000:0000:0000:0000:0001
| |
| | |
| == RFC 4291 ==
| |
| ; Notation von IPv6-Adressen
| |
| | |
| ; Hexadezimale Notation
| |
| ; Acht Blöcke je 4 Nibble
| |
| * Mit Doppelpunkten getrennt
| |
| 2001:0db8:85a3:08d3:1319:8a2e:0370:7344
| |
| | |
| ; Führende Nullen dürfen ausgelassen werden
| |
| 2001:0db8:0000:08d3:0000:8a2e:0070:7344
| |
| ist gleichbedeutend mit
| |
| 2001:db8:0:8d3:0:8a2e:70:7344
| |
| | |
| ; Aufeinander folgende 0-Blöcke werden durch :: ersetzt
| |
| * 2001:0db8:0:0:0:0:1428:57ab
| |
| ist gleichbedeutend mit
| |
| 2001:db8::1428:57ab
| |
| | |
| == RFC 4291 ==
| |
| ; Adressnotation
| |
| | |
| ; Einbettung eines IPv4-Adressraums in den IPv6-Adressraum
| |
| ; Die letzten vier Byte können dezimal notiert werden
| |
| ::ffff:127.0.0.1
| |
| ist eine alternative Schreibweise für
| |
| ::ffff:7f00:1
| |
| | |
| == RFC 5952 ==
| |
| ; Darstellung für und zwischen Menschen
| |
| | |
| ; Schreibweisen nach RFC 4291
| |
| 2001:db8:0:0:1:0:0:1
| |
| 2001:0db8:0000:0000:1:00:0:1
| |
| 2001:db8::1:0:0:1
| |
| 2001:db8::0:1:0:0:1
| |
| 2001:0db8::0:1:0:0:1
| |
| 2001:db8:0:0:1::1
| |
| 2001:db8:0000:0:1::1
| |
| 2001:DB8:0:0:1::1
| |
| 2001:DB8:0:0:1::1
| |
| | |
| ; RFC 5952
| |
| ; Darstellung für und zwischen Menschen
| |
| | |
| == RFC 5952 ==
| |
| ; Verbindliche Regeln zur Notation
| |
| | |
| ; Verbindliche Regeln zur Notation und Darstellung fest
| |
| * für und zwischen Menschen
| |
| | |
| 1. Führende Nullen müssen weggelassen werden
| |
| 2001:0db8:00::001 → 2001:db8::001
| |
| 2001:0db8:00::001 → 2001:db8::1
| |
| 2. Zwei Doppelpunkte müssen die größtmögliche Anzahl von Null-Blöcken kürzen
| |
| 2001:db8:0:0:0:0:0:1 → 2001:db8::0:1
| |
| 2001:db8:0:0:0:0:0:1 → 2001:db8::1
| |
| 3. Zwei Doppelpunkte dürfen nicht zur Kürzung eines alleinstehenden Null-Blocks benutzt werden
| |
| 2001:db8:0:1:1:1:1:1 → 2001:db8::1:1:1:1:1
| |
| 2001:db8:0:1:1:1:1:1 → 2001:db8:0:1:1:1:1:1
| |
| 4. Bei gleichwertigen Möglichkeiten zur Kürzung ist die erste von links zu wählen
| |
| 2001:db8:0:0:1:0:0:1 → 2001:db8:0:0:1::1
| |
| 2001:db8:0:0:1:0:0:1 → 2001:db8::1:0:0:1
| |
| 5. Alphabetische Zeichen werden klein geschrieben
| |
| 2001:DB8::1
| |
| 2001:db8::1
| |
| 6. Bei der Angabe von Port-Nummern wird die Adresse in eckige Klammern geschrieben
| |
| 2001:db8::1:80
| |
| [2001:db8::1]:80
| |
| | |
| == RFC 5952 ==
| |
| ; Verbindliche Regeln zur Notation
| |
| | |
| ; URL-Notation
| |
| ; In einer URL wird die IPv6-Adresse in eckige Klammern eingeschlossen
| |
| http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/
| |
| | |
| verhindert die Interpretation von Portnummern als Teil der IPv6-Adresse
| |
| http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:8080/
| |
| | |
| == RFC 5952 ==
| |
| ; Verbindliche Regeln zur Notation
| |
| | |
| ; Netznotation
| |
| ; IPv6-Netzwerke werden in der CIDR-Notation aufgeschrieben
| |
| * Dazu werden die erste Adresse (bzw. die Netzadresse) und die Länge des Präfixes in Bit
| |
| getrennt durch einen Schrägstrich notiert.
| |
| * Zum Beispiel steht
| |
| 2001:0db8:1234::/48
| |
| * für das Netzwerk mit den Adressen
| |
| 2001:0db8:1234:0000:0000:0000:0000:0000
| |
| bis
| |
| 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff
| |
| | |
| ; Die Größe eines IPv6-Netzwerkes
| |
| * (oder Subnetzwerkes) im Sinne der Anzahl der vergebbaren Adressen in diesem Netz muss
| |
| eine Zweierpotenz sein.
| |
| | |
| ; Ein einzelner Host
| |
| * Da ein einzelner Host auch als Netzwerk mit einem 128 Bit langen Präfix betrachtet werden
| |
| kann, werden Host-Adressen manchmal mit einem angehängten „/128“ geschrieben.
| |
| | |
| == Adress-Repräsentation ==
| |
| | |
| == IPv6-Adressnotation ==
| |
| ; Zusammenfassung
| |
| [[File:ipv6Adressierung13.png|600px]]
| |
|
| |
|
| = Interface Identifier = | | = Interface Identifier = |
| | | {{:IPv6/Interface Identifier}} |
| == Aufbau und automatische Erzeugung ==
| |
| | |
| * Bei dem 64 Bit langen IPv6-Interface Identifier handelt es sich um die Link Layer Adresse
| |
| (OSI-Modell Schicht 2), d.h. der MAC-Adresse, der Schnittstelle.
| |
| * Dazu wird das 64 Bit lange, genormte IEEE EUI-64 Adressformat in einer leicht abgeänderten
| |
| Form verwendet.
| |
| * Durch Invertierung des u-Bits wird die Konfiguration von Hand erleichtert.
| |
| * Bei den folgenden Darstellung der Adresse handelt es sich um die kanonische Sichtweise in der
| |
| ISO/OSI-Modell Schicht 2.
| |
| | |
| [[File:ipv6Adressierung07a.png|600px]]
| |
| | |
| u Kennzeichnung:
| |
| „1“ = universal : weltweit eindeutige Adresse
| |
| „0“ = local : lokal eindeutige Adresse
| |
| g Kennzeichnung:
| |
| „1“ = group : Gruppen-/Multicast-Adresse
| |
| „0“ = individual : Einzel-Adresse
| |
| c durch IEEE festgelegte Bits die den Interface-Hersteller
| |
| kennzeichnen
| |
| x durch Interface-Hersteller vergebene Adressbit
| |
| | |
| == Abbildungsvorschriften ==
| |
| # IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)
| |
| # IEEE 802.3 MAC-Adresse (48 Bit) => IPv6-Interface ID Adresse (64 Bit)
| |
| | |
| == IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit) ==
| |
| ; Alle 64 Bit der IEEE EUI-64 Adresse werden übernommen
| |
| * Es wird lediglich das u-Bit invertiert.
| |
| * Beispiel
| |
| ** IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)
| |
| | |
| IEEE EUI-64 Adresse (64 Bit) 7834:1234:ABCD:5678
| |
| IPv6-Interface ID Adresse (64 Bit) 7A34:1234:ABCD:5678
| |
| | |
| [[File:ipv6Adressierung10.png|600px]]
| |
| | |
| == IEEE 802.3 MAC-Adresse (48 Bit) => IPv6-Interface ID Adresse (64 Bit) ==
| |
| * Bei der Abbildung der 48 Bit langen IEEE 802.3 auf die 64 Bit langen IPv6-Interface ID Adresse, führt der Weg über die Abbildung auf eine IEEE EUI-64 Adresse [RFC2464].
| |
| * Dazu werden die ersten drei Oktette der IEEE 802.3 MAC-Adresse (OUI = Organizational Unique Identfier) in die IEEE EUI-64 Adresse übernommen.
| |
| * In das vierte und das fünfte Oktett wird die Zahlen FF16 und FE16 eingefügt.
| |
| * Die letzten 3 Oktette der IEEE 802.3 MAC-Adresse werden zu den letzten drei Oktetten der IEEE EUI-64 Adresse. Zusätzlich wird auch das u-Bit invertiert.
| |
| | |
| ; Beispiel
| |
| IEEE 802.3 MAC-Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)
| |
| | |
| IEEE 802.3 MAC-Adresse (48Bit) 3007:8912:3456
| |
| IPv6-Interface ID Adresse (64 Bit) 3207:89FF:FE12:345
| |
| | |
| [[File:ipv6Adressierung08.png|600px]]
| |
| | |
| == EUI-64 ==
| |
| ; EUI-64 (64-Bit Extended Unique Identifier)
| |
| bezeichnet ein vom IEEE standardisiertes MAC-Adressformat zur Identifikation von
| |
| ; Netzwerkgeräten.
| |
| | |
| ; Eine EUI-64 Adresse ist 64 Bit lang und setzt sich aus zwei Teilen zusammen:
| |
| * Die ersten 24, 28 oder 36 Bit identifizieren den Hardwarehersteller (siehe OUI)
| |
| * Die restlichen Bits dienen der Geräteidentifikation
| |
| | |
| ; Eine Variante davon ist das sogenannte modifizierte EUI-64 Adressformat
| |
| * welches bei IPv6 zum Einsatz kommt.
| |
| * Dieses unterscheidet sich darin, dass der Wert des siebten Bits (von links) einer EUI-64
| |
| Adresse, auch Universal/Local Bit genannt, invertiert wird.
| |
| | |
| == EUI-64 ==
| |
| ; Umrechnung
| |
| ; Eine 48 Bit lange MAC-Adresse lässt sich ohne Probleme in das modifizierte EUI-64
| |
| ; Adressformat umrechnen:
| |
| | |
| ; Die MAC-Adresse wird in zwei 24 Bit lange Teile geteilt
| |
| * wobei der erste Teil die ersten 24 Bit und der zweite Teil die letzten 24 Bit der modifizierten EUI-
| |
| 64 Adresse bilden
| |
| | |
| ; Die restlichen 16 Bits werden nach folgendem Bitmuster belegt:
| |
| * 1111 1111 1111 1110 (Hexadezimal: FFFE)
| |
| | |
| ; Nach Schritt zwei befindet sich die Adresse im EUI-64-Format
| |
| | |
| ; Wenn man nun den Wert des siebten Bits invertiert, erhält man die modifizierte EUI-
| |
| 64-Adresse
| |
| | |
| == EUI-64 ==
| |
| [[File:ipv6Adressierung11.png|600px]]
| |
| | |
| == EUI-64 ==
| |
| | |
| [[File:ipv6Adressierung04.png|600px]]
| |
|
| |
|
| = Adressraum = | | = Adressraum = |
| ; Aufteilung des Adressraums
| | {{:IPv6/Adressraum}} |
| | |
| == Adresszuweisung ==
| |
| [[File:ipv6Adressierung14.png|mini|600px]]
| |
| ; Internetprovider und Regional Internet Registry
| |
| ; Internetprovider (ISP) bekommen die ersten 32 Bit (oder weniger) als Netz von einer
| |
| ; Regional Internet Registry (RIR) zugewiesen
| |
| * Dieser Bereich wird vom Provider weiter in Subnetze aufgeteilt
| |
| | |
| ; Die Länge der Zuteilung an Endkunden wird dabei dem ISP überlassen
| |
| * Vorgeschrieben ist die minimale Zuteilung eines /64-Netzes
| |
| * Ältere Dokumente (z.B. RFC 3177) schlagen eine Zuteilung von /48-Netzen an Endkunden vor
| |
| * In Ausnahmefällen ist die Zuteilung größerer Netze als /48 oder mehrerer /48-Netze an einen Endkunden möglich
| |
| * Informationen über die Vergabe von IPv6-Netzen können über die Whois-Dienste der jeweiligen RIRs abgefragt werden
| |
| | |
| == Präfixe ==
| |
| ; Präfixe geben den Netzwerkteil der Adresse an
| |
| * Sie werden in CIDR - Notation angegeben
| |
| | |
| ; Alle übrigen Bit können verwendet werden zur
| |
| * Unterteilung in Subnetze
| |
| * Adressierung von Nodes
| |
| | |
| ; Das Präfix /128 bezeichnet einen einzelnen Node
| |
| | |
| ; Typische Präfix-Längen
| |
| [[File:ipv6Adressierung03.png|600px]]
| |
| | |
| == Netzsegmente ==
| |
| ; Einzelnen Netzsegmenten werden in der Regel ein 64 Bit langer Präfix zugewiesen
| |
| * das zusammen mit dem 64 Bit langen Interface-Identifier die Adresse bildet
| |
| | |
| ; Der Interface-Identifier
| |
| * kann aus der MAC-Adresse der Netzwerkkarte erstellt oder
| |
| * anders eindeutig zugewiesen werden
| |
| * das genaue Verfahren ist in RFC 4291, Anhang A beschrieben
| |
| | |
| == Netzsegmente ==
| |
| ; Hat ein Netzwerkgerät die IPv6-Adresse
| |
| 2001:0db8:85a3:08d3:1319:8a2e:0370:7347/64
| |
| | |
| so lautet das Präfix
| |
| 2001:0db8:85a3:08d3::/64
| |
| | |
| und der Interface-Identifier
| |
| 1319:8a2e:0370:7347
| |
| | |
| ; Der Provider bekam von der RIR wahrscheinlich das Netz
| |
| 2001:0db8::/32
| |
| | |
| zugewiesen und der Endkunde vom Provider möglicherweise das Netz
| |
| 2001:0db8:85a3::/48
| |
| | |
| oder aber nur
| |
| 2001:0db8:85a3:0800::/56
| |
| | |
| == IPv6-Adressraum ==
| |
| ; Der Adressraum von IPv6 teilt sich in mehrere große Blöcke auf
| |
| * die weiter unterteilt sein können
| |
| | |
| ; Alle Adressen unterhalb der hierarchischen Adressebene eines Blockes weisen
| |
| einen identischen Präfix auf
| |
| * Dadurch wird das Routing entschieden vereinfacht
| |
| * Router können einen großen Teil der Entscheidungen schon anhand des Präfix treffen
| |
| | |
| ; IPv4-Adressen
| |
| * Können mit dem Präfix 0 in den IP6-Raum eingeblendet werden
| |
| | |
| ; Durch die neue Struktur stehen viele neuer Adressen und neue Adressierungsarten
| |
| zur Verfügung
| |
| | |
| ; Pakete werden je nach Adressierung
| |
| * an genau eine Station gesendet (Unicast),
| |
| * an eine Gruppe von Stationen (Multicast)
| |
| * an die schnellste aus einer Gruppe von Stationen (Anycast)
| |
| | |
| == Adressierungsarten ==
| |
| [[File:ipv6Adressierung06.png|800px]]
| |
| | |
| == Zu unterstützende Adressen ==
| |
| [[File:ipv6Adressierung21.png|800px]]
| |
| | |
| == Zugeordnete Adressbereiche ==
| |
| [[File:ipv6Adressierung17.png|800px]]
| |
| | |
| == Address Scopes (Gültigkeitsbereiche) ==
| |
| ; Es gibt verschiedene IPv6-Adressbereiche mit Sonderaufgaben
| |
| * und unterschiedlichen Eigenschaften
| |
| | |
| ; Diese werden meist schon durch die ersten Bit der Adresse signalisiert
| |
| * Sofern nicht weiter angegeben, werden die Bereiche in RFC 4291 bzw. RFC 5156 definiert
| |
| | |
| ; Scopes
| |
| interface/host Verlässt nie den Host
| |
| link-local Verlässt nie das lokale Subnetz
| |
| global Geht um die ganze Welt
| |
| | |
| ; Address Scopes sind nicht mit Multicast Scopes zu verwechseln
| |
| | |
| == Besondere Adressen ==
| |
| ; Nicht spezifizierte Adresse
| |
| | |
| ::/128
| |
| * 128 0-Bit
| |
| * darf keinem Host zugewiesen werden
| |
| * zeigt das Fehlen einer Adresse an
| |
| | |
| ; Verwendung
| |
| * Absenderadresse eines initialisierenden Hosts, solange er noch keine Adresse hat
| |
| * Serverprogramme werden durch Angabe dieser Adresse angewiesen, auf allen Adressen des
| |
| Hosts lauschen
| |
| | |
| ; Loopback-Adresse
| |
| | |
| ::1/128
| |
| * 127 0-Bit, ein 1-Bit
| |
| * ist die Adresse des eigenen Rechners
| |
| * loopback-Adresse, die in der Regel mit localhost verknüpft ist
| |
| | |
| == Unicast-Adressen ==
| |
| ; Charakterisieren Kommunikation eines Netzknotens mit genau einem anderen
| |
| ; Netzknoten
| |
| | |
| == 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 fe80::/10
| |
| | |
| 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
| |
| | |
| ; Beispiel
| |
| fe80::7645:6de2:ff:1%1 bzw. fe80::7645:6de2:ff:1%eth0
| |
| | |
| == Site Local Unicast (veraltet) ==
| |
| fec0::/10 (fec0… bis feff…)
| |
| * Auch: 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) ==
| |
| fc00::/7 (fc00… bis fdff…)
| |
| | |
| ; 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
| |
| | |
| == Unique Local Unicast (ULA) ==
| |
| ; Beispiel
| |
| fd9e:21a7:a92c:2323::1
| |
| | |
| ; 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“ noch nicht gegründet
| |
| * Sowohl der RFC 4193 als auch der proposed standard sind identisch in Bezug auf das
| |
| Adressformat und den Generierungs-Algorithmus
| |
| | |
| == 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.
| |
| | |
| == Multicast-Adressen ==
| |
| ; Einer-zu-vielen-Kommunikation wird durch Multicast-Adressen abgebildet
| |
| [[File:ipv6Adressierung24.png|800px]]
| |
| | |
| == Multicast-Adressen ==
| |
| ; Präfix ff00::/8 (ff…)
| |
| | |
| 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
| |
| * 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)
| |
| | |
| == Multicast-Adressen ==
| |
| ; Gültigkeitsbereiche
| |
| | |
| ; Die restlichen Bereiche sind nicht zugewiesen
| |
| * und dürfen von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren.
| |
| | |
| 1 interfacelokal, diese Pakete verlassen die Schnicite_ref-multicast_28-1cite_ref-multicast_28-1
| |
| ttstelle 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, der überallhin geroutet werden darf.
| |
| 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 ==
| |
| [[File:ipv6Adressierung22.png|800px]]
| |
| | |
| == Anycast-Adressen ==
| |
| ; 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
| |
| | |
| == Unterteilung des IPv6-Adressraums ==
| |
| Präfix Verwendung
| |
| 0000 0000 Reserviert und IPv4
| |
| 0000 0001 Nicht zugewiesen
| |
| 0000 0010 OSI-NSAP-Adressen
| |
| 0000 010 Netware IPX-Adressen
| |
| 0000 011 Nicht zugewiesen
| |
| 0000 1 Nicht zugewiesen
| |
| 1 Nicht zugewiesen
| |
| 1 Nicht zugewiesen
| |
| 10 Adressen für Service Provider
| |
| 11 Nicht zugewiesen
| |
| 100 Adressen für geographische Bereiche
| |
| 101 Nicht zugewiesen
| |
| 110 Nicht zugewiesen
| |
| 1110 Nicht zugewiesen
| |
| 1111 10 Nicht zugewiesen
| |
| 1111 110 Nicht zugewiesen
| |
| 1111 1110 Nicht zugewiesen
| |
| 1111 1110 0 Nicht zugewiesen
| |
| 1111 1110 10 verbindungsspezifische lokale Adressen
| |
| 1111 1110 11 Standortspezifische lokale Adressen
| |
| 1111 1111 Multicast
| |
| | |
| ; Unicast Adressen
| |
| | |
| == Unicast-Adressen ==
| |
| ; 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
| |
| | |
| ; Der 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
| |
| | |
| == Global Unicast ==
| |
| ; Alle anderen Adressen gelten als Global-Unicast-Adressen
| |
| ; Von diesen sind jedoch bisher nur die folgenden Bereiche zugewiesen
| |
| | |
| ::/96 (96 0-Bit)
| |
| * 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
| |
| | |
| 0:0:0:0:0:ffff::/96 (80 0-Bit, gefolgt von 16 1-Bit)
| |
| * 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
| |
| | |
| 2000::/3 (2000… bis 3fff…; was dem binären Präfix 001 entspricht)
| |
| * Stehen für die von der IANA vergebenen globalen Unicast-Adressen
| |
| * Routbare und weltweit einzigartige Adressen
| |
| | |
| == Bildung einer Globalen Unicast Adresse ==
| |
| [[File:ipv6Adressierung15.png|800px]]
| |
| | |
| == Global Unicast Adressen ==
| |
| 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
| |
| | |
| == IPv6-Adressraum ==
| |
| ; Zusammenfassung
| |
| [[File:ipv6Adressierung09.png|800px]]
| |
|
| |
|
| = Privacy-Extensions = | | = Privacy-Extensions = |
| ; Privacy Extensions nach RFC 4941
| | {{:IPv6/Privacy Extensions}} |
| | |
| ; Erzeugung des Interface-Identifiers
| |
| * Die Erzeugung des Interface-Identifiers aus der global eindeutigen MAC-Adresse ermöglicht die
| |
| Nachverfolgung von Benutzern
| |
| | |
| ; Privacy-Extensions (PEX, RFC 4941)
| |
| * hebt die permanente Kopplung der Benutzeridentität an die IPv6-Adressen auf
| |
| | |
| ; Zufällig generiert und regelmäßig gewechselt
| |
| * Indem der Interface-Identifier zufällig generiert wird und regelmäßig wechselt, soll ein Teil der
| |
| Anonymität von IPv4 wiederhergestellt werden
| |
| | |
| ; Täglich wechselndes Präfix wünschenswert
| |
| * Im Privatbereich lässt das Präfix allein recht sicher auf einen Nutzer schließen
| |
| * Daher ist aus Datenschutzgründen ein vom Provider dynamisch zugewiesenes Präfix
| |
| wünschenswert
| |
| ** in Verbindung mit den Privacy Extensions
| |
| ** z. B. täglich wechselnd
| |
| | |
| ; Whois-Datenbank
| |
| * Statische Adresszuteilung erfordern meist ein Eintrag in der öffentlichen Whois-Datenbank
| |
| * In Deutschland hat der Deutsche IPv6-Rat Datenschutzleitlinien formuliert, die auch eine
| |
| dynamische Zuweisung von IPv6-Präfixen vorsehen
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Stateless Address Autoconfiguration (SLAAC)
| |
| * nutzt auf einigen Betriebssystemen per Vorgabe die Hardware-Adresse der
| |
| Netzwerkschnittstelle
| |
| | |
| ; Solche Adressen sind im Internet leicht wiederzuerkennen
| |
| | |
| ; Abhilfe schaffen die Privacy Extensions
| |
| * die zusätzliche, über Zufallszahlen generierte und wechselnde IPv6-Adressen erzeugen
| |
| | |
| ; Stateless Address Autoconfiguration
| |
| * schiebt in der Mitte der nur 48 Bit langen MAC-Adresse zusätzlich die Bytes ff:fe ein
| |
| * erzeugt daraus den Local Identifier, also die hinteren 64 Bit einer IPv6-Adresse
| |
| * Die ersten 64 Bit gehören dem Netzwerk-Präfix, das der IPv6-Router im Netzwerk bekannt gibt
| |
| und das der Rechner in die globale IPv6-Adresse übernimmt.
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Linux
| |
| * leiten ohne Eingriff ihre globale IPv6-Adresse aus der Hardware ab
| |
| * damit offenbaren sie Informationen über den Benutzer
| |
| | |
| ; Windows
| |
| * erzeugt immer eine temporäre IPv6-Adresse
| |
| * die dem Nutzer mehr Privatheit verschafft
| |
| | |
| ahahaha ... so ein UNSINN ))
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Den IPv6-Entwicklern fiel schnell auf
| |
| * dass dieses Verfahren die Privatsphäre von Rechner und Nutzer gefährdet
| |
| * Solche statischen IPv6-Adressen wirken wie eine eindeutige Hardware-ID, die der Rechner bei jedem Kontakt zu einem IPv6-tauglichen Server überträgt.
| |
| * Brisant ist das bei Geräten wie Tablets oder Smartphones, denn sie werden in der Regel nur von einer Person genutzt.
| |
| * Die für jeden Serverbetreiber und Netzbeobachter zugängliche MAC-Adresse erlaubt es damit, diese Person wiederzuerkennen.
| |
| | |
| ; Privacy Extensions for Stateless Address Autoconfiguration in IPv6
| |
| * Daher definierten sie nachträglich das Verfahren "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC 4941)
| |
| * mit dem sich zusätzlich zu diesen statischen Adressen temporäre erzeugen lassen
| |
| * die der Rechner für seine Anfragen ins IPv6-Internet einsetzt
| |
| | |
| ; Der Host Identifier dieser Adressen wird über Zufallszahlen ermittelt
| |
| * Allerdings setzen längst nicht alle aktuellen Betriebssysteme diese Erweiterung ab Werk ein
| |
| | |
| ; Derzeit hat einzig Windows die Privacy Extensions eingeschaltet
| |
| * Andere wie Mac OS und Linux beherrschen das Verfahren
| |
| * man muss es aber per Hand aktivieren
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| Übersicht
| |
| | |
| ; Betriebssystem Privacy ab Werk de-/aktivierbar Anmerkung
| |
| Extensions aktiv
| |
| ; Windows XP + + +/+
| |
| ; Windows Vista + + +/+
| |
| ; Windows 7 + + +/+
| |
| ; Windows Server 2003 + - +/+
| |
| ; Windows Server 2008 + - +/+
| |
| ; R2
| |
| ; OpenSuse Linux + - +/+
| |
| ; Ubuntu Linux + ab 12.04 +/+
| |
| ; Debian Linux + - +/+
| |
| ; Fedora Linux + - +/+
| |
| ; Mac OS X + ab 10.7 +/+
| |
| iOS 4.1 + - -/- Privacy Extensions via
| |
| Jailbreak
| |
| iOS 4.2 + - -/- Privacy Extensions via
| |
| Jailbreak
| |
| iOS 4.3 + + -/-
| |
| ; Android ab 2.1 + - -/- Privacy Extensions über
| |
| Rooting
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Windows
| |
| | |
| ; Ohne dass der Nutzer eingreifen muss
| |
| * richten die Desktop-Versionen von Windows per Stateless Autoconfiguration bereits temporäre
| |
| IPv6-Adressen ein.
| |
| * Wie im RFC vorgesehen wechselt Windows diese Adressen in Intervallen
| |
| * die sich wie auch andere IPv6-Parameter über das Kommando netsh einstellen lassen
| |
| | |
| ; Wechselnde Adressen auf Servern wenig sinnvoll
| |
| * Daher hat Microsoft die Privacy Extensions auf Windows-Server-Versionen nicht eingeschaltet
| |
| * Anders als andere erzeugen Windows-Rechner ihre statische IPv6-Adresse auch nicht aus der
| |
| Hardware-Adresse der jeweiligen Schnittstelle.
| |
| * Stattdessen würfelt Windows die Adresse einmal, meist bei der Installation, aus
| |
| | |
| ; Abschalten
| |
| * Dieses Verhalten lässt sich als Administrator ändern
| |
| * Mit folgendem Befehl nutzt Windows für seine statische, globale IPv6-Adresse nun die MAC der
| |
| Netzwerkschnittstelle
| |
| netsh interface ipv6 set global randomizeidentifiers=disabled
| |
| | |
| ; Nachschauen
| |
| * Die aktuelle Einstellung zeigt das folgende Kommando in der Ausgabezeile an
| |
| netsh interface ipv6 show global
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Windows
| |
| | |
| ; Aktuelle IPv6-Adressen aller Netzwerkkarten
| |
| | |
| netsh interface ipv6 show addresses
| |
| | |
| ; Vorgaben für die Privacy Extensions ausgeben
| |
| | |
| netsh interface ipv6 show privacy
| |
| Der aktive Status wird abgefragt...
| |
| Parameter für temporäre Adressen
| |
| ------------------------------------------------
| |
| Temporäre Adresse verwenden : enabled
| |
| Versuch, doppelte Adr. zu entdecken : 5
| |
| Maximale Gültigkeitsdauer : 7d
| |
| Maximale bevorzugte Gültigkeitsdauer: 1d
| |
| Regenerationszeit : 5s
| |
| Maximale Verzögerungszeit : 10m
| |
| Verzögerungszeit : 0s
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Windows
| |
| | |
| y
| |
| | |
| Windows erzeugt seine feste IPv6-Adresse nicht über die MAC, die Privacy Extensions hat
| |
| Microsoft ab Werk aktiviert.
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Windows
| |
| | |
| ; Die Ausgabe bestätigt, dass die Privacy Extensions (Temporäre Adresse verwenden)
| |
| aktiv sind.
| |
| | |
| ; Maximale bevorzugte Gültigkeitsdauer
| |
| * legt fest, nach welcher Zeit (hier in Tagen) der Rechner eine neue temporäre Adresse erzeugt
| |
| und für ausgehende Pakete auch einsetzt.
| |
| | |
| ; Maximale Gültigkeitsdauer
| |
| * Eingehende Verbindungen akzeptiert der Rechner deutlich länger auf einer temporären Adresse,
| |
| was etwa für Peer-to-Peer-Anwendungen nützlich sein kann.
| |
| | |
| ; Temporären IPv6-Adressen vollständig abschalten
| |
| netsh interface ipv6 set privacy state=disabled
| |
| | |
| ; Gültigkeitsdauer setzen
| |
| netsh interface ipv6 set privacy maxpreferredlifetime=12h
| |
| * Schlüssel maxpreferredlifetime und maxvalidlifetime
| |
| * Zeitangaben in Tagen (d), Stunden (h), Minuten (m) und Sekunden (s)
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Linux
| |
| | |
| ; Alle großen Linux-Distributionen aktivieren IPv6, die Privacy Extensions jedoch
| |
| nicht
| |
| * Das bemerkt man schnell an den aus der Hardware-Adresse abgeleiteten Adressen, die im
| |
| hinteren Teil die Bytes ff und fe enthalten.
| |
| | |
| ; Die Privacy Extensions lassen sich über das Sysctl-System dauerhaft einschalten
| |
| * Am einfachsten gelingt das, wenn man für jede Netzwerkschnittstelle im Computer eine Zeile in
| |
| die Datei /etc/sysctl.conf nachträgt.
| |
| net.ipv6.conf.IF.use_tempaddr = 2
| |
| Den Platzhalter IF müssen Sie dabei durch die Schnittstellenbezeichnung ersetzen, also etwa
| |
| eth0 für die erste Ethernet-Karte oder wlan0 für das WLAN-Interface.
| |
| | |
| ; Testweise können Sysctl-Werte auch über die Shell eingeben werden
| |
| sysctl net.ipv6.conf.wlan0.use_tempaddr=2
| |
| * Damit Linux die Netzwerkschnittstelle mit einer temporären IPv6-Adresse versorgt, müssen Sie
| |
| die Schnittstelle einmal aus- und wieder einschalten (etwa über den Network Manager).
| |
| * Anschließend zeigt ifconfig an der Schnittstelle eine weitere IPv6-Adresse, deren hinterer Teil
| |
| nicht mehr aus der Hardware-Adresse abgeleitet wurde.
| |
| * Dass es sich tatsächlich um eine temporäre Adresse handelt, zeigt der Befehl ip -6 addr show
| |
| über den Bezeichner "temporary" in seinen Ausgaben an.
| |
| * Bei Ubuntu muss zusätzlich der Wert net.ipv6.conf.default.use_tempaddr=2 in der Datei
| |
| /etc/sysctl.conf setzen.
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Linux: Vorgaben ändern
| |
| | |
| ; Vorgaben zum Wechseln der temporären IPv6-Adresse lassen sich via sysctl
| |
| anpassen
| |
| * Die Sysctl-Schlüssel
| |
| | |
| net.ipv6.conf.IF.temp_valid_lft
| |
| net.ipv6.conf.IF.temp_prefered_lft
| |
| | |
| * setzen die maximale Zeit in Sekunden, in der Linux die Adresse für eingehende und
| |
| ausgehende Anfragen nutzt.
| |
| * Der letzte Schlüssel hat typischerweise den Wert 86400 (24 Stunden), eingehende Pakete
| |
| akzeptiert Linux sieben Tage an dieser Adresse.
| |
| * Den Platzhalter IF müssen Sie dabei wie oben durch den Schnittstellennamen ersetzen.
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Android
| |
| | |
| ; Googles Smartphone-Betriebssystem setzt auf Linux auf
| |
| * das zufällige und wechselnde IPv6-Adressen erzeugen kann
| |
| * Andererseits hat Google die dafür nötigen Vorgaben nicht gesetzt, sodass bislang jede Android-
| |
| Version ohne die Privatsphäre schützenden IPv6-Adressen auskommen muss.
| |
| * Auch lassen sie sich nicht einfach einschalten, denn die Mobilfunk-Provider und Handy-Hersteller
| |
| vernageln den dafür nötigen Root-Zugang.
| |
| * Zwei Befehle genügen und ein gerootetes Android surft über die wechselnden und nicht aus der
| |
| Hardware abgeleitetden IPv6-Adressen.
| |
| * Wie auch auf iPhones bleibt nur der Weg über das nachträgliche
| |
| Freischalten des Root-Zugangs oder über die Installation von
| |
| Custom-ROMs:
| |
| * Mit dem für solche Verwaltungsaufgaben nötigen Root-Benutzer
| |
| lassen sich dann wieder die Sysctl-Werte setzen, die die
| |
| Privacy Extensions für IPv6 aktivieren.
| |
| * Steht auf dem Telefon das Kommando sysctl bereit, reichen die Befehle
| |
| | |
| su
| |
| sysctl -w net.ipv6.conf.default.use_tempaddr=2
| |
| sysctl -w net.ipv6.conf.all.use_tempaddr=2
| |
| | |
| * Nach einem Neustart vergisst Android diese Einstellungen jedoch wieder.
| |
| * Man kann die beiden Befehle allerdings in eine Datei namens /data/local/userinit.sh schreiben.
| |
| * Existiert diese Datei, führt Cyanogenmod die darin aufgelisteten Befehle beim Systemstart aus.
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| ; Mac OS X
| |
| | |
| ; Auch Apples Betriebssystem Mac OS X über die Privacy Extensions ermittelte IPv6-
| |
| ; Adressen erzeugen und einsetzen
| |
| * Allerdings hat Apple dafür keinen Schalter vorgesehen.
| |
| * Das Programm IPv6 Anonymizer von c't
| |
| ** zeigt den Status der Privacy Extensions,
| |
| ** schaltet sie an oder aus und
| |
| ** sorgt dafür, dass die Funktion auch
| |
| beim Neustart zur Verfügung steht.
| |
| | |
| ; Kommandozeile
| |
| * Die Privacy Extensions lassen sich im Terminal (im Dienstprogramme-Ordner) mit einem Befehl
| |
| aktivieren
| |
| | |
| sudo sysctl -w net.inet6.ip6.use_tempaddr=1
| |
| | |
| * Damit das klappt, müssen Sie mit einem Benutzer angemeldet sein, der den Mac verwalten darf.
| |
| * Leider verschwindet die Einstellung nach einem Neustart.
| |
| | |
| == Privacy Extensions nach RFC 4941 ==
| |
| iPhone und iPad (IOS)
| |
| | |
| ; Noch schlechter als auf dem Apple-Desktop sah es bis vor kurzem unter den Mobil-
| |
| ; Betriebssystemen für iPhones und iPads aus
| |
| * Bis zur Version 4.3 waren auch dort die Privacy Extensions abgeschaltet. Erst das Update aktiviert die
| |
| Erweiterung.
| |
| * Im Unterschied zu Mac OS X steht aber auf den Mobilbetriebssystemen für iPhone und iPad kein vom
| |
| Hersteller vorgesehener Weg offen, die Privacy Extensions zu aktivieren oder abzuschalten.
| |
| * Will man auf Geräten mit der IOS-Version kleiner als 4.3 die Privacy Extensions einschalten, hat man
| |
| nur dann eine Chance, wenn man einen Administrator-Zugang zum Betriebssystem hat (Jailbreak): In
| |
| diesem Fall reicht der Aufruf von
| |
| | |
| sudo sysctl -w net.inet6.ip6.use_tempaddr=1
| |
| | |
| * respektive der Eintrag in die Datei /etc/sysctl.conf:
| |
| | |
| net.inet6.ip6.use_tempaddr=1
| |
| | |
| * Starten Sie dazu im Terminal einen Editor mit root-Rechten und fügen Sie die Zeile am Ende der Datei
| |
| an.
| |
| | |
| sudo pico /etc/sysctl.conf
| |
| | |
| * Nach einem Neustart der WLAN-Schnittstelle respektive einem Neustart des Geräts sollte die
| |
| Webseite http://ct.de/ip die zweite, über die Privacy Extensions erzeugte IPv6-Adresse anzeigen.
| |
| | |
| == RFC 4291 ==
| |
| ; Adressnotation
| |
| | |
| ; Reduktion durch Regel 3 darf nur einmal durchgeführt werden
| |
| * Es darf höchstens eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt
| |
| werden.
| |
| | |
| 2001:0db8:0:0:8d3:0:0:0
| |
| | |
| darf gekürzt werden zu
| |
| 2001:db8:0:0:8d3::
| |
| oder
| |
| 2001:db8::8d3:0:0:0
| |
| | |
| ; Wegen Mehrdeutigkeit Unzulässig
| |
| 2001:db8::8d3::
| |
| | |
| 2001:db8:0:0:0:8d3:0:0
| |
| * interpretiert werden könnte.
| |
| | |
| * Es empfiehlt sich den Block mit den meisten Null-Blöcken zu kürzen.
| |
| | |
| = TMP =
| |
| == Adressnotation ==
| |
| ; IPv6-Adresse werden hexadezimal notiert
| |
| * Acht Segmente zu je 16 Bit
| |
| * Die Segmente sind durch Doppelpunkte voneinander getrennt
| |
| * Führende Nullen innerhalb eines Segments können weggelassen werden
| |
| | |
| ; Segmente, die nur aus Nullen bestehen
| |
| * können unter Umständen leer gelassen werden.
| |
| * Daraus ergeben sich zwei aufeinander folgende Doppelpunkte
| |
| * Wenn mehrere aufeinander folgende Segmente aus Nullen bestehen, können diese aufdieselbe Art notiert werden
| |
| * Innerhalb einer einzelnen IPv6-Adresse kann nur einmal ein doppelter Doppelpunkt verwendet werden, weil sonst im mittleren Bereich nicht mehr eindeutig festgestellt werden kann, wo der Netzwerkanteil der Adresse endet bzw. der Host-Anteil beginnt.
| |
| | |
| ; Beispiel
| |
| fe80::20c:6eff:febe:22fc
| |
| Dies ergibt
| |
| fe80:0000:0000:0000:020c:6eff:febe:22fc
| |
| | |
| * Hierbei handelt es sich übrigens um eine link-lokale Adresse
| |
| * Diese Adressen werden nur für die Kommunikation innerhalb eines Netzwerksegments verwendet und sind nicht routingfähig
| |
| * Die Host-Adresse kann ein IPv6-Host aus seiner MAC-Adresse selbst errechnen. Ein DHCP-Server ist deshalb zumindest in einfachen Netzwerken nicht erforderlich.
| |
| | |
| == IPv6-Adressbereiche ==
| |
| === IPv6 Präfixe ===
| |
| {|class="wikitable"
| |
| |-
| |
| | | '''Bezeichnung'''
| |
| | | '''Präfix'''
| |
| | | '''Verwendung'''
| |
| |-
| |
| | | '''Link Local Unicast'''
| |
| | | <tt>fe80::/10</tt>
| |
| | | Rechner im eigenen Subnetz
| |
| |-
| |
| | | '''Site Local Unicast'''
| |
| | | fec0 - feff
| |
| | | Standortlokale Adressen
| |
| |-
| |
| | | '''Unique Local Unicast'''
| |
| | | fc00 - fdff
| |
| | | Private Adressen
| |
| |-
| |
| | | '''Multicast'''
| |
| | | ff00
| |
| | | Für mehrere Clients
| |
| |-
| |
| | | '''Global Unicast'''
| |
| | | 2000 - 3fff
| |
| | | Weltweite eindeutige Adressen
| |
| |-
| |
| | |
| |
| | | <tt>2001</tt>
| |
| | | An Provider vergeben, die weiterverteilen.
| |
| |-
| |
| | |
| |
| | | <tt>2002</tt>
| |
| | | Tunnelmechanismus 6to4
| |
| |-
| |
| | | '''NAT64 '''
| |
| | | <tt>64:ff9b::/96 </tt>
| |
| | | Übersetzungsmechanismus NAT64
| |
| |-
| |
| |}
| |
| | |
| === Link-lokale Unicast-Adressen ===
| |
| * Adressbereich fe80::/10 sind, wie weiter oben schon erwähnt, nur zur Kommunikation innerhalb desselben Netzwerksegments gedacht.
| |
| * Routing ist mit diesen Adressen nicht möglich.
| |
| | |
| === Unique-lokale Unicast-Adressen ===
| |
| * Adressbereich fc00::/7 entsprechen den privaten Adressen des IPv4-Protokolls.
| |
| * Sie lösen die inzwischen veralteten sitelokalen Unicast-Adressen ab und werden im Internet nicht geroutet.
| |
| | |
| === Globale Unicast-Adressen ===
| |
| * Hier sind mehrere Adressbereiche in Gebrauch.
| |
| * Die endgültigen Bereiche scheinen noch nicht ganz festzustehen, sind für die LPI-Prüfung aber auch nicht von Belang
| |
| * Der globale Bereich ist jedenfalls für die Kommunikation im Internet zuständig
| |
| * Da diese Adressen bei den meisten Internet Service Providern noch nicht nativ zu bekommen sind, empfehle ich zum Experimentieren die Verwendung eines Tunnelbrokers
| |
|
| |
|
| | <noinclude> |
| | == Anhang == |
| | === Siehe auch === |
| | {{Special:PrefixIndex/IPv6}} |
| | ==== Dokumentation ==== |
| | ==== Links ==== |
| | ===== Projekt ===== |
| | ===== Weblinks ===== |
|
| |
|
| [[Kategorie:IPv6]] | | [[Kategorie:IPv6/Adresse]] |
| | </noinclude> |