Skript/Netzwerk/IPv6
Einführung
IPv6 - Internetprotokoll Version 6
Beschreibung
DoD-Schicht | Protokolle | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Anwendung | HTTP | IMAP | SMTP | DNS | … | |||||
Transport | TCP/UDP | |||||||||
Internet | IP (IPv4, IPv6) | |||||||||
Netzzugang | Ethernet | Token Bus | Token Ring | FDDI | … |
- Arbeiten an IPv6
- 1995: IETF
- RFC 2460
- Im Dezember 1998 wurde IPv6 mit der Publikation von RFC 2460 auf dem Standards Track offiziell zum Nachfolger von IPv4 gekürt
- Paketvermittlung
- IP/Versionen
Anwendung
Problembehebung
Header
IPv6/Header
Beschreibung
Definiert im RFC 2460
- Feste Größe
- 40 Bytes
- davon je 16 Bytes für Absender- und Empfängeradresse
Header-Format
Feste Länge
Bei IPv6 eine feste Länge von 40 Byte (320 Bit)
- Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header)
Extension Headers
Optionale, seltener benutzte Informationen werden in so genannten Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet * zwischen dem IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (engl. Payload)
Header-Felder
- Kopfdatenbereich nach RFC 2460
Feld | Länge | Inhalt |
---|---|---|
Version | 4 Bit | IP-Versionsnummer (6) |
Traffic Class | 8 Bit | Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe. |
Flow Label | 20 Bit | Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt. |
Payload Length | 16 Bit | Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte |
Next Header | 8 Bit | Identifiziert den Typ des nächsten Kopfdatenbereiches, dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol) bezeichnen, wie z. B. TCP (Typ 6) oder UDP (Typ 17). |
Hop Limit | 8 Bit | Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers („Hops“) um eins verringert. Pakete mit null als Hop Limit werden verworfen. Es entspricht dem Feld Time to Live (TTL) bei IPv4. |
Source Address | 128 Bit | Adresse des Senders |
Destination Address | 128 Bit | Adresse des Empfängers
|
Extension Headers
Vereinfachung des Headers
- Enthält nur grundlegende Forwarding-Information
- Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern, welche durch das „Next Header“ Feld identifiziert werden
- Trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge
IPv6 (Felder)
Byte/Bin | 00–03 | 04–07 | 08–11 | 12–15 | 16-19 | 20–23 | 24–27 | 28–31 | |
---|---|---|---|---|---|---|---|---|---|
01 | Version | Traffic Class | Flow Label | H e a d e r | |||||
02 | Payload Length | Next Header | Hop Limit | ||||||
03 - 06 | Quell-IP-Adresse | ||||||||
07 - 10 | Ziel-IP-Adresse | ||||||||
11+ | Payload |
IPv4 Header Felder
Option | Beschreibung |
---|---|
Version | always 4 |
TOS (type of service) | precedence (3 bits) and “minimize delay”, “maximize throughput”, “maximize reliability”, “minimize cost” bits |
Identifier | identifier, different for each packet |
TTL | time to live field; initialized to 64; decremented at each router; drop if TTL = 0 |
Protocol | next header proto (TCP 6, UDP 17) |
Header checksum | add together 16-bit words using one’s complement: software optimized |
Entfallene Felder
Option | Beschreibung |
---|---|
HL | weil der IPv6Header eine feste Länge hat |
Protocol | wurde herausgenommen, weil das Feld Next-Header angibt welches Protokoll auf der Transportschicht verwendet wird. |
Alle Felder in Bezug auf Fragmentierung | wurden weggelassen, weil IPv6 Fragmentierung anders handhabt
|
Checksum | entfernt, weil die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die Performance auswirkt
|
Padding |
Header-Format
- Feste Länge
- Bei IPv6 eine feste Länge von 40 Byte (320 Bit)
- Im Gegensatz zu IPv4
- Extension Headers
- Optionale, seltener benutzte Informationen werden in Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet
- zwischen IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (Payload)
Kopfdaten
- Kopfdaten laut RFC 2460
Feld | Länge | Inhalt |
---|---|---|
Version | 4 Bit | IP-Versionsnummer (6) |
Traffic Class | 8 Bit | Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe. |
Flow Label | 20 Bit | Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt. |
Payload Length | 16 Bit | Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte |
Next Header | 8 Bit | Identifiziert den Typ des nächsten Kopfdatenbereiches, dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol) bezeichnen, wie z. B. TCP (Typ 6) oder UDP (Typ 17). |
Hop Limit | 8 Bit | Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers („Hops“) um eins verringert. Pakete mit null als Hop Limit werden verworfen. Es entspricht dem Feld Time to Live (TTL) bei IPv4. |
Source Address | 128 Bit | Adresse des Senders |
Destination Address | 128 Bit | Adresse des Empfängers |
IPv6 Header in einem Trace File
IPv4 und IPv6 Header im Vergleich
IPv6-Erweiterungsheader
IPv6/Header/Erweiterungsheader
Maximum Transmission Unit (MTU)
Adressierung
topic - Beschreibung
IPv6 Adressen
Eigenschaften von IPv6-Adressen
$ ip -6 a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2001:470:6d:b25:8ad:9fd5:a987:ae27/64 scope global dynamic noprefixroute valid_lft 86281sec preferred_lft 14281sec inet6 fe80::2aa1:d9b5:c8a6:bcbb/64 scope link noprefixroute valid_lft forever preferred_lft forever
Eigenschaft | Beschreibung |
---|---|
Länge | 128 Bit
128 Bit sind in dezimaler Darstellung schlecht lesbar
|
IPv6-Adressen sind wie in IPv4 Netzwerk-Interfaces zugewiesen | Ein Interface hat in der Regel mehrere IPv6-Adressen |
Scope | IPv6-Adressen haben beschränkten Gültigkeitsbereich
|
lifetime | IPv6-Adressen haben begrenzte Lebensdauer
|
Unicast, Multicast und Anycast | Spezifikation verschiedener Unicast, Multicast und Anycast Adressen
|
Mehreren IP-Adressen | Netzwerkschnittstellen können unter mehreren IP-Adressen erreichbar sein
|
Interface-Identifier | Ein Interface-Identifier kann damit Teil mehrerer IPv6-Adressen sein
|
Zu unterstützende Adressen
- IPv6 Adressen, die IPv6 Geräte mindestens unterstützen müssen
Device | Adressen |
---|---|
Host |
|
Router |
|
Interface Identifier
IPv6 Interface Identifier
Beschreibung
Aufbau und Erzeugung
- Interface Identifier
Link Layer Adresse (OSI-Modell Schicht 2)
- 64 Bit
- 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
- Kanonische Sichtweise
ISO/OSI-Modell Schicht 2
0–7 | 8–15 | 16–23 | 24–31 | 32–39 | 40–47 | 48–55 | 56–63 |
---|---|---|---|---|---|---|---|
cccc ccUG | cccc cccc | cccc cccc | xxxx xxxx | xxxx xxxx | xxxx xxxx | xxxx xxxx | xxxx xxxx |
Kennzeichnung | Beschreibung |
---|---|
U | 1: universal - weltweit eindeutige Adresse 0: local - lokal eindeutige Adresse |
G | 1: group - Gruppen-/Multicast-Adresse 0: individual - Einzel-Adresse |
c | Interface-Hersteller |
x | Adressbit |
Abbildungsvorschriften
Quelle | Ziel |
---|---|
EUI-64 | IPv6-Interface ID Adresse (64 Bit) |
MAC-Adresse (48 Bit) | IPv6-Interface ID Adresse (64 Bit) |
EUI-64
- IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)
- EUI-64 Adresse wird übernommen
- Das U-Bit wird invertiert
Adresse | 0–7 | 8–15 | 16–23 | 24–31 | 32–39 | 40–47 | 48–55 | 56–63 |
---|---|---|---|---|---|---|---|---|
IEEE EUI-64 Adresse (64 Bit) | cccc cc0G | cccc cccc | cccc cccc | xxxx xxxx | xxxx xxxx | xxxx xxxx | xxxx xxxx | xxxx xxxx |
IPv6-Interface ID Adresse (64 Bit) | cccc cc1G | cccc cccc | cccc cccc | xxxx xxxx | xxxx xxxx | xxxx xxxx | xxxx xxxx | xxxx xxxx |
- Beispiel
Option | Beschreibung |
---|---|
IEEE EUI-64 Adresse (64 Bit) | 7834:1234:ABCD:5678 |
IPv6-Interface ID Adresse (64 Bit) | 7A34:1234:ABCD:5678 |
MAC-Adresse
- IEEE 802.3 MAC-Adresse (48 Bit) => IPv6-Interface ID Adresse (64 Bit)
- RFC 2464
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 RFC/2464
Option | Beschreibung |
---|---|
1 | Dazu werden die ersten drei Oktette der IEEE 802.3 MAC-Adresse (OUI = Organizational Unique Identfier) in die IEEE EUI-64 Adresse übernommen |
2 | In das vierte und das fünfte Oktett wird die Zahlen FF16 und FE16 eingefügt |
3 | 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 |
Adresse | 0–7 | 8–15 | 16–23 | 24–31 | 32–39 | 40–47 |
---|---|---|---|---|---|---|
MAC-Adresse (48 Bit) | cccc ccUG | cccc cccc | cccc cccc | xxxx xxxx | xxxx xxxx | xxxx xxxx |
Adresse | 0–7 | 8–15 | 16–23 | 24–31 | 32–39 | 40–47 | ||
---|---|---|---|---|---|---|---|---|
MAC-Adresse (48 Bit) | cccc ccUG | cccc cccc | cccc cccc | xxxx xxxx | xxxx xxxx | xxxx xxxx |
Adresse | 0–7 | 8–15 | 16–23 | 24–31 | 32–39 | 40–47 | 48–55 | 56–63 |
---|---|---|---|---|---|---|---|---|
IPv6-Interface ID Adresse (64 Bit) | cccc cc0G | cccc cccc | cccc cccc | 1111 1111 | 1111 1110 | xxxx xxxx | xxxx xxxx | xxxx xxxx |
IPv6-Interface ID Adresse (64 Bit) | cccc cc0G | cccc cccc | cccc cccc | F F | F E | xxxx xxxx | xxxx xxxx | xxxx xxxx |
IPv6-Interface ID Adresse (64 Bit) | cccc cc1G | cccc cccc | cccc cccc | F F | F E | xxxx xxxx | xxxx xxxx | xxxx xxxx |
Beispiel
- IEEE 802.3 MAC-Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)
Option | Beschreibung |
---|---|
IEEE 802.3 MAC-Adresse (48Bit) | 3007:8912:3456 |
IPv6-Interface ID Adresse (64 Bit) | 3207:89FF:FE12:345 |
- EUI-64 (64-Bit Extended Unique Identifier)
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 Bit 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
Adressraum
IPv6/Adressraum - Aufteilung des Adressraums
IPv6-Adressraum
- Adressraum teilt sich in große Blöcke
- 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
Übersicht
3 | 5 | n Bit | 56–n | Intranet Subcriber Bereich 64 Bit (z. B. 16+48) | |||||
---|---|---|---|---|---|---|---|---|---|
010 | Provider‑ID | Subsciber‑ID | Subnet‑ID | Interface‑ID |
80 Bit | 16 Bit | 32 Bit |
---|---|---|
0* | 0* bis 1* | IPv4‑Adresse |
10 Bit | n Bit | 118-n Bit | |||||
---|---|---|---|---|---|---|---|
1111 1101 10 | 0* | Interface‑ID |
10 Bit | n Bit | m Bit | 118-n-m Bit |
---|---|---|---|
1111 11101 11 | 0* | Subnet‑ID | Interface‑ID |
8 Bit | 4 Bit | 4 Bit | 112 Bit |
---|---|---|---|
1111 1111 | Flags | SCOP | Group-ID |
4 Bit | |||
0 | 0 | 0 | T |
- T.
- 0 - dauerhaft
- 1 - temporär
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
Übersicht
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 |
Netzsegmente
- Typische Präfix-Längen
10 Bit | n Bit | 118-n Bit | |||||
---|---|---|---|---|---|---|---|
1111 1101 10 | 0* | Interface‑ID |
- Netzsegmenten werden 64 Bit lange Präfixe zugewiesen
- Bildet mit dem Interface-Identifier die Adresse
- 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
Beispiel
- 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
- Provider bekam von der RIR etwa das Netz
-
- 2001:0db8::/32
zugewiesen
- Endkunde vom Provider gegebenenfalls das Netz
-
- 2001:0db8:85a3::/48
oder nur
- 2001:0db8:85a3:0800::/56
Adressierungsarten
Gültigkeitsbereiche
- Address Scopes (Gültigkeitsbereiche)
- Es gibt verschiedene IPv6-Adressbereiche mit Sonderaufgaben und unterschiedliche 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
Scope | Beschreibung |
---|---|
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
Zugeordnete Adressbereiche
Der Rest hat momentan noch keine Verwendung
Verwendung | Präfix | Präfix (binär) | % Anteil |
---|---|---|---|
reserved | 0::/8 | 0000 0000 | 0,4% |
Loopback | 0::0:1 | ||
IPv4 compatible (für IPv4 -> IPv6 Transition) | ::0102:0304 | ||
IPv4 mapped (für IPv4 -> IPv6 Transition) | FFFF:0102:0304 | ||
ISO Network addresses | 200::/7 | 0000 001 | 0,8% |
Novell Network addresses | 400::/7 | 0000 010 | 0,8% |
Aggregatable global unicast addresses | 2000::/3 | 001 | 12,5% |
ehem. Geographic based unicast adresses | 8000::/3 | 100 | |
Link local address | FE80::/10 | 1111 1110 10 | 0,1% |
Site local address | FECO0::/10 | 1111 1110 11 | 0,1% |
Multicast address | FF00::/8 | 11111111 | 0,4% |
Summe gesamt | 15,1 % |
Besondere Adressen
Adresse | Beschreibung | Verwendung | |
---|---|---|---|
Keine Adresse | ::/128 | 128 0-Bit |
|
Loopback-Adresse | ::1/128 | 127 0-Bit ein 1-Bit |
|
Privacy-Extensions
IPv6 Privacy Extensions - RFC 4941
Beschreibung
- Privacy Extensions nach RFC 4941
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
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.
Betriebsysteme
- Linux
leiten ohne Eingriff ihre globale IPv6-Adresse aus der Hardware abdamit offenbaren sie Informationen über den Benutzer
- Windows
erzeugt immer eine temporäre IPv6-Adressedie dem Nutzer mehr Privatheit verschafft
- 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
Windows
IPv6/Privacy Extension/Windows
Linux
Android
IPv6/Privacy Extension/Android
Mac OS X
IPv6/Privacy Extension/Mac OS X
iPhone und iPad (IOS)
topic - Beschreibung
Beschreibung
- IPv6-Adressen werden mit Subnetzmasken in einen Netz- und einen Host-Teil unterteilt
- subnet masks
- wie bei IPv4
Bei IPv4 hat sich gezeigt, dass es manchmal von Nutzen wäre, einem Interface mehr als eine IP-Adresse zuweisen zu können, je nach Bedarf und Zweck (aliases, multicast etc.). Um in Zukunft flexibler bleiben zu können, geht man bei IPv6 weiter und erlaubt pro Interface mehr als eine zugewiesene IP-Adresse. Derzeit sind durch die RFCs kein Limit gesetzt, wohl aber in der Implementierung des IPv6 Stacks (um DoS Attacken vorzubeugen).
Neben der großen Bit-Anzahl für Adressen definiert IPv6 basierend auf einigen vorangestellten Bits verschiedene Adress-Typen. Diese werden hoffentlich in der Zukunft niemals aufgehoben (zum Unterschied zu IPv4 heute und die Entwicklung der class A, B und C Netze).
Zur Unterstützung einer automatischen Konfiguration wird die Bitanzahl in einen Netzwerk-Teil (vordere 64 Bits) und einen Hostteil (hintere 64 Bit).
Adress-Typ | Beschreibung |
---|---|
Adressen ohne speziellen Präfix | |
Netzteil der Adresse (Präfix) | |
Adress-Typen (Host-Teil) | |
Präfixlängen für das Routing |
IPv6 Präfixe
Bezeichnung | Präfix | Verwendung |
---|---|---|
Link Local Unicast | fe80::/10 | 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 |
2001 | An Provider vergeben, die weiterverteilen. | |
2002 | Tunnelmechanismus 6to4 | |
NAT64 | 64:ff9b::/96 | Übersetzungsmechanismus NAT64 |
Adressen ohne speziellen Präfix
Adress-Typ | Beschreibung |
---|---|
Localhost Adresse | |
Unspezifische Adresse | |
IPv6 Adressen mit eingebetteter IPv4 Adresse |
Localhost Adresse
- Dies ist eine spezielle Adresse für das Loopback Interface, vergleichbar zur ”127.0.0.1” bei IPv4. Bei IPv6 lautet die localhost Adresse
bzw. komprimiert:
Pakete mit dieser Quell- bzw. Ziel-Adresse sollten niemals den sendenden Host verlassen.
Unspezifische Adresse
- Dies ist eine spezielle Adresse vergleichbar mit ”any” oder ”0.0.0.0” bei IPv4. In IPv6 lautet sie
oder:
Diese Adresse wird meistens in Routing-Tabellen und beim ”socket binding” (zu jeder IPv6 Adresse) angewandt bzw. gesehen.
Beachten: Die Unspezifizierte Adresse kann nicht als Ziel-Adresse verwendet werden.
IPv6 Adressen mit eingebetteter IPv4 Adresse
Es gibt zwei Adressen-Typen, die IPv4 Adressen enthalten können.
IPv4 Adressen in IPv6 Format
IPv4-only IPv6-kompatible Adressen kommen manchmal bei IPv6 kompatiblen Daemon zur Anwendung, die allerdings ausschließlich an IPv4 Adressen gebunden sind.
Diese Adressen sind mit einer speziellen Präfixlänge von 96 definiert (a.b.c.d. ist die IPv4 Adresse):
oder in komprimiertem Format:
Die IPv4 Adresse 1.2.3.4. z.B. sieht wie folgt aus:
IPv4 kompatible IPv6 Adressen
Dieser Adress-Typ wurde für das automatische Tunneln (RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers) verwendet, welches aber durch das 6to4 tunneling ersetzt wurde.
oder in komprimierter Form:
Netzteil der Adresse (Präfix)
Es wurden einige Adress-Typen definiert und zugleich blieb für zukünftige Anforderungen ausreichend Raum für weitere Definitionen. In RFC 4291 / IP Version 6 Addressing Architecture wird das aktuelle Adress-Schema definiert.
- Lassen Sie uns nun einen Blick auf die verschiedenen Präfixe (und somit auf die Adress-Arten) werfen
Adress-Typ | Beschreibung |
---|---|
Link-lokaler Adress-Typ | |
Site-lokaler Adress-Typ | |
Unique Local IPv6 Unicast Adressen | |
Globaler Adress-Typ ("Aggregatable global unicast") | |
Multicast-Addressen | |
Anycast-Adressen |
Link-lokaler Adress-Typ
- 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.
Es handelt sich um spezielle Adressen, die ausschließlich auf einem Link eines Interfaces gültig sind. Wird diese Adresse als Zieladresse verwendet, so kann das Paket niemals einen Router passieren. Die Adresse wird bei der Link-Kommunikation eingesetzt, z.B.:
- Ist noch jemand anderer auf diesem Link?
- Ist jemand mit einer speziellen Adresse hier (z.B. Suche nach einem Router)?
Die Adresse beginnt mit (wobei ”x” für ein hexadezimales Zeichen steht, im Normalfall ”0”)
Eine Adresse mit diesem Präfix gibt es an jedem IPv6 fähigen Interface nach einer stateless automatischen Konfiguration (dies ist der Regelfall).
Site-lokaler Adress-Typ
Diese Adressen sind vergleichbar zu den RFC 1918 / Address Allocation for Private Internets im heutigen IPv4. Eine Neuerung und Vorteil hierbei ist, vergleichbar zum 10.0.0.0/8 im IPv4, die Nutzbarkeit von 16 bits bzw. ein Maximum von 65536 Subnetzen.
Ein weiterer Vorteil: Da man bei IPv6 mehr als eine Adresse an ein Interface binden kann, ist auch die Zuweisung einer site-local Adresse zusätzlich zu einer globalen Adresse möglich.
Die Adresse beginnt mit:
(”x” ist ein hexadezimales Zeichen, normalerweise ”0”)
Dieser Adresstyp ist nun abgekündigt RFC 3879 / Deprecating Site Local Addresses und sollte nicht mehr verwendet werden. Für Tests im Labor sind solche Adressen meineserachtens aber immer noch eine gute Wahl.
Unique Local 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.
Weil die schon früh definierten site-local Adressen nicht eindeutig sind, kann dies zu großen Problemen führen, wenn z.B. einst unabhängige Netzwerke später zusammengeschlossen werden (Überlappung von Subnetzen). Aufgrund dessen und anderer Gründe wurde ein neuer Adresstyp definiert, genant RFC 4193 / Unique Local IPv6 Unicast Addresses.
Die Adresse beginnt mit:
Ein Teil des Präfix (40 Bits) werden pseudozufällig generiert. Es ist sehr unwahrscheinlich, daß zwei generierte Präfixe identisch sind.
Ein Beispiel für einen Präfix (generiert mit Hilfe des web-basierten Werkzeugs: Goebel Consult / createLULA):
Globaler Adress-Typ ("Aggregatable global unicast")
- 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
Heute gibt es ist per Definition eine globale Adress-Art (Das erste Design, ''Provider based'' genannt, wurde bereits vor einigen Jahren wieder aufgegeben RFC 1884 / IP Version 6 Addressing Architecture [obsolete]. Einige Überbleibsel hiervon sind in älteren Linux Kernelquellen noch zu finden.
Die Adresse beginnt mit (x sind hexadezimale Zeichen)
Hinweis: Der Zusatz ”aggregatable” im Namen wird in aktuellen Drafts abgelegt. Es sind weitere Subarten definiert:
6bone Test-Adressen
Diese globalen Adressen waren die Ersten definierten und auch benutzen Adressen. Sie alle beginnen mit:
Beispiel:
Eine spezielle 6bone Test-Adresse, die niemals weltweit einmalig ist, beginnt mit
und wird zumeist in alten Beispielen benutzt, um zu vermeiden, dass Anwender diese mit Copy & Paste in Ihre Konfigurationen übernehmen können. Auf diese Weise können Duplikate weltweit einmaliger Adressen aus Versehen bzw. Unachtsamkeit vermieden werden. Es würde für den Original-Host ernste Probleme bedeuten (z.B. Antwortpakete für niemals gesendete Anfragen bekommen...). Aufgrund dessen, daß IPv6 nun produktiv ist, wird dieser Präfix nicht mehr länger delegiert und nach dem 6.6.2006 vom Routing ausgenommen (mehr unter RFC 3701 / 6bone Phaseout ).
6to4 Adressen
Diese Adressen werden für einen speziellen Tunnelmechanismus verwendet [RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds und RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers]. Sie kodieren eine gegebene IPv4 Adresse, ein eventuelles Subnetz und beginnen mit
z.B. wird 192.168.1.1/5 repräsentiert durch:
Ein kleines Shell-Kommando kann aus einer IPv4 eine 6to4 Adresse erstellen:
Siehe auch tunneling using 6to4 und information about 6to4 relay routers.
Durch einen Provider zugewiesene Adressen für ein hierarchisches Routing
Diese Adressen werden an Internet Service Provider (ISP) delegiert und beginnen mit:
Präfixe für große ISPs (mit eigenem Backbone) werden durch local registries vergeben. Zurzeit wird ein Präfix mit der Länge 32 zugeteilt.
Grosse ISPs delegieren ihrerseits an kleinere ISPs ein Präfix mit der Länge 48.
Für Beispiele und Dokumentationen reservierte Adressen
Momentan sind zwei Adressbereiche für Beispiele und Dokumentationen RFC 3849 / IPv6 Address Prefix Reserved for Documentation reserviert:
Diese Adressbereiche sollten nicht geroutet werden und am Übergangsrouter zum Internet (basierend auf Absendeadressen) gefiltert werden.
Multicast-Addressen
Multicast-Adressen werden für entsprechende Dienste verwendet.
Sie beginnen immer mit (xx ist hierbei der Wert der Reichweite)
Die Adressen werden in Reichweiten und Typen unterteilt:
Multicast-Bereiche
Die Multicast Reichweite ist ein Parameter, mit dem die maximale Distanz angegeben werden kann, die ein Multicast Paket sich von der versendenden Einheit entfernen kann.
Zurzeit sind folgende Regionen (reichweiten) definiert:
- ffx1: Node-lokal, Pakete verlassen niemals den Knoten
- ffx2: Link-lokal, Pakete werden niemals von Routers weitergeleitet, der angegebene Link wird nie verlassen.
- ffx5: Site-lokal, Pakete verlassen niemals den Standort (Site)
- ffx8: organisationsweit, Pakete verlassen niemals eine Organisation (nicht einfach zu implementieren, dies muss durch das Routing Protokoll abgedeckt werden)
- ffxe: Globale Reichweite
- Sonstige sind reserviert
Multicast-Typen
Es sind bereits viele Typen definiert bzw. reserviert (siehe RFC 4291 / IP Version 6 Addressing Architecture für weitere Details), einige Beispiele:
- All Nodes Adresse: ID = 1h, alle Hosts am lokalen Node (ff01:0:0:0:0:0:0:1) oder am angeschlossenen Link (ff02:0:0:0:0:0:0:1) werden adressiert.
- All Routers Adresse: ID = 2h, alle Router am lokalen Node (ff01:0:0:0:0:0:0:2), am angeschlossenen Link (ff02:0:0:0:0:0:0:2) oder am lokalen Standort werden adressiert.
Erforderliche node link-local Multicast Adresse
Diese spezielle Multicast Adresse wird als Zieladresse bei der Erkundung des Nahbereichs verwendet, da es ARP bei IPv6 im Gegensatz zu IPv4 nicht mehr gibt.
Ein Beispiel für diese Adresse könnte sein:
Das benutzte Präfix zeigt, dass es sich um eine link-lokale Multicast Adresse handelt. Dass Suffix wird aus der Zieladresse erstellt. In diesem Beispiel soll ein Paket zur Adresse “fe80::1234” gesendet werden, aber die Netzwerk-Schicht hat keine Kenntnis der aktuellen Schicht 2 MAC Adresse. Die oberen 104 bits werde mit “ff02:0:0:0:01:ff00::/104” ersetzt und die unteres 24 bits bleiben unverändert. Diese Adresse wird nun ”am Link” verwendet, um den entsprechenden Node zu finden, der wiederum seine Schicht 2 MAC Adresse als Antwort zurücksendet.
Anycast-Adressen
Anycast Adressen sind spezielle Adressen und werden verwendet, um besondere Bereiche wie den nächstgelegenen DNS-Server, den nächstliegenden DHCP Server und vergleichbare dynamische Gruppen abzudecken. Die Adressen werden dem Pool des Unicast Adressraums (global-aggregierbar oder Site-lokal zurzeit) entnommen. Der Anycast-Mechanismus (client view) wird von dynamischen Routing-Protokollen gehandhabt.
Hinweis: Anycast Adressen können nicht als Quelladresse verwendet werden, sondern ausschließlich als Zieladressen.
Subnet-Router Anycast-Adresse
Die Subnet-Router Anycast Adresse ist ein einfaches Beispiel für eine Anycast Adresse. Angenommen, der Knoten hat folgende global zugewiesene IPv6 Adresse:
Die Subnet-Router Anycast Adresse wird durch komplette Streichung des Suffixes (die letzten gültigen 64 bits) erstellt:
Adress-Typen (Host-Teil)
In Hinblick auf Auto-Konfigurations- und Mobilitätsfragen wurde entschieden, die niedrigeren 64 bits als Host-Bestandteil zu nutzen. Jedes einzelne Subnetz kann deshalb eine große Anzahl an Adressen enthalten.
Der Host-Teil kann aus unterschiedlichen Blickwinkeln betrachtet werden:
Adress-Typ | Beschreibung |
---|---|
Automatisch erstellte Adressen | |
Manuell festgelegte Adressen |
Automatisch erstellte Adressen
- Automatisch erstellte Adressen (auch unter dem Namen stateless bekannt)
Bei der Auto-Konfiguration wird der Hostteil der Adresse durch die Konvertierung der MAC-Adresse eines Interfaces (falls vorhanden) zu einer einmaligen IPv6 Adresse (mittels EUI-64 Methode) generiert. Falls keine MAC-Adresse verfügbar ist (z.B. bei virtuellen Interfaces), wird anstelle dessen etwas anderes herangezogen (wie z.B. die IPv4 Adresse oder die MAC-Adresse eines physikalischen Interfaces).
Als Beispiel hat hier ein NIC folgende MAC-Adresse (48 bit):
Diese wird gemäß demIEEE-Tutorial EUI-64 Design für EUI-48 Identifiers zum 64 bit Interface Identifier erweitert:
Mit einem gegebenen Präfix wird daraus die schon oben gezeigte IPv6-Adresse:
Datenschutzproblem
- Datenschutzproblem mit automatisch erstellten Adressen sowie eine Lösung
Der "automatisch generierte" Hostteil ist weltweit einmalig (mit Ausnahme, wenn der Hersteller einer NIC die gleiche MAC-Adresse bei mehr als einer NIC einsetzt). Die Client-Verfolgung am Host wird dadurch möglich, solange kein Proxy verwendet wird.
Dies ist ein bekanntes Problem und eine Lösung wurde dafür definiert: Datenschutz-Erweiterung, definiert in RFC 3041 / Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (es gibt bereits ein neueres Draft: draft-ietf-ipv6-privacy-addrs-v2-*). Es wird von Zeit zu Zeit mittels eines statischen und eines Zufallswertes ein neues Suffix erstellt. Hinweis: Dies ist nur für ausgehende Client-Verbindungen sinnvoll und bei bekannten Servern nicht wirklich sinnvoll.
Manuell festgelegte Adressen
Bei Servern ist es wahrscheinlich leichter, sich einfachere Adressen zu merken. Dies kann z.B. mit der Zuweisung einer zusätzlichen IPv6 Adresse an ein Interface geschehen.
Für das manuelle Suffix, wie ”::1” im obigen Beispiel, muss das siebte höchstwertige Bit auf 0 gesetzt sein (das universale/local Bit des automatisch generierten Identifiers). Es sind auch noch andere (ansonsten nichtausgewählte) Bit-Kombinationen für Anycast-Adressen reserviert.
Präfixlängen für das Routing
ICMPv6
ICMPv6 - Internet Control Message Protocol für IPv6
Beschreibung
ICMPv6 (Internet Control Message Protocol Version 6) | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Familie | Internetprotokolle | |||||||||||||||||
Einsatzgebiet | Fehlermeldungen, Diagnose, Autoconfiguration, Routing | |||||||||||||||||
|
Das Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) ist die mit IPv6 zusammen verwendete Version des Internet Control Message Protocol
- Es dient, wie schon bei IPv4, in Netzwerken zum Austausch von Fehler- und Informationsmeldungen
- Zusätzlich findet es aber noch im Neighbor Discovery Protocol, dem Ersatz des Address Resolution Protocol, Verwendung
- ICMPv6 zwingend notwendig
Im Gegensatz zum ICMP bei IPv4 ist ICMPv6 zwingend für den Betrieb von IPv6 nötig
- Ein generelles Blockieren von ICMPv6 auf der Firewall führt dazu, dass IPv6 nicht funktioniert (vgl. RFC 4890)
ICMPv6 dient als Hilfsprotokoll für IPv6, ist in derselben OSI-Schicht 3 wie dieses angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten
- Als Protokoll-Nummer wird dabei 58 ins Next-Header-Feld des IPv6-Headers eingefügt
Header
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
… | ICMPv6-Nachricht … |
Das Feld Type gibt die Klasse der ICMP-Nachricht an
- welche mit dem Feld Code genauer spezifiziert werden kann
Die Prüfsumme wird zur Verifizierung der Gültigkeit des ICMPv6-Pakets benutzt
Der restliche Inhalt der ICMP-Nachricht wird durch den jeweiligen Typ bestimmt
- Bei Fehlernachrichten wird nach den möglichen zusätzlichen Feldern immer noch so viel wie möglich vom fehlerverursachenden Paket angehängt
Prüfsumme
0 | IPv6-Absender-Adresse | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | ||||||||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||||||
128 | IPv6-Ziel-Adresse | |||||||||||||||||||||||||||||||
160 | ||||||||||||||||||||||||||||||||
192 | ||||||||||||||||||||||||||||||||
224 | ||||||||||||||||||||||||||||||||
256 | IPv6-Nutzlast-Größe | |||||||||||||||||||||||||||||||
288 | Checksumme 0 | Next Header 58 |
Die Prüfsumme (engl. checksum) eines ICMPv6-Pakets ist ein 16-Bit-Einerkomplement der Summe des Einerkomplements der gesamten ICMPv6-Nachricht
- Zusätzlich zur Nachricht wird noch ein IPv6-Pseudoheader vorne angehängt
- Zur Berechnung der Prüfsumme wird das Prüfsummenfeld auf 0 gesetzt
- Der zur Berechnung der Prüfsumme verwendete Pseudoheader sieht wie im Schema nebenan aus
Dies ist eine der Neuerungen von ICMPv6 gegenüber ICMP, wo die Prüfsumme nur über den ICMP-Header berechnet wurde
Verarbeitung
- Regeln für die Verarbeitung von ICMPv6-Nachrichten
- Unbekannte ICMPv6-Fehlernachrichten müssen an die darüberliegende Netzwerkschicht weitergereicht werden
- Unbekannte ICMPv6-Informationsnachrichten müssen ohne Benachrichtigung des Absenders verworfen werden
- Jeder Fehlernachricht wird am Ende so viel wie möglich des fehlerverursachenden Pakets angehängt
- Die Protokollnummer zum Weiterreichen von unbekannten Fehlernachrichten wird aus dem angehängten Originalpaket entnommen
- Auf folgende Pakete werden keine Fehlernachrichten versandt
- Fehlernachrichten
- Pakete an Multicast-, Link-Level-Multicast- oder Link-Level-Broadcast-Adressen mit folgenden Ausnahmen:
- Packet-Too-Big-Nachrichten
- Parameter-Problem-Nachrichten mit Code 2 – unbekannte IPv6-Option
- Das Netz darf nicht mit ICMPv6-Fehlernachrichten geflutet werden
Nachrichten-Typen
Gruppe | TType | Beschreibung |
---|---|---|
Fehlernachrichten | 0–127 | mit dem höchstwertigen Bit (engl. most significant bit) auf 0, sind Fehlernachrichten |
Informationsnachrichten | 128–255 | mit dem höchstwertigen Bit auf 1, sind Informationsnachrichten |
Fehlernachrichten
Type | Beschreibung | RFC |
---|---|---|
1 | Destination Unreachable | RFC 4443 |
2 | Packet Too Big | RFC 4443 |
3 | Time Exceeded | RFC 4443 |
4 | Parameter Problem | RFC 4443 |
Destination Unreachable
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Unbenutzt | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Destination Unreachable - Type 1
Destination-Unreachable-Nachrichten sollten vom Router erzeugt werden, wenn ein Paket nicht ausgeliefert werden konnte
- Wenn das Paket wegen Überlastung fallen gelassen wurde, muss keine Destination Unreachable versandt werden
Wenn das Paket wegen fehlender Routen nicht ausgeliefert wurde, wird der Code 0 gesetzt
- Ist das Ausliefern administrativ verboten (Firewall), wird der Code 1 gesetzt
- Wenn der Router die IPv6-Adresse nicht auflösen kann, oder ein Problem mit dem Link hat, wird der Code 3 gesetzt
- Wenn ein Zielhost für ein UDP-Paket keinen Listener hat, sollte er ein Destination Unreachable mit Code 4 versenden
Wenn ein Destination Unreachable empfangen wird, muss es der darüberliegenden Schicht weitergereicht werden
Packet Too Big
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | MTU | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Packet Too Big - Type 2
Eine Packet-Too-Big-Nachricht muss vom Router erzeugt werden, wenn ein Paket nicht weitergeleitet werden kann, weil es größer ist als die maximale MTU des Links, über den es versendet werden soll. Packet-Too-Big-Nachrichten werden vom Path MTU Discovery gebraucht, um die pfadabhängige MTU zu ermitteln
Der Code sollte vom Sender auf 0 gesetzt und vom Empfänger ignoriert werden
Wenn ein Packet Too Big empfangen wird, muss es dem darüberliegenden Layer weitergereicht werden
Time Exceeded
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Unbenutzt | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Time Exceeded - Type 3
Wenn ein Router ein Paket mit einem Hop-Limit von 0 erhält, oder den Time-to-Live-Wert auf 0 reduziert, muss er das Paket verwerfen und ein Time Exceeded mit Code 0 an den Absender versenden
- Das zeigt entweder eine Endlosschleife im Routing an oder ein zu kleines anfängliches Hop-Limit
Wenn von einer fragmentierten Nachricht nicht alle Fragmente innerhalb einer gewissen Zeit ankommen, wird das Paket verworfen und es muss ein Time Exceeded mit Code 1 versendet werden
Parameter Problem
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Pointer | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Parameter Problem - Type 4
Wenn ein Host beim Verarbeiten eines IPv6-Pakets ein Problem in einem Feld feststellt und nicht mit der Verarbeitung weiterfahren kann, muss er das Paket verwerfen und eine Parameter-Problem-Nachricht verschicken
Mit dem Code wird dabei die Art des Problems genauer beschrieben
0 | Fehlerhaftes Header-Feld gefunden |
1 | Unbekannter Next-Header-Typ gefunden |
2 | Unbekannte IPv6-Option |
3 | Unvollständiger IPv6 Header Chain im ersten IPv6 Fragment |
Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist
Informationsnachrichten
Type | Beschreibung | RFC |
---|---|---|
128 | Echo Request | RFC 4443 |
129 | Echo Reply|Echo Reply | RFC 4443] |
130 | Multicast Listener Query | RFC 2710 und RFC 3810 |
131 | RFC 2710 | |
132 | Multicast Listener Done | RFC 2710 |
133 | Router Solicitation | RFC 4861 |
134 | Router Advertisement | RFC 4861 |
135 | Neighbor Solicitation | RFC 4861 |
136 | Neighbor Advertisement | RFC 4861 |
137 | Redirect | RFC 4861 |
138 | Router Renumbering | RFC 2894 |
139 | ICMP Node Information Query | RFC 4620 |
140 | ICMP Node Information Response | RFC 4620 |
141 | Inverse Neighbor Discovery Solicitation Message | RFC 3122 |
142 | Inverse Neighbor Discovery Advertisement Message | RFC 3122 |
143 | Version 2 Multicast Listener Report | RFC 3810 |
144 | Home Agent Address Discovery Request Message | RFC 3775 |
145 | Home Agent Address Discovery Reply Message | RFC 3775 |
146 | Mobile Prefix Solicitation | RFC 3775 |
147 | Mobile Prefix Advertisement | RFC 3775 |
148 | Certification Path Solicitation Message | RFC 3971 |
149 | Certification Path Advertisement Message | RFC 3971 |
150 | ICMP messages utilized by experimental mobility protocols such as Seamoby | RFC 4065 |
151 | Multicast Router Advertisement | RFC 4286 |
152 | Multicast Router Solicitation | RFC 4286 |
153 | Multicast Router Termination | RFC 4286 |
155 | RPL Control Message | RFC 6550 |
200 | Private experimentation | |
201 | Private experimentation | |
255 | Reserved for expansion of ICMPv6 informational messages |
Echo Request
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Identifikation | Sequenznummer | ||||||||||||||||||||||||||||||
… | Daten |
- Echo Request - Type 128
Mit einem Echo Request wird um eine Antwort gebeten
- Ein Echo Request ist nichts anderes als ein simpler Ping
- Das Datenfeld kann mit Daten vergrößert werden, um größere Pakete zu produzieren
- So kann man zum Beispiel die MTU ermitteln
Jedes System muss gemäß RFC auf Echo Requests reagieren und mit Echo Replies antworten
- Auch sollte jedes System eine Anwendung zum Versenden und Empfangen von Echo Request/Replies besitzen
- Hiervon wird in der Praxis jedoch oft abgewichen, so blockiert beispielsweise die Windows-Firewall standardmäßig ICMPv6-Echo-Request-Anfragen
Empfangene Echo Request können an Anwendungen weitergeleitet werden, die auf ICMP-Nachrichten horchen
Echo Reply
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Identifikation | Sequenznummer | ||||||||||||||||||||||||||||||
… | Daten |
- Echo Reply - Type 129
Auf eine Echo-Request-Nachricht muss mit einem Echo Reply geantwortet werden
- Das Paket ist bis auf das Typenfeld dasselbe. Echo-Reply-Nachrichten sollen nur an Unicast-Adressen verschickt werden
Anhand der Identifikation und der Sequenznummer wird der Empfänger die Antworten zu seinen Anfragen zuordnen können
Empfangene Echo-Reply-Nachrichten müssen an die Anwendung weitergereicht werden, die den zugehörigen Echo Request versendet hat
- An die restlichen auf ICMP horchende Anwendungen kann es weitergereicht werden
Multicast Listener Discovery
- Multicast Listener Discovery - Type 130
MLD ist die Implementation von IGMP (IPv4) in IPv6
- Es wird also genutzt, um Multicast-Abonnements zu verwalten
- Dabei entspricht MLDv1 IGMPv2 und MLDv2 IGMPv3
- Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast-Streams akzeptabel sind.), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0)
Upper Layer Protokolle
topic - Beschreibung
Beschreibung
DNS
Bedeutung von DNS
Wegen der Länge der IP-Adressen, die an das menschliche Erinnerungsvermögen höhere Anforderungen stellt als IPv4-Adressen, ist IPv6 in besonderem Maße von einem funktionierenden Domain Name System (DNS) abhängig.
AAAA
3596 definiert den Resource Record (RR) Typ AAAA (sprich: Quad-A), der genau wie ein A Resource Record für IPv4 einen Namen in eine IPv6-Adresse auflöst.
Der Reverse Lookup, also die Auflösung einer IP-Adresse in einen Namen, funktioniert nach wie vor über den RR-Typ PTR, nur ist für IPv6 die Reverse Domain nicht mehr IN-ADDR.ARPA wie für IPv4, sondern IP6. ARPA und die Delegation von Subdomains darin geschieht nicht mehr an 8-Bit-, sondern an 4-Bit-Grenzen.
Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen.
Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im Betriebssystem und auf der Anwendungsebene, also z. B. im Browser, einstellbar.
Root-Nameserver
Elf der dreizehn Root-Nameserver und mindestens zwei Nameserver der meisten Top-Level-Domains sind bereits über IPv6 erreichbar.
Das übertragende Protokoll ist unabhängig von den übertragenen Informationen. Insbesondere kann man über IPv4 einen Nameserver nach AAAA-RRs fragen.
Anbieter großer Portalseiten denken jedoch darüber nach, nur DNS-Anfragen, die über IPv6 gestellt werden, auch mit AAAA Resource Records zu beantworten, um Probleme mit fehlerhaft programmierter Software zu vermeiden.
Sicherheit
topic - Beschreibung
Sicherheit des Knoten
Es wird sehr empfohlen alle verfügbaren Patches einzuspielen sowie alle nicht benötigten Dienste zu deaktivieren. Ebenfalls sollten Sie lokales firewalling aktivieren und binden Sie die Dienste ausschließlich an benötigte IPv4/IPv6 Adressen.
Mehr Infos hierzu in späteren Versionen.
Zugangsbeschränkungen
Viele Dienste setzen die tcp_wrapper Bibliothek für die Zugangskontrolle ein. Eine Beschreibung finden Sie unter use of tcp_wrapper.
Mehr Infos hierzu in späteren Versionen.
IPv6 Sicherheitsüberwachung
Aktuell gibt es keine komfortablen Sicherheitstools mit denen man ein System über ein Netzwerk nach IPv6 relevanten Sicherheitslücken hin überprüfen kann. Weder Nessus noch irgendein kommerzieller Security Scanner ist zur Zeit dazu in der Lage, IPv6-Adressen scannen zu können.
Rechtsfragen
ACHTUNG: Bitte stellen Sie immer sicher, dass Sie ausschließlich ihr eigenes Netzwerk scannen oder einen Scan nur nach Erhalt einer schriftlichen Erlaubnis durchführen. Andernfalls haben sie mit rechtlichen Konsequenzen zu rechnen! ÜBERPRÜFEN Sie die Ziel-IPv6-Adresse ZWEIMAL, bevor Sie einen Scan starten.
Sicherheitsüberwachung mit IPv6 fähigen netcat
Mit dem IPv6 fähigen netcat (siehe IPv6+Linux-status-apps/security-auditing für Details) können Sie einen Portscan durchführen. Es wird ein Script abgearbeitet, wobei u.a. ein Port-Bereich überprüft und Banners mitprotokolliert werden. Anwendungsbeispiel:
Sicherheitsüberwachung mit IPv6 fähigen NMap
NMap, einer der weltweit besten Portscanner, unterstützt IPv6 seit der Version 3.10ALPHA1. Anwendungsbeispiel:
Sicherheitsüberprüfung IPv6 fähigen strobe
Strobe ist (im Vergleich zu NMap) ein low budget Portscanner. Allerdings gibt es für Strobe einen IPv6 Patch (siehe IPv6+Linux-status-apps/security-auditing für Details). Anwendungsbeispiel:
Hinweis: strobe wird nicht wirklich weiterentwickelt, die abgebildete Versionsnummer ist zudem falsch.
Sicherheitsüberprüfung mit Online-Werkzeugen
Es gibt einige IPv6-fähige Online-Werkzeuge, welche das Testen einer Firewall-Konfiguration bzgl. eingehenden Verbindungen unterstützen können:
- Tim's Online IPv6 TCP/UDP Port Scanner
- SubnetOnline IPv6 Scanner
Überprüfungsergebnisse
Falls das Ergebnis einer Überwachung nicht Ihren IPv6 Sicherheitsrichtlinien entspricht, schließen Sie die Lücken mit Hilfe der IPv6-Firewall-Funktionalität, z.B. mit netfilter6 (siehe Firewalling/Netfilter6 für Details).
Hinweis: Detailliertere Informationen zum Thema IPv6 Sicherheit finden Sie unter folgenden Links:
- IETF drafts - IPv6 Operations (v6ops)
- RFC 3964 / Security Considerations for 6to4
QoS
IPv6/QoS - IPv6 - Quality of Service
Beschreibung
- IPv6 unterstützt QoS durch die Anwendung von Flow Labels und Traffic Classes.
Vernünftig funktionierendes QoS ist nur an der ausgehenden Schnittstelle eines Routers oder Host möglich, wo der Flaschenhals anfängt. Alles andere bereitet nur Probleme und funktioniert wahrscheinlich nicht so, wie erwartet.
Linux QoS mit ”tc”
Router
topic - Beschreibung
Beschreibung
Migration
IPv6/Migration - Umstieg von IPv4 auf IPv6
Beschreibung
IPv6 wird IPv4 in den nächsten Jahren ablösen
Übergangstechnologie | Beschreibung |
---|---|
Parallelbetrieb | |
Tunnel | |
Übersetzen |
Parallelbetrieb
Verfahren | Beschreibung |
---|---|
Dual-Stack | Netzknoten mit IPv4 und IPv6 |
Dual-Stack Lite (DS-Lite) | Dual-Stack mit globaler IPv6 und Carrier-NAT IPv4 |
Tunnel
Verfahren | Beschreibung |
---|---|
4in6 | IPv4 in IPv6 |
6in4 | IPv6 in IPv4 |
6over4 | Transport von IPv6-Datenpaketen zwischen Dual-Stack Knoten über ein IPv4-Netzwerk |
6to4 | Transport von IPv6-Datenpaketen über ein IPv4-Netzwerk (veraltet) |
AYIYA | Anything In Anything |
6rd | IPv6 rapid deployment |
ISATAP | Intra-Site Automatic Tunnel Addressing Protocol (veraltet) |
Teredo | Kapselung von IPv6-Datenpaketen in IPv4-UDP-Datenpaketen |
Translation
Übersetzung
Verfahren | Beschreibung |
---|---|
NAT64 | IPv4-Adressen in IPv6-Adressen |
464XLAT | IPv4- in IPv6- in IPv4-Adressen |
SIIT | Stateless IP/ICMP Translation |
Firewall
topic - Beschreibung
Beschreibung
Firewall-Funktionalität
Die IPv6 Firewall-Funktionalität ist wichtig; vor allem dann, wenn Sie auf Ihren internen Netzen IPv6 mit globalen IPv6 Adressen einsetzen. In IPv6 werden - im Unterschied zu IPv4, wo interne Hosts automatisch durch private IPv6 Adressen geschützt werden (RFC 1918 / Address Allocation for Private Internets bzw. Google search for Microsoft + APIPA) - globale Adressen verwendet und jeder mit IPv6-Anbindung kann alle internen Knoten, bei denen IPv6 aktiv ist, erreichen.
netfilter6
Von Haus aus unterstützt wird die IPv6-Firewall-Funktionalität im Kernel erst ab Version 2.4+. In älteren 2.2+ Versionen können sie nur mit Protocol 41 das generelle Tunnel von IPv6-in-IPv4-Paketen filtern.
Achtung: Es gibt keine Garantie, dass die beschriebenen Regeln und Beispiele ihr System auch wirklich schützen können!
Beobachten Sie nach der Installation ihr Regelset, siehe Abschnitt Abschnitt 19.3.
Kernels ab Version 2.6.20 (Februar 2007) unterstützen den IPv6-Verbindungsstatus (connection tracking) vollständig.
Kernels ab Version 3.9.0 (April 2013) unterstützen NAT für IPv6 in Verbindung mit ip6tables >= 1.4.18
Kernels ab Version 3.13 (April 2014) unterstützen ein neues Framework namens: nftables
Weitere Informationen
- Netfilter project
- maillist archive of netfilter users
- maillist archive of netfilter developers
- Unofficial status informations
Vorbereitung
Dies ist nur notwendig, wenn der mitgelieferte Kernel und Netfilter nicht den Ansprüchen genügt und neue Featurs bereits verfügbar sind, jedoch noch nicht beinhaltet.
Quellen besorgen
Besorgen Sie sich den aktuellsten Kernel: http://www.kernel.org/
Besorgen Sie sich das aktuellste iptables Paket:
- Source tarball (für Kernel Patches): http://www.netfilter.org/
Quellen entpacken
Wechseln Sie in das Source-Verzeichnis:
Entpacken sie die Kernel-Quellen und vergeben diesen einen neuen Namen
Entpacken Sie die iptables Quellen
Neueste iptables/IPv6-relevante Patches den Kernel-Quellen hinzufügen
Wechseln Sie in das iptables Verzeichnis
Fügen Sie relevante Patches hinzu
Fügen Sie zusätzliche IPv6 relevante IPv6 Patches hinzu (die nach wie vor nicht im Standard-Kernel enthalten sind)
Sagen Sie zu folgenden Optionen (iptables-1.2.2) Ja:
- ah-esp.patch
- masq-dynaddr.patch (nur benötigt bei Systemen mit dynamischer IP-Zuweisung am WAN mittels PPP oder PPPoE)
- ipv6-agr.patch.ipv6
- ipv6-ports.patch.ipv6
- LOG.patch.ipv6
- REJECT.patch.ipv6
Überprüfen Sie die Erweiterungen
Konfiguration, kompilieren und Installation eines neues Kernels
Wechseln Sie zu den Kernel-Quellen
Editieren Sie das Makefile
Starten Sie configure und aktivieren Sie IPv6 relevante Optionen
Konfigurieren Sie bei Bedarf Sonstiges abseits von IPv6.
Kompilieren und Installation: siehe Kapitel Kernel sowie andere HOWTOs.
iptables neu kompilieren und installieren
Stellen Sie sicher, dass obige Kernel-Sourceverzeichnisstruktur unter /usr/src/linux liegt
Benennen sie das ältere Verzeichnis um
Erstellen Sie einen neuen symbolischen Link
Erstellen Sie ein neues SRPMS
Installieren Sie das neue iptables Paket (iptables + iptables-ipv6)
- Bei RH 7.1 Systemen ist normalerweise eine ältere Version hiervon bereits installiert, verwenden Sie daher die Option ”Freshen”:
- Ist keine ältere Version installiert, benutzen Sie die Option ”install”:
- Bei RH 6.2 Systemen ist normalerweise kein Kernel Version 2.4.x installiert und die Anforderungen sind demnach nicht gegeben. Benutzen Sie in diesem Fall ”nodeps”:
Damit iptables die Libraries finden kann, ist es eventuell notwendig, einen symbolischen Link für die iptables Libraries zu erstellen:
Verwendung
Unterstützung im Kernel
Laden Sie das Modul (falls dies im Kernel so kompiliert wurde):
Überprüfen der IPv6-Unterstützung:
Die Benützung von iptables lernen
Auflistung aller netfilter Einträge
- Kurze Auflistung:
- Erweiterte Auflistung:
Auflistung angegebener Filter
Hinzufügen einer Log-Regel zum Input-Filter mit Optionen
Hinzufügen einer Drop-Regel zum Input-Filter
Löschen einer Regel mit Hilfe der Regelnummer
Aktiviere die Auswertung des Verbindungsstatus (connection tracking)
Seit Kernel-Version 2.6.20 ist die Auswertung des IPv6-Verbindungsstatus gut unterstützt. Die bis dahin statuslosen Filterregeln sollten ersetzt werden..
ICMPv6 erlauben
Bei älteren Kernelversionen (unpatched kernel 2.4.5 und iptables-1.2.2) kann keine nähere Spezifizierung des ICMPv6-Typs vorgenommen werden:
- Eingehender ICMPv6 Verkehr durch Tunnel erlauben
- Ausgehenden ICMPv6 Verkehr durch Tunnel erlauben
Neuere Kernel erlauben das Spezifizieren des ICMPv6-Typs:
Rate-limiting
Da es zu einem ICMPv6 Storm kommen kann (der Autor hat dies bereits mehrfach beobachtet), sollten sie das rate limiting zumindest für das ICMP Regelset einsetzen. Zusätzlich sollten auch die Logging Regeln mit rate limiting geschützt werden, um DoS Attacken gegen das syslog sowie gegen die Logdateien enthaltenden Patitionen entgegenzuwirken. Ein Beispiel für ein rate limited ICMPv6 sieht wie folgt aus:
Eingehende SSH-Verbindung erlauben
Im folgenden Beispiel werden eingehende SSH-Verbindungen von einer speziellen IPv6 Adresse zugelassen:
- Eingehende SSH Verbindungen werden von der Adresse 2001:0db8:100::1/128 erlaubt
- Erlaube Antwortpakete (nicht mehr notwendig, wenn der IPv6-Verbindungsstatus ausgewertet wird!)
Getunnelten IPv6-in-IPv4 Datenverkehr erlauben
Um getunnelte IPv6-in-IPv4 Pakete zu akzeptieren, müssen Sie in Ihrem IPv4 Firewall-Setup entsprechende Regeln einzufügen, z.B.
- Akzeptiere eingehende IPv6-in-IPv4 Daten am interface ppp0
- Akzeptiere ausgehende IPv6-in-IPv4 Daten am interface ppp0
Haben Sie nur einen statischen Tunnel, dann können sie die IPv4 Adresse auch dediziert angeben:
- Akzeptiere eingehende IPv6-in-IPv4 Daten vom Tunnel-Endpunkt 192.0.2.2 am interface ppp0
- Akzeptiere ausgehende IPv6-in-IPv4 Daten vom Tunnel-Endpunkt 192.0.2.2 am interface ppp0
Schutz gegen eingehende TCP-Verbindungs-Anfragen
SEHR EMPFOHLEN! Aus Sicherheitsgründen sollten Sie auf jeden Fall eine Regel inkludieren, wodurch eingehende TCP-Verbindungs-Anfragen geblockt werden. Wenn Sie andere Interfacenamen verwenden, müssen Sie die Option "-i" entsprechend anpassen!
- Blockiere eingehende TCP-Verbindungs-Anfragen zu diesem Host
- Blockiere eingehende TCP-Verbindungs-Anfragen zu Hosts hinter diesem Router
Eventuell müssen diese Regeln unterhalb anderer Regeln platziert werden. Nehmen Sie sich für die Reihenfolge der Regeln etwas Zeit. Sinnvoll wird es auch sein, ein Script mit den Regeln zu erstellen, damit die Regeln in der gewünschten Reihenfolge angewandt werden.
Schutz gegen eingehende UDP-Verbindungs-Anfragen
EBENFALLS SEHR EMPHOLEN! Wie bereits im Kapitel Firewall erwähnt, ist es möglich die Ports bei ausgehenden UDP/TCP-Verbindungen zu kontrollieren. Im Falle, dass all Ihre IPv6 Systeme lokale Ports verwenden, z.B. von 32768 bis 60999, dann können sie ebenfalls UDP Verbindungen filtern (bis das Verbindungs-Tracking funktioniert):
- Blockiere eingehende UDP-Pakete, die nicht Antworten ausgehender Anfragen dieses Host sein können
- Blockiere eingehende UDP-Pakete, die nicht Antworten auf Anfragen von hinter diesem Router gelegenen Hosts sein können
Anwendungsbeispiele
Einfaches Beispiel für Fedora
Folgende Zeilen zeigen eine einfache Firewall-Konfiguration für Fedora 6 (ab Kernel-Version 2.6.20). Ausgehend von dem Origina (generiert durch system-config-firewall) wurden Modifikationen für die Unterstützung des Verbindungsstatus und der Rückgabe der passenden ICMPv6-Meldung für Rejects. Eingehende SSH (Port 22) Verbindungen sind erlaubt.
Zwecks der Vollständigkeit ist hier auch die entsprechende Konfiguration für IPv4 gezeigt:
Benutzung:
- Erzeugen/Modifizieren der Konfigurationsdateien
- Aktivieren von IPv4 & IPv6 Firewalling
- Aktivieren des automatischen Starts nach dem Reboot
Umfangreicheres Beispiel
Folgende Zeilen zeigen ein umfangreicheres Setup. Happy netfilter6 Regelset erstellen...
Network Address Translation (NAT) mit netfilter6
Seit mindestens Linux Kernel-Version 3.9.0 und ip6tables ab 1.4.18 kann Network Address Translation (NAT) genutzt werden.
IPv6 Maskierung
Wie bei IPv4 können Systeme hinter einem Router versteckt werden mit Hilfe von IPv6 Maskierung (hide/overlap NAT), z.B.
IPv6 Destination NAT
Eine dedizierte öffentliche IPv6-Adresse kann zu einer internen IPv6-Adresse weitergeleitet werden, z.B.
IPv6 Port Weiterleitung
Ein dedizierter Port kann zu einem internen System weitergeleitet werden, z.B.
Firewall-Setup mit nftables
Mit nftables wurde die Unterstützung einer Tabelle names ”inet” eingeführt in welcher Regeln für IPv4/IPv6 gleichzeitig gelten
Präparation zur Nutzung von nftables
Installieren einer Linux-Distribution, welche die Unterstützung für nftables bereits eingebaut hat. Beim Schreiben dieses Absatzes (Mai 2014) war mindestens Fedora Rawhide (Vorläufer der Version 21) mit entsprechendem Support und nftables version 0.2.0 versehen.
Basis-nftables Konfiguration
Laden der Kernel-Module:
Löschen der Regeln in iptables and ip6tables um Interferenzen zu vermeiden:
Erzeugen der Filter-Tabelle:
Erzeugen einer input chain in der Filter-Tabelle:
Einfache Filter-Policy mit nftables
Konfiguration
Erlauben von Paketen, die zu existierenden Einträgen in der Connection-Tracking-Tabelle gehören
Erlauben von IPv4 und IPv6 ICMP echo-request (aka ping)
Erlauben einiger wichtiger IPv6 ICMP Pakete, ohne Zähler, dafür mit Hop-Limit-Prüfung (erhöht die Sicherheit)
Erlauben von eingehenden SSH-Verbindungen für IPv4 und IPv6
Reject/drop anderer Pakete
Ergebnis
Tabelle für IP unabhängigen Filter
Tipps für's Loggen
Für Logging wird ein zusätzliches Kernelmodul benötigt:
ACHTUNG, MOMENTAN KANN DER LOG-LEVEL NICHT ANGEGEBEN WERDEN, dadurch werden nftables-Ereignisse mit Log-Level kern.emerg ausgegeben - ES BESTEHT DIE GEFAHR, DASS DIE KONSOLE DADURCH ÜBERFLUTET WIRD!
Für erste Tests mit der Log-Option kann es nützlich sein, das Loggens für emergency-Ereignisse in z.B. /etc/rsyslog.conf zu deaktivieren mit Hilfe eines ”#” am Anfang der Zeile und Neustart des logging-Daemons
Regel von oben, welche SSH auf Port 22 erlaubt, nun mit Logging:
Filter-Policy mit nftables unter Benutzung der Tablellen ”ip”, ”ip6” und ”inet”
Wie oben schon beschrieben, wenn die Regeln in den einzelnen Tabellen konfiguriert werden, muss gesichert sein, dass frühere ”accepts” nicht aufgehoben werden. Eine einfache Lösung ist die Benutzung von Markierungen. Regeln, die Pakete erlauben, setzen die Marke mit ”meta mark set xxxx”. Eine generische Regel erlaubt Pakete mit gesetzter Marke ”mark xxxx”. Beispiel für ein resultierendes Filter-Regelwerk:
Tunnel
topic - Beschreibung
Beschreibung
Ein Tunnelbroker ist im Bereich der Computernetzwerke ein Dienst, der Tunnel bereitstellt, die zum Beispiel dazu genutzt werden können, Verkehr gesichert (Virtual Private Network) oder verkapselt zu transportieren, um z. B. IPv6 über ein IPv4-Netzwerk zu transportieren
Obwohl es mehrere Arten von Tunnelbrokern gibt, werden damit meist Broker bezeichnet, die Tunnel bereitstellen, die es ermöglichen, IPv6-Pakete über alte IPv4-Infrastruktur zu routen (RFC 3053), allerdings kann es auch IPv4-Tunnelbroker geben, die IPv4-Pakete über IPv6-Infrastruktur leiten
- Um IPv6 über IPv4 zu leiten, werden verschiedene Methoden wie 6in4, 6over4, 6to4 oder 6rd verwendet
- Heutzutage wird häufig Dual-Stack verwendet, bei dem sowohl IPv4 und IPv6 unabhängig voneinander verwendet werden
Automatische Konfiguration
Normalerweise werden IPv6-Tunnel über das Tunnel Setup Protocol oder Tunnel-Information-Control-Protokoll konfiguriert und erstellt
- Oft wird ein Tunnel jedoch manuell konfiguriert
Probleme mit Network Address Translation und Routern
- Protokoll-41-Tunnel, wobei IPv6 direkt in IPv4 verpackt wird, funktionieren hinter NATs eventuell nicht mehr zuverlässig
- Mit vielen modernen Routern gibt es allerdings keine Probleme
- Umgehen kann man auftretende Probleme, indem man den Endpunkt entweder in eine Demilitarisierte Zone legt oder gleich auf das NAT-Gerät; moderne Router für den Heimeinsatz, die IPv6-fähig sind, unterstützen dies inzwischen
- Ebenfalls möglich ist der Gebrauch von AYIYA oder TSP (Tunnel Setup Protocol), die IPv6-Pakete in UDP-Pakete verpacken
- Diese können die meisten Firewalls problemlos passieren (vorausgesetzt, es gibt keine verbietende Regel)
- Ein Problem, das immer noch auftreten kann, ist, dass eine NAT-Regel aus der Tabelle entfernt wird, obwohl die Verbindung noch besteht
- Falls dann von außen Pakete für den Tunnel ankommen, kann der Router diese nicht mehr weiterleiten und verwirft sie
- Das unterbricht die Tunnelverbindung, bis der Nutzer wieder ein Paket durch den Tunnel sendet
- Ältere (Heim-)Router routen teilweise generell keine Protokoll-41-Pakete
Dynamische Endpunkte
Falls der Client-Endpunkt des Tunnels eine dynamische IP-Adresse besitzt (wie bei Privatkunden-Breitbandanschlüssen), dann muss der Kunde den Tunnelbroker immer bei einer Änderung über die neue IP-Adresse informieren
- Das geschieht entweder manuell über die Website des Tunnelbrokers oder über ein automatisches Protokoll wie TSP oder Heartbeat
Andere Tunnelbroker erlauben eine komfortable webbasierte Lösung, bei der eine vorgegebene URL aufgerufen wird, in der Nutzername, Passwort und der Hostname oder die ID des Tunnels enthalten sind. Über die IP des Aufrufers (der Server für diese Lösung ist über IPv4 angebunden) kann der Endpunkt aktualisiert werden
tunnelbroker.net
Hurricane Electric bietet einen kostenlosen tunnel broker Dienst an, der unter Arch relativ einfach zu benutzen ist, wenn Sie einem IPv4-Host IPv6-Konnektivität hinzufügen möchten
Registrierung für einen Tunnel
Gehen Sie auf die Tunnelbroker-Site und füllen Sie die Registrierung aus
Einrichten des Hurricane Electric-Tunnels
- Erstellen Sie die folgende systemd-Unit und ersetzen Sie den fettgedruckten Text durch die IP-Adressen, die Sie von HE erhalten haben
- Hinweis
- Wenn Sie sich hinter einem NAT befinden (typische Heimrouter-Einrichtung), verwenden Sie Ihre lokale IPv4-Adresse für client_IPv4_address, z.B. 192.168.0.2
- /etc/systemd/system/he-ipv6.service
[Einheit] Beschreibung=he.net IPv6-Tunnel Nach=network.target
[Service] Typ=oneshot RemainAfterExit=yes ExecStart=/usr/bin/ip tunnel add he-ipv6 mode sit remote server_IPv4_address local client_IPv4_address ttl 255 ExecStart=/usr/bin/ip link set he-ipv6 up mtu 1480 ExecStart=/usr/bin/ip addr add client_IPv6_address dev he-ipv6 ExecStart=/usr/bin/ip -6 route add ::/0 dev he-ipv6 ExecStop=/usr/bin/ip -6 route del ::/0 dev he-ipv6 ExecStop=/usr/bin/ip link set he-ipv6 down ExecStop=/usr/bin/ip tunnel del he-ipv6
[Install] WantedBy=multi-user.target
- Dann start/enable he-ipv6.service
systemd-networkd
- Wenn systemd-networkd Ihre Netzwerkverbindungen verwaltet, ist es wahrscheinlich eine bessere Idee, ihn auch den Tunnelbroker verwalten zu lassen (anstatt eine .service-Datei zu verwenden)
- /etc/systemd/network/he-tunnel.netdev
[Match]
[NetDev] Name=he-ipv6 Kind=sit MTUBytes=1480
[Tunnel] Lokal=<lokale IPv4> Entfernt=<Tunnel-Endpunkt> TTL=255
- /etc/systemd/network/he-tunnel.network
[Match] Name=he-ipv6
[Netzwerk] Adresse=<lokale IPv6> Gateway=<IPv6-Gateway> DNS=2001:4860:4860::8888 DNS=2001:4860:4860::8844
Und fügen Sie diese Zeile in den Abschnitt "[Network]</nowiki>" Ihrer Standard-Internetverbindungsdatei "'.network" ein
Tunnel=he-ipv6
Verwendung des Tunneling mit dynamischer IPv4 IP
Aktualisierung über Cronjob
- Der einfachste Weg, das Tunneln mit einer dynamischen IPv4-IP zu nutzen, besteht darin, einen Cronjob einzurichten, der Ihre aktuelle Adresse regelmäßig aktualisiert
- Die Beispiel-URL und einen Update Key finden Sie auf der Registerkarte Advanced der Seite Tunnel Details
- Um zu überprüfen, ob die Aktualisierung funktioniert, führen Sie den folgenden Befehl aus (ersetzen Sie USERNAME, UPDATEKEY und TUNNELID durch die Angaben zu Ihrem Konto und Ihrem Tunnel)
wget -O - https://USERNAME:UPDATEKEY@ipv4.tunnelbroker.net/nic/update?hostname=TUNNELID
- Wenn es funktioniert, erstellen Sie einen Cronjob, indem Sie crontab -e öffnen und eine neue Zeile hinzufügen
*/10 * * * * wget -q -O /dev/null https://USERNAME:UPDATEKEY@ipv4.tunnelbroker.net/nic/update?hostname=TUNNELID
Aktualisieren über ddclient
- Alternativ kann dies auch durch die Installation von ddclient und die Konfiguration von /etc/ddclient.conf konfiguriert werden
protocol=dyndns2 use=web web=checkip.dns.he.net server=ipv4.tunnelbroker.net ssl=ja anmeldung=BENUTZERNAME passwort=UPDATEKEY TUNNELID
Und schließlich start/enable ddclient.service
Setting up a tunnelbroker.net IPv6 tunnel on Debian
Things you need to find out first
The IP address you plan to use the tunnel from (e.g. your current IP, or the IP of the server you want to set this up on) - $yourip
Getting a tunnelbroker account
- Hit the registration page and sign up
- Wait for the confirmation email, then login
- From the (left-hand-side) “User Functions” menu click “Create Regular Tunnel”
- Enter the IP you want to use the tunnel from
- Pick a host near the machine with that IP - the closer it is, the shorter the path your IPv6 packets will have to take to hit the IPv6 Internet
Configure your machine to use the tunnel
Pick a name for the tunnel - it is just used as the interface name on Linux. Let’s say sit1
. Now click on the your new tunnel, and you’ll be on the “Tunnel details” page
Open up /etc/network/interfaces:
auto sit1
iface sit1 inet6 v4tunnel
address $address
netmask 64
local $yourip
endpoint $endpoint
up ip route add 2000::0/3 via $theirip dev sit1
Where:
$address
is the value of “Client IPv6 address”
$yourip
is the local IP address
$endpoint
is the value of “Server IPv4 address”
$theirip
is the value of “Server IPv6 address”, with the /64 removed
Test
Ping
Make sure iputils-ping
is installed (sudo aptitude install iputils-ping
, if it isn’t), then try ping6 www.kame.net
in a terminal::
PING www.kame.net(orange.kame.net) 56 data bytes
64 bytes from orange.kame.net: icmp_seq=1 ttl=54 time=126 ms
Web
If you are setting this up on your desktop, visit Kame using your browser. If this is on a server, use ssh -D1027 yourserver
(via ipv4, of course) on your local machine to create a SOCKS proxy, tell your browser to use localhost:1027
as a SOCKS proxy, then visit Kame in your browser. If the tortoise is dancing, you’re done
IPv6 Tunnel unter Debian mit Tunnelbroker.net
Da es ja bald (TM) nur noch IPv6 Adressen gibt, wollte ich damit schon mal frühzeitig etwas herumspielen
Die Frage war nur wie, den natives IPv6 bekommt man nicht von jedem Provider, und als privater DSL Nutzer schon mal garnicht
- Aber eine Lösung gibt es dennoch, sie heißt IPv6 Tunnel
- Dabei wird der komplett IPv6 Traffic in IPv4 Pakete verpackt und zu einem Tunnelserver geschickt, der das ganze Entpackt und ins IPv6 Internet weiterleitet
- Insgesamt eine schöne Sache, und es gibt kostenlose Dienste die einen solchen Service anbieten
- Einer ist tunnelbroker.net, hier kann man sich Registrieren und bekommt dann Ipv6 Adressen und die Daten zu einem Tunnel Server
Einrichtung Debian
/etc/network/interfaces folgenden Eintrag hinzugefügt:
#IPv6 TUNNEL auto 6in4 iface 6in4 inet6 v4tunnel address 2001:470:1f0a:cf7::2 #Zugewiesene Addresse des eigenen Endpunkts netmask 64 endpoint 216.66.80.30 #IPv4 Adresse des Tunnelservers auf der anderen Seite gateway 2001:470:1f0a:cf7::1 # IPv6 Adresse des Tunnelservers der anderen Seite up ip route add ::/0 dev 6in4
Dann speichern und man kann danach mit
ifup 6in4 #Tunnel anfahren ifdown 6in4 #Tunnel herrunterfahren
Subnetting
topic - Beschreibung
Beschreibung
- Wie bei IPv4 können IPv6-Adressen mittels Subnetzmasken (subnet masks) in einen Netz- und einen Host-Teil unterteilt werden
Präfixlängen für das Routing
Um eine maximale Reduktion an Routing-Tabellen zu erzielen, war in der frühen Design-Phase noch ein vollkommen hierarchischer Routing-Ansatz vorgesehen. Die Überlegungen hinter diesem Ansatz waren die gegenwärtigen IPv4 Routing-Einträge in den Haupt-Routern (mit über 400.000 Einträgen im Jahr 2013) sowie die Reduktion des Speicherbedarfs für die Routing-Tabellen bei Hardware-Routern (ASIC ”Application Specified Integrated Circuit”, speziell konstuierter Chip) sowie ein daraus resultierender Geschwindigkeitszuwachs (weniger Einträge ergeben hoffentlich schnellere Abfragen).
Heutiger Standpunkt ist, dass das Routing für Netzwerke mit nur einem Service Provider hauptsächlich mit einem hierarchischen Design realisiert wird. Eine solche Vorgehensweise ist nicht möglich, wenn mehr als eine ISP-Verbindung besteht. Diese Problematik wird unter dem Thema multi-homing diskutiert (Infos zu multi-homing: drafts-ietf-multi6-*,IPv6 Multihoming Solutions).
Präfixlängen (netmasks)
Vergleichbar zu IPv4, handelt es sich hierbei um den routbaren Netzwerkpfad für das stattfindende Routing. Da die Standard-Notierung der Netzmaske von 128 bit nicht sehr fein aussieht, verwenden die Designer das aus IPv4 bekannte Classless Inter Domain Routing Schema (CIDR, RFC 1519 / Classless Inter-Domain Routing). Mit Hilfe des CIDR wird die Bitanzahl der IP Adresse festgelegt, welche für das Routing verwendet werden. Diese Methode wird auch als "Slash"-Notation genannt.
Ein Beispiel:
Diese Notation wird erweitert zu:
- Netzwerk:
- Netzmaske:
Zutreffende Routen
Im Normalfall (ohne QoS) ergibt eine Suche in der Routing-Tabelle eine Route mit der signifikantesten Adress-Bit-Anzahl, d.h. jene Route mit der größten Präfix-Länge wird zuerst herangezogen.
Wenn z.B. eine Routing-Tabelle folgende Einträge zeigt (Liste ist nicht komplett):
Die gezeigten Zieladressen der IPv6 Pakete werden über die entsprechenden Geräte geroutet