theo/hwr-notes
1
0
Fork 0
mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-06 03:01:08 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
hwr-notes/Netzwerke/zusammenfassungen/nw4 - zusammenfassung.md
theoleuthardt 850aa3455d docs: add obsidian hwr docs
2026-04-09 11:24:56 +02:00

794 lines
32 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# IT2221 – Netzwerktechnik: Vorlesung 4
**Dozentin:** Gabriele Schrenk | **Datum:** 13.03.2026 | **Hochschule:** HWR Berlin (EANTC)
---
## Inhaltsübersicht
1. [OSPF Areas & Route Summarization](#1-ospf-areas--route-summarization)
2. [Zusammenfassen von Routen (IPv4)](#2-zusammenfassen-von-routen-ipv4)
3. [IPv6 – Grundlagen & Motivation](#3-ipv6--grundlagen--motivation)
4. [IPv6-Header](#4-ipv6-header)
5. [IPv6-Adressierung](#5-ipv6-adressierung)
6. [IPv6-Adresstypen](#6-ipv6-adresstypen)
7. [ICMPv6 & Neighbor Discovery](#7-icmpv6--neighbor-discovery)
8. [Migration von IPv4 zu IPv6](#8-migration-von-ipv4-zu-ipv6)
9. [Layer 7 – DHCP](#9-layer-7--dhcp)
10. [Weitverkehrsnetze (WAN)](#10-weitverkehrsnetze-wan)
11. [PPPoE & DSL](#11-pppoe--dsl)
---
## 1. OSPF Areas & Route Summarization
### OSPF Areas
OSPF (Open Shortest Path First) nutzt **Areas**, um große Netzwerke hierarchisch zu strukturieren.
- **Areas verbergen Topologien** vor anderen Areas → reduziert Overhead
- **Kleinere LSDBs** (Link-State Databases) → weniger Belastung auf den Routern
- Jede Area hat eine eigene Topologie-Datenbank; nur zusammengefasste Routen werden über Area-Grenzen hinweg ausgetauscht
**Wichtige Router-Rollen:**
|Router-Typ|Abkürzung|Funktion|
|---|---|---|
|Area Border Router|**ABR**|Vermittelt zwischen verschiedenen OSPF Areas. Gehört zu mindestens zwei Areas (eine davon ist immer Area 0 / Backbone).|
|Autonomous System Border Router|**ASBR**|Empfängt Routing-Informationen aus **anderen Routing-Protokollen** (z. B. BGP, RIP) und leitet sie ins OSPF-Netz ein.|
Die **Backbone Area** (Area 0, 0.0.0.0) ist das Zentrum: Alle anderen Areas müssen direkt oder über virtuelle Links mit ihr verbunden sein.
### ABR/ASBR Route Summarization
ABR und ASBR können Netzwerkadressen und deren Kosten **zusammenfassen** (Route Summarization / Route Aggregation).
**Vorteile der Zusammenfassung:**
- Möglichst **wenige Routen** in der Routing-Tabelle
- **Spart Ressourcen** (CPU, RAM) auf Routern ein
- **Schnellere Konvergenz** – Änderungen in einem Subnetz führen nicht zu Updates in der gesamten Routing-Tabelle
- **Verbergen von Netzdetails** – interne Topologie bleibt hinter der Zusammenfassung versteckt
- **Unempfindlichkeit** gegen Zustandsänderungen einzelner Routen
**Zwei Arten der Zusammenfassung:**
1. **Inter-area route summarization** – Zusammenlegen von Netzwerkadressen, die innerhalb eines Autonomous Systems (AS) liegen. Wird auf ABRs konfiguriert.
2. **External route summarization** – Netzwerkadressen, die von außen in ein AS integriert wurden (z. B. über Redistribution), werden zusammengelegt. Wird auf ASBRs konfiguriert.
---
## 2. Zusammenfassen von Routen (IPv4)
### Algorithmus
1. **Netze in Binärdarstellung umwandeln**
2. **Anzahl der identischen Bits** (von links nach rechts) bestimmen → das wird die neue Präfixlänge
3. **Prüfen**, ob nur die gewünschten Netze in der Zusammenfassung enthalten sind
4. Falls ungewünschte Netze mit eingeschlossen würden → **weitere Bits hinzufügen**, bis nur die gewünschten Netze abgedeckt sind
5. **Restliche Netze** separat behandeln und den Prozess von vorne beginnen
> **Wichtig:** Die zusammengefassten Netze müssen logisch zum **gleichen Next Hop / gleichen Interface** führen!
### Beispiel 1: Einfache Zusammenfassung
Gegeben: 172.16.0.0/24 bis 172.16.3.0/24
```
172.16.0.0: 1010 1100.0001 0000.0000 00|00.0000 0000
172.16.1.0: 1010 1100.0001 0000.0000 00|01.0000 0000
172.16.2.0: 1010 1100.0001 0000.0000 00|10.0000 0000
172.16.3.0: 1010 1100.0001 0000.0000 00|11.0000 0000
↑
Erste 22 Bits identisch
```
**Ergebnis:** `172.16.0.0/22` – Die ersten 22 Bits sind bei allen vier Netzen gleich, die letzten 2 Bits im dritten Oktett variieren (00, 01, 10, 11 = genau 4 Netze).
### Beispiel 2: Nicht-triviale Zusammenfassung
Gegeben: 192.168.0.0/24 bis 192.168.9.0/24
Hier ist eine **einzelne Zusammenfassung nicht möglich**, ohne ungewünschte Netze (192.168.10.0 bis 192.168.15.0) einzuschließen.
```
192.168.0.0: ...0000 0|000.0000 0000 ─┐
... ├─ Erste 21 Bits identisch
192.168.7.0: ...0000 0|111.0000 0000 ─┘
→ Zusammenfassung: 192.168.0.0/21
192.168.8.0: ...0000 100|0.0000 0000 ─┐
192.168.9.0: ...0000 100|1.0000 0000 ─┘ Erste 23 Bits identisch
→ Zusammenfassung: 192.168.8.0/23
```
**Ergebnis:** Zwei Zusammenfassungen nötig:
- `192.168.0.0/21` (deckt .0 bis .7 ab)
- `192.168.8.0/23` (deckt .8 und .9 ab)
### Beispielaufgabe aus der Vorlesung
**Gegeben:**
- 192.168.160.0/24
- 192.168.161.0/24
- 192.168.162.0/23
- 192.168.164.0/22
**Lösung:**
```
192.168.160.0: ...1010 0|000.0000 0000
192.168.161.0: ...1010 0|001.0000 0000
192.168.162.0: ...1010 0|010.0000 0000
192.168.164.0: ...1010 0|100.0000 0000
```
Alle Netze liegen im Bereich 160–167 (drittes Oktett Bits: 1010 0xxx). Die ersten 21 Bits sind identisch.
**Ergebnis:** `192.168.160.0/21`
### Gruppenaufgabe
**Gegeben:**
- 172.30.31.0/24
- 172.30.32.0/24
- 172.30.33.0/24
- 172.30.34.0/23
- 172.30.36.0/23
- 172.30.38.0/24
**Lösung (Schritt für Schritt):**
172.30.31.0 hat das dritte Oktett `0001 1111` – das passt nicht in eine Gruppe mit den anderen (die alle `0010 xxxx` haben), weil eine Zusammenfassung zu viele ungewünschte Netze einschließen würde.
```
172.30.31.0: ...0001 1111.0000 0000 → Einzeln: 172.30.31.0/24
172.30.32.0: ...0010 00|00.0000 0000 ─┐
172.30.33.0: ...0010 00|01.0000 0000 ├─ 22 Bits identisch
172.30.34.0: ...0010 00|10.0000 0000 ─┘
→ Zusammenfassung: 172.30.32.0/22
172.30.36.0: ...0010 01|00.0000 0000 → 172.30.36.0/23
172.30.38.0: ...0010 01|10.0000 0000 → 172.30.38.0/24
```
**Ergebnis:** 4 Zusammenfassungen:
- `172.30.31.0/24`
- `172.30.32.0/22`
- `172.30.36.0/23`
- `172.30.38.0/24`
### Hilfstabelle: Bit-Wertigkeiten im Oktett
|2⁷|2⁶|2⁵|2⁴|2³|2²|2¹|2⁰|
|---|---|---|---|---|---|---|---|
|128|64|32|16|8|4|2|1|
---
## 3. IPv6 – Grundlagen & Motivation
### Warum IPv6?
- **IPv4-Adressraum zu klein:** 2³² = ca. 4,3 Milliarden Adressen – bei über 8 Milliarden Menschen und einem Vielfachen an Geräten nicht ausreichend
- **IPv4-Adressen ungleich verteilt** auf der Welt (historisch bedingte Vergabe)
- **IPv6-Adressraum:** 2¹²⁸ = ca. 3,4 × 10³⁸ Adressen – praktisch unerschöpflich
### Merkmale von IPv6
- Spezifiziert im **Dezember 1995** von der IETF in **RFC 1883** (aktuell RFC 8200)
- Weiterentwicklung von IPv4 mit folgenden Verbesserungen:
- **Vereinfachtes Protokollformat** (keine Header-Checksumme mehr)
- **Dienstgüte (QoS)** – Flow Label im Header
- **Sicherheitsmechanismen** – IPSec war ursprünglich verpflichtend
- **Erweitertes Routing** – Extension Headers statt fester Felder
- **Koexistenz:** IPv6 existiert parallel mit IPv4 (Dual Stack)
- **128-Bit-Adressen** ermöglichen:
- Größeren Adressraum
- Bildung mehrerer Hierarchiestufen
- Verschiedene Adresstypen (Unicast, Multicast, Anycast)
- Neue Diensteadressierung
- **DNS bleibt gültig** (AAAA-Records für IPv6)
- **Autokonfiguration** der Endgeräte (SLAAC)
### Eigenschaften des IPv6-Headers
- **Stark vereinfachter Protokollkopf** – keine Checksumme mehr (Prüfung wird von Layer 2 und 4 übernommen)
- Enthält nur **grundlegende Informationen** zur Weiterleitung
- **Feste Headerlänge von 40 Byte** (nicht 48 wie auf der Folie angegeben – die 48 Byte schließen möglicherweise Padding ein) ermöglicht schnelles Routing
- Trotz **vierfacher Adresslänge** (16 Byte statt 4 Byte) nur **doppelte Headerlänge** gegenüber IPv4 (20 Byte)
- **Verschlüsselung** möglich (IPSec)
- **Quality of Service** über Traffic Class und Flow Label
- **Aktuell (2024):** ca. 30–60% der Netze weltweit auf IPv6 migriert
---
## 4. IPv6-Header
### Aufbau des Basis-Headers (40 Byte fest)
```
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address (128 Bit) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address (128 Bit) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
|Feld|Bits|Beschreibung|
|---|---|---|
|**Version**|4|Immer `6` für IPv6|
|**Traffic Class**|8|Enthält DSCP (Differentiated Services Code Point) und ECN (Explicit Congestion Notification) für QoS|
|**Flow Label**|20|Identifiziert einen Datenfluss (z. B. eine TCP-Verbindung oder einen Stream). Ermöglicht Routing-Entscheidungen nur anhand des Flow Labels.|
|**Payload Length**|16|Länge des Rests des Pakets **nach dem Header** in Byte|
|**Next Header**|8|Gibt an, welches Protokoll bzw. welcher Extension Header als nächstes folgt (z. B. 6 = TCP, 17 = UDP, 43 = Routing Header)|
|**Hop Limit**|8|Entspricht der TTL aus IPv4 – wird bei jedem Router um 1 heruntergezählt, Paket wird bei Wert 0 verworfen|
|**Source Address**|128|Quelladresse|
|**Destination Address**|128|Zieladresse|
### Extension Headers (Erweiterungsköpfe)
IPv6 verwendet eine **verkettete Liste von Headern** statt fester Felder. Jeder Extension Header enthält ein „Next Header"-Feld, das auf den nächsten Header zeigt.
|Extension Header|Next Header Wert|Beschreibung|
|---|---|---|
|Hop-by-Hop Options|0|Optionen, die von **jedem** Gerät auf dem Pfad geprüft werden|
|Routing|43|Routenvorgabe (z. B. SRv6 Segment Routing Header, Typ 4)|
|Fragment|44|Parameter für Fragmentierung (nur beim Sender, nicht auf dem Pfad!)|
|Authentication Header (AH)|51|Authentizität und Integrität des Pakets|
|ESP (Encapsulating Security Payload)|50|Verschlüsselte Datenübertragung|
|Destination Options|60|Optionen, die nur vom **Ziel** geprüft werden|
|Mobility|135|Mobile IPv6|
|Host Identity Protocol|139|HIPv2|
|Shim6 Protocol|140|Multihoming|
**Beispiel der Verkettung:**
- IPv6 Header (Next Header = 43) → Routing Header (Next Header = 60) → Destination Options (Next Header = 6) → TCP Header → Payload
### IPv6 im Ethernet-Frame
- **IPv6** nutzt den Ethernet Protocol ID (EtherType): **0x86DD**
- **IPv4** nutzt den Ethernet Protocol ID (EtherType): **0x0800**
```
| Dest MAC | Source MAC | 0x86DD | IPv6 Header and Payload |
| Dest MAC | Source MAC | 0x0800 | IPv4 Header and Payload |
```
---
## 5. IPv6-Adressierung
### Darstellungsregeln
IPv6-Adressen sind **128 Bit** lang und werden in **hexadezimaler Notation** dargestellt:
- **8 Blöcke** à 4 Hex-Zeichen (= 16 Bit pro Block)
- Blöcke getrennt durch **Doppelpunkt** `:`
- **Führende Nullen** innerhalb eines Blocks dürfen weggelassen werden
- **Aufeinanderfolgende Nullblöcke** können durch `::` zusammengefasst werden (**maximal 1× pro Adresse!**)
**Beispiel:**
```
Vollständig: 2001:0000:0001:0002:0000:0000:0000:ABCD
Gekürzt: 2001:0:1:2:0:0:0:ABCD
Maximal: 2001:0:1:2::ABCD (3 Nullblöcke durch :: ersetzt)
```
### Adressstruktur
Eine IPv6-Adresse besteht aus zwei Hälften:
```
|←────────── 64 Bit ──────────→|←────────── 64 Bit ──────────→|
| Netz-Präfix | Interface ID |
```
### IPv6 Subnetting
- Funktioniert wie bei IPv4, nur mit 128 Bit Adresslänge und Hex-Schreibweise
- CIDR-Notation wird verwendet: z. B. `2001:0db8:85a3::/64`
- Subnetting bleibt auch bei IPv6 relevant
### Routenzusammenfassung bei IPv6
**Beispiel:** Zusammenfassung von drei /64-Netzen:
```
2001:0db8:85a3:0001::/64 → ...0000 0000 0001 (Hex: 0001)
2001:0db8:85a3:0002::/64 → ...0000 0000 0010 (Hex: 0002)
2001:0db8:85a3:0003::/64 → ...0000 0000 0011 (Hex: 0003)
```
Die ersten **62 Bits** sind identisch (die letzten 2 Bits des 4. Blocks variieren: 01, 10, 11).
**Ergebnis:** `2001:0db8:85a3:0000::/62`
**Vorteile:**
- Effizientere Nutzung des Adressraums
- Weniger Routing-Tabellen-Einträge
- Bessere Routing-Effizienz
- Vereinfachtes Netzwerkmanagement
### Adressierungsschema
- IPv6-Adresse mit allen Bits auf 1: `FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`
- IPv4-Adresse mit allen Bits auf 1: `255.255.255.255` = `FFFF:FFFF` (nur 32 Bit)
---
## 6. IPv6-Adresstypen
### Spezielle Adressen
|Adresse|Beschreibung|
|---|---|
|`::1` (= 0:0:0:0:0:0:0:1)|**Loopback** – Entspricht 127.0.0.1 bei IPv4|
|`::` (= 0:0:0:0:0:0:0:0)|**Unspecified** – Wird vor der Adresszuweisung verwendet, darf nicht als Zieladresse genutzt werden|
|`::/0`|**Default Route** – Entspricht 0.0.0.0/0 bei IPv4|
### Interface Identifiers (EUI-64)
Der Host-Teil einer IPv6-Adresse (die letzten 64 Bit) kann automatisch aus der **MAC-Adresse** generiert werden:
1. MAC-Adresse (48 Bit) wird in **zwei 3-Byte-Blöcke** geteilt
2. Zwischen beiden Blöcken wird **FFFE** eingeschoben (→ 64 Bit)
3. Das **Universal/Local Bit** (2. Bit des ersten Bytes) wird invertiert
**Beispiel:**
```
MAC: 00:90:27:17:FC:0F
Teilen: 00:90:27 | 17:FC:0F
FFFE: 00:90:27:FF:FE:17:FC:0F
U/L-Bit: 02:90:27:FF:FE:17:FC:0F (Bit 2 von 00 → 02)
```
**Privacy Extension:** Zufällig generierte Interface IDs statt EUI-64 zum Schutz der Privatsphäre (verhindert Tracking über die MAC-Adresse).
### Unicast-Adresstypen
#### Global Aggregatable Unicast Adressen (2000::/3)
Für die **weltweite Kommunikation** im Internet. Über verschiedene Netzwerke hinweg routbar.
```
|←── 48 Bit ──→|←16 Bit→|←────────── 64 Bit ──────────→|
| Global Prefix | Subnet | Interface ID |
| (vom ISP) | ID | |
```
- **Global Prefix** (48 Bit): Von der IANA → RIR → ISP zugewiesen
- **Subnet ID** (16 Bit): Vom Netzwerkadministrator vergeben → bis zu 65.536 Subnetze
- **Interface ID** (64 Bit): Identifiziert das Interface (EUI-64 oder zufällig)
#### Link-Local Unicast Adressen (FE80::/10)
Für die **lokale Kommunikation** innerhalb eines Netzwerksegments.
```
|←────────── 64 Bit ──────────→|←────────── 64 Bit ──────────→|
| FE80:0000:0000:0000 | Interface ID |
```
- Prefix ist immer **FE80::/64**
- Werden **nicht geroutet** – bleiben im lokalen Netz
- Werden für die **Autokonfiguration** und das Neighbor Discovery Protocol verwendet
- Jedes IPv6-fähige Interface hat automatisch eine Link-Local-Adresse
#### Vergleichstabelle
|Merkmal|Global Aggregatable Unicast|Link-Local Unicast|
|---|---|---|
|**Präfix**|2000::/3|fe80::/10|
|**Verwendung**|Kommunikation im Internet|Kommunikation im LAN|
|**Routing**|Ja, weltweit routbar|Nein, nicht routbar|
|**Zuweisung**|Von ISPs zugewiesen|Automatisch, lokal|
|**Beispiel**|2001:0db8:85a3::8a2e:0370:7334|fe80::1a2b:3c4d:5e6f|
IPv6-Adressen werden von der **IANA** (Internet Assigned Numbers Authority) oder regionalen Stellen (RIPE NCC für Europa) zugewiesen.
### Anycast Adressen
- Syntaktisch eine **globale Unicast-Adresse**, die aber **mehrfach vergeben** wird
- Router leitet Verkehr zur **nächstgelegenen Instanz** (nach Routing-Metrik)
- Anwendung: z. B. DNS-Root-Server, CDN-Knoten
### Multicast Adressen (FF00::/8)
Ersetzt IPv4-Broadcast (den es in IPv6 **nicht mehr gibt**).
```
|←8 Bit→|←4 Bit→|←4 Bit→|←────── 112 Bit ──────→|
| FF | Flags | Scope | Group ID |
```
**Flags:**
- R = 0/1: Kein/Eingebetteter Rendezvous Point
- P = 0/1: Nicht/Basierend auf Unicast-Präfix
- T = 0/1: Permanent (IANA-zugewiesen) / Temporär (lokal zugewiesen)
**Scope:**
|Wert|Scope|
|---|---|
|1|Node|
|2|Link|
|3|Subnet|
|4|Admin|
|5|Site|
|8|Organization|
|E|Global|
### Nicht mehr gebräuchliche Adresstypen
- **IPv4-kompatible IPv6-Adresse** (`0:::/96`) – veraltet
- **Site-local Adressen** (`FC00::/7`) – durch Unique Local Addresses (ULA) ersetzt
---
## 7. ICMPv6 & Neighbor Discovery
### ICMPv4 vs. ICMPv6
ICMPv6 (RFC 4443) übernimmt deutlich **mehr Aufgaben** als ICMPv4 (RFC 792):
|Funktion|ICMPv4|ICMPv6|
|---|---|---|
|Connectivity Checks (Ping)|✓|✓|
|Informational/Error Messaging|✓|✓|
|Fragmentation Needed Notification|✓|✓|
|Address Assignment (SLAAC)|✗|✓|
|Address Resolution (ersetzt ARP)|✗|✓|
|Router Discovery|✗|✓|
|Multicast Group Management|✗|✓|
|Mobile IPv6 Support|✗|✓|
### Neighbor Discovery Protocol (NDP) – Neue ICMPv6-Nachrichten
|Nachricht|ICMP Code|Sender|Ziel|Zweck|
|---|---|---|---|---|
|**Router Solicitation (RS)**|133|Nodes|Alle Router (ff02::2)|Router auffordern, ein RA zu senden|
|**Router Advertisement (RA)**|134|Router|Sender des RS oder alle Hosts (ff02::1)|Default Router, Präfixe, Konfigurationsparameter bekanntgeben|
|**Neighbor Solicitation (NS)**|135|Node|Solicited Node Multicast / Target Node|Link-Layer-Adresse des Ziels erfragen (= ARP-Ersatz)|
|**Neighbor Advertisement (NA)**|136|Node|Anfragender Node|Antwort auf NS mit eigener Link-Layer-Adresse|
|**Redirect**|137|Router|–|Host über besseren First Hop informieren|
### Automatische Adressvergabe (SLAAC)
**Stateless Address Autoconfiguration** – Hosts konfigurieren sich selbst ohne DHCP-Server.
**Router Discovery Prozess:**
1. **Host sendet RS** (Router Solicitation, Typ 133) an Multicast-Adresse `ff02::2` (alle Router)
2. **Router antwortet mit RA** (Router Advertisement, Typ 134) an `ff02::1` (alle Hosts) mit:
- Netzwerkpräfix (z. B. `2001:0db8:abcd::/64`)
- Präfix-Lebensdauer (z. B. 3600 Sekunden)
- Flags für DHCPv6-Nutzung
- Informationen ob SLAAC oder DHCPv6 verwendet werden soll
3. **Host generiert seine Adresse** aus Netzwerkpräfix + Interface ID (EUI-64 oder zufällig)
**Flags im Router Advertisement:**
- **A-Flag** (Autonomous): ON = Host darf SLAAC verwenden
- **M-Flag** (Managed): OFF = Kein DHCPv6 für Adressen nötig
Router senden regelmäßig RA-Nachrichten; Hosts können jederzeit RS senden, um aktuelle Informationen zu erhalten.
### Duplicate Address Detection (DAD)
Bevor ein Host seine neu generierte Adresse verwendet, prüft er per **DAD** (RFC 4862), ob die Adresse bereits im Netz existiert:
1. Host empfängt RA mit Präfix
2. Host generiert vorläufige Adresse (Präfix + Interface ID)
3. Host sendet **NS** an die Solicited-Node-Multicast-Adresse der vorläufigen Adresse
4. Wenn **keine Antwort** kommt → Adresse ist eindeutig → wird übernommen
5. Wenn **NA** empfangen wird → Adresse ist bereits vergeben → neue Interface ID generieren
### ARP-Ersatz in IPv6
IPv6 hat **kein ARP** mehr. Stattdessen wird **Neighbor Solicitation / Neighbor Advertisement** verwendet:
1. **Host A** will die MAC-Adresse von **Host B** wissen
2. Host A sendet **NS** (Typ 135) an die Solicited-Node-Multicast-Adresse von Host B
- Enthält: eigene Link-Local-Adresse, Frage nach Host Bs Link-Layer-Adresse
3. **Host B** antwortet mit **NA** (Typ 136) per Unicast an Host A
- Enthält: eigene Link-Local-Adresse und MAC-Adresse
---
## 8. Migration von IPv4 zu IPv6
### Dual Stack
- Server, Router und Hosts betreiben **unabhängige Stacks** für IPv4 und IPv6
- Falls die Gegenseite IPv6 unterstützt → Kommunikation über IPv6
- Anwendungen müssen IPv6 unterstützen
- **Bevorzugte Methode** – natives IPv6
### Tunneling-Verfahren
Verbindung von **IPv6-Inseln** über ein IPv4-Transportnetz.
|Verfahren|Beschreibung|Status|
|---|---|---|
|**Manueller Tunnel (6in4)**|IPv6-Pakete werden in IPv4-Pakete gekapselt. Manuell konfiguriert.|Empfohlen wenn Tunnel nötig|
|**6-to-4**|IPv6-Prefix `2002::/16` + IPv4-Adresse des Edge-Routers. Automatisch.|Übergangslösung|
|**6rd**|Weiterentwicklung von 6-to-4, kontrolliert vom ISP. Teile der Kunden-IPv4-Adresse werden in den IPv6-Präfix eingebaut.|Übergangslösung, Ziel: natives IPv6|
|**Teredo**|IPv6-Pakete werden in IPv4-UDP-Pakete verpackt. Funktioniert auch hinter NAT.|Wird abgelöst|
|**ISATAP**|Intra-Site Automatic Tunnel Addressing Protocol|Veraltet|
**Empfehlung:** Besser natives IPv6 (Dual Stack). Wenn Tunnel nötig, dann manuell mit 6in4 oder 6rd.
---
## 9. Layer 7 – DHCP
### DHCP (IPv4) – Dynamic Host Configuration Protocol
Automatische Vergabe von IP-Adressen und Netzwerkparametern.
#### DORA-Prozess (Discover → Offer → Request → Acknowledge)
|Schritt|Nachricht|Richtung|Typ|Beschreibung|
|---|---|---|---|---|
|1|**DHCP Discover**|Client → Broadcast|0.0.0.0 → 255.255.255.255|Client sucht DHCP-Server. Enthält MAC-Adresse des Clients.|
|2|**DHCP Offer**|Server → Broadcast|Server → 255.255.255.255|Server bietet eine IP-Adresse an.|
|3|**DHCP Request**|Client → Broadcast|0.0.0.0 → 255.255.255.255|Client akzeptiert das Angebot. Enthält Server Identifier in den DHCP-Optionen.|
|4|**DHCP ACK**|Server → Unicast||Server bestätigt die zugewiesene IP-Adresse.|
#### Fehlersituationen
|Nachricht|Beschreibung|
|---|---|
|**DHCP-Decline**|Client macht ARP-Request für angebotene Adresse → wird beantwortet → Adresse bereits in Benutzung → Client lehnt ab|
|**DHCP-NACK**|Server hat die angefragte IP bereits vergeben, angefragte Optionen nicht verfügbar, oder Server nicht für die Adresse zuständig|
|**DHCP-Release**|Client benötigt die IP-Adresse nicht mehr (z. B. `ipconfig /release` unter Windows)|
|**DHCP-Inform**|Client hat bereits eine IP, fragt aber zusätzliche Parameter ab|
#### DHCP Lease-Erneuerung
|Zeitpunkt|Verhalten|
|---|---|
|**Nach 50% der Leasezeit**|Client sendet **DHCP Request per Unicast** an den bekannten Server. Server antwortet mit DHCP ACK (= neue Lease) oder antwortet nicht (Lease kann bis zum Ende genutzt werden).|
|**Nach 7/8 der Leasezeit**|Client sendet **DHCP Request per Broadcast** an alle Server. Verhalten wie bei 50%.|
|**Nach Ablauf der Leasezeit**|IP-Adresse wird freigegeben. Client sendet erneut **DHCP Discover**.|
#### DHCP-Optionen (mögliche Parameter)
- IP-Adresse, Netzmaske, Default-Gateway
- Name-Server (DNS), Time-Server
- WINS, Proxy-Server
- Bootimages, Bootserver
- u. v. m.
#### DHCP Relay
- DHCP arbeitet über **Broadcast** → funktioniert nur im lokalen Subnetz
- Ohne Relay bräuchte man **pro Subnetz einen DHCP-Server**
- Ein **Router als DHCP Relay Agent** kann DHCP-Pakete in andere Subnetze weiterleiten
- DHCP-Pakete bekommen zusätzliche Optionen:
- **DHCP Relay-Agent** Information
- **Option 82** (Switchport-Information)
**Ablauf mit Relay:**
```
Client (Port 68) ──→ Relay (Port 67 & 68) ──→ Server (Port 67)
DHCP Discover → DHCP Discover →
← DHCP Offer ← DHCP Offer
DHCP Request → DHCP Request →
← DHCP Acknowledge ← DHCP Acknowledge
```
---
## 10. Weitverkehrsnetze (WAN)
### Überblick
- **WANs verbinden LANs** über große Entfernungen
- Die Bereitstellung hängt von den **Benutzeranforderungen** ab
- WANs werden auf den **drei unteren OSI-Schichten** (Layer 1–3) betrieben
### WAN-Übergangspunkt (Kunde ↔ Service Provider)
|Komponente|Beschreibung|
|---|---|
|**CPE** (Customer Premises Equipment)|Geräte beim Kunden (Router, Modem)|
|**Hausanschluss**|Physische Verbindung ins Gebäude|
|**Teilnehmeranschluss**|Letzte Meile zum Provider|
|**Netzabschluss SP**|Übergabepunkt zum Provider-Netz|
|**Trunk-Leitungen und Switches**|Backbone des Providers|
### WAN-Verbindungsarten
```
WAN
/ \
Dediziert Switching
| / \
Mietleitungen Leitungs- Paketvermittelt
(Synchron E1, vermittelt
über Ethernet) (ISDN/DSL) (Ethernet, IP)
```
### Layer-1-Zugangstechnologien
**Heutige Technologien (IP-basiert, paketvermittelt):**
- Glasfaseranschlüsse (FTTH, FTTB)
- Kupferkabel (ehemaliges Telefonnetz, aktuell DSL)
- Kabel-Internet über DOCSIS (Coaxialkabel, ursprünglich für TV)
- Satelliten
- LTE/5G Mobilfunk
**Frühere Technologien:**
- Plesiochrone Digitale Hierarchie (PDH)
- Synchrone Digitale Hierarchie (SDH)
- Frame Relay
- Asynchronous Transfer Mode (ATM)
### WAN-Protokolle (Paketvermittelt)
|Protokoll|Beschreibung|
|---|---|
|**MPLS** (Multiprotocol Label Switching)|Label-basiertes Forwarding für Unternehmen und SPs. Ermöglicht effiziente Datenübertragung und QoS.|
|**Segment Routing** (SR-MPLS und SRv6)|Vereinfachte Netzwerkverwaltung – intermediate Router brauchen keine Pfadinfos. Ingress Router legt den Weg als Liste von Segmenten fest (im IPv6 als Routing Extension Header / SRH, bei MPLS als Label Stack). Form von Source Routing.|
|**Carrier Ethernet**|Ethernet-Protokolle für Hochgeschwindigkeitsverbindungen zwischen Standorten. Von Carriern/SPs bereitgestellt.|
|**SD-WAN**|Software-Defined WAN – dynamische Verwaltung von Netzwerkverbindungen über verschiedene Transportmittel (MPLS, LTE, Internet).|
|**PPPoE**|Point-to-Point Protocol over Ethernet – nutzt DSL als Zugangstechnologie zum WAN des SPs.|
---
## 11. PPPoE & DSL
### PPPoE (Point-to-Point Protocol over Ethernet)
PPPoE ermöglicht die Übertragung unterschiedlicher Protokolle (z. B. IP) über eine Leitung (Modem/xDSL). Es ist standardisiert in **RFC 2516** und bietet:
- Kontrollierten Verbindungsaufbau über **LCP** (Link Control Protocol)
- **Authentifizierung** (für Abrechnung beim Provider)
- **Autokonfiguration**
### PPPoE-Verbindungsphasen
```
┌─────────────────────────────────────────────────┐
│ │
▼ │
┌──────┐ Physik. Verbindung ┌──────┐ │
│ Down │ ───────────────────→ │ Auth │ │
└──────┘ └──┬───┘ │
▲ │ │
│ Anmeldung gescheitert │ Anmeldung │
│ │ erfolgreich │
│ ▼ │
│ ┌──────────┐ │
│ │ Network │ │
│ │ Config │ │
│ └────┬─────┘ │
│ │ Austausch │
│ │ erfolgreich │
│ ▼ │
│ Abbauwunsch/Fehler ┌─────────────┐ │
└────────────────────── │ Operational │ ─────────┘
└─────────────┘
```
### Phase 1: Discovery & Verbindungsaufbau
1. **PADI** (PPPoE Active Discovery Initiation) – Client sendet Broadcast, sucht PPPoE-Server
2. **PADO** (PPPoE Active Discovery Offer) – Server antwortet mit Angebot und Infos über sich
3. **PADR** (PPPoE Active Discovery Request) – Client wählt einen Server und sendet Anfrage
4. **PADS** (PPPoE Active Discovery Session Confirm) – Server bestätigt und weist **Session-ID** zu
### Phase 2: Authentifizierung
Nach erfolgreichem Verbindungsaufbau wird ein PPPoE-Sitzungstunnel aufgebaut. Alle Daten werden in PPP-Pakete eingekapselt.
**PAP (Password Authentication Protocol):**
- **Einfaches, unverschlüsseltes** Verfahren (unsicher!)
- **2-Way Handshake:** Client sendet LoginID + Passwort → Server akzeptiert oder verwirft
- Passwort wird **im Klartext** übertragen
- **Nicht mehr verwendet** für Anschlüsse zum SP
**CHAP (Challenge Handshake Authentication Protocol):**
- **Verschlüsseltes**, sichereres Verfahren
- **3-Way Handshake:**
1. Server sendet eine **zufällige Challenge** an den Client
2. Client kombiniert Challenge mit seinem Passwort und sendet einen **Hash-Wert** zurück (SHA-1, SHA-256 oder SHA-384)
3. Server führt **dieselbe Berechnung** durch und vergleicht die Ergebnisse
- **Keine Übertragung von Passwörtern** über die Leitung
- Authentifizierung durch lokalen Router oder externen Authentifizierungsserver
### Phase 3: Netzkonfiguration
Nach erfolgreicher Authentifizierung werden Netzwerkparameter ausgetauscht:
- IP-Adresse, Subnetzmaske, Standard-Gateway
- DNS-Server-Adressen
- MTU (Maximum Transmission Unit für Ethernet)
- Session-ID
- QoS-Parameter
### Phase 4: Operational (Betrieb)
- **Session Timer / Idle Timer** zur Verwaltung der Sitzung
- **Keepalive-Nachrichten** – bei Ausbleiben wird Session ungültig markiert
- **Timeouts** – Session-ID wird nach Timer-Ablauf für ungültig erklärt (Ressourcen freigeben)
- **Fehlerüberprüfung** – Server kann erneute Authentifizierung anfordern
### DSL (Digital Subscriber Line)
Bereitstellung von Internet über **herkömmliche Telefonleitungen** (Kupfer).
**Aufbau:**
```
Kunde/Teilnehmer │ Vermittlungsstelle
│
Telefon ─── NTBA ──┐ │ ┌── Digitale Vermittlung ── Telefonnetz
├─ TAL ┤ │
PC ─── DSL-Router ──┘ │ ├── DSLAM ── BRAS ── Internet
│ │
Splitter│ Splitter
```
- **TAL** = Teilnehmeranschlussleitung (letzte Meile, Kupfer)
- **DSLAM** = Digital Subscriber Line Access Multiplexer – sammelt und aggregiert Daten der Teilnehmer
- **BRAS/BNG** = Broadband Remote Access Server / Broadband Network Gateway – terminiert PPPoE
### DSL-Varianten
|Variante|Typ|Max. Datenrate|Besonderheit|
|---|---|---|---|
|**ADSL**|Asymmetrisch|Bis 8 Mbit/s|Download > Upload|
|**ADSL2+**|Asymmetrisch|Bis 24 Mbit/s|Zusätzliche Frequenzbänder|
|**SDSL**|Symmetrisch|2,36 Mbit/s|Upload = Download|
|**VDSL**|Asymmetrisch|Bis 100 Mbit/s|Optimiert für kurze Entfernungen|
|**VDSL2-Vectoring**|Hybrid|Bis 250 Mbit/s|Kupfer letzte Meile + Glasfaser zum ISP. Crosstalk-Kompensation.|
Höhere Raten als VDSL2-Vectoring sind nur über **FTTH** (Fiber to the Home) oder **Kabelinternet** (DOCSIS) möglich.
### Abschaltung von DSL in Deutschland
- **Ziel:** Glasfaserausbau komplett bis **2030**
- DSL-Abschaltung bei einzelnen Service Providern kann **ab 2026** beginnen
- **Bundesnetzagentur** reguliert den Telekommunikationsmarkt
- Stand Juni 2025: **42,9%** aller Haushalte verfügen über einen Glasfaseranschluss (FTTB/FTTH)
- **Gigabitversorgung** (1000 Mbit/s) über alle Technologien hinweg: **knapp 79%**
---
## Zusammenfassung der Kernthemen
|Thema|Kernaussage|
|---|---|
|**OSPF Areas**|Hierarchische Strukturierung reduziert Routing-Overhead. ABR/ASBR fassen Routen zusammen.|
|**Route Summarization**|Binärvergleich der Netzadressen → gemeinsame Bits = neues Präfix. Spart Ressourcen, beschleunigt Konvergenz.|
|**IPv6 Motivation**|128-Bit-Adressen, vereinfachter Header, Autokonfiguration, integrierte Sicherheit.|
|**IPv6 Header**|40 Byte fest, Extension Headers für Erweiterungen. Next Header verkettet die Header.|
|**IPv6 Adresstypen**|Global Unicast (2000::/3), Link-Local (fe80::/10), Multicast (ff00::/8), Anycast. Kein Broadcast!|
|**NDP/ICMPv6**|Ersetzt ARP (NS/NA), ermöglicht Router Discovery (RS/RA), SLAAC und DAD.|
|**IPv4→IPv6 Migration**|Dual Stack bevorzugt. Tunnel (6in4, 6rd) als Übergangslösung.|
|**DHCP**|DORA-Prozess, Lease-Erneuerung bei 50% und 7/8, Relay für subnetzübergreifende Vergabe.|
|**WAN**|Dediziert vs. Switching (leitungs-/paketvermittelt). MPLS, Segment Routing, Carrier Ethernet, SD-WAN.|
|**PPPoE**|Discovery → Auth (PAP/CHAP) → Network Config → Operational. Verbindungsprotokoll für DSL.|
|**DSL**|ADSL, VDSL, Vectoring. DSLAM aggregiert Teilnehmer. Ablösung durch Glasfaser bis 2030.|
Reference in a new issue View git blame Copy permalink