Vorlesung. Rechnernetze I Teil 10. Wintersemester 2005/2006

Transkript

1 Vorlesung Rechnernetze I Teil 10 Wintersemester 2005/2006 Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze

2 Rückblick Teil 9 IP und ICMP Funktion von traceroute Fragmentierung von IP-Paketen Adressierung in IP Version 4 Default Gateway und Network Mask Classful IP Addressing und Classless InterDomain Routing Dynamic Host Configuration Protocol Network Address Translation Routing Protokolle RIP OSPF BGP C. Grimm 21. Dezember 2005 Folie 2

3 Übersicht Teil 10 Multicast Adressierung Umsetzung und Architektur Multicast Routing Shared Tree Routing: Steiner Tree und Center-based Tree Source Based Tree Routing: Shortest Path Tree und Reverse Path Forwarding IPv6 Motivation Adressierung Migration von IPv4 nach IPv6 Mobile IP Motivation und Terminologie mögliche Umsetzung der Mobilität in IP Mobile IPv4 Verbesserungen von Mobile IPv4 C. Grimm 21. Dezember 2005 Folie 3

4 Allgemeine Adressierungsarten (vgl. Teil 1, Seite 10) Unicast Adresse Adressierung eines einzelnen aus n erreichbaren Interfaces Kardinalität: 1:1 (wobei 1 aus n ist) n=7 Multicast Adresse Adressierung einer Gruppe von m aus n erreichbaren Interfaces Kardinalität: 1:m (m=1 ist Unicast, m=n ist Broadcast) m=3 n=7 Anycast Adresse Adressierung eines einzelnen aus einer Gruppe von m aus n erreichbaren Interfaces Kardinalität: 1:1 (wobei 1 aus m ist, m=n ist möglich) m=3 n=7 Broadcast Adressierung aller n erreichbaren Interfaces Kardinalität: 1:n n=7 C. Grimm 21. Dezember 2005 Folie 4

5 Multicast Routing Ziel von Multicast aus Sicht einer Anwendung mit einem Aufruf von sendto () werden Daten an eine Gruppe von Hosts gesendet drei mögliche Ansätze zu jedem Host werden explizit die Daten gesendet: Abbildung durch Unicast Hosts leiten untereinander Daten weiter: Abbildung durch Unicast Router vervielfältigen und verteilen Daten: Multicast Fragen 1. wie werden Gruppen von Hosts adressiert? 2. wie kann ein Host einer Gruppe beitreten und eine Gruppe verlassen? 3. wie können alle Hosts einer Gruppe auch über ein WAN! erreicht werden? Antwort auf 1. Frage in IPv4 werden Class D Adressen für Adressierung von Multicast Gruppen verwendet Präfix ist die restlichen 28 Bit werden zur Identifizierung verschiedener Gruppe verwendet d. h. es sind 2 28 verschiedene Gruppen möglich C. Grimm 21. Dezember 2005 Folie 5

6 Multicast Routing: One-to-all Unicast Ansatz Router unterstützen nur Unicast Sender sendet IP-Pakete an alle Empfänger einer Multicast Gruppe d. h. Multicast wird durch Unicast zwischen den Hosts abgebildet Empfänger in Multicast Gruppe Sender in Multicast Gruppe Empfänger in Multicast Gruppe Empfänger in Multicast Gruppe Probleme dem Sender müssen alle Hosts der Gruppe bekannt sein Verfahren skaliert nicht, für große Anzahl Empfänger nicht durchführbar C. Grimm 21. Dezember 2005 Folie 6

7 Multicast Routing: Application-level Multicast Ansatz Router unterstützen nur Unicast Sender sendet IP-Paket an einen Empfänger der Multicast Gruppe Empfänger leiten IP-Pakete untereinander weiter d. h. Multicast wird durch Unicast zwischen den Hosts abgebildet Empfänger in Multicast Gruppe Sender in Multicast Gruppe Empfänger in Multicast Gruppe Empfänger in Multicast Gruppe Probleme Performance wie wird sichergestellt, dass alle Hosts erreicht werden? wie erfährt Sender, ob und wann alle Hosts erreicht wurden? C. Grimm 21. Dezember 2005 Folie 7

8 Multicast Routing: Explicit Multicast Ansatz Router unterstützen Multicast IP-Pakete werden im Netz dupliziert und verteilt kann nur für UDP funktionieren das ist für Multimedia-Conferencing allerdings ok Empfänger in Multicast Gruppe Sender in Multicast Gruppe Empfänger in Multicast Gruppe Empfänger in Multicast Gruppe Probleme wie wird durchgehendes Netz aus Multicast Routern gebildet? wie wird sichergestellt, dass alle Hosts erreicht werden? wie erfährt Sender, ob und wann alle Hosts erreicht wurden? C. Grimm 21. Dezember 2005 Folie 8

9 Multicast Routing Ansatz Hosts melden sich über Router an Multicast-Gruppe an und erhalten deren IP-Adresse IP-Pakete werden an IP-Adresse der Multicast-Gruppe gesendet Router leiten IP-Pakete zu allen Hosts in der entsprechenden Multicast-Gruppe grundsätzliche Policy jeder Host kann einer Multicast-Gruppe beitreten jeder Host kann Daten an eine Multicast-Gruppe senden C. Grimm 21. Dezember 2005 Folie 9

