View
1
Download
0
Category
Preview:
Citation preview
Seite 1 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet Protocol
Seite 2 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungFehler
einzelne Bits der Datagrammköpfe verfälschtLebenszeit eines Datagramms abgelaufen Empfängers bemerkt, dass Daten nicht korrekt
InternetkontrollnachrichtInternet Control Message
ICMP Internet Control Message ProtocolKommunikation zwischen Internetsoftware (IP-Schicht)
zwischen Routern bzw. von Routern zu Rechnernauch zwischen Rechnern
integraler Bestandteil des InternetprotokollsKommunikation zwischen den für Datenübertragung verantwortlichen Instanzen eines Rechnernetzes
Seite 3 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungICMP-Nachricht in Datagramm
Eintrag 1 inTransportfeld
Nachrichtenformat des ICMP Typ CodeFunktionPrüfsummeSumme aller 16-Bit-Felder der ICMP-Nachricht.
Seite 4 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungEcho-Anforderung (echo request)
Fordert Empfänger schickt Sender Echo-Antwort gleichen Daten im Datenfeld Beliebige Datenlänge
Echo-Antwort (echo reply)Antwort auf Echo-Anforderung
Seite 5 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungZiel nicht erreichbar (destination unreachable)
Router kann Datagramm nicht abliefern
Grund Code Bedeutung
0 Netzwerk nicht erreichbar
1 Rechner nicht erreichbar
2 Protokoll nicht erreichbar
3 Adresse im Rechner nicht erreichbar
4 Fragmentierung nötig, aber 'Do not fragment' gesetzt
5 Angegebener Weg konnte nicht eingehalten werden.
Seite 6 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungFlusskontrolle (Pufferüberlauf, source quench)
PufferüberlaufNachrichten vernichten
Auch wenn Pufferüberlauf drohtsendet für jedes vernichtete Datagramm Meldung an Quelle
Datagrammstrom drosselnRouter drosselt Datagrammstrom
bis keine ICMP-Meldungen mehr eintreffenDatagrammstrom dann langsam wieder erhöhen
ältere Versionen ignorieren diese Nachrichten
Seite 7 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungAufforderung, den Weg zu ändern(route change request; oder route redirect)
Code Bedeutung
0 Datagramme für das Netz umlenken
1 Datagramme für den Rechner umlenken
2 Datagramme für Netz+Dienst umlenken
3 Datagramme für Rechner+Dienst umlenken
Seite 8 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungZeit abgelaufen (time exceeded)
Lebenszeitzähler des Datagramms Wert 0 Fragmentierungstimer im Zielrechner abgelaufen
GrundCode Bedeutung
0 Lebenszeit des Datagramms abgelaufen
1 Fragmentierungszeit abgelaufen
Seite 9 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungDatagrammkopf inkorrekt
(incorrect datagramm header)Router kann Datagramm nicht interpretieren ICMP-Nachricht an Absender Zeiger verweist auf erstes fehlerhafte Oktett im Header
Seite 10 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungUhrzeitabfrage (clock synchronization)
'Senderzeitmarke' ← Uhrzeit (in ms seit MN)'Empfängerzeitmarke bei Zugang''Empfängerzeitmarke bei Abgang'
Uhren vergleichen werdenUmlaufzeit (round trip time) von Datagrammen
Seite 11 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungNetzadresse (network address request)
Adresse des NetzesRechner angeschlossen
Funktion ähnlich wie RARP
vollständige Adresse des Senders und Empfängers
Seite 12 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungUnternetzmaske
subnetwork address mask request):
Maske des Subnetzes, an dem Rechner angeschlossen
Subnetzadressen in jedem Netz beliebig
Seite 13 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungAnwendungen von ICMP
Aufrechterhaltung des Betriebs einer IP-ImplementierungErreichbarkeit der Gegenstelle mit ICMP testen
Systemprogramm ping verwendet ICMP-Echo-RequestGegenstelle anfragen
Ermittlung der maximalen Datagramm-Größe auf PfadDon't Fragment-Bit setzenBei zu großem Datagramm: Fragmentation Required Empfänger erkennt, dass Datagramm noch zu groß richtige Größe austestenPfad ändert sich kurzfristig nicht
Seite 14 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungAnwendungen von ICMP
Routen (Pfad zu Ziel) mit ICMP findentraceroute verwendet ICMP-Time Exceeded-Nachricht
Hopcounterwert 1 Datagramm an Ziel erste Router sendet ICMP-Time Exceeded-Nachricht IP-Adresse des IP-Datagramms ersten Router ermittelnHopcounterwert 2, usw.
Reihe von FehlermöglichkeitenDuplizierte Datagramme werden ignoriertVerlorene Datagramm noch einmal sendennötige Wartezeit vom Anwender als Parameter gesetztPfade ändern sich u.U. dynamischZiel erreicht, auf nicht existierenden Port Protokoll: UDP; Antwort: Destination Unreachable statt Time Exceede
Seite 15 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPv6IPv4
bisher IP (IPv4 für Version 4, RFC 791) verschiedene NachteileErgänzungen im Standard (RFC 2460) für IPv6 aufgelistet
ErweiterungenAdresserweiterung
Adressraum 128 Bits wesentlich mehr adressierbare Knoten hierarchische Adressierung einfachere Autokonfiguration von Adressen Mehrfachadressierung neuer Adresstyp "Anycast"
Mindestens eine einer Gruppe von Adressen
Seite 16 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Erweiterungen in IPv6Vereinfachung des Header-Formats
Einige Felder des IPv4-Headers fortgelassen / optionalVerarbeitungskosten in Knoten verringern
keine Fragmentierung in Routerminimal notwendiger Header
weitere Funktionen optional in eigenen, konkatenierten Erweiterungsheadern Fragmentierungusw.
Verbesserte Unterstützung von Erweiterungen / Optionen
neue Kodierung der IP-Headeroptionenverbesserte Weiterleitung bei Router-Option größere Optionenlängenneue Optionen einfacher einführbar
Seite 17 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Fehlerbehandlung und -meldungErweiterungen
Markierung von DatagrammflüssenVerkehrsflüsse können markiert werdenverschiedene Qualitätsmerkmale garantierbar
Realzeitdienste
Authentication and Privacy CapabilitiesAuthentisierung, Datenintegrität Vertraulichkeit der Daten
Seite 18 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPv6 (auch IpnG)IPv6 in mehreren Standards beschrieben
RFC 2460Aufbau der Header und ErweiterungsheaderFunktionen
RFCs 2401, 2402 und 2406Sicherheitsaspekte
RFC 2373Adressformate
RFC 2463Management von IPv6 über ICMPv6
Seite 19 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Header im IPv6
Seite 20 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolHeader im IPv6
Verkehrsklasse (Traffic Class) Optimiert Verkehrsparameter
Durchsatz, Übertragungszeitverzögerung Übertragungsschwankung, Fehlerwahrscheinlichkeit oder Verlustwahrscheinlichkeit
noch in der EvaluierungFlussmarken (Flow Label)
Routern erkennen Datagrammfolge (Flow)Sender meldet Flow anSender legt Endzeit fest
Realzeitdiensten Abarbeitung innerhalb einer bestimmten ZeitAbarbeitung in richtiger Reihenfolge
noch in der Evaluierung
Seite 21 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Erweiterungsheader im IPv6optionaldirekt hinter Ipv6-HeaderRouter arbeitet (fast) nur ersten Header ab
Außer wenn Router Ziel istnächster Erweiterungsheader abgearbeitet bzw. Header des nächsthöheren Protokolls(Upper-Layer-Header)
nur Datenteil(hier TCP-Paket)
direkt an IPv6-Header angehängtim Next Header-Feld steht Wert für TCP (6)
Seite 22 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Erweiterungsheader im IPv6Routing-Header
zwischen IPv6-Header und TCP-Paket Next Header-Feld des Pv6-Headers: Routing (43)Next Header-Feld des Routing-Erweiterungsheader: TCP (6)
Seite 23 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Erweiterungsheader im IPv6Fragmentation-Header (neben Routing-Header)
zwischen IPv6-Header und TCP-Paket Next Header-Feld desPv6-Headers: Routing (43)Next Header-Feld desRouting-Erweiterungsheader Fragmentation (44)Next Header-Feld des Fragmentation-Erweiterungsheader:TCP (6)
Seite 24 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Erweiterungsheader im IPv6Next Header Feld: welcher Headertyp als nächstes Reihenfolge der Headertypen fest:
IPv6-HeaderHop-by-Hop Options-Header (Next Header = 0)Destination Options-Header (Next Header = 60)Routing-Header (Next Header = 43)Fragment-Header (Next Header = 44)Authentication-Header (Next Header = 51)Encapsulating Security Payload-Header (Next Header = 50)Destination Options-Header (Next Header = 60)Upper-Layer-Header (Next Header: TCP=6, UDP=17 usw.)
Seite 25 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Erweiterungsheader im IPv6Jeder Header nur einmal
außer Destination Options-Headernach Hop-by-Hop Options-Header vor Upper-Layer-Header
letzter Header / Erweiterungsheader Next-Header-Feld: 59 No-Next-Header
Optionen in DatagrammenHop-by-Hop Options-Header (0): werten nur Router ausDestination Options-Header (60): werten nur Empfänger auszur Zeit eine standardisierte Option
Nulloptionen (0=Länge 1 Byte, 1=Länge explizit)
Seite 26 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolRouting-Header (43)
Liste zu durchlaufender Adressenbis zu 127 Adressen
Länge des Extension Headers in 8 Bytes Left: Anzahl noch zu durchlaufender Stationen
Wert null,Routingheader von Router nicht mehr bearbeitet.
Router mit Destination-Adresse routet explizit (loose coupling)Zieladresse →DestinationSegments Left dekrementieren Datagramm weiterschicken
Seite 27 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolFragment-Header (44)
fragmentierte PaketeIPv6 keine Fragmentierung in Routern
sendende Station erzeugt Fragment in IPv6-Datagramme mit Fragment-Headern32 Bit lange IdentifikationQuell- und Zieladresse 13 Bit langer Fragment-Offset letzte Fragment: More-Bitmaximale Fragmentlänge
vom Pfad im Internetvom Absender gewählt 60 s Zeit für reassemble
Mindestgröße: 1280 Oktetteempfohlen: 1500 Oktette (Tunneling)MTU (maximum transmission unit per link) nach RFC 1981
Seite 28 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten in ICMPv6Internet Control Message Protocol für IPv6 (ICMPv6) Fehlerübermittlung andere Funktionen der Vermittlungsschicht RFC 2463
vollständige Implementierung von ICMPv6 obligatorisch
Aufbau der ICMPv6-Nachricht8 Bit Feld für den Typ der ICMPv6 Nachricht,8 Bit Feld für den Code der ICMPv6 Nachricht,16 Bit Feld für die Prüfsumme der ICMPv6 Nachricht.
Seite 29 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten in ICMPv6Prüfsumme
Über gesamte ICMPv6-Nachricht zuzüglich Pseudoheaders (ICMPv4 ohne)
Länge des ICMPv6-DatagrammsNext-Header-EintragQuell- und Zieladresse
mehrere einfache Zieladressen (unicast) Mehrfachadressen
Prüfsummenverfahren wie bei IPv6ICMPv6-Fehlermeldungen unbekannten Typs
an höhere Schicht weitergereichtICMPv6-Informationsmeldungen unbekannten Typs
Verworfen
Seite 30 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten in ICMPv6ICMPv6-Fehlermeldungen
möglichst viel Daten des Pakets
ICMPv6-Nachrichten dürfen nicht gesendet werdenwenn ICMPv6-Fehlermeldungen Fehler enthaltenbei Multicast- oder Broadcastadressen keine eindeutige Absenderadresse vorliegtMechanismen zur Beschränkung der ICMPv6-Nachrichtenrate
Seite 31 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolKontrollnachrichten ICMPv6
Destination Unreachable Message (1)Datagramm kann nicht weitergereicht werden
Außer bei Überlastung des ÜbertragungswegsGrund
Code 0: Der Router fand keinen passenden Eintrag in Routingtabelle (auch keine Default-Route).Code 1: Die Weiterleitung ist verbotenz.B. wegen eines Firewall-Filters.Code 3: Link ist nicht erreichbar; Adresse keinem Link zuordbar: Address unreachable.Code 4: kein Prozess kann Paket entgegennehmen: Port unreachble.Code 2 ist noch keine Bedeutung zugewiesen. Zieladresse Absenderadresse des verursachenden Datagramms Nachricht muss an Transportschicht weitergeleitet werden.
Seite 32 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten ICMPv6Packet Too Big Message (2)
Datagramm zu großKann nicht weitergereicht werden
An Transportschichtprotokoll zu übergebenBestandteil des Path MTU Discovery process
Ermittelt maximale Paketlänge auf Pfad
Seite 33 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten ICMPv6Time Exceeded Message (3)
Hop Limit-Zähler Wert nullCodewert 0
Reassemblierungszeit des Empfängers überschrittenCodewert 1
Nachricht an Transportschicht weiterleiten
Seite 34 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolKontrollnachrichten ICMPv6
Parameter Problem Message (4)Header oder Erweiterungsheader eines Datagramms können nicht bearbeitet werden32 Bit-Zeigerfeld zeigt Oktett, wo Fehler erkanntGrund
Code 0: fehlerhaftes Headerfeld entdeckt.Code 1: unbekannter Nextheader-Wert entdeckt.Code 2: unbekannte IPv6-Option entdeckt.
Fehlerhafte Nachricht wird verworfen.an Absenderadresse des verursachenden Datagramms diese Nachricht an Transportschicht weiterleitenBeispiel
ICMPv6-Nachricht: Typ 4, Code 1, Zeiger 40: Erweiterungsheader hinter IPv6-Header: unbekannter Nextheader-Wert
Seite 35 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten ICMPv6Die ICMPv6-Informationsnachrichten (128)
Echo-BeantwortungsfunktionAnwendungsschnittelle zur Verwendung dieser FunktionEcho Request Message
jeder legalen IPv6-Adresse Nachricht übersenden16 Bit-Identifier-Feld: mögliche Antwort zuordnen16 Bit-Sequence Number-Feld: Folge solcher Nachrichten organisierenAnzahl und Inhalt der Datenoktette optional
Seite 36 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Kontrollnachrichten ICMPv6Die ICMPv6-Informationsnachrichten (129)
Echo Reply MessageAntwort auf Echo-Reqest-Nachricht
Identifier-/Sequence Number-Feld von Anfrage kopiertAnzahl und Inhalt der Datenoktette kopiert
Absenderadresse: Empfängeradresse der Echo-ReqestMulticast-Adresse: Adresse, über welche Nachricht eintraf dem initierenden Prozess zuzustellenKönnen auch anderen Prozessen zugestellt werden
Seite 37 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Sicherheit beim ICMPv6Authentisierung und Verschlüsselung
mittels Authentisierungsheader identifizierbarwenn Zieladresse entsprechende Assoziation vorschreibt bei falscher Authentisierung: Datagram verwerfen Administrator soll sämtliche nicht authentisierte ICMPv6-Nachrichten verwerfen können
Verschlüsselung von ICMPv6-Nachrichten IP-Sicherheitsarchitektur RFC 2401 betrachtet.
Seite 38 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Sicherheit beim ICMPv6verschieden ICMP-Angriffsszenarien
1.Angreifer kann Absenderadresse einer ICMPv6-Nachricht verfälschen
durch Verwendung der Authentisiserung verhindert2.Angreifer kann Ziel einer ICMPv6-Nachricht verfälschen
z.B. durch geschützte Prüfsummen / Verschlüsselung verhindern3.Angreifer kann Daten e. ICMPv6-Nachricht verfälschen
durch Authentisierung oder Verschlüsselung verhindert4.Denial of Service-Angriff: Senden fehlerhafter IP-Pakete.
ICMPv6-Antworten nur senden bei ausreichenden Ressourcen
Seite 39 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolAdressstruktur in IPv6
Adresserweiterung mit 128 Bits (RFC 2373)drei Adresstypen verwendet bzw. in Planung
Unicast-Adressen spezifizieren genau ein ZielMulticast-Adressen spezifizieren eine Menge von ZielenDatagramme werden an jedes der Ziele gesendetAnycast-Adressen spezifizieren eine Menge von Zielen
nur eines ausgewähltdas räumlich nächste entsprechend Router-Topologie
Unicast-Adresse u.U. mehreren Schnittstellen zugeordnetz.B. zum Lastausgleich
Broadcast-Adressen stellen Teil der Multicast-AdressenIPv6-Adressen werden Schnittstellen, nicht Knoten zugeordnet.
Knoten kann mehrere IPv6-Adressen besitzenSchnittstelle kann IPv6-Adressen unterschiedlichen Typs habenmuss lokale IPv6-Adresse besitzen(nur auf angeschlossenem Link gültig)einem Link wird Subnetzadresse zugeordnet
Seite 40 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Notation der 128 Bit langen Adressen
acht 16 Bit-Blöcke jeweils vier Hexadezimalzahlengetrennt durch ':', z.B.
FEDC:BA98:7654:3210:FEDC:BA98:7654:32101080:0:0:0:8:800:200C:417A
Längere Nullfolgen durch '::' abgekürztnur einmal je Adresse vorkommen
1080:0:0:0:8:800:200C:417A eine Unicast-AdresseFF01:0:0:0:0:0:0:101 eine Unicast-Adresse0:0:0:0:0:0:0:1 Die Loopback-Adresse0:0:0:0:0:0:0:0 Die unspezifizierte Adresse
Seite 41 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6
kürzer darstellbar
1080:0:0:0:8:800:200C:417A eine Unicast-AdresseFF01:0:0:0:0:0:0:101 eine Unicast-Adresse0:0:0:0:0:0:0:1 Die Loopback-Adresse0:0:0:0:0:0:0:0 Die unspezifizierte Adresse
1080::8:800:200C:417A eine Unicast-AdresseFF01::101 eine Unicast-Adresse::1 Die Loopback-Adresse:: Die unspezifizierte Adresse
Seite 42 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Mischformen IPv4, IPv6
0:0:0:0:0:0:13.1.68.30:0:0:0:0:FFFF:129.144.52.38
die komprimierte Form::13.1.68.3::FFFF:129.144.52.38
Seite 43 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Anfangsstück heißt Präfix; spezifiziert durch
Adresse / Länge 60 Bit langer Präfix 12AB00000000CD316korrekt schreibbar als:12AB:0000:0000:CD30:0000:0000:0000:0000/6012AB::CD30:0:0:0:0/6012AB:0:0:CD30::/60
Präfix zu Adresse: adresse/12AB:0:0:CD30:123:4567:89AB:CDEF/60
Knotenadresse12AB:0:0:CD30:123:4567:89AB:CDEFPräfix: 12AB:0:0:CD30::/60.
Seite 44 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Adresstyp durch Präfix festgelegt
bisher folgende Adresstypen spezifiziert
reservierter Präfix auch für bestimmte Adressen verwendetLoopback eingebettete IPv4-Adressen
eigener Adressraum für NSAP und IPXGegenwärtig nur 15% des Adressraums belegt
Adreßtyp Präfixreserviert 0000 0000 / 8Aggregatable Global Unicast Addresses 001 / 3Link-Local Unicast Addresses 1111 1110 10 / 10Site-Local Unicast Addresses 1111 1110 11 / 10Multicast Addresses 111 111 / 8
Seite 45 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Unicast-Adressen
Pv6-Adressen können hierarchische Struktur besitzennicht jeder Router muss diese erkennen
IPv6-Adressen aus Linkadresse einer Schnittstelle gebildet 64 Bits von Herstellern der jeweiligen Hardware festgelegtIEEE vergibt dazu eine
24 Bit-Herstelleadresseeindeutige 40 Bit-Adresse vom Hersteller hinzufügt (EUI64)Ethernets verwendet nur 48 Bits für MAC-Adressen
Linkadresse enthält u (universal/local) Bit lokale Adresse bei Verwendung als IPv6-Adresse invertiertvereinfacht Schreibung lokaler Adressen
Seite 46 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Unicast-Adressen
::0 unspezifizierte AdresseWird niemals einer Schnittstelle zugewiesen keine ZieladresseAls Quelladresse wenn Host eigene Adresse noch nicht kennt
::1Loopback-Adresse niemals einer Schnittstelle zugewiesenniemals aus Host herausgeschickt niemals von Router weitergeleitet
Seite 47 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolAdressstruktur in IPv6
Unicast-AdressenIPv4-kompatiblen IPv6-Adresse(IPv4-compatible IPv6 address)
::<IPv4-adresse> (32 Bit lange IPv4-Adresse, 96 führende Nullen)
während Übergangszeit von IPv4 → IPv6 von IPv6-Routern benutzt Vermeidet aufwändige Adresstransformation
Seite 48 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Unicast-Adressen
IPv4-mapped IPv6 address ::FFFF:<IPv4-adresse>(32 Bit lange IPv4-Adresse; 80 führende 0en; 16 führende 1en) Hosts, welche kein IPv6-Adressierung beherrschen
Auch Abbildungen von NSAP-Adressen nach OSI-Basisreferenzmodell IPX-Adressen →Standards
Aggregatable Global Unicast Addressesvereinfachen Routing von Internetpaketen für Top-Level 13 Bitsfür nächsten Level 24 Bitsfür Sitelevel 16 Bits zusätzlich 64 Bit-Linkadresse
Seite 49 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Unicast-Adressen
linklokale Adresse (link local address)in lokalen Netzen bzw. In routerlosen Netze
unterstützen automatische Adressierung 1111111010::<Linkadresse>/10Router leiten diese nicht auf andere Links weiter
Bereichslokale Adressen (site local address)Zuweisung nur lokal verwendeter Adressen
1111111011::<Linkadresse>/10Router leiten diese nicht auf andere Bereiche weiter
Seite 50 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Multicast-Adressen
FF16PG:X...P=1: Permanent (dauerhaft gültig)P=2: Transient (nur begrenzte Zeit gültig)G: Gültigkeitsbereich
1: Knoten2: Link4. Site8: Organisation
Multicast-GruppeGruppenangabe von 112 Bit
Multicast-Adressen dürfen nicht verwendet werden als Quelladressen Routing-Header
Seite 51 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Multicast-Adressen
Aufgabe des RoutersDatagramm mit Multicast-Adresse an sämtliche Schnittstellen der zugehörigen Multicast-Gruppe senden
Well-Known-AdressenVordefinierte Multicast-Adressen 16 Reserved Multicast-Adressen
FF00::0, FF01::0, ... FF0F::0 FF01::1 und FF02::1
alle Schnittstellen-Adressen in Gültigkeitsbereichen 1 und 2 ersetzen Broadcast-Adressen von IPv4
FF01::2, FF02::2 und FF05::2alle Router in den Gültigkeitsbereichen 1, 2 und 5
Seite 52 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
Adressstruktur in IPv6Multicast-Adressen
Well-Known-AdressenSolicited-Node Address
Präfix FF02:0:0:0:0:1:FF00/10424 Bit an diesen Präfix angehängtalle Schnittstellen, deren IPv6-Adressen in den unteren 24 Bits die gleichen Werte haben
Permanente Multicast-Gruppenbisher nur durch die unteren 32 Bits unterschieden (FFPG::<gruppe>/96)berechnet schneller Abbildung Multicast-Adresse → MAC-Adresse
Seite 53 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolAdressstruktur in IPv6
Multicast-AdressenHost empfängt Datagramme mit folgenden Adressen
Link-Lokale Adresse für jede Schnittstelle.Zugewiesene Unicast-Adresse.Loopback-Adresse.Multicast Adressen für alle Knoten (Broadcast).Solicited-Node Multicast-Adresse jede zugewiesenenUni- und Anycast-Adresse.Multicast-Adressen für alle anderen Gruppen, denen Host angehört
Router erkennt zusätzlich folgende AdressenSubnetzrouter-Anycast-Adressen Router-Interface als Router konfiguriertAlle weiteren Anycast-Adressen, für welche Router konfiguriertMulticast Adressen für alle Router.Multicast Adressen für alle anderen Gruppen, denen Router angehört
Seite 54 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolAdressstruktur in IPv6
Multicast-Adresseneinzige Adresspräfixe, die in Implementierung vordefiniert
Unspezifizierte Adresse.Loopback-Adresse.Multicast-Präfix (FF...).Lokale Präfixe (Link-lokal FF11:.. und Link-lokal FF12:..).Vordefinierte Multicast-Adressen.IPv4-kompatible Präfixe.
Seite 55 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet ProtocolAdressstruktur in IPv6
Anycast-Adresseneine Schnittstelle einer Menge von Schnittstellen
gleiche syntaktische Form wie Unicast-AdressenMind. nicht leerer Präfix für die Region
Router müssen Mitglieder der Anycast-Menge kennen wählen "toplogisch naheste" Ziel aus
Subnet-Router-Anycast-Adressevordefinierte Anycast-AdressePakete werden an nächsten Router in Subnetz geleitetbesteht aus Subnetzpräfix, gefolgt von Nullen
andere Anwendung für Anycast-AdressenInformationsdienst oder Internetprovider Pakete stets zm nächsten Server geleitet Gegenwärtig dürfen nur Router als Ziele verwendbar
mobiler Host mit Routern seines lokalen NetzesReihe von Beschränkungen
instabile Netze
Seite 56 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPsecAuthentisierungsheader (Authentication Header)
Datenintegrität, Authentisierung Schutz vor Wiederholung
Seite 57 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPsecEncapsulating Security Payload-HeaderESP-Header
Vertraulichkeit Verschlüsselung Verkehrfluß-vertraulichkeit DatenintegritätAuthentisierung Schutz vor Wiederholung Austausch krypto-graphischer Schlüssel
Zugangskontrolle
Seite 58 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPsecBeide Header kombinierbar
Teilweise redundante Funktion
Seite 59 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPsecSecurity Associations
Gesicherte Verbindung (auf IP!)Verschieden ModeTransport-Verbindung
Verbindung zweierEndpunkte (Hosts)Verschlüsselung undAuthentisierung getrennt
TunnelInterne- und externeHeaderZiel-Adresse verschlüsseltVerkehrflussvertraulichkeit
Seite 60 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPsecDaten in Datenbanken gespeichert
SPD: Security Policy DatabaseBeschreibt allgemeine SicherheitsstrategieVom Administrator eingerichtet
SAD: Security Association DatabaseBeschreibt Parameter einer Verbindung
SchlüsselZähler
Bei jeder neuen (IP-)Verbindung einzurichten
Seite 61 Rechnernetze 1 Prof. Dr. W. Kowalk
Internet ProtocolInternet Protocol
IPsecKritikpunkte
Komplexität des Protokollsschlechte Dokumentation
Beweggründe für einzelne EntwurfsentscheidungenZu viele VariantenKomplexität unnötig vergrößertAuthentifizierungsheader und Transportmodus im Prinzip vollständig überflüssigIP ist verbindunglos!
Recommended