theo/hwr-notes
1
0
Fork 0
mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-06 02:11:08 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: add obsidian hwr docs

Browse source
This commit is contained in:
theoleuthardt 2026-04-09 11:24:56 +02:00
parent b2636f4b92
commit 850aa3455d
245 changed files with 30757 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

794
Netzwerke/zusammenfassungen/nw4 - zusammenfassung.md Normal file
View file

@ -0,0 +1,794 @@
# 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.|