10 Multicast Routing: Architektur zweistufiger Ansatz Registration: Hosts melden sich über IGMP bei lokalem Multicast-Router an IGMP: Internet Group Management Protocol Routing: Router tauschen Multicast-Informationen über eigene Protokolle aus DVMRP: Distance Vector Multicast Routing Protocol MOSPF: Multicast Open Shortest Path First PIM: Protocol Independent Multicast und weitere IGMP MOSPF PIM DVMRP IGMP IGMP IGMP C. Grimm 21. Dezember 2005 Folie 10

11 Multicast Routing Ziel: finde geeignete Wege zwischen allen Hosts einer Multicast-Gruppe Shared Tree: ein gemeinsamer Routing-Baum zwischen allen Routern Steiner Tree Center-based Tree Source Based Tree: jeder Router verwendet eigene Routen Shortest Path Tree Reverse Path Forwarding Shared Tree Source based Trees C. Grimm 21. Dezember 2005 Folie 11

12 Shared Tree Routing 1: Steiner Tree Ziel ermittle einen Baum über alle Router mit geringsten Kosten mögliche Lösung Steiner Tree (Minimal Spanning Tree) 3 4 Eigenschaften Variation von Travelling Salesman-Problem ebenfalls NP-komplexes Problem Nachteile Steiner Tree setzt Informationen über alle Routen und Kosten voraus bei Änderungen von Routern, Routen oder Kosten neue Berechnung notwendig starke Änderungen der gewählten Pfade möglich Steiner Tree ist akademisch interessant, in der Praxis aber nicht relevant C. Grimm 21. Dezember 2005 Folie 12

13 Shared Tree Routing 1: Instabilität Steiner Tree Annahme: alle Links mit identischen Kosten Ausgangssituation Quelle ist C Ziele sind A und D A B C Pfad ist CBAD D E weiteres Ziel E A B Quelle ist C Pfad CBAD schwenkt auf CEDA D E C weiteres Ziel B A B Quelle ist C Pfad CEDA schwenkt auf CEBAD D E C C. Grimm 21. Dezember 2005 Folie 13

14 Shared Tree Routing 2: Center-based Tree Ansatz ein Router wird als Zentrum (Center, Rendevous Point, Core) des Baums bestimmt andere Router senden per Unicast Join-Messages an Center Router Join-Message trifft entweder auf Center Router oder vorher auf Zweig des Baumes der Pfad, den die Join-Message zurückgelegt hat, wird neuer Zweig des Baumes Ablauf E ist Center Router für eine Multicast-Gruppe 1. F schließt sich Multicast-Gruppe an direkter Weg zum Center Router E A 3. B 2. B schließt sich Multicast-Gruppe an Weg über D zum Center Router E C A schließt sich Multicast-Gruppe an Anschluss über B Probleme F 1. E 2. D G Bestimmung des Center Router Verbreitung der Adresse des Center Router C. Grimm 21. Dezember 2005 Folie 14

15 Source-based Tree 1: Shortest Path Tree Erinnerung an Dijkstra s Algorithmus berechnet die least-cost Pfade von der Quelle zu allen Zielen (Unicast) Ansatz für Multicast Vereinigung aller über Dijkstra ermittelten Pfade liefert least unicast-cost path tree entspricht bei identischen Kosten shortest unicast path tree Nachteile Dijkstra s Algorithmus setzt Informationen über alle Routen und Kosten voraus bei Änderungen von Routern, Routen oder Kosten sind neue Berechnungen notwendig Ansätze nach Shortest Path Tree sind in der Praxis nicht relevant C. Grimm 21. Dezember 2005 Folie 15

16 Source-based Tree 2: Reverse Path Forwarding Algorithmus: Reverse Path Forwarding (RPF) Router R erhält Multicast IP-Paket von Source S auf Link L Annahme: R kennt Unicast Shortest Path von S zu R eigene Routing-Tabelle enthält allerdings nur Shortest Path von R zu S d. h. neben Routing-Tabelle muss Router jetzt auch eine RPF-Tabelle pflegen! prüfe: L ist Link für Unicast Shortest Path von S zu R wenn ja: leite IP-Paket auf allen anderen Links von R weiter wenn nein: verwerfe IP-Paket Ablauf A ist Quelle, d. h. IP-Paket enthält Quell-Adresse von A A grüne/dicke Linien kennzeichnen least-cost Pfad von jeweiligen Routern zu A 1. A sendet Pakete an B und C 2. B leitet Paket an C und D, C ignoriert C C leitet Paket an B, E und F; B ignoriert 3. D leitet Paket an E und G; E ignoriert E leitet Pakete an E und D; beide ignorieren F leitet Paket an E; E ignoriert F E B D G C. Grimm 21. Dezember 2005 Folie 16

17 Source-based Tree 2: Reverse Path Forwarding Problem Router D und G erhalten Multicast-Pakete, obwohl keine Multicast-Router oder Multicast-Hosts angeschlossen sind Router und Netze werden unnötigerweise mit Multicast-Paketen geflutet Baum enthält Zweige, in denen temporär kein Multicast-Verkehr benötigt wird Lösung: Pruning (Abschneiden) Ablauf 1. G sendet nach Erhalt eines Multicast-Pakets von D eine Prune-Message zurück 2. D stoppt Übertragung von Multicast-Paketen an G und entfernt G aus Baum 3. da D keine Multicast-Router oder Multicast-Hosts versorgt, sendet D Prune-Message an B 4. B stoppt Übertragung von Multicast-Paketen an D und entfernt D aus Baum C A B D F E G C. Grimm 21. Dezember 2005 Folie 17

