|
|
| Zeile 10: |
Zeile 10: |
| ===== Projekt ===== | | ===== Projekt ===== |
| ===== Weblinks ===== | | ===== Weblinks ===== |
|
| |
| = TMP =
| |
| == IPv4 Header ==
| |
| [[File:ipv4Ipv6Heaser.png|800px]]
| |
|
| |
| – IPv6-Header ist gegenüber IPv4 stark vereinfacht
| |
| • Enthält nur grundlegende Forwarding-Information
| |
| • Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern,
| |
| welche durch das „Next Header“ Feld identifiziert werden
| |
| • Damit trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge
| |
|
| |
| [[File:img-003-000.png|600px]]
| |
|
| |
| == Die folgenden Felder wurden weggelassen ==
| |
|
| |
| 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.
| |
| ● IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht kleinere
| |
| Pakete zu schicken.
| |
|
| |
| Checksum
| |
| ● ist verschwunden, weil die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die
| |
| Performance auswirkte,
| |
| ● und auf den Schichten über und unter der Vermittlungsschicht schon genug Prüfsummen
| |
| berechnet werden.
| |
|
| |
| Padding
| |
|
| |
| == Extension-Prinzip ==
| |
| [[File:ipv6HeaderExtension.png|mini|300px]]
| |
| ; IPv6-Header ist durch Extension-Prinzip flexibel erweiterbar
| |
| * Per Hop ausgewertete Header
| |
| ** Hop-by-Hop Options (z.B. Jumbogramm Notifier)
| |
| ** Routing Information Header
| |
| * Nur im Endsystem ausgewertete Header
| |
| ** Fragmentation Header
| |
| ** Authetication Header
| |
| * Header-Extensions u.U. auf Applikationsniveau direkt nutzbar
| |
| * Die meisten IPv6 Pakete bestehen nur aus IPv6- und TCP Header sowie Daten
| |
|
| |
| == Unterschiede IPv4/IPv6 ==
| |
| [[File:img-006-001.png|600px]]
| |
|
| |
| == IPv6 - 6 ==
| |
| 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)
| |
|
| |
| == Felder im IPv6-Header ==
| |
| [[File:img-008-002.png|600px]]
| |
|
| |
| == Kopfdaten laut RFC 2460 ==
| |
|
| |
| {| style="border-spacing:0;margin:auto;width:17cm;"
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Feld
| |
| || Länge
| |
| || Inhalt
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Version
| |
| || 4 Bit
| |
| || IP-Versionsnummer (6)
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Traffic Class
| |
| || 8 Bit
| |
| || Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Flow Label
| |
| || 20 Bit
| |
| || Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Payload Length
| |
| || 16 Bit
| |
| || Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || 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).
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || 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.
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Source Address
| |
| || 128 Bit
| |
| || Adresse des Senders
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Destination Address
| |
| || 128 Bit
| |
| || Adresse des Empfängers
| |
| |}
| |
|
| |
| == Next Header Werte ==
| |
| [[File:img-010-003.png|400px]]
| |
| [[File:img-010-004.png|400px]]
| |
|
| |
| == IPv6 Header in einem Trace File ==
| |
| [[File:img-011-005.png|400px]]
| |
|
| |
| == IPv4 und IPv6 Header im Vergleich ==
| |
| [[File:img-012-006.png|400px]]
| |
|
| |
| == IPv6 - 12 ==
| |
| [[File:img-013-007.png|400px]]
| |
|
| |
| == IPv4 Header Felder ==
| |
|
| |
| 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
| |
|
| |
| == IPv6-Erweiterungsheader ==
| |
|
| |
| Einige der gestrichenen Felder sind manchmal doch noch notwendig
| |
| ● für diese Fälle sind derzeit 6 Erweiterungsheader definiert,
| |
| ● die benutzt werden um zusätzliche Informationen zu kodieren.
| |
| ● Alle Erweiterungsheader sind optional.
| |
| ● Werden mehrere benutzt müssen sie direkt nach dem Hauptheader erscheinen.
| |
|
| |
| Optionen für Teilstrecken
| |
| ● Dieser Header wird für Informationen benutzt die alle Router auf der Strecke prüfen müssen.
| |
| ● Bisher ist eine Option definiert, die Unterstützung von Jumbogrammen, also Paketen die größer als 64 kByte
| |
| sind.
| |
| ● Routing
| |
| – Mit diesem Header kann eine Route vollständig oder teilweise spezifiziert werden.
| |
| – Fragmentierung Dieser Header enthält Optionen für die Fragmentierung von Paketen.
| |
| – Nanu, hatten wir nicht eben gesagt IPv6 fragmentiert nicht? Im Prinzip ja.
| |
| – Der Quellhost darf Pakete immer noch fragmentieren.
| |
| – Nur die Router auf der Strecke sind nicht mehr dazu berechtigt.
| |
| ● Authentifikation
| |
| – Der Authentifizierungsheader bietet einen Mechanismus, durch den der Empfänger sicher sein kann, das der in der Adresse
| |
| angegebene Sender auch tatsächlich der ist, der er behauptet zu sein.
| |
| ● Verschlüsselte Sicherheitsdaten
| |
| – Dieser Header enthält Informationen über das verwendete Verschlüsselungsverfahren.
| |
|
| |
| Optionen für Ziele
| |
| ● Dieser Header ist für Optionen vorgesehen, die nur vom Zielhost interpretiert werden müssen.
| |
| ● Er wird derzeit nicht benutzt.
| |
|
| |
| == Optionale Erweiterungsheader ==
| |
| [[File:img-016-008.png|600px]]
| |
|
| |
| == IPv6 - 16 ==
| |
| [[File:img-017-009.png|600px]]
| |
|
| |
| == IPv6 - 17 ==
| |
| [[File:img-018-010.png|600px]]
| |
|
| |
| == Extension Headers ==
| |
| Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen
| |
| ● Extension Headers können bis auf den Destination Options Header nur einmal in jedem Paket
| |
| vorkommen
| |
| ● Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination
| |
| Options Header stehen
| |
| ● Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der folgenden
| |
| Tabelle
| |
| ● Wie im Next Header Feld verwiesen sind einige Extension Headers und ein Platzhalter definiert
| |
|
| |
| == Extension Headers ==
| |
| {| style="border-spacing:0;margin:auto;width:17cm;"
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || '''Name'''
| |
| || '''Typ'''
| |
| || '''Größe'''
| |
| || '''Beschreibung'''
| |
| || '''RFCs'''
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Hop-By-Hop Options
| |
| || 0
| |
| || variabel
| |
| || Optionenvon allen IPv6-Geräten zu beachtenwird z.B. für Jumbograms benutzt
| |
| || RFC 2460RFC 2675
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Routing
| |
| || 43
| |
| || variabel
| |
| || Hier kann der Weg des Paketes durch das Netzwerk beeinflusst werdenwird u.a. für Mobile IPv6 verwendet
| |
| || RFC 2460RFC 6275RFC 5095
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Fragment
| |
| || 44
| |
| || 64 Bit
| |
| || Parameter zur Fragmentierung
| |
| || RFC 2460
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Authentication Header (AH)
| |
| || 51
| |
| || variabel
| |
| || Daten zur Vertraulichkeit (IPsec)
| |
| || RFC 4302
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Encapsulating Security Payload (ESP)
| |
| || 50
| |
| || variabel
| |
| || Daten zur Verschlüsselung (IPsec)
| |
| || RFC 4303
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Destination Options
| |
| || 60
| |
| || variabel
| |
| || Optionennur vom Zielrechner zu beachten
| |
| || RFC 2460
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Mobility
| |
| || 135
| |
| || variabel
| |
| || Daten für Mobile IPv6
| |
| || RFC 6275
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || No Next Header
| |
| || 59
| |
| || leer
| |
| || Platzhalterzeigt Ende eines Header-Stapels an
| |
| || RFC 2460
| |
| |-
| |
| |}
| |
|
| |
| == Verwendung von Extension Headers ==
| |
| [[File:img-021-011.png|400px]]
| |
|
| |
| == Reihenfolge der Extension Header ==
| |
|
| |
| 1) IPv6 Header
| |
| 2) Hop-by-Hop Options Header (für Optionen, welche von Routern auf dem Pfad zum endgültigen Empfänger verarbeitet werden müssen)
| |
| 3) Routing Header
| |
| 4) Fragment Header
| |
| 5) Authentication Header
| |
| 6) Encapsulating Security Payload Header
| |
| 7) Destination Options Header (für Optionen, welche vom endgültigen Empfänger des Paketes verarbeitet werden müssen)
| |
| 8) Upper-Layer Header
| |
|
| |
| == IPv6 - 22 ==
| |
| Extension Headers
| |
|
| |
| Next-Header
| |
| ● Alle Extension Headers enthalten ein Next-Header-Feld, in dem
| |
| ● der nächste Extension Header oder
| |
| ● das Upper Layer Protocol genannt wird
| |
| ● Größen immer Vielfache von 64 Bit
| |
| ● Speicherzugriffe im Router beschleunigen
| |
| ● die meisten Felder der Kopfdatenbereiche sind auf 64-Bit-Grenzen ausgerichtet
| |
|
| |
| Keine Prüfsummen
| |
| ● Es werden keine Prüfsummen über die IP-Kopfdaten berechnet
| |
| ● im Gegensatz zu IPv4
| |
| ● Fehlerkorrektur auf Schichten 2 und 4
| |
|
| |
| == Format des Hop-by-Hop Options Headers ==
| |
| [[File:img-024-012.png|400px]]
| |
|
| |
| == Format des Routing Headers ==
| |
| [[File:img-025-013.png|400px]]
| |
|
| |
| == Die Maximum Transmission Unit (MTU) ==
| |
|
| |
| Beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht
| |
| ● Schicht 3 des OSI-Modells
| |
| ● gemessen in Oktetten
| |
| ● welche ohne Fragmentierung in den Rahmen (engl. "Frames") eines Netzes der
| |
| Sicherungsschicht (Schicht 2) übertragen werden kann
| |
| ● Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht.
| |
| ● Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der
| |
| Sicherungsschicht (engl. 'link MTU') bezeichnet.
| |
| ● Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen:
| |
|
| |
| Maximale Rahmengröße = Größte MTU aller benutzten Protokolle der Vermittlungsschicht +
| |
| Größe der Sicherungsschicht-Header
| |
|
| |
| == IPv6 - 26 ==
| |
| Die Maximum Transmission Unit (MTU)
| |
|
| |
| Hardware und Technik
| |
| ● Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware
| |
| und Technik bestimmt.
| |
| ● Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der
| |
| Vermittlungsschicht (z. B. IPv4 oder IPv6) annehmen.
| |
| ● Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten
| |
| verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt
| |
| werden.
| |
|
| |
| Terminologie
| |
| ● Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'),
| |
| während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht.
| |
| ● Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-
| |
| Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt
| |
|
| |
| Paket- und Rahmengröße
| |
| ● Unter der „packet size“ (Paketgröße) wird fälschlicherweise teils die „frame size“ (Rahmengröße)
| |
| verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar.
| |
| ● Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll
| |
| getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame').
| |
|
| |
| == Typische MTU-Größen ==
| |
| {| style="border-spacing:0;margin:auto;width:17cm;"
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || '''Medium'''
| |
| || '''MTU in Bytes'''
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Hyperchannel
| |
| || 65535
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Token Ring(4)(802.5)
| |
| || 4464
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Token Ring(16)
| |
| || 17914
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || FDDI
| |
| || 4352
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Ethernet
| |
| || 1500
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || Gigabit Ethernet mit Jumboframes
| |
| || 9000
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || PPPoE (z. B. DSL)
| |
| || ≤ 1492
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || SLIP/PPP (low delay)
| |
| || 296
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || X.25
| |
| || 576
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || FibreChannel
| |
| || theoretisch unbegrenzt
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || ISDN
| |
| || 576
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || ATM
| |
| || 4500
| |
| |- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
| |
| || 802.11
| |
| || 2312 (WiFi)
| |
| |-
| |
| |}
| |
|
| |
| == Path MTU (PMTU) ==
| |
|
| |
| Path MTU (PMTU)
| |
| ● beschreibt die maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden
| |
| kann, ohne einer Fragmentierung zu unterliegen
| |
| ● Sie ist die kleinsten MTU aller Schicht-2-Teilstücke im Pfad
| |
| ● Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden.
| |
|
| |
| Beispiel Brief
| |
| ● Das Konzept der MTU auf die Post adaptiert ist verständlicher.
| |
| ● Eine MTU 50 g heißt, dass man max. 50 g Inhalt (entspricht der Packet Size) in den Brief
| |
| einpacken kann.
| |
| ● Der Brief insgesamt kann selbst aber schwerer als 50 g sein, da im Normalfall noch ein
| |
| Briefumschlag z.B. 4 g und eine Briefmarke 0,3 g hinzukommt.
| |
| ● Bezahlt und verschickt wird der ganze Brief von 54,3 g Masse entsprechend der Frame Size.
| |
|
| |
| == Beispiel Ethernet ==
| |
|
| |
| Ethernetrahmen bestehen aus zwei Teilen
| |
| ● dem „Header“, in dem Quell- und Zieladressen und andere wichtige Parameter für den Versand kodiert
| |
| sind, und der Nutzlast, deren Größe durch die MTU bestimmt ist.
| |
| ● In diesem Versuch ist die Größe der MTU mit 1500 Byte vorgegeben.
| |
| ● Mit Hilfe des ping-Programmes wird ein „Frame“ erzeugt, der dann im Netzwerk über das Ethernet-
| |
| Protokoll versendet wird.
| |
| ● Die Verwendung des Begriffes Nutzlast ist hier mehrdeutig, da im OSI-Modell die verschiedenen
| |
| Protokolle ineinander eingepackt (gekapselt) werden.
| |
|
| |
| ping -s 1472 10.0.0.1 (Windows-Befehl ping -l 1472 10.0.0.1)
| |
| ● sendet ein ICMP-Paket mit der Nutzlast von 1472 Bytes an die IP-Adresse 10.0.0.1.
| |
|
| |
| ping -f -l 1472 10.0.0.1
| |
| 1472 bytes Nutzlast des ICMP-Protokolles (Transportschicht)
| |
| + 8 bytes ICMP-Header (Transportschicht)
| |
| + 20 bytes IPv4-Header (der Vermittlungsschicht)
| |
| -------------
| |
| = 1500 bytes (Nutzlast von Ethernet)
| |
| + 14 bytes (Header der Sicherungsschicht)
| |
| + 4 bytes (Frame Check Sequence)
| |
| -------------
| |
| = 1518 bytes (kompletter Ethernetrahmen)
| |
|
| |
| == Beispiel Ethernet ==
| |
|
| |
| Mit einem Sniffer wie z. B. Wireshark
| |
| ● wird als Ethernet Header nur die Größe von 14 Byte angezeigt.
| |
| ● Hierzu kommt noch die 4 Byte große Frame Check Sequence am Ende des Frames.
| |
|
| |
| Falls VLANs verwendet werden
| |
| ● besteht der Header der Sicherungsschicht aus 18 Byte
| |
| ● der gesamte Ethernetrahmen kann eine Größe von bis zu 1522 Byte annehmen
| |
|
| |
| Würde IPv6 verwendet
| |
| ● änderte sich obige Berechnung dahingehend, dass der IPv6-Header der Vermittlungsschicht 40 statt
| |
| 20 Byte beträgt und damit statt 1472 Byte ICMP-Nutzlast nur 1452 Byte möglich wären.
| |
| ● Oft ist es hilfreich dem ping-Programm vorzugeben das „don’t fragment (DF) bit“ für die Testpakete
| |
| im IPv4-Header zu setzen,
| |
|
| |
| für Linux z. B.
| |
| ping -M do -s 1472 10.0.0.1
| |
|
| |
| für Windows
| |
| ping -l 1472 -f 10.0.0.1
| |
| ● denn dann erhält man eine Nachricht, falls die MTU überschritten wird.
| |
| ● Leicht sichtbar machen lässt sich die Path MTU mit dem Programm tracepath für IPv4 bzw.
| |
| tracepath6 für IPv6.
| |
|
| |
| == Jumbo Frames für Gigabit Ethernet ==
| |
|
| |
| Jumbo Frames können deutlich mehr als 1518 Oktette beinhalten
| |
| ● und damit ist es möglich, größere Pakete unfragmentiert zu übertragen
| |
|
| |
| Positiv
| |
| ● wiegt, dass der Protokoll-Overhead bei der Verwendung von Jumbo Frames reduziert werden
| |
| kann und Router weniger Pakete behandeln müssen.
| |
|
| |
| Allerdings
| |
| ● ist die Terminologie bzgl. MTU derart uneinheitlich unter den Herstellern, dass es in der Praxis
| |
| schwierig ist, von den Standardeinstellungen abzuweichen.
| |
|
| |
| Jumbo Frames sind nicht im IEEE-802.3-Standard spezifiziert
| |
| ● trotzdem unterstützen die meisten Hersteller von Gigabit Ethernet Switches und Routern MTUs
| |
| bis 9000 Oktette.
| |
|
| |
| Quasistandard eine Path MTU um ca. 1500 Byte
| |
| ● So hat sich als Quasistandard eine Path MTU um ca. 1500 Byte im Internet eingebürgert, die
| |
| durch das weit verbreitete Fast Ethernet sowieso meist nicht überschritten werden kann.
| |
|
| |
| == Jumbo Frames für Gigabit Ethernet ==
| |
|
| |
| Tunnelprotokolle
| |
| ● Mit dem Aufkommen von Internetzugängen, die auf Tunnelprotokollen basieren, zum Beispiel
| |
| beim Verbindungsaufbau über das PPPoE-Protokoll hat die MTU an Bedeutung gewonnen.
| |
| ● Obwohl die PMTUD in diesem Fall dafür sorgen soll, dass die Kommunikation trotz der durch
| |
| den Tunnel abgesenkten MTU möglich ist, gibt es immer wieder fehlkonfigurierte Firewalls, die
| |
| durch Verwerfen von ICMP-Steuerpaketen die PMTUD stören.
| |
| ● Auch große Websites sind oft von diesem Konfigurationsfehler betroffen, sodass die Nutzer von
| |
| getunnelten Zugängen die MTU ihrer Geräte verkleinern müssen, um auch mit diesen Sites
| |
| kommunizieren zu können.
| |
|
| |
| == Optimale MTU ==
| |
|
| |
| Diskussionen über die optimale MTU
| |
| Einfache Optimierung
| |
| ● So groß wie möglich, ohne dass Probleme auftreten
| |
|
| |
| Komplexe Optimierung
| |
| ● so viel kleiner als o. g. Maximum, dass der Verschnitt der Transportzellen der unter der DSL-
| |
| Schicht liegenden ATM-Transportschicht möglichst klein wird.
| |
|
| |
| Oder: Einfach probieren
| |
| ● Die MTU bei ATM (4500) ist nicht zu verwechseln mit der Zellengröße (53 Bytes, 48 davon
| |
| Nutzlast).
| |
| ● Bei der Übertragung über einen ATM-Link werden IP-Pakete in Stücke zu je 48 Bytes zerlegt
| |
| und für die Übertragung auf mehrere ATM-Zellen verteilt.
| |
| ● Der Router am anderen Ende des ATM-Links sammelt diese Zellen und setzt das ursprüngliche
| |
| IP-Paket wieder zusammen.
| |
| ● Im Gegensatz dazu wird bei der IP-Fragmentierung das Paket nicht vom Router reassembliert,
| |
| sondern erst von dem Host, für den das Paket bestimmt war.
| |
| ● Probleme, die durch einen falschen MTU-Wert auftreten können, sind Webseiten, die gar nicht
| |
| oder nur teilweise angezeigt werden.
| |
|
| |
| == Paketgrößen ==
| |
|
| |
| MTU und PMTU
| |
| ● Die Maximum Transmission Unit (MTU) darf in einem IPv6-Netzwerk 1280 Byte nicht
| |
| unterschreiten.
| |
| ● Somit unterschreitet auch die Path MTU (PMTU) diesen Wert nicht und es können Pakete bis zu
| |
| dieser Größe garantiert ohne Fragmentierung übertragen werden.
| |
| ● Minimale IPv6-Implementierungen verlassen sich auf diesen Fall.
| |
| ● Ein IPv6-fähiger Rechner muss in der Lage sein, aus Fragmenten wieder zusammengesetzte
| |
| Pakete mit einer Größe von mindestens 1500 Byte zu empfangen.
| |
| ● Für IPv4 beträgt dieser Wert nur 576 Byte.
| |
| ● Im anderen Extrem darf ein IPv6-Paket auch fragmentiert laut Payload-Length-Feld im IPv6-
| |
| Header die Größe von 65.575 Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld
| |
| 16 Bit lang ist (216 − 1 Byte zzgl. 40 Byte Kopfdaten).
| |
|
| |
| Jumbograms
| |
| ● RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur
| |
| Verfügung, Pakete mit Größen bis zu 4.294.967.335 Byte, sogenannte Jumbograms zu
| |
| erzeugen.
| |
| ● Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z. B. TCP oder
| |
| UDP, da diese oft auch nur 16 Bit für Größenfelder definieren, außerdem muss bei jedem Paket,
| |
| welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf 0 gesetzt werden.
| |
|
| |
| == Format des Fragment Headers ==
| |
| [[File:img-036-014.png|400px]]
| |
|
| |
| == Fragmentierung mit IPv6 ==
| |
| [[File:img-037-015.png|400px]]
| |
|
| |
| == Der Fragment Header in einem Trace File ==
| |
| [[File:img-038-016.png|400px]]
| |
|
| |
| == Das letzte Paket des Fragment Sets ==
| |
| [[File:img-039-017.png|400px]]
| |
|
| |
| == Format des Destination Options Headers ==
| |
| [[File:img-040-018.png|400px]]
| |
|
| |
|
| [[Kategorie:IPv6/Header]] | | [[Kategorie:IPv6/Header]] |
|
| |
|
| </noinclude> | | </noinclude> |