Vorlesung. Rechnernetze II Teil 8. Sommersemester 2004

Transkript

1 Vorlesung Rechnernetze II Teil 8 Sommersemester 2004 Jan Wiebelitz, Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze J. Wiebelitz, C. Grimm 9. Juni 2004

2 Übersicht IP Version 6 Motivation für -Adressen Darstellung Aufbau Vergabe -Header Besonderheiten von Neighbor Discovery Protocol DNS und Prefix Renumbering Routing Applikationen für und Socket-Programmierung in IPV6 Dual Stack Hosts J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 2

3 Einordnung von ist ein Protokoll des Network Layer Application Application TCP / UDP TCP / UDP IP IP IP Data Link Data Link Data Link Data Link Physical Physical Physical Physical Host Router Switch Host zwischen Transport- (TCP, UDP) und Sicherungsschicht (Ethernet, ) beinhaltet u. a. Adressen von Netzwerkknoten im Betriebssystem implementiert z. Zt. IP Version 4 Übergang zu IP Version 6 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 3

4 Host-Density-Ratio (RFC 3194) die HD-Ratio ist ein Maß für die Effizienz von Adressverteilungen knappe Adressen sorgen für Probleme bei der Vergabe neuer Adressbereiche knapper Adressraum erschwert eine sinnvolle Strukturierung Berechnung log(anzahl belegter Objekte) H = log(anzahl maximal belegbarer Objekte) Untersuchungen in Telefonnetzen (USA und Frankreich) ergaben H 0,8 ist ein erträgliches Maß zwischen Effizienz und Unannehmlichkeit H = 0,87 stellt die maximale Schmerzgrenze dar Anwendung der HD-Ratio auf -Adressen in mit 32 Bit Adressen sind maximal Adressen belegbar Schmerzgrenze (H = 0,87) wird bei belegten Adressen erreicht J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 4

5 Zuwachs an Hosts im Internet (Januar 2004) NAT, RFC 1631, Mai 1994 NAT, RFC 1631, Mai 1994 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 5

6 Erschöpfung von -Adressen? Ansatz: es stehen insgesamt 256 /8er Netze zur Verfügung 0.xxx.xxx.xxx 255.xxx.xxx.xxx davon können 35 Netze (13,7 %) nicht vergeben werden 16 /8er für Multicast reserviert (224/8 239/8) 16 /8er werden als Reserve vorgehalten (240/8 255/8) 3 /8er nicht zum Gebrauch vorgesehen ( /8, /8, /8) davon sind 131 (51,2 %) von der IANA zugeteilt davon werden ca. 6 % als Reserve gehalten die restlichen ca. 46 % werden von den RIRs an LIRs vergeben 29 % der zugeteilten Adressen sind in den Routing-Tabellen bekannt gegeben 17 % werden nicht im Internet geroutet d. h. es können noch = 90 Netze (35,2 %) vergeben werden entspricht ca Adressen J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 6

7 Erschöpfung von -Adressen? Entwicklung bis 2003 extrapoliert bis ist der -Adresspool der IANA erschöpft 2023 sind die Reserven der RIRs erschöpft bis 2028 werden die z. Zt. nicht gerouteten Adressbereiche aufgebraucht sein J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 7

8 Zuwachs an Nutzern im Internet Nutzer (in Millionen) USA Asia-Pacific W. Europe Worldwide Quelle: Computer Industrie Almanac Inc., Mai 2002 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 8

9 Vergrößerung der Routingtabellen CIDR, RFC1519, September 1993 NAT, RFC 1631, Mai 1994 Fri May 28 01:31: (Australian Eastern Time) J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 9

10 128 Bit Adressenlänge davon 64 Bit für Interface ID -Header feste Länge, 40 Byte optionale Header Verbessertes Routing keine Fragmentierung Aggregation von Subnetzen Prefix Renumbering Stateless Autoconfiguration Host generiert sich die eigene -Adresse selbst plug and ping, Link-Local Address für Kommunikation auf Verbindungsebene Router Advertisements für globale Kommunikation J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 10

11 Timeline IETF IPnG Started 1st Specification 6bone 6TAP Forum Founded Cisco Support 12.2(t) 6WIN DFN Uni Hannover Connected to the 6WIN DFN-Project JOIN RIRs Assigned Spaces Provider based Spaces J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 11

12 Vergleich der Adressräume von und : 32-Bit Adressen ergibt verschiedene Adressen (in Worten: ca. 4,3 Milliarden) entspricht 0, Adressen pro m 2 Erdoberfläche : 128-Bit Adressen ergibt verschiedene Adressen mit wird der Adressraum von 96x verdoppelt entspricht 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 -Adressen zugewiesen werden 2 64 = (in Worten: 18,5 Trillionen) Anmerkung: es stehen nicht wirklich alle Adressen zur Verfügung... J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 12

13 Darstellung von -Adressen I bevorzugte Darstellung acht 16-bit-Teile hexadezimal dargestellt durch Doppelpunkt voneinander getrennt führende Nullen in einem Feld können weggelassen werden, anhängende nicht Beispiele 1234:5678:9ABC:DEF0:1234:5678:9ABC:DEF0 1080:0:0:0:8:800:200C:417A vereinfachte Darstellung 16-bit-Gruppen von Nullen können einmal zusammengefasst werden führende Nullen einer 16-bit-Gruppe können weggelassen werden, anhängende nicht Beispiel 1080::8:800:200C:417A J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 13