18 Internet Protocol Version 6 (IPv6) Motivation für IPv6: Schwächen von IPv4 IPv4-Adresse umfasst lediglich 32 Bit, d. h. sehr begrenzter Adressraum schlechte Performance auf jedem Router muss Prüfsumme neu berechnet werden IPv4-Header kann variable Länge aufweisen, d. h. aufwändiges Parsing fehlende Features keine ausreichende Unterstützung von Serviceklassen und Dienstgüte Eigenschaften von IPv6 IPv6-Adresse umfasst 128 Bit (16 Byte), d. h. IPv4-Adressraum wird 96 mal verdoppelt ermöglicht auch verbesserte hierarchische Strukturierung der IP-Adressbereiche bessere Performance Verzicht auf Prüfsumme Verzicht auf Fragmentation im Standard IPv6-Header (nur über Extension Header möglich) Länge des Headers beträgt konstant 40 Byte, d. h. einfaches Parsing neue Features Flow-Label und Traffic Class für verbesserte Quality of Service (siehe Rechnernetze II) Verschlüsselung und Authentisierung (Anlehnung an IPSec) Anycast: IPv6-Paket wird an genau einen aus einer Menge von Knoten gesendet C. Grimm 21. Dezember 2005 Folie 18

19 Übersicht der Versionen von IP 0 IP March 1977 version deprecated 1 IP January 1978 version deprecated 2 IP February 1978 version A deprecated 3 IP February 1978 version B deprecated 4 IPv4 September 1981 version current widespread 5 ST Stream Transport not a new IP, little use 6 IPv6 December 1998 version formerly SIP and SIPP 7 CATNIP IP next Generation evaluation formerly TP/IX; deprecated 8 PIP IP next Generation evaluation deprecated 9 TUBA IP next Generation evaluation deprecated unassigned Quelle: Cisco SIP/SIPP Simple Internet Protocol (Plus), Name einer IETF Working Group CATNIP CATNIP: Common Architecture for the Internet (RFC 1707, Oktober 1994) ehem. Common Architecture Technology for Next-generation Internet Protocol PIP General Purpose Internet Protocol (?) (RFCs 1621 und 1622, Mai 1994) TUBA TCP and UDP with Bigger Addresses (RFC 1347, Juni 1992) auch Name der IETF Working Group TCP/UDP over CLNP-Addressed Networks (TUBA) mit CLNP: Connectionless Network Protocol, ISO 8473 C. Grimm 21. Dezember 2005 Folie 19

20 Bedarf an IP-Adressen Verhältnis von vergebenen zu verfügbaren IPv4-Adressen seit 1995 ist Dank CIDR, NAT und DHCP ein gebremster Anstieg zu erkennen 100 % 75 % 50 % 25 % 0 % Quelle: IANA Zukunft: neue Nutzer und Anwendungen erfordern eindeutige Adressen ein besonders hoher Bedarf für neue Adressen wird in Asien (China, Indien) erwartet generell fordert Erreichbarkeit (z. B. für Multimedia-Conferencing) eindeutige Adressen Beispiel UMTS: jedes Endgerät (Handy) erhält eigene IP-Adresse C. Grimm 21. Dezember 2005 Folie 20

21 Vergleich der Adressräume von IPv4 und IPv6 IPv4: 32-Bit Adressen ergibt verschiedene Adressen (in Worten: ca. 4,3 Milliarden) entspricht 0, IPv4-Adressen pro m 2 Erdoberfläche IPv6: 128-Bit Adressen ergibt verschiedene Adressen mit IPv6 wird der Adressraum von IPv4 96x verdoppelt entspricht IPv6-Adressen pro m 2 Erdoberfläche alternatives Beispiel für anschauliche Darstellung der Größenordnung auf das erste Feld eines Schachbretts wird ein (=2 0 ) Reiskorn gelegt auf jedem weiteren Feld wird die Anzahl der Reiskörner verdoppelt (2 1, 2 2, 2 3,...) d. h. auf dem letzten Feld liegen Reiskörner die Summe über alle Felder des Schachbretts ergibt Reiskörner diese Menge entspricht bei einem Gewicht von 0,025 g pro Reiskorn 461 Mrd. Tonnen Reis Anmerkung: die Reisernte des Jahres 2000 betrug lt. wikipedia.de weltweit ungefähr 431 Mio. Tonnen jedem Reiskorn auf dem Schachbrett können 2 64 eindeutige IPv6-Adressen zugewiesen werden 2 64 = (in Worten: 18,5 Trillionen) Anmerkung: es stehen nicht wirklich alle IPv6-Adressen zur Verfügung... C. Grimm 21. Dezember 2005 Folie 21

