Im Folgenden wurde die IP-Adresse `8.8.8.8` als Ziel für die Pinganfragen verwendet,
die untersucht werden. Die Pinganfragen wurden von einer VM mit Netzwerkbrücke
auf einem Ethernetadapter durchgeführt und Wireshark wurde zur Aufzeichnung
innerhalb der VM verwendet.
Im ersten Screenshot lässt sich ablesen, dass die *IP-Adresse des Computers* von
dem die Pinganfrage verschickt wurde **`192.168.188.52`** lautet.
Der *Typ* des IP-Pakets ist als Wert **`1` (`ICMP`)** angegeben.
Im IP-Paket sind insgesamt laut Wireshark **84 Bytes** enthalten, davon belegt der
*IP-Header* **20 Bytes**, die restlichen **64 Bytes** sind die tatsächliche
*Nutzlast* des IP-Pakets, die aus der ICMP-Nachricht besteht.
Die *Roundtrip Time (RTT)* ist der Zeitabstand zwischen Versand des Anfragepakets
und Erhalten des Antwortpakets. Im Screenshot sieht man als Interval für die
erste Anfrage (Pakete 1 und 2) **etwa 15,05 Millisekunden**.
Die *Identifikationsnummern* lauten laut Wireshark für das IP-Paket selbst
`0x7566 (30054)` und das ICMP-Paket selbst hat die Identifikationsnummern
im *Big-Endian-Format (BE)*`3533` oder `0x0dcd` bzw. im *Little-Endian-Format (LE)*
`52493` oder `0xcd0d`. Im zweiten Screenshot sieht man, dass die Identifikationsnummern
für das Antwortpaket genau gleich sind. Wären diese Nummern verschieden, könnte
die Antwort der Anfrage nicht mehr zugeordnet werden.
Das IP-Paket der Anfrage wurde nicht fragmentiert. Fragmentiert ist ein Paket erst dann,
wenn es beim Versenden in mehrere Teile aufgespalten wurde und der entsprechende
Flag für die Fragmentierung im IP-Header gesetzt wurde, was hier nicht der Fall ist
(der Flag ist `0x4000` was Wireshark entsprechend als `Don't fragment` anzeigt).
## Analyse eines fragmentierten Pings
### Ping mit 2000 Bytes Inhalt
Die *IP-Adressen* haben sich nicht geändert.
Der IP-Header enthält als *Typ* ebenso noch den gleichen Wert.
Die Headergröße hat sich ebenfalls nicht verändert, aber die Größe der *Nutzlast*
ist jetzt auf **1500 Bytes** angewachsen. Die restlichen **500 Bytes** finden
sich in einem Folgepaket das aufgrund der Fragmentierung mitgeschickt wurde.
Die *Roundtrip Time* beträgt jetzt **16,93 Millisekunden** (Unterschied Paket 1 zu 3).
### Ping mit 3500 Bytes Inhalt
Die Änderungen sind ähnlich wie oben, außer dass die *Nutzlast* des ersten Pakets
sich nicht mehr ändert und **1500 Bytes** beträgt. Dafür ist ein weiteres Teilpaket
dazugekommen, bei dem der zusätzliche Inhalt angehängt wurde.
Die *Roundtrip Time* beträgt jetzt **15,80 Millisekunden** (Unterschied Paket 1 zu 4).
\clearpage
# Analyse der Fragmentierung
In dieser Analyse scheinen Daten über 1500 Bytes fragmentiert zu werden. Beide
Pakete (2000 Bytes und 3500 Bytes) wurden in max. 1500 Bytes große Datenteile
aufgespalten und dann nacheinander verschickt.
Die wichtige Identifikationsnummer für fragmentierte Pakete ist die `Identification`
im IP-Header, nicht die `Identifier`-Felder im ICMP-Paket, denn dieses wurde
in mehrere Teile zerspaltet und um das Paket zusammensetzen zu können muss stattdessen
die Quelle mehrere Pakete mit dem gleichen Identifizierer verschicken. Entsprechend sehen wir im obigen Screenshot, dass die IP-ID der Folgepakete in der Übersicht die gleiche ID haben wir der IP-Header des ersten Pakets.
Während der Analyse konnten wir kaum wertvolle Informationen zur Änderung der
*Roundtrip Time* abhängig von der Fragmentierung gewinnen. In der Theorie braucht
es länger, größere Datenmengen zu verschicken, vor allem wenn diese vorher in mehrere
Teile aufgespalten wurden und für jeden Teil ein weiterer Header mitverschickt wird.
Die Übertragung läuft jedoch hier in der Praxis so schnell ab, dass andere Abweichungen
in der Übertragung sich stärker in der RTT abbilden.
\clearpage
# Analyse einer Routenverfolgung
Im Folgenden wurde `reutlingen.de` explizit über IPv4 als Ziel für die Routenverfolgung
verwendet. Das Tool das eingesetzt wurde ist `tracepath` (mit entsprechendem `-4` Flag).
Wireshark registriert eine Sequenz von Paketen vom Typ DNS, UDP und meistens ICMP als Antwort.
Die Pakete der eigentlichen Anfragen zur Routenverfolgung werden über **UDP** versendet.
Dabei fällt auf, dass die UDP-Pakete von oben nach unten beginnend von einer *Time-To-Live (TTL)*
Die *Antwort* auf alle Pakete ist immer ein **ICMP**-Paket. Alle Antworten bis auf
das letzte Paket sind ein **ICMP-Paket mit der Nachricht "Time-to-live exceeded"**.
Diese Antwort wird von dem jeweiligen routenden Knotenserver selbst verschickt
und daran misst `tracepath` die Zeit und die Reaktionsfähigkeit des jeweiligen
Knotens.
Die *ersten beiden Knotenpunkte* in diesem Fall sind:
-`192.168.188.1` (`fritz.box`) - der Router im lokalen Netzwerk.
-`62.214.63.94` (`i59F4DCE4.versanet.de`) - der erste externe Router aus dem ISP-Netzwerk.
\clearpage
# ICMP
Ein ICMP-Paket ist wie folgt aufgebaut:
- **`Type`** - ein Wert der die Art der ICMP-Nachricht angibt, z. B. `8` für eine Echo-Anfrage oder `11` für *Time-to-live exceeded*. **Weitere Typen** wären:
-`0` - Echo Reply
-`3` - Destination Unreachable
-`5` - Redirect (IP-Umleitung)
-`9` - Router Advertisement (wird benutzt um einem Rechner den Router bekannt zu machen zur IP-Vergabe). Gegenstück dazu: `10` (Router Solicitation)
-`12` - Parameter Problem (bei ungültigen Inhalten in einer ICMP-Anfrage)
- **`Code`** - ein separater Code zur Angabe einer Fehlerursache oder eines anderen Details
- **`Checksum`** - ein Hash des Pakets zum Sicherstellen einer korrekten Übertragung
- **Informationen zu ursprünglichen Anfragepaketen**, meisten IP-Paket und dessen Inhalt. Aufgrund der Informationen die hier enthalten sind (wie der Identifizierer) weiß der Empfänger der Nachricht **basiend auf diesen Informationen auf welche ursprünglich gesendeten Pakete sich diese ICMP-Meldung bezieht.**