14 Darstellung von -Adressen II gemischte Darstellung in gemischter /-Umgebung -compatible Address für Tunnel durch -Netze -mapped Address präsentiert -Adressen als -Adressen führende Nullen in einem Feld können weggelassen werden, anhängende nicht 16-bit-Gruppen von Nullen können einmal zusammengefasst werden Beispiel 0:0:0:0:0:0: (-compatible Address) ::FFFF: (-mapped Address) Nibble-Format für Rückwärtsauflösung im DNS jeweils 4 Bit werden durch eine Punkt (.) voneinander getrennt hexadezimale Schreibweise Adresse wird rückwärts geschrieben, Domäne wir angehängt Beispiel 7.F E.F.F.F.A.D ip6.int J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 14

15 Darstellung von -Adressen III kompakte Darstellung durch Base85-Codierung definiert in RFC 1924 A Compact Representation of Addresses Codierung der -Adresse durch 85 ASCII Zeichen 0.. 9, A.. Z, a.. z,!, #, $, %, &, (, ), *, +, -, ;, <, =, ^, _, `, {,, } und ~ folgende Zeichen sind verboten,,,,., /, :, [, ], \ Vorgehen Adresse wird als 128 Bit Integer angenommen mehrfache Division durch 85, Rest wird jeweils dargestellt Beispiel -Adresse: 1080:0:0:0:8:800:200C:4174A 16 erschienen am 1. April 1996 als 128 Bit Integer: Division mod 85: 51, 34, 65, 57, 58, 0, 75, 53, 37, 4, 19, 61, 31, 63, 12, 66, 46, 70, 68, 4 sortierte Darstellung: in Base85-Codierung: +k&c#vzj4br>0wv%yp J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 15

16 Vergabe von -Adressen Vergaberichtlinie RFC 3177, IAB/IESG Recommendations on Address Allocation to Sites sieht Vergabe von drei verschiedenen Adressbereiche vor /48-Präfix: Normalfall "Home network" Teilnehmer mit "on-demand"- oder "always-on"-verbindungen kleine und große Unternehmen sehr große Teilnehmer erhalten mehrere /48 Präfixe oder /47-Präfix bzw. einen geringfügig kürzeren Präfix /64-Präfix: wenn genau ein Subnetz benötigt wird z. B. Netzwerke in Fahrzeugen z. B. Mobiltelefone mit einem zusätzlichen Interface (Bluetooth oder b), um direkt mit anderen Geräten zu kommunizieren /128-Präfix: wenn genau eine Adresse benötigt wird einzelnes Gerät J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 16

17 Reichweiten von Adressen Adressen sind in nur innerhalb bestimmter Reichweiten gültig insgesamt sind 16 verschiedene Reichweiten möglich davon sind 3 reserviert und 7 sind noch nicht zugewiesen Node-Local Scope, Interface-Local Scope oder Loopback für Interprozess-Kommunikation vergleichbar in Link-Local Scope Kommunikation innerhalb einer Broadcast-Domain 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äfixes Organization-Local Scope umfasst mehrere Site-Local Scope Bereiche Global Scope weltweite Gültigkeit J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 17

18 Global Unicast Adressen Aufbau 128 Bit n Bit 64 n Bit 64 Bit global routing prefix network prefix subnet ID interface ID Global Routing Prefix identifiziert eine Site Beispiel 2001:0600::/23 ist u.a. dem RIPE NCC von der IANA zugewiesen 2001:0638::/32 ist dem DFN vom RIPE NCC zugewiesen Subnet ID identifiziert ein Subnetz innerhalb einer Site Beispiel 2001:0638:0606::/48 ist der Uni Hannover vom DFN zugewiesen 2001:0638:0606:0001::/64 ist ein -Testnetz der Uni Hannover Interface ID im modifizierten EUI-64 Format J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 18

19 Unicast Adressen Aufbau 128 Bit 10 Bit 54 Bit 64 Bit routing prefix subnet ID interface ID Node-Local Scope Loopback Address 0:0:0:0:0:0:0:1 d. h. Interface ID wird auf 1 gesetzt Link-Local Scope Subnet ID ist stets 0 FE80::/10 und <Interface ID im mod. EUI-64 Format> Site-Local Scope FEC0::/10 und <Interface ID im mod. EUI-64 Format> ist definiert im RFC 3515 Internet Protocol Version 6 () Address Architecture Draft Deprecating Site Local Address plädiert für die Abschaffung Unspecified Address (0:0:0:0:0:0:0:0:0) hat keine definierte Reichweite d. h. Interface ID wird auf 0 gesetzt J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 19

20 Interface ID im modifizierten EUI-64 Format Aufbau nach IEEE-Guidelines 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 gilt für alle Unicast Adressen Interface ID einer Netzwerkkarte basiert auf deren MAC-Adresse zwischen Company ID (c) und Extension ID (x) wird FF FE 16 eingefügt das universal/local Bit im Company-Anteil wird auf 1 gesetzt Ausnahme: alle Adressen die mit beginnen J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 20