22 Vergleich von IPv4- und IPv6-Header IPv4-Header IPv6-Header 32 Bit 32 Bit Ver. Hdr Len Type of Service Total Length Ver. Traffic Class Flow Label Identification Flg Fragment Offset Payload Length Next Header Hop Limit min. 20 Byte Time to Live Protocol Source Address Checksum Destination Address Options Padding Source Address genau 40 Byte Feld entfällt in IPv6 Feld in IPv4 und IPv6 enthalten Destination Address Name und Position in IPv6 verändert neues Feld in IPv6 C. Grimm 21. Dezember 2005 Folie 22

23 Besondere Felder im IPv6-Header Traffic Class und Flow Label beide Felder sind für Priorisierung und Nutzung von Service Levels vorgesehen das Feld Traffic Class wird in einzelnen IP-Paketen gesetzt durch ein Flow Label wird eine Folge mehreren IP-Pakete gekennzeichnet die exakte Bedeutung eines Flows ist bisher nicht festgelegt vorgesehen für die Kennzeichnung eines besondere Datenflusses, z. B. Streaming mit Echtzeitanforderung allg. priorisierter Verkehr aufgrund höherer Tarifierung weitere Betrachtung in Rechnernetze II Verwendung des Next Header kennzeichnet Transportprotokoll, z. B. 6 für TCP oder 17 für UDP andere Werte geben an, dass das IP-Paket zunächst so gen. Extension Header enthält über Extension Header werden Optionen in IPv6 realisiert Kaskadierung mehrerer Extension Header möglich Nutzdaten folgen auf letzten Extension Header C. Grimm 21. Dezember 2005 Folie 23

24 Realisierung der Extension Header spezifizierte Extension Header Hop-by-Hop Options Destination Option Ver. Traffic Class Flow Label Payload Length Next Header Hop Limit Routing Fragment Authentication Source Address genau 40 Byte Encapsulating Security Payload Destination Address Anmerkungen Next Header Extension Header #1 variabel Reihenfolge ist bei Bearbeitung der Extension Header wichtig Next Header Extension Header #2 variabel jeder Extension Header besitzt eigenes Format Spezifizierung neuer Extension Header ist möglich Payload (TCP, UDP Paket) variabel C. Grimm 21. Dezember 2005 Folie 24

25 Darstellung von IPv6-Adressen bevorzugte Darstellung acht 16-Bit Teile hexadezimal dargestellt durch Doppelpunkt voneinander getrennt führende Nullen können weggelassen werden Beispiele 1234:5678:9ABC:DEF0:1234:5678:9ABC:DEF0 1080:0000:0000:0000:0008:0800:200C:417A 1080:0:0:0:8:800:200C:417A vereinfachte Darstellung 16-Bit Gruppen mit dem Wert 0 können komplett ausgelassen werden aufeinander folgende Auslassungen können zusammengefasst werden Beispiel Vereinfachung 1: 1080::::8:800:200C:417A Vereinfachung 2: 1080::8:800:200C:417A C. Grimm 21. Dezember 2005 Folie 25

26 Darstellung von IPv6-Adressen gemischte Darstellung nützlich in gemischten IPv4/IPv6-Umgebungen die letzten 32-Bit (entspricht IPv4-Adresse) werden als dotted quad dargestellt IPv4-compatible IPv6 address: für Tunnel durch IPv4-Netze (siehe unten) IPv4-mapped IPv6 address: stellt IPv4-Adressen als IPv6-Adressen dar Beispiele 0000:0000:0000:0000:0000:0000: (IPv4 compatible IPv6 address) 0000:0000:0000:0000:0000:FFFF: (IPv4 mapped IPv6 address) Nibble-Format Einträge im DNS für Rückwärtsauflösung jeweils 4 Bit werden durch einen Punkt voneinander getrennt hexadezimale Schreibweise Adresse wird rückwärts geschrieben, Domäne ip6.int wird angehängt Beispiel mit IPv6-Adresse von vorhergehender Folie A.7.1.A.4.C ip6.int C. Grimm 21. Dezember 2005 Folie 26

27 Vergabe von IPv6-Adressen Vergaberichtlinie sieht zunächst drei verschiedene IPv6-Adressbereiche vor IAB, IESG. IAB/IESG Recommendations on IPv6 Address Allocation to Sites. RFC 3177, IETF, September 2001 /48-Präfix: der Normalfall für kleine und große Einrichtungen so gen. Home network -Teilnehmer mit on-demand - oder always-on -Verbindungen größere Teilnehmer erhalten mehrere /48 Präfixe oder einen geringfügig kürzeren Präfix /64-Präfix: wenn genau ein Subnetz benötigt wird Netzwerke in Fahrzeugen Mobiltelefone mit zusätzlichen Netzwerk-Interfaces, um direkt mit anderen Geräten zu kommunizieren /128-Präfix: wenn genau eine Adresse benötigt wird einzelnes Gerät zusätzlich werden IPv6-Adressen nach verschiedenen Reichweiten unterschieden von 16 möglichen sind derzeit 6 verschiedene Reichweiten definiert (3 reserviert, 7 frei) C. Grimm 21. Dezember 2005 Folie 27

28 Reichweiten von IPv6-Adressen wichtig unklar veraltet unklar wichtig wichtig Node-Local Scope (auch Interface-Local Scope oder Loopback genannt) für lokale Interprozess-Kommunikation vergleichbar mit IPv4-Adresse Link-Local Scope Kommunikation innerhalb einer Broadcast-Domain (s. Teil 12) Admin-Local Scope kleinste Reichweite die administrativ konfiguriert werden muss Adressen können nicht von physikalischen Gegebenheiten abgeleitet werden Site-Local Scope für Kommunikation innerhalb einer Einrichtung, ohne den Bedarf eines globalen Präfix Organization-Local Scope umfasst mehrere Site-Local Scope Bereiche Global Scope weltweite Gültigkeit C. Grimm 21. Dezember 2005 Folie 28

29 Global Unicast Adressen Aufbau Network Prefix Global Routing Prefix Subnet ID Interface ID n Bit 64 n Bit 64 Bit Eigenschaften Unterteilung des Network Prefix lässt hierarchische Adressierung zu das Netz 2001:0600::/23 ist dem RIPE NCC zugewiesen (aus Sicht des RIPE NCC ist n=23) das Netz 2001:0638::/32 ist dem DFN zugewiesen (aus Sicht des DFN ist n=32) der DFN vergibt davon Subnetze mit 16 Bit an angeschlossene Einrichtungen 2001:0638:0606::/48 ist der Uni Hannover vom DFN zugewiesen (aus Sicht der UH ist n=48) Uni Hannover kann restliche 16 Bit für Adressierung von lokalen Einrichtungen verwenden 2001:0638:0606:0001::/64 ist ein IPv6-Netz am LG Rechnernetze (aus Sicht des RVS ist n=64) Interface ID wird aus Hardware-Adresse generiert (siehe Folie 30) Anmerkung Unterteilung zwischen Global Routing Prefix und Subnet ID je nach Sichtweise siehe oben, genanntes Beispiel mit wechselnden n C. Grimm 21. Dezember 2005 Folie 29

30 Interface ID im modifizierten EUI-64 Format Aufbau und Generierung Grundlage ist die Hardware-Adresse eines Netzwerk-Interface die Hardware-Adresse eines Netzwerk-Interface wird im Data Link Layer spezifiziert die Hardware-Adresse eines Netzwerk-Interface umfasst in der Regel 48 Bit z. B. MAC-Adresse in Ethernet zwischen Company ID (c) und Extension ID (x) wird die Folge FF FE 16 eingefügt das universal/local Bit in der Company ID wird auf 1 gesetzt Ausnahme: alle Hardware-Adressen, die mit beginnen Anmerkung 48 Bit MAC-Adresse cccc ccug cccc cccc cccc cccc xxxx xxxx xxxx xxxx xxxx xxxx universal/local Bit wird von 0 nach 1 invertiert FF FE cccc ccug cccc cccc cccc cccc xxxx xxxx xxxx xxxx xxxx xxxx 64 Bit Interface ID die Nutzung der Hardware-Adresse zur Bildung der Interface ID ist nicht zwingend, wird aber wegen weitgehend automatischer Generierung von IPv6-Adressen empfohlen C. Grimm 21. Dezember 2005 Folie 30

31 Weitere Adressen in IPv6 weitere Unicast Adressen (Aufbau von Global Unicast Adresse siehe oben) Unspecified Address ist 0:0:0:0:0:0:0:0 Präfix 0::/64, Interface-ID wird auf 0 gesetzt Interface-Local Scope Adresse ist 0:0:0:0:0:0:0:1 Präfix 0::/64, Interface-ID wird auf 1 gesetzt Link-Local Scope Adressen haben Präfix FE80::/10 bzw Site-Local Scope Adressen haben Präfix FEC0::/10 bzw Anycast Adressen haben keinen syntaktischen Unterschied zu Unicast-Adressen dürfen nur Ziel-Adresse d. h. nicht Quell-Adresse sein dürfen nur Netzwerk-Interfaces in Routern d. h. nicht Hosts zugewiesen werden Routing zum nächstgelegenen Netzwerk-Interface mit der Anycast-Adresse Auswahl des nächstgelegenen Netzwerk-Interface anhand Distanzen aus Routing- Protokollen Multicast Adressen Präfix FF::/8 bzw , 4 Bit für Flags, 4 Bit für Scope und 112 Bit für Gruppe C. Grimm 21. Dezember 2005 Folie 31

32 Migration von IPv4 nach IPv6 Situation Annahme: IPv6 wird kommen Gründe dafür siehe Folie 21 IPv4 ist derzeit auf allen Knoten (Hosts und Router) im Internet implementiert ein Übergang von IPv4 auf IPv6 zu einem fixen Termin (Flag Day) ist nicht möglich würde Implementierung von IPv6 auf allen Knoten voraussetzen Anmerkung: der Übergang von NCP zu TCP fand am 2. Januar 1983 statt (Flag Day) daraus folgt, dass der Übergang von IPv4 zu IPv6 nur kontinuierlich erfolgen kann d. h. Mischbetrieb von IPv4 und IPv6 ist über längeren Zeitraum notwendig Ansätze für Mischbetrieb von IPv4 und IPv6 Dual Stack ausgewählte Router verfügen über IPv4- und IPv6-Stack Router können zwischen beiden Protokollen übersetzen Tunneling IPv6-Pakete werden als Nutzdaten in IPv4-Pakete eingepackt und über IPv4-Router ohne IPv6-Stack übertragen C. Grimm 21. Dezember 2005 Folie 32