21 Anycast Adressen in Aufbau 128 Bit n Bit 128 n Bit subnet prefix interface ID haben keinen syntaktische Unterschied zu Unicast-Adressen sind mehr als einem Interface zugeordnet dürfen nur Routern zugewiesen werden, Hosts nicht dürfen in Datenpaketen nicht Source Address sein werden zum nächstgelegenen Interface mit der Anycast-Adresse geroutet Auswahl des nächstgelegenen Interface anhand Distanzen aus Routing Protokollen durch Host-Route Einträge auf den Routern J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 21

22 Multicast Adressen in Aufbau 128 Bit 8 Bit 4 Bit 4 Bit 112 Bit prefix flags scope group ID Präfix ist immer Flags die drei höherwertigen Flags sind reserviert und müssen 0 sein, das vierte Flag gibt an, ob die Multicast Adresse permanent (0) ist, d. h. von der IANA zugewiesen nichtpermanent (1) ist Scope: Reichweite der Multicast-Adresse insgesamt 16 verschiedene Reichweiten möglich, davon sind 3 reserviert und 7 noch nicht zugewiesen Beispiele 1: Interface-Local Scope 2: Link-Local 4: Admin-Local Scope 5: Site-Local Scope 8: Organizational-Local Scope E: Global Scope J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 22

23 Reservierte Multicast-Adressen Node-Local Scope FF01::1 All Nodes Adresse FF01::2 All Routers Adresse Link-Local Scope FF02::1 All Nodes Adresse FF02::2 All Routers Adresse FF02::3 nicht zugewiesen Site-Local Scope FF05::2 All Routers Adresse FF05::1:3 All DHCP Servers Adressen Multicast-Adressen ab FF0x::100 sind verschiedenen Anwendungen zugeordnet Beispiel für Network Time Protocol (NTP) über Link-Local Scope: FF02::101 Beispiel für Network Time Protocol (NTP) über Global Scope: FF0E::101 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 23

24 Solicited Node Address Solicited Node Address Multicast Adresse FF02::1:FF00:0000/104 und die niederwertigen 24 Bit der Unicast-Adresse Link-Local Scope Ersatz für ARP in Zieladresse bei Duplicate Address Detection Multicast-Adresse im Data Link Layer Broadcast auf Network Layer wird durch Multicast ersetzt Multicast-Adresse im Data Link Layer ergibt sich aus Solicitated Node Address des Network Layer niederwertigen 32 Bit der Solicited Node Address wird das Prefix vorangestellt FF FF M[14] M[15] M[16] Solicited Node Address FF M[14] M[15] M[16] Multicast-Adresse im Data Link Layer J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 24

25 Vergleich von - und -Header -Header -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 Feld in und enthalten Destination Address Name und Position in verändert neues Feld in J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 25

26 Aufbau -Header I Version IP-Version, bei = 6 Traffic Class Kennzeichung von Prioritätsklassen Flow Label Kennzeichnung für Sequenzen von Paketen zur spezielle Behandlung Hauptsächlich für Endsysteme erfordert Unterstützung von QoS auf dem Pfad Router, die dieses Feature nicht unterstützen, müssen den Wert 0 eintragen für Streaming Applikationen wie Videoconferencing und VoIP Status experimentell Payload Length Länge der Payload Extension Header werden mitgezählt J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 26

27 Aufbau -Header II Next Header gibt den Typ des folgenden Headers an 0 = Hop by Hop Header 6 = TCP 17 = UDP 43 = Routing Header 44 = Fragment Header 58 = ICMPv6 59 = No Next Header 60 = Destination Options Header Hop Limit Entspricht TTL in wird von jedem Routern um 1 dekrementiert bei Null wird das Paket verworfen und ICMPv6-Nachricht Typ3 Time exceeded gesendet J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 27

28 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 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 28

29 Extension Header I Hop-by-Hop Header enthält Informationen die jeder Knoten entlang der Transportpfades verarbeiten muss muss direkt nach dem -Header folgen mehrere Optionen können hintereinander folgen für Management- und Debugging-Zwecke Destination-Option Header wird vom Zielhost ausgewertet wird von Routern aus dem Routing-Header ausgewertet, wenn er vor dem Routing- Header steht Routing Header enthält Liste von Routern über die die IP-Pakete zum Ziel geroutet werden letzter Eintrag ist das Ziel Zieladresse im Basis-Header ist der erste zu benutzende Router folgt nach dem Basis-Header oder jedem Extension-Header J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 29

30 Extension Header II Fragment Header Fragmentierung soll weitgehend vermieden werden nur der sendende Host darf Pakete fragmentieren nur der Zielhost darf fragmentierte Pakete wieder zusammensetzen Authentication Header identisch mit IPSec AH Header Implementierung in vorgeschrieben Integrität und Authentifizierung des Quellknotens Schutz gegen Replay-Angriffe Encapsulating-Security-Payload Header identisch mit IPSec ESP Header Implementierung in vorgeschrieben Vertraulichkeit und Authentifizierung des Quellknotens Unversehrtheit der Daten Schutz gegen Replay-Angriffe J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 30