33 Migration von IPv4 nach IPv6: Dual Stack Ansatz Dual-Stack Router B und E verfügen über IPv6- und IPv4-Stack Router B und E können IPv4- in IPv6-Pakete konvertieren und umgekehrt A B C D E F IPv6 IPv6 IPv4 IPv4 IPv4 IPv6 IPv4 IPv6 Flow x Src A 6 Dest F 6 Src A 4 Dest F 4 Src A 4 Dest F 4 Src A 4 Dest F 4 Flow? Src A 6 Dest F 6 data data data data data IPv6 IPv4 IPv4 IPv4 IPv6 Anmerkungen Probleme bei Umsetzung der IPv6-Adressen in IPv4-Adressen (nicht bei IPv4 in IPv6!) einige Optionen im Header von IPv6 lassen sich nicht in IPv4 abbilden Extension Header können nicht durchgereicht werden C. Grimm 21. Dezember 2005 Folie 33

34 Migration IPv4 nach IPv6: Tunneling IPv6-Pakete werden in IPv4-Pakete eingepackt und über IPv4-Strecken übertragen A B C D E F IPv6 IPv6 IPv4 IPv4 IPv4 IPv6 IPv4 IPv6 Flow x Src B 4 Dest E 4 Src B 4 Dest E 4 Src B 4 Dest E 4 Flow x Src A 6 Dest F 6 Flow x Flow x Flow x Src A 6 Dest F 6 data Src A 6 Dest F 6 Src A 6 Dest F 6 Src A 6 Dest F 6 data IPv6 data data data IPv6 Anmerkungen IPv4 IPv4 IPv4 transparente Übertragung von IPv6: aus Sicht von A und F existieren C und D nicht! Tunnel zwischen Router B und E muss in der Regel manuell konfiguriert werden IPv6-Pakete mit max. Payload müssen in Router B fragmentiert werden C. Grimm 21. Dezember 2005 Folie 34

35 Mobile IP Ziele Ubiquitous Computing über ein mobiles Endgerät überall Zugang zum Internet erhalten überall Zugang zu allen gewünschten Diensten und Daten erhalten überall erreichbar sein Forderungen an Mobilität in IP Zuweisung einer IP-Adresse (Frage: ist die Adresse beliebig oder eindeutig?) Routing der IP-Adresse Einordnung von Mobilität in IP keine Mobilität hohe Mobilität Wechsel zwischen Access Points eines WLAN, aber innerhalb eines IP-Netzes Micro Mobility Wechsel zwischen verschiedenen IP-Netzen, wobei Gerät aus- und wieder eingeschaltet wird Wechsel zwischen verschiedenen IP-Netzen, wobei kontinuierlich Daten übertragen werden Macro Mobility C. Grimm 21. Dezember 2005 Folie 35

36 Abgrenzung von Micro und Macro Mobility Internet IP-Netz A IP-Netz B IP-Netz C Access Points tritt auf z. B. bei Übergang zwischen Häufigkeit der Übergänge ist Aufgabe des Micro Mobility verschiedenen Access Points hoch Data Link Layer (Ebene 2) Macro Mobility verschiedenen IP-Subnetzen gering Network Layer (Ebene 3) C. Grimm 21. Dezember 2005 Folie 36

37 Terminologie in Mobile IP Mobile Node mobiles Endgerät Permanent Address dauerhafte IP-Adresse des mobilen Endgeräts im Home Network Internet Home Network permanentes (originäres) Heimatnetz des mobiles Endgeräts C. Grimm 21. Dezember 2005 Folie 37

38 Terminologie in Mobile IP Mobile Node mobiles Endgerät Permanent Address dauerhafte IP-Adresse des mobilen Endgeräts im Home Network Foreign Network Netz, in dem sich mobiles Endgerät temporär aufhält Internet Home Network permanentes (originäres) Heimatnetz des mobiles Endgeräts Correspondent will mit mobilem Endgerät unabhängig von dessen Aufenthaltsort kommunizieren C. Grimm 21. Dezember 2005 Folie 38

39 Umsetzung Mobilität Ansatz 1 Lösung: dynamische Adressvergabe über DHCP DHCP-Server in Foreign Network liefert dynamische IP-Adressen mobiles Endgerät erhält neue IP-Adresse aus Foreign Network Home Network Internet Foreign Network DHCP-Server C. Grimm 21. Dezember 2005 Folie 39

40 Umsetzung Mobilität Ansatz 1 Lösung: dynamische Adressvergabe über DHCP DHCP-Server in Foreign Network liefert dynamische IP-Adressen mobiles Endgerät erhält neue IP-Adresse aus Foreign Network Vorteil standardisiertes Verfahren in vielen Netzen bereits verfügbar Nachteil: neue IP-Adresse ist ungleich Permanent Address IP-basierte Authentifizierung bei Zugriff auf Home Network scheitert DNS-Auflösung liefert noch Permanent Address dem Correspondent muss neue Adresse des Mobile Node mitgeteilt werden Änderung der IP-Adresse führt zur Unterbrechung der Übertragung Fazit: die Permanent Address sollte in Foreign Network erhalten bleiben C. Grimm 21. Dezember 2005 Folie 40

41 Umsetzung Mobilität Ansatz 2 Lösung: die Umsetzung der Mobilität ist Aufgabe des Routing mobiles Endgerät behält Adresse aus Home Network Border Router in Foreign Network annonciert IP-Adresse des mobilen Endgeräts Erinnerung: durch Classless InterDomain Routing (CIDR) möglich, siehe Teil Home Network /16 Internet / /32 Foreign Network / C. Grimm 21. Dezember 2005 Folie 41