31 Neighbor Discovery Protocol (NDP) NDP ist das Schlüsselprotokoll in T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (). IETF RFC 2461, Dezember 1998 erweitert ICMPv6 um fünf neue Nachrichten enthält drei Komponenten Neighbor Discovery als Ersatz für ARP aus Stateless Autoconfiguration zur optionalen(!) automatischen Generierung von -Adressen Router Redirection zur automatischen Optimierung von Routing-Tabellen auf den Hosts Neighbor Discovery Protocol Neighbor Discovery (Ersatz für ARP in ) Stateless Autoconfiguration Router Redirection Prefix Advertisement Duplicate Address Detection Prefix Renumbering J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 31

32 ICMPv6 Nachrichten im NDP (Teil 1) Neighbor Solicitation (NS) ICMPv6 Typ 135 Ersatz für ARP, MAC Adresse von Link-Local Nachbarn erfragen Duplicate Address Detection (DAD) Neighbor Advertisement (NA) ICMPv6 Typ 136 Antwort auf Neighbor Solicitation Ersatz für ARP, MAC-Adresse wird bekannt gegeben J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 32

33 Neighbor Discovery I Host A sendet Neighbor Solicitation Message (NS) ICMPv6 Typ 135 Quelladresse: eigene Global Scope oder Link-Local -Adresse Zieladresse: Solicited Node Multicast Address korrespondierend zur Zieladresse nur noch der Kommunikationspartner wird befragt nicht wie in die gesamte Broadcast-Domain ND-Message muss die MAC-Adresse des Quellhosts beinhalten Host A MAC Address 08:00:20:21:5B:92 Address 2001:638:606:1:A00:20FF:FE21:5B92 Host B MAC Address 00:02:E3:1D:B7:50 Address 2001:638:606:1:202:E3FF:FE1D:B750 Eth ICMPv6 Source MAC Address: 08:00:20:21:5B:92 Destination MAC Address: 33:33:FF:1D:B7:50 ICMPv6 Type 135 (Neighbor Solicitation) Source Address: 2001:638:606:1:A00:20FF:FE21:5B92 Destination Address: FF02::1:FF1D:B750 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 33

34 Neighbor Discovery II Host B sendet Neighbor Advertisement Message (NA) ICMPv6 Typ 136 Quelladresse: eigene Global Scope oder Link-Local -Adresse Zieladresse: Global Scope oder Link-Local -Adresse des Kommunikationspartners Host A MAC Address 08:00:20:21:5B:92 Address 2001:638:606:1:A00:20FF:FE21:5B92 Host B MAC Address 00:02:E3:1D:B7:50 Address 2001:638:606:1:202:E3FF:FE1D:B750 Eth ICMPv6 Source MAC Address: 00:02:E3:1D:B7:50 Destination MAC Address: 08:00:20:21:5B:92 ICMPv6 Type 136 (Neighbor Advertisement) Source Address: 2001:638:606:1:202:E3FF:FE1D:B750 Destination Address: 2001:638:606:1:A00:20FF:FE21:5B92 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 34

35 ICMPv6 Nachrichten im NDP (Teil 2) Router Solicitation (RS) ICMPv6 Typ 133 Anfrage nach Router Advertisements enthält optional die MAC-Adresse der Quelle, wenn die Zieladresse nicht die Solicited Node Address ist Router Advertisement (RA) ICMPv6 Typ 134 wird periodisch ausgesendet und ist Antwort auf Router Solicitation Prefix Renumbering enthält M-Flag Managed Address Configuration 0 bedeutet stateless address autoconfiguration 1 bedeutet stateful address autoconfiguration O-Flag Other Stateful Configuration 1 bedeutete das zusätzliche Informationen von DHCPv6-Server geliefert werden Router Lifetime 0 bedeutet Not Default Router Reachable Time Retrans Timer optional Präfixinformationen J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 35

36 Stateless Autoconfiguration I Host A generiert aus Link-Local Prefix und Interface ID eine provisorische Adresse FE80::<Interface ID im mod. EUI-64 Format> Duplicate Address Detection Quell-Adresse: Unspecified Address (::) Zieladresse: Solicited Node Address (FF02::1FF00:0000/104 und die niederwertigen 24 Bit der Unicast-Adresse) ICMPv6 Typ 135 (Neighbor Solicitation) Host A MAC Address 00:50:DA:80:33:F7 Address FE80::250:DAFF:FE80:33F7 Router C MAC Address 00:10:11:65:18:00 Address 2001:638:606:1:210:11FF:FE65:1800 Eth ICMPv6 Source MAC Address: 00:50:DA:80:33:F7 Destination MAC Address: 33:33:FF:80:33:F7 ICMPv6 Type 135 (Neighbor Solicitation) Source Address: :: Destination Address: FF02::1:FF80:33F7 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 36

37 Stateless Autoconfiguration II Host A sendet Router Solicitation Message (RS) Quelladresse: Link-Local Scope Adresse FE80::<Interface ID im mod. EUI-64 Format> Zieladresse: All Routers Multicast-Adresse mit Link-Local Scope FF02::2 ICMPv6 Typ 133 Host A MAC Address 00:50:DA:80:33:F7 Address FE80::250:DAFF:FE80:33F7 Router C MAC Address 00:10:11:65:18:00 Address 2001:638:606:1:210:11FF:FE65:1800 Eth ICMPv6 Source MAC Address: 00:50:DA:80:33:F7 Destination MAC Address: (33:33:00:00:00:02) ICMPv6 Type 133 (Router Solicitation) Source Address: FE80::250:DAFF:FE80:33F7 Destination Address: FF02::2 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 37

38 Stateless Autoconfiguration III Router C sendet Router Advertisement Message (RA) Quelladresse: Link-Local Scope Adresse FE80::<Interface ID im mod. EUI-64 Format> Zieladresse: All Routers Multicast-Adresse mit Link-Local Scope FF02::2 enthält Global Routing Prefix Host A generiert eine globale Unicast-Adresse aus Global Routing Prefix und Interface ID Host A MAC Address 00:50:DA:80:33:F7 Address FE80::250:DAFF:FE80:33F7 Router C MAC Address 00:10:11:65:18:00 Address 2001:638:606:1:210:11FF:FE65:1800 Eth ICMPv6 Source MAC Address: 00:10:11:65:18:00 Destination MAC Address: 33:33:00:00:00:01 ICMPv6 Type 134 (Router Advertisement) Source Address: FE80::210:11FF:FE65:1800 Destination Address: FF02::1 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 38

39 Stateful Autoconfiguration Hosts empfangen Adresse, andere Konfigurationsinformation oder beides von einem DHCPv6-Server Stateful und Stateless Autoconfiguration können sich ergänzen über Router Advertisement (RA) kann gesteuert werden, ob Stateless oder Stateful Autoconfiguration genutzt wird (M-Flag) über Stateful Autoconfiguration können zusätzliche Informationen geliefert werden DNS-Server Adressen Nutzung von spezielle Adressen All_DHCP_Relay_Agents_and_Servers (FF02::1:2) All_DHCP_Servers (FF05::1:3) J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 39

40 ICMPv6 Nachrichten im NDP (Teil 3) Redirect Message ICMPv6 Typ 137 Informationen über besseren ersten Hop ICMPv6 Target Address Feld enthält -Adresse des besseren ersten Hop ICMPv6 Destination Address Feld enthält -Adresse des System welches zum Target ungelenkt wird Zielhost ist Link-Local Nachbar ICMPv6 Target Address Feld muss den selben Wert wie das ICMPv6 Destination Feld haben Adresse des Quellrouters muss eine Link-Local Adresse sein J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 40

41 Router Redirect Ablauf Host A sendet -Paket an LAN Z über seinen Default Router C Router C sendet Router Redirect Host A ändert Routing-Tabelle Host A sendet nächstes -Paket an LAN Z über Router B LAN Z Host A Default Router C Router B Router C Router D 1. IP-Paket (Dest.- in LAN Z, Dest.-MAC Router C) 2. ICMPv6 Redirect (in Payload: Router B für LAN Z nutzen) 3. IP-Paket (Dest.- in LAN Z, Dest.-MAC Router B) J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 41

42 DNS (proposed standard) (Teil 1) Neuer Address Record: AAAA-Record Beispiel $ORIGIN rvs.uni-hannover.de dns1 IN AAAA 2001:638:606:1:202:e3ff:fe1d:b750 Neue Domäne: ip6.int Adressen werden im "Nibble"-Format dargestellt Beispiel b.d.1.e.f.f.f.3.e ip6.int IN PTR dns1.rvs.uni-hannover.de J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 42

43 DNS (proposed standard) (Teil 2) neue Konzepte kommen zum Einsatz Adresse wird in mehreren Teilen aufgelöst DNAME-Resource-Record Aufbau von Chains innerhalb des DNS-Systems ähnlich dem CNAME-Resource-Record für und Beispiel $ORIGIN new-style.in-addr.arpa DNAME in-addr.example.net. $ORIGIN in-addr.example.net 188 DNAME in-addr.customer.example. $ORIGIN in-addr.customer.example. 1 PTR 2 PTR mail.customer.example. J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 43

44 DNS (experimental) (Teil 1) A6-Resource-Records konkurrierend zu den AAAA-Records haben jedoch den Status experimental dienen der Vorwärtsauflösung nur einen Teil der -Adresse auflösen Verweis auf einen symbolischen Namen für den Rest Beispiel 1 $ORIGIN rvs.uni-hannover.de dns1 IN A :638:606:1:202:e3ff:fe1d:b750 Beispiel 2 $ORIGIN uni-hannover.de. IN A :638:606:: $ORIGIN rvs.uni-hannover.de. IN A6 48 0:0:0:1 rvs.uni-hannover.de. dns1 IN A6 64 ::202:e3ff:fe1d:b750 rvs.uni-hannover.de. dns2 IN A6 64 ::a00:20ff:fe21:5b92 rvs.uni-hannover.de. J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 44