42 Umsetzung Mobilität Ansatz 2 Lösung: die Umsetzung der Mobilität ist Aufgabe des Routing mobiles Endgerät behält Adresse aus Home Network Border Router in Foreign Network annonciert IP-Adresse des mobilen Endgeräts Erinnerung: durch Classless InterDomain Routing (CIDR) möglich, siehe Teil 9 Vorteile mobiles Endgerät behält IP-Adresse aus Home Network keine Änderungen oder Erweiterungen an Endgeräten notwendig Nachteil Border Router muss Routing Tabelle aktualisieren und annoncieren Verbreitung der neuen Routing Tabelle dauert Verfahren skaliert bei vielen Mobile Nodes und schnellen Standortwechseln nicht Fazit: Verfahren ist in der Praxis nicht geeignet C. Grimm 21. Dezember 2005 Folie 42

43 Mobile IPv4 Ziel mobiles Endgerät behält Permanent Address auch bei Wechsel des IP-Netzes Aktualisierung des Routing soll nach Standortwechsel möglichst schnell erfolgen Aspekte des Entwurfs (Beginn ca. 1994) im Vergleich zu stationären Endgeräten gibt es nur wenige mobile Endgeräte Verfahren soll aus Sicht der Correspondents transparent sein nicht gestattet sind Änderungen von IP, da es bereits in zu vielen Systemen implementiert ist Änderungen des Routing Erweiterungen der Correspondents gestattet sind Erweiterungen der mobilen Endgeräte zusätzliche Instanzen im Netz C. Grimm 21. Dezember 2005 Folie 43

44 Mobile IPv4 Spezifikation C. Perkins, Ed. IP Mobility Support. RFC 2002, IETF, Oktober 1996 C. Perkins, Ed. IP Mobility Support for IPv4. RFC 3220, IETF, Januar 2002 C. Perkins, Ed. IP Mobility Support for IPv4. RFC 3344, IETF, August 2002 neue Komponenten Adressierung Care-of-Address Instanzen Home Agent Foreign Agent Protokolle C. Grimm 21. Dezember 2005 Folie 44

45 Komponenten in Mobile IPv4 Permanent Address IP-Adresse aus Home Network bleibt erhalten Home Network MoIP Care-of-Address (CoA) IP-Adresse in Foreign Network, unter der mobiles Endgerät von außen erreichbar ist Internet MoIP Foreign Network Home Agent leitet an Permanent Address gerichtet Daten an mobiles Endgerät weiter, sobald es in einem Foreign Network angemeldet ist Foreign Agent vergibt CoA nimmt Daten an CoA entgegen und leitet sie an mobiles Endgerät weiter C. Grimm 21. Dezember 2005 Folie 45

46 Ablauf in Mobile IPv4 Phase 1: Agent Discovery und Registrierung mobiles Endgerät sucht Foreign Agent in Foreign Network und meldet sich an Foreign Agent weist mobilem Endgerät CoA zu mobiles Endgerät meldet neue CoA seinem Home Agent C. Grimm 21. Dezember 2005 Folie 46

47 Phase 1: Agent Discovery und Registration Schritt 1 Mobiles Endgerät sucht Foreign Agent Home Network MoIP Schritt 3 Mobiles Endgerät teilt Home Agent CoA mit 3 Internet MoIP Foreign Network Schritt 2 Foreign Agent bietet mobilem Endgerät CoA an Correspondent C. Grimm 21. Dezember 2005 Folie 47

48 Agent Discovery Nachrichten für Agent Discovery werden über ICMP übertragen (siehe Teil 9) zwei Ansätze für Agent Discovery Agent Advertisement (ICMP Type = 9) Foreign Agent sendet periodisch Nachrichten per Broadcast mit mehreren freien CoA mobiles Endgerät wählt CoA und führt Registrierung auf Foreign Agent durch Agent Solicitation (ICMP Type = 10) mobiles Endgerät sendet Broadcast Request Foreign Agent sendet Nachricht mit CoA direkt an mobiles Endgerät mobiles Endgerät nimmt CoA von Foreign Agent und führt Registrierung durch vgl. mit DHCP, Teil 9 Seite 23ff Registration auf Home Agent erfolgt über UDP auf Port 434 C. Grimm 21. Dezember 2005 Folie 48

49 Ablauf in Mobile IPv4 Phase 2: Datenübertragung Correspondent sendet Daten an Permanent Address Home Agent fängt Daten bei Erreichen des Home Network ab und leitet sie an CoA weiter Foreign Agent fängt Daten bei Erreichen des Foreign Network ab und leitet sie an mobiles Endgerät weiter Daten in Rückrichtung werden direkt geroutet C. Grimm 21. Dezember 2005 Folie 49

50 Phase 2: Datenübertragung Home Network MoIP Schritt 2 Home Agent fängt Daten ab und leitet sie durch Tunnel an Foreign Agent um 2 Internet Schritt 3 Foreign Agent leitet Daten an mobiles Endgerät weiter MoIP 3 Foreign Network 4 Schritt 1 Correspondent sendet Daten an Permanent Address des mobilen Endgeräts 1 Correspondent Schritt 4 Mobiles Endgerät sendet Daten an Correspondent direkt C. Grimm 21. Dezember 2005 Folie 50