45 DNS (experimental) (Teil 2) neue Domäne ip6.arpa konkurrierend zur Domäne ip6.int die den Status experimental hat neues Darstellungsformat für die Rückwärtsauflösung bitstring label für die neue Domäne ip6.arpa teilweise Auflösung von -Adressen ist möglich Beispiel 1 \[x e3fffe1db750/128].ip6.arpa IN PTR dns1.rvs.uni-hannover.de Beispiel 2 mit DNAME \[x /48].ip6.arpa. \[x0001/16].uni-hannover.de. \[x0202e3fffe1db750/64].rvs.uni-hannover.de. IN PTR uni-hannover.de IN DNAME rvs.uni-hannover.de IN DNAME dns1.rvs.uni-hannover.de J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 45

46 Renumbering Präfix ändern hilfreich z. B. beim Wechsel des ISP Strict Aggregation: ein Präfix darf nicht weitergegeben werden Änderung der geographischen Adressverteilung Vorgehen Stateless Autoconfiguration der Knoten ist notwendig während der Übergangszeit haben die Knoten zwei Unicast-Adressen Zeitparameter im Router Advertisement werden genutzt Lebenszeit des alten Präfix wird reduziert neuer Präfix wird verkündet neuer Präfix erhält Status preferred alter Präfix erhält vor Status deprecated und sollte dann nicht mehr genutzt werden DNS Einträge ändern durch DNAME-Resource-Records kann der Präfix von Netzen geändert werden J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 46

47 Routing Wachstum der Routing-Tabellen kontrollierbar durch Clusterbildung Strict Aggregation Prefix Renumbering Routing Modifikation von Unicast-Routing (OSPF, RIP, BGP) Modifikation Multicast-Routing Protokollen (PIM, DVMRP, MOSPF) longest prefix match wie bei CIDR Nutzung des Routing-Header um Pakete mit Hilfe von Anycast-Adressen gezielt zu leiten Auswahl von Internet Service Providern Policy-Aspekte Leistungsaspekte J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 47

48 Was geht es mit weiter? Adressierung Secure Neighbor Detection (SEND) Reichweiten der Adressen Duplicate Address Detection (Optimistic DAD) DNS Dynamic DNS mit Stateless Autoconfiguration Dynamic DNS mit DHCPv6 DHCPv6 Lifetime Configuration Options NIS Configuration Options Prefix Options Mobility insgesamt erst Draft-Status J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 48

49 Client/Server-Applikationen in und Verbindungsmatrix für Hosts mit TCP/IP-Stack für und Frage: welche Kombinationen von Host unter und können miteinander kommunizieren? Ziel: alle! klassische Client/Server-Applikationen sind für programmiert die Erfahrung zeigt: Hosts können über miteinander kommunizieren der Kombination -Client auf -Server ist also erledigt Server Client??? J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 49

50 Anpassung einer -Applikation an Applikationen nutzen im Allgemeinen die Socket-Schnittstelle Sockets sind Schnittstelle (API) zum Transport Layer (TCP / UDP) IP befindet sich erst im Network Layer, d. h. unterhalb des Transport Layer Folgerung: die Version von IP bleibt der Applikation beinah verborgen Application Application Sockets Sockets TCP / UDP TCP / UDP IP IP IP IP Data Link Data Link Data Link Data Link Physical Physical Physical Physical Anpassung bestehender -Applikationen an im Wesentlichen muss lediglich die Adressierung angepasst werden d. h. Anpassung von Datenstrukturen und Funktionen für Adressierung der Aufwand ist gering, s. Beispiele J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 50

51 Client/Server-Applikation TCP über #include <...> #include <...> #define BUFFERSIZE 20 #define PORT 7923 Client #define BUFFERSIZE 20 #define PORT 7923 Server int main ( int argc, char *argv[] ) { int sockfd; int sendlen; char sendbuf[buffersize]; struct sockaddr_in saddr; int main ( void ) { int int char struct sockaddr_in sockfd, newsockfd; clielen, recvlen; recvbuf[buffersize]; saddr, caddr; if ( ( sockfd = socket ( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { perror ( "socket" ); return -1; } bzero ( ( char * ) &saddr, sizeof ( saddr ) ); saddr.sin_family = AF_INET; saddr.sin_port = htons ( PORT ); if ( inet_pton ( AF_INET, argv[1], &saddr.sin_addr ) <= 0 ) { perror ( "inet_pton" ); return -1; } if ( ( sockfd = socket ( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { perror ( "socket" ); return -1; } bzero ( ( char * ) &saddr, sizeof ( saddr ) ); saddr.sin_family = AF_INET; saddr.sin_port = htons ( PORT ); saddr.sin_addr.s_addr = htonl ( INADDR_ANY ); strcpy ( sendbuf, "Hi there!!" ); sendlen = strlen ( sendbuf ); if ( bind ( sockfd, (struct sockaddr *) &saddr, sizeof ( saddr ) ) < 0 ) { perror ( "bind" ); return -1; } listen ( sockfd, 5 ); if ( connect ( sockfd, (struct sockaddr *) &saddr, sizeof (saddr) ) < 0 ) { perror ( "connect" ); return -1; } clielen = sizeof ( caddr ); newsockfd = accept ( sockfd, (struct sockaddr *) &caddr, &clielen ); if ( newsockfd < 0 ) { perror ( "accept" ); return -1; } if ( send ( sockfd, sendbuf, strlen ( sendbuf ), 0 ) < 0 ) { perror ( "send" ); return -1; } recvlen = recv ( newsockfd, recvbuf, BUFFERSIZE, 0 ); if ( recvlen < 0 ) { perror ( "recv" ); return -1; } recvbuf[recvlen] = 0; printf ( "Empfangen: %s\n", recvbuf ); close ( sockfd ); close ( sockfd ); close ( newsockfd ); } return 0; } return 0; J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 51

52 Client/Server-Applikation TCP über #include <...> #include <...> #define BUFFERSIZE 20 #define PORT 7923 Client #define BUFFERSIZE 20 #define PORT 7923 Server int main ( int argc, char *argv[] ) { int sockfd; int sendlen; char sendbuf[buffersize]; struct sockaddr_in6 saddr; int main ( void ) { int int char struct sockaddr_in6 sockfd, newsockfd; clielen, recvlen; recvbuf[buffersize]; saddr, caddr; if ( ( sockfd = socket ( AF_INET6, SOCK_STREAM, 0 ) ) < 0 ) { perror ( "socket" ); return -1; } bzero ( ( char * ) &saddr, sizeof ( saddr ) ); saddr.sin6_family = AF_INET6; saddr.sin6_port = htons ( PORT ); if ( inet_pton ( AF_INET6, argv[1], &saddr.sin6_addr ) <= 0 ) { perror ( "inet_pton" ); return -1; } Initialisierung anpassen if ( ( sockfd = socket ( AF_INET6, SOCK_STREAM, 0 ) ) < 0 ) { perror ( "socket" ); return -1; } bzero ( ( char * ) &saddr, sizeof ( saddr ) ); saddr.sin6_family = AF_INET6; saddr.sin6_port = htons ( PORT ); saddr.sin6_addr.s_addr = in6addr_any; strcpy ( sendbuf, "Hi there!!" ); sendlen = strlen ( sendbuf ); Programmablauf nicht anpassen if ( bind ( sockfd, (struct sockaddr *) &saddr, sizeof ( saddr ) ) < 0 ) { perror ( "bind" ); return -1; } listen ( sockfd, 5 ); if ( connect ( sockfd, (struct sockaddr *) &saddr, sizeof (saddr) ) < 0 ) { perror ( "connect" ); return -1; } clielen = sizeof ( caddr ); newsockfd = accept ( sockfd, (struct sockaddr *) &caddr, &clielen ); if ( newsockfd < 0 ) { perror ( "accept" ); return -1; } if ( send ( sockfd, sendbuf, strlen ( sendbuf ), 0 ) < 0 ) { perror ( "send" ); return -1; } recvlen = recv ( newsockfd, recvbuf, BUFFERSIZE, 0 ); if ( recvlen < 0 ) { perror ( "recv" ); return -1; } recvbuf[recvlen] = 0; printf ( "Empfangen: %s\n", recvbuf ); close ( sockfd ); close ( sockfd ); close ( newsockfd ); } return 0; } return 0; J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 52

53 Client/Server-Applikationen in und Verbindungsmatrix für Hosts mit TCP/IP-Stack für und Frage: welche Kombinationen von Host unter und können miteinander kommunizieren? Ziel: alle! Frage: was ist mit heterogenen Applikationen? -Client kommuniziert mit -Server -Client kommuniziert mit -Server Server Client der klassische Fall?? einfache Anpassung J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 53

54 Dual Stack und in einem Host Eigenschaften eines Dual Stack Host im TCP/IP-Stack des Betriebssystems sind und implementiert der Host verfügt über mindestens je eine - und -Adresse im DNS sind A- und AAAA-Records für den Host eingetragen Server auf Dual Stack Hosts können generell - und -Clients bedienen Voraussetzung: Server-Applikation ist für implementiert Konventionen für Server-Applikation auf Dual Stack Host auf -Socket gebundener Server kann nur -Pakete empfangen auf -Socket gebundener Server kann nur -Pakete empfangen, wenn der Socket auf eine reguläre -Adresse gebunden ist auf -Socket gebundener Server kann nur -Pakete empfangen, wenn der Socket auf eine -mapped Adress gebunden ist auf -Socket gebundener Server kann - und -Pakete empfangen, wenn der Socket auf die Unspecified Address (0::0) gebunden ist J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 54

55 Anpassung der IP-Adressen im Dual Stack Server Übergabe der IP-Adresse des Client an Server-Applikation Port Number Server 1234 Server 1235 Server Server Socket TCP/ Socket TCP/ Socket UDP/ Socket UDP/ TCP UDP -Paket ist an eine Applikation auf -Socket gerichtet - mapped - mapped Paket Paket J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 55

56 Dual Stack Server Frage: woher weiß ein Host, ob ein - oder ein -Paket kommt? Antwort anhand unterschiedlicher Protocol-IDs im Data Link Layer Protocol-ID 0x0800 für und 0x86dd für Frage: wie kann ein -Server Daten an einen -Client zurücksenden? Anmerkung: Client sendet Daten in -Paketen Antwort TCP/IP-Stack übergibt -Server die -mapped Address des Client -Server sendet Daten an die -mapped Address des Client TCP/IP-Stack auf -Server erkennt -mapped Address des Client löst -mapped Address in tatsächliche -Adresse des -Client auf weitere Bearbeitung der Daten durch -Stack J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 56