51 Phase 2: Beispiel Datenübertragung Home Network MoIP Src Dest Src Dest Src Dest data Internet Src Dest data MoIP Src Dest Foreign Network data data C. Grimm 21. Dezember 2005 Folie 51

52 Mobile IPv4: Bewertung Funktionalität mit Mobile IPv4 ist ein mobiles Endgerät stets unter seiner Permanent Address erreichbar Einschränkung: in allen besuchten Netzen muss ein Foreign Agent vorhanden sein Performance Übertragungsrate asymmetrisches Routing zwischen Correspondent und mobilem Endgerät (auch Indirect Routing oder Triangle Routing) asymmetrisches Routing beeinträchtigt Übertragungsrate von TCP Unterbrechung bei Übergang zwischen IP-Subnetzen Dauer wird durch Agent Discovery und Registration bestimmt Größenordnung ~ 1 s Security lediglich Authentifizierung des mobilen Endgeräts gegenüber Home Agent C. Grimm 21. Dezember 2005 Folie 52

53 Datenrate von TCP über Mobile IP bei asymmetrischem Routing Weg von mobilem Endgerät zu Correspondent ist der kürzeste Weg Weg zwischen Correspondent und mobilem Endgerät ist länger Verkehr weist höhere Verzögerung auf als in Gegenrichtung höhere Wahrscheinlichkeit, dass ein schwacher Link Teil des Weges ist Fazit: geringere Datenrate als bei symmetrischer Verbindung ungünstiger, je näher Correspondent und mobiles Endgerät sind worst case: Corrrespondent ist in Foreign Network mobile Node bei Wechsel des IP-Netzes neue CoA von neuem Foreign Agent neue Registrierung auf Home Agent mobiles Endgerät ist währenddessen nicht erreichbar Dauer in Größenordnung von 1 s währenddessen Verlust von typisch mehreren Paketen Correspondent Correspondent führt bei TCP-Verbindungen Slow Start durch häufige Wechsel lassen folglich nur geringe Datenraten über TCP zu MoIP MoIP C. Grimm 21. Dezember 2005 Folie 53

54 Auswahl an Verbesserungen von Mobile IPv4 Verzicht auf Foreign Agent mobiles Endgerät kann auch Funktion des Foreign Agent übernehmen Zuweisung einer Co-Located CoA (CCoA) über DHCP in Foreign Network d. h. mobiles Endgerät hat zwei IP-Adressen und ist Endpunkt des Tunnels Optimierung des Routing: Direct Routing Phase 1: Agent Discovery und Registration bleiben unverändert Phase 2: Correspondent ruft vor der Übertragung CoA von Home Agent ab erfordert Erweiterung des Correspondent Verfahren ist nicht mehr transparent Correspondent speichert CoA temporär (Binding Cache) Home Agent muss Correspondent Änderungen der CoA mitteilen (Binding Update) Phase 3: Correspondent sendet Daten über Tunnel direkt an Foreign Agent C. Grimm 21. Dezember 2005 Folie 54

55 Direct Routing Phase 1 Agent Discovery und Registration wie bisher Home Network Visited Network MoIP Internet MoIP Phase 2 Correspondent ruft von Home Agent die CoA des mobilen Endgeräts ab Correspondent Phase 3 Correspondent sendet Daten über Tunnel direkt an CoA mobiles Endgerät sendet Daten an Correspondent direkt C. Grimm 21. Dezember 2005 Folie 55

56 Zusammenfassung Teil 10 Multicast Adressierung Umsetzung und Architektur Multicast Routing Shared Tree Routing: Steiner Tree und Center-based Tree Source Based Tree Routing: Shortest Path Tree und Reverse Path Forwarding IPv6 Motivation Adressierung Migration von IPv4 nach IPv6 Mobile IP Motivation und Terminologie mögliche Umsetzung der Mobilität in IP Mobile IPv4 Verbesserungen von Mobile IPv4 C. Grimm 21. Dezember 2005 Folie 56

57 Übungsaufgabe Reverse Path Forwarding Annahme alle Router sind Mitglieder einer Multicast-Gruppe least-cost path über alle Router ist bekannt und verändert sich nicht A B C D Aufgaben 1. bilde Multicast-Baum beginnend mit Router A 2. bilde Multicast-Baum beginnend mit Router C 3. bilde Multicast-Baum beginnend mit Router E 4. vergleiche die Multicast-Bäume der drei Aufgaben! E C. Grimm 21. Dezember 2005 Folie 57

58 Lösung Reverse Path Forwarding Aufgabe 1 1. A sendet an B und D 2. B sendet an C und E D sendet an E E ignoriert 3. C sendet an E E ignoriert D A B C Aufgabe 2 1. C sendet an B und E E ignoriert 2. B sendet an A und E 3. A sendet an D E sendet an C und D beide ignorieren 4. D sendet an E E ignoriert Aufgabe 3 1. E sendet an B, C und D C und D ignorieren 2. B sendet an A und C 3. A sendet an D C sendet an E E ignoriert 4. D sendet an E E ignoriert D D A A E B E B E C C C. Grimm 21. Dezember 2005 Folie 58