57 Datenfluss im Dual Stack Server für TCP IP-Adressen Quellen sind und 2001:...:8156 Ziele sind und 2001:...:d4a5 beide Adressen auf einem Host Socket 2001:0638:0606:0001: 0a00:20ff:fe8e:8156 Socket Client IP address 0000:0000: 0000:0000: 0000:FFFF: Socket local IP address 0::0 local port 7923 Server 7923 TCP 6 Data Link 00:E0:7D:82:D4:A5 Client IP address 2001:0638: 0606:0001: 0a00:20ff: fe8e: dd 2001:0638: 0606:0001: 2e0:7dff: fe82:d4a5 Eth 00:E0:7D:82:D4:A IP TCP Data... Eth IP TCP Data 00:E0:7D:82:D4:A dd :...: :...:d4a J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 57

58 Dual Stack Client Frage: wie entscheidet Client, ob Daten über oder gesendet werden? Annahme: es ist nicht bekannt, ob Ziel ein - oder -Server ist Antwort: Entscheidung hängt von DNS-Auflösung ab Dual Stack Client fragt DNS nach A- und AAAA-Record des Servers in jedem Fall erwartet Applikation eine Adresse für -Datenstrukturen Fall 1: Ziel ist ein -Server mit AAAA-Record im DNS Dual Stack Client erhält reguläre -Adresse Fall 2: Ziel ist ein -Server mit A-Record im DNS Dual Stack Client erhält -mapped Address des -Servers Betriebssystem entscheidet anhand Adresstyp über - oder -Paket Problem: -Client und -Server auf Dual Stack Hosts DNS enthält sowohl A- als auch AAAA-Record des Servers Client erhält auf DNS Request den AAAA-Record des Servers Client sendet Daten an -Adresse des Servers J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 58

59 Senden von IP-Paketen auf Dual Stack Client Client Client Client Client Socket TCP/ Socket TCP/ Socket UDP/ Socket UDP/ TCP UDP DNS-Auflösung ergibt lediglich A-Record, d. h. Ziel ist -Server - mapped - mapped Paket Paket J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 59

60 Client/Server-Applikationen in und Verbindungsmatrix für Hosts mit TCP/IP-Stack für und Frage: welche Kombinationen von Host unter und können miteinander kommunizieren? Ziel: alle! Server Socket TCP/IP-Stack Dual Dual DNS A AAAA A und AAAA A und AAAA A??? Client Dual AAAA A?????? Dual A und AAAA??? J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 60

61 Client/Server-Applikationen in und Verbindungsmatrix für Hosts mit TCP/IP-Stack für und Frage: welche Kombinationen von Host unter und können miteinander kommunizieren? Ziel: alle! Praxis Server Socket TCP/IP-Stack Dual Dual DNS A AAAA A und AAAA A und AAAA A Client Dual AAAA A Dual A und AAAA J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 61

62 Client/Server-Applikationen in und Verbindungsmatrix für Hosts mit TCP/IP-Stack für und Frage: welche Kombinationen von Host unter und können miteinander kommunizieren? Ziel: alle! Praxis fast alle relevanten Fälle können miteinander kommunizieren Server Socket TCP/IP-Stack Dual Dual DNS A AAAA A und AAAA A und AAAA A Client Dual AAAA A Dual A und AAAA reine -Stacks, in der Praxis nicht relevant J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 62

63 Client/Server-Applikationen in und Verbindungsmatrix für Hosts mit TCP/IP-Stack für und Frage: welche Kombinationen von Host unter und können miteinander kommunizieren? Ziel: alle! Praxis fast alle relevanten Fälle können miteinander kommunizieren nur in einer der relevanten Kombinationen wird tatsächlich genutzt Server Socket TCP/IP-Stack Dual Dual DNS A AAAA A und AAAA A und AAAA A Client Dual AAAA A Dual A und AAAA reine -Stacks, in der Praxis nicht relevant J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 63

64 Literatur RFCs Internet Protocol, Version 6 () Specification, IETF RFC 2460 Neighbor Discovery for IP Version 6 (), IETF RFC Stateless Address Autoconfiguration, IETF RFC Internet Control Message Protocol (ICMPv6) for the Internet, Protocol Version 6 () Specification. IETF RFC Internet Protocol Version 6 () Addressing Architecture. IETF RFC Bücher R. Desmeules, Cisco Self-Study Implementing Networks () Cisco Press, 2003 H. P. Dittler,, 2.Auflage, dpunkt.verlag, 2002 H. Wiese, Das neue Internetprotokoll IPV6, Hanser Verlag, 2002 P. Albitz, C. Liu, DNS und Bind, 4. Auflage, O'Reilly, 2002 W. R. Stevens, UNIX Network Programming Volume 1: Networking APIs: Sockets and XTI, Prentice Hall, 1998 J. Wiebelitz, C. Grimm 9. Juni 2004 Folie 64