Kommunikationsnetze. Praxis Internet. Version 4.0

Transkript

1 Kommunikationsnetze Praxis Internet Michael Rotert Version 4.0

2 Inhalt Einführung (Teil 1) Lokale Netze (LAN) Topologie, Komponenten Ethernet Punkt-zu-Punkt über Ethernet Virtuelle LANs Internet Ebene 3 Protokolle (Teil 2) Definition, Geschichte Architektur, Protokolle IPv4 (Teil3) IPv4 Header Fragmentierung IPv4 Adressierung IPv4 Routing (Teil 4) Autonome Systeme Routing Protokolle Internet Exchanges Zusatzprotokolle (Teil 5) ARP / RARP ICMP (ping und traceroute) DHCP und NAT IPv6 (Teil 6) Entwicklung, Geschichte IPv6 Header IPv6 Adressierung IPv6 Zusatzprotokolle (Teil 7) Konfiguration, Autokonfiguration Fragmentierung DHCP, ICMP Drahtlose und mobile Netze (Teil 8) Eigenschaften Adressierung/Routing mobiler Benutzer Mobilität in IPv4 Netzen WLAN/Wifi Transportschicht (Teil 9) TCP und UDP Anwendungsschicht (Teil 10) Grundlagen, Architekuren DNS Electronic Mail (SMTP, POP3, IMAP) P2P-Anwendungen Kommunikationsnetze M.Rotert SS2015 Teil 6 2

3 Warum neue Adressen? IP Technik Adressierung morgen Adressknappheit starker Anstieg der Internetnutzung Verdoppelung pro Jahr Größe der Routingtabellen (IPv4, kleinteiligere Aufteilung) 2003: Einträge 2008: Einträge 2014: Einträge 3

4 Entwicklung von IPv6 IP - genauer IPv4 - seit Schätzung, dass irgendwann mal Netze adressiert werden müssen Prognose: Klasse B ist März 1994 erschöpft 1991 ROAD (Routing and Addressing) Group (IETF Santa Fe) Juli 1993 IPnG Decision Process BOF (IETF Amsterdam) Sep IESG initiiert A Direction for IPnG ALE (Address Lifetime Expectation) nach Auswertung der derzeitigen Statistik Erschöpfung des Ipv4 Adressraumes zwischen 2005 und 2011 konservative Schätzung neue Killerapplikationen 4

5 Entwicklung von IPv Aufruf, Anforderungen an IPnG aus allen Anwendungsbereichen zu dokumentieren (RFC 1550) 1994 Kriterienpapier (Auszug) vollständige Spezifikation einfache Architektur Skalierbarkeit, mindestens 1 Milliarde Adressen performant, robust, medienunabhängig einfache (automatische) Konfigurierung Multicast drei Vorschläge CATNIP (Common Architecture for the Internet) integriert CLNP, IP und IPX SIPP (Simple Internet Protocol Plus) neue Version von IP TUBA (TCP/UDP over CLNP - addressed Networks) Vereinigung von IP und OSI Entscheidung für SIPP (128 Version) 5

6 Entwicklung von IPv6 Neben der langfristigen Lösung des Adressraumproblems bietet IPv6 gegenüber IPv4 zahlreiche neue Möglichkeiten und Anwendungen: Funktionen zur vereinfachten Adressierung: Stichwort Autokonfiguration. Damit ist es möglich, dass Knoten sich ihre global eindeutige IPv6-Adresse selbständig vergeben ohne dass ein DHCP-Server oder eine manuelle Konfiguration notwendig ist. NAT/PAT wird überflüssig: durch den erweiterten Adressraum kann jeder Knoten eine global eindeutige und im Internet gültige IPv6-Adresse erhalten, um mit dem Internet zu kommunizieren. NAT und dessen Einschränkungen entfallen. Das ermöglicht vielen nicht NAT-fähigen Protokollen die einfacherer Kommunikation zwischen den Endgeräten. IPsec ist integriert: während IPsec-Lösungen bei IPv4 auf Extra-Software basiert, bringt IPv6 die notwendigen Voraussetzungen für IPsec grundsätzlich mit, da IPsec eine Pflichtimplementierung jedes IPv6-Stacks ist. 6

7 Entwicklung von IPv6 Umnummerierung: mit IPv6 ist es einfacher möglich, Netzwerke komplett umzunummerieren. Dazu liefern die Router entsprechende Informationen, so dass sich die Knoten im Netzwerk eine passende Adresse vergeben können. Einfacherer Header: der IPv6-Header ist vereinfacht und mit einer festen Länge versehen (40 Bytes). Dadurch ist die Verarbeitung optimiert. Flexible Funktionalität durch Extension Header: bei Bedarf werden an den Basis-Header so genannte Extension- Header angefügt, die bestimmte Funktionen übernehmen. Dieses Konzept ist bei Bedarf beliebig erweiterbar. 7

8 Entwicklung von IPv6 IPv6 bietet eine Reihe von Features, die einige der Probleme mit IPv4 lösen. Dennoch : IPv6 ist kein Allheilmittel! Es hat durchaus auch Schattenseiten: IPv6 ist nicht sicherer als IPv4! Neue Features bringen neue Sicherheitsrisiken mit sich! IPv6 ist ausgereift, aber bei weitem noch nicht gleichermaßen praxiserprobt wie IPv4. In der Praxis kann es durchaus zu Problemen kommen, die derzeit noch nicht absehbar sind. IPv6 wird nicht von allen Anbietern gleichermaßen unterstützt. Bis hier eine umfassende, fehlerfreie Unterstützung gewährleistet ist, kann es noch Jahre dauern. IPv6 erfordert umfangreiche Maßnahmen, um reibungslos eingeführt zu werden. 8

9 Migrationsaspekte Bei IPv4 fester Zeitpunkt zu dem der»hebel umgelegt«wurde. Dies war der 1. Januar Ab da sprach das Internet IPv4. Das funktionierte damals auch recht gut, da das Internet zu dieser Zeit noch recht übersichtlich war. Da IPv6 nicht von einem Tag zum anderen weltweit eingeführt werden kann, gibt es Migrationstechnologien, die es ermöglichen, IPv4 und IPv6 parallel zu betreiben. Mithilfe von Dual-Stack, Tunnel- und Translationstechnologien wird IPv6 in den nächsten Jahren behutsam und parallel zu IPv4 in den Netzwerken Einzug halten und somit eine sanfte Migration erfahren. Als ein Anbieter von Netzwerk-Komponenten unterstützt Cisco natürlich IPv6. Allerdings ist dies nicht in jedem IOS (Betriebssystem der Router und Switches) enthalten, so dass im Einzelfall überprüft werden muss, ob die Software-Version IPv6-Unterstützung enthält. Dafür gibt es den Cisco-Feature- Navigator, den man unter findet. 9

10 Weitere Veränderungen gegenüber IPv4! Prüfsumme: entfernt, um die Verarbeitung in den Routern zu erleichtern! Optionen: als separate Header, die auf den IP-Header folgen - Werden durch das Nächster Header -Feld angezeigt - Einfachere Behandlung in Hosts und Routern! ICMPv6: neue Version von ICMP - Zusätzliche Nachrichtentypen, z.b. Packet Too Big - Funktionen zur Verwaltung von Multicast-Gruppen! Übergang von IPv4 nach IPv6 - Es können nicht alle Router gleichzeitig umgestellt werden - Wie kann ein Netzwerk funktionieren, in dem sowohl IPv4- als auch IPv6-Router vorhanden sind? Lösung: Tunneling IPv6 wird im Datenteil von IPv4-Datagrammen durch das klassische IPv4-Netzwerk transportiert 10

11 IPv6 Paketaufbau Zur Entlastung der Router wurde die Länge des IP-Headers fest definiert und die Adressfelder auf 64 Bit ausgerichtet (64 bit aligned). Dadurch findet der Router in jedem IPv6-Paket alles an der selben Stelle. Obwohl der IPv6-Header weniger Felder als der IPv4-Header enthält, ist er durch die längeren IPv6-Adressen trotzdem 40 Byte lang. 11

12 Feldinhalt IPv6 Paketaufbau Bit Beschreibung Version 4 Hier steht eine sechs für IPv6. Auch im IPv4-Header vorhanden. Traffic Class 8 Der Wert des Feldes definiert die Priorität des Paketes. Flow Label 20 Das Flow Label kennzeichnet Pakete für ein viel schnelleres Routing. Das MPLS macht dieses Verfahren allerdings überflüssig. Payload Length 16 gibt die Länge des IPv6-Pakets ohne den IPv6-Header an. Bei IPv4 ebenfalls enthalten, hier als Total Length inklusive IPv4-Header. Bisher musste der Wert aus dem Feld Total Length abzüglich dem Feld IHL ermittelt werden. Next Header 8 Zeigt den nächsten Header, der auf den IPv6 Header folgt. Im Normalfall werden das die Werte 6 (TCP) oder 17 (UDP) sein. Der IPv6 Header kann durch eine Reihe von Extension Headers erweitert werden. Dieses Feld existiert auch bei IPv4 unter der Bezeichnung Protocol. Hop Limit / TTL 8 Dieses Feld enthält die Anzahl der verbleibenden weiterleitenden Stationen, bevor das IP-Paket verfällt. Es entspricht dem TTL-Feld von IPv4. Jede Station, die ein IP-Paket weiterleitet, muss von diesem Wert 1 abziehen. Bei Null ICMP Message Source Address 128 An dieser Stelle steht die IP-Adresse der sendenden Station Destination Address 128 An dieser Stelle steht die IP-Adresse der Ziel Station Header-Erweiterungen jeweils 64 Bit (8 Byte) Im IPv6-Header können optional Informationen im separaten Header dem IP-Kopf angehängt werden. Bis auf wenige Ausnahmen werden diese Header-Erweiterungen von IP-Routern nicht beachtet. 12

13 IPv6 Paketaufbau 13

14 IPv6 Paketaufbau Der IPv6-Header selbst beschränkt sich auf essentielle Funktionen, die grundsätzlich benötigt werden. Werden zusätzliche Features benötigt, kann ein passender Extension-Header angehängt werden. Die Verknüpfung geschieht hier über das Next Header-Feld. Dieses enthält die Protokollnummer des nachfolgenden Protokolls. Nachfolgend ein paar Beispiel für typische Protokollnummern: Während TCP (6) und UDP (17) als klassische Transport-Protokolle dem IP(v6)- Header folgen, sind neue Protokollnummern hinzugekommen, die unter anderem die Extension-Header kennzeichnen. Diese sind in der Abbildung rot gekennzeichnet 14

15 IPv6 Paketaufbau Kommen Extension-Header zum Einsatz, enthalten diese in einem eigenen Next Header-Feld wiederum den Verweis auf das nachfolgende Protokoll bzw. dessen Header. So können auch mehrere Extension-Header eingefügt werden: 15

16 IPv6 Paketaufbau RFC 2460 enthält die Basis-Festlegungen für das Internet Protocol Version 6 (IPv6). Hier werden sechs Extension Header definiert: Hop-by-Hop Options Header (Protocol-Nr. 0): er dient zur Übermittlung von wichtigen Informationen für jeden Hop (Router) auf dem Weg zum Ziel. Destination Options Header (Protocol-Nr. 60): wird für Zusatzinformationen eingesetzt, die in der Regel nur vom Empfänger benötigt werden. Ein Praxisbeispiel hierfür ist die Home Address im Rahmen von Mobile IPv6. Hier erhält der mobile Knoten eine feste Adresse, die Home Address, über die er immer erreichbar ist, unabhängig vom aktuellen Standort des Knotens. Diese Home Address wird über den Destination Options Header übermittelt. Routing Header (Protocol-Nr. 43): wird für Source-Routing eingesetzt, wenn also der Absender die Route selbst definiert. Dazu enthält der Routing Header die Hops (Router), die übersprungen werden müssen. Dieser Extension- Header ist aus sicherheitstechnischer Sicht sehr problematisch und wird von vielen Netzwerk-Komponenten (Router, Firewalls) ignoriert bzw. verworfen. Insbesondere das Loose-Routing (Typ 0) sollte unbedingt verhindert werden, da somit nicht der gesamte Weg sondern nur einzelne Stationen definiert werden, was verschiedene Angriffsszenarien ermöglicht. 16

17 IPv6 Paketaufbau Fragment Header (Protocol-Nr. 44): müssen IPv6-Pakete fragmentiert werden, wird ein Fragment Header eingesetzt. Er enthält die Fragmentierungsinformationen, die der IPv4-Header direkt enthielt und die aus dem IPv6-Header entfernt wurden. Ein weiterer Unterschied zu IPv4 ist, dass nur noch die Absender der Pakete fragmentieren dürfen, nicht mehr die Router auf dem Weg zum Ziel. Encapsulation Security Payload (Protocol-Nr. 50): ein im Rahmen von IPsec verwendeter Header, der auch bei IPv4 bereits zum Einsatz kommt, ursprünglich aber im Rahmen der IPv6-Spezifikation entwickelt wurde. Authentication Header (Procotol-Nr. 51): ein alternativer Header für IPsec, der nur Authentizität und Integrität bietet, aber im Gegensatz zu ESP keine Verschlüsselung. 17

18 IPv6 Paketaufbau Weitere Extension-Header können jederzeit hinzukommen. So ist im Rahmen der Mobile IPv6-Spezifikation z.b. der Mobility-Header definiert. Unter dem Strich wird IPv6 damit sehr flexibel, da fast beliebige Funktionen durch die Extension-Header definiert und abgebildet werden können. Für den Einsatz der Extension-Header schlägt RFC 2460 eine Reihenfolge vor, wenn mehrere Header gleichzeitig hinzukommen: 1. Hop-by-Hop Options Header 2. Destination Options Header 3. Routing Header 4. Fragment Header 5. Authentication Header (AH) 6. Encapsulation Security Payload (ESP) Zu diesem Thema ist anzumerken, dass einige Netzwerk-Komponenten, insbesondere Firewalls, derzeit oftmals nur den ersten Extension Header interpretieren und analysieren können. 18

19 IPv6 Adressen Anzahl der Adressen: Das sind 340 Sextillionen Diese Zahl ist ausreichend, um jedem Sandkorn auf der Erde seine eigene IPv6-Adresse zuzuweisen. 19

20 IPv6 Adresstypen 3 Sorten von Adressen: Unicast-Adressen: sind sowohl die Absender- als auch die Zieladresse bekannt, werden diese in den IPv6-Header eingetragen. Die Systeme kommunizieren direkt miteinander. Es handelt sich um eine Eins-zu-Eins-Kommunikation. Multicast-Adressen: sollen in einem Paket mehrere Zielsysteme mit einer bestimmten Eigenschaft angesprochen werden, so wird als Zieladresse eine passende Multicast-Adresse genutzt. Dies kann z.b. die All-Routers-Adresse sein, mit der alle Router innerhalb eines bestimmten Bereichs angesprochen werden. Multicast wird, wie bei IPv4, zur Verbreitung von Multimediainhalten, z.b. Video, genutzt. Anycast-Adressen: in manchen Fällen soll der nächstliegende Dienst-Server angesprochen werden. Dies wird durch Anycast-Adressen erreicht. Dies ist z.b. vergleichbar mit dem Polizei-Notruf 110, da die Wahl dieser Nummer ebenso eine Verbindung zur nächstliegenden Notrufzentrale aufbaut. Broadcast-Adressen werden von IPv6 nicht mehr genutzt! Stattdessen existiert eine All-Nodes-Multicast-Adresse, die de facto die Rolle der Broadcast-Adressen übernimmt. 20

21 IPv6 Adressen Regeln für IPv6-Adressen Für IPv4 galt: jedes Interface, das über IPv4 kommunizieren möchte, benötigt eine IPv4-Unicast-Adresse. Bei IPv6 ist die Situation etwas komplexer geworden. Hier die Grundregeln: Jedes Interface muss mindestens eine Unicast-Adresse haben Ein einzelnes Interface kann auch mehrere IPv6-Adressen besitzen (auch in Kombination aus Unicast-, Multicast- und Anycast-Adressen) Wie bei IPv4 kann auch bei IPv6 eine Unicast-Adresse auf mehrere Interfaces verteilt werden (Loadsharing) Die Betonung in der obigen Auflistung liegt in der Möglichkeit, mehrere IPv6- Adressen an ein Interface zu binden und dies wird in vielen Fällen sogar die Regel sein, da bestimmte Adresstypen unterschiedliche Aufgaben übernehmen. 21

22 Schreibweise einer IPv6-Adresse IPv6 Adressen Die 128 Bits einer IPv6-Adresse werden in acht hexadezimale, 16-Bit lange Blöcke unterteilt, die durch Doppelpunkte getrennt werden, z.b.: 2001:0DB8:0000:0000:0208:C7FF:FEC5:5E7A Dabei gelten folgende Darstellungsregeln: Führende Nullen können ausgelassen werden: 2001:DB8:0:0:208:C7FF:FEC5:5E7A Aufeinanderfolgende Null-Blöcke können EINMAL pro Adresse durch zwei Doppelpunkte ersetzt werden: 2001:DB8::208:C7FF:FEC5:5E7A Die Adresse 2001:0db8:0000:0000:0000:0000:0000:0001 kann durch 2001:db8::1 repräsentiert werden. IPv4-Adressen können in IPv6-Adressen eingebettet (bzw. zum Schluss angehängt) werden, z.b. X:X:X:X:X:X: oder 0:0:0:0:0:0: bzw. :: , oder aber: ::C0A8:1 22

23 Aufbau einer IPv6-Adresse IPv6 Adressen Der grundsätzliche Typ und der Aufbau einer IPv6-Adresse wird durch Präfix der Adresse bestimmt. Wie bei IPv4 bilden Präfixe den vorderen Teil der Adresse. Der Netzanteil ist in einer IPv6-Unicast-Adresse festgelegt auf die ersten 64 Bits. Das bedeutet, dass eine IPv6-Unicast-Adresse genau in der Mitte aufgeteilt wird der vordere Teil bildet den Netzanteil und der hintere Teil den Hostanteil, Interface- ID genannt. Jedes einzelne IPv6-Subnetz hat damit 2^64 = 18,4 Trillionen mögliche Host- Adressen und damit rund 4,3 Milliarden mal so viele Adressen in einem einzelnen Subnetz wie der gesamte Adressraum bei IPv4 umfasst. Auch bei IPv6 gibt es Subnetzmasken! Diese werden jedoch nicht in Dezimalschreibweise à la angegeben sondern ausschließlich in der Präfix-Notation. Für ein normales IPv6-Subnetz gilt also fast immer /64. 23

24 IPv6 Adressen Welcher Art eine IPv6-Adresse ist, bestimmt das Präfix. Das Präfix ist grundsätzlich eine bestimmte Anzahl festgelegter High-Order-Bits. Das bedeutet, dass die höchstwertigen (linksseitigen) Bits einer Adresse festgelegt sind und damit den Typ der IPv6-Adresse angeben. Gemäß RFC 4291 werden folgende Routing-Präfixe unterschieden: Global Unicast-Adressen (Präfix binär: 001, Präfix hexadezimal: 2000::/3): diese Adressen bilden die normalen, routing-fähigen IPv6-Adressen. Adressen, die mit einem Präfix zwischen 2000 und 3FFFF beginnen, gehören in diese Kategorie. Link-Local Unicast-Adressen (Präfix binär: , Präfix hex: FE80::/10): jedes IPv6-aktivierte Interface verfügt über eine Link-Local-Adresse. Sie ist nur im lokalen Subnetz (IPv6-Terminologie: am lokalen Link) nutzbar und wird nicht geroutet. Unique Local IPv6-Adressen (Präfix binär: (1), Präfix hex: FC00::/7 bzw. FD00::/8): diese Adressen sind für den privaten Gebrauch in Unternehmensnetzwerken vorgesehen und sollten im Internet nicht geroutet werden. Diese Adressen entsprechen auf ihre Art den privaten IPv4-Adressbereichen. Multicast-Adressen (Präfix binär: , Präfix hexadezimal: FF00::/8): Multicast-Adressen sind bei IPv6 ungleich wichtiger als bei IPv4, da sie elementare Funktionen umsetzen, wie z.b. Neighbor Discovery und Autoconfiguration. 24

25 IPv6 Adressen IPv6 Prefix Allocation Reference Notes 0000::/8 Reserved by IETF [RFC4291] 0100::/8 Reserved by IETF [RFC4291] 0100::/64 reserved for Discard-Only Address Block [RFC6666]. 0200::/7 Reserved by IETF [RFC4048] Deprecated as of December 2004 [RFC4048]. Formerly an OSI NSAP-mapped prefix set [RFC4548]. 0400::/6 Reserved by IETF [RFC4291] 0800::/5 Reserved by IETF [RFC4291] 1000::/4 Reserved by IETF [RFC4291] 2000::/3 Global Unicast [RFC4291] The IPv6 Unicast space encompasses the entire IPv6 address range with the exception of ff00::/ ::/3 Reserved by IETF [RFC4291] 6000::/3 Reserved by IETF [RFC4291] 8000::/3 Reserved by IETF [RFC4291] a000::/3 Reserved by IETF [RFC4291] c000::/3 Reserved by IETF [RFC4291] e000::/4 Reserved by IETF [RFC4291] f000::/5 Reserved by IETF [RFC4291] f800::/6 Reserved by IETF [RFC4291] fc00::/7 Unique Local Unicast[RFC4193] For complete registration details, see iana-ipv6-special-registry. fe00::/9 Reserved by IETF [RFC4291] fe80::/10 Link-Scoped Unicast [RFC4291] Reserved by protocol fec0::/10 Reserved by IETF [RFC3879] Deprecated by [RFC3879] in September ff00::/8 Multicast [RFC4291] assignments from this block registered in ipv6-multicast addresses 25

26 IPv6 Adressen Beispiel: 26

27 IPv6 Adressen (Link Local-Adressen) Sobald ein Interface für IPv6 aktiviert wird, erhält es eine IPv6-Unicast-Adresse. Diese Adresse wird automatisch vom Betriebssystem erstellt und heißt Link Local-Adresse. Diese ist bei IPv6 eine Pflichtadresse. Sobald IPv6 auf einem Interface aktiviert ist, muss dieses auch eine Link Local-Adresse erhalten. Diese Adresse wird automatisch gebildet und hat das Präfix FE80::/10 bzw. binär Da andererseits die folgenden 54 Bits ebenfalls festgelegt sind und 0 sein müssen, ergibt sich der folgende Aufbau einer Link Local-Adresse: Während das Präfix bis zum 64. Bit festgelegt ist, muss die Interface-ID automatisch gebildet werden. Dies kann entweder auf Basis des Randomized Interface Identifier geschehen (nur bei Windows vorhanden), mittels EUI-64-Verfahren oder durch die Privacy Extensions nach RFC Anschließend zeigt z.b. ipconfig diese Adresse auch dann an, wenn keine weitere IPv6-Konfiguration für dieses Interface vorgenommen wurde: Kommunikationsnetze M.Rotert SS2015 Teil6: IPv6 Grundlagen 27

28 IPv6 Adressen (Link Local-Adressen) Sobald ein Interface für IPv6 aktiviert wird, erhält es eine IPv6-Unicast-Adresse. Diese Adresse wird automatisch vom Betriebssystem erstellt und heißt Link Local-Adresse. Diese ist bei IPv6 eine Pflichtadresse. Sobald IPv6 auf einem Interface aktiviert ist, muss dieses auch eine Link Local-Adresse erhalten. Diese Adresse wird automatisch gebildet und hat das Präfix FE80::/10 bzw. binär Da andererseits die folgenden 54 Bits ebenfalls festgelegt sind und 0 sein müssen, ergibt sich der folgende Aufbau einer Link Local-Adresse: Anschließend zeigt z.b. ipconfig diese Adresse auch dann an, wenn keine weitere IPv6- Konfiguration für dieses Interface vorgenommen wurde. 28

29 IPv6 Adressen (Global-Unicast-Adressen) Die Global Unicast-Adressen entsprechen den öffentlichen, routbaren Adressen im Internet. Sie werden zukünftig die größte Rolle bei der IPv6-Adressplanung spielen. Global-Unicast-Adressen bilden grundsätzlich den Rest aller IPv6-Adressen, die nicht anderweitig definiert sind. Jedoch wurden bisher nur bestimmte Adressbereiche konkret zugewiesen: 2000::/3 dieser Bereich umfasst im ersten Block die Adressen von 2000 bis 3FFF. Er ist derzeitig der einzige Bereich, der für die Vergabe offizieller Adressen an Kunden freigegeben ist. Das Präfix lautet binär 001. Daraus ergibt sich binär der Bereich bis :0:0:0:0:FFFF::/96 die IPv4-mapped IPv6-Adressen enthalten in den letzten 32 Bits der Adresse die IPv4-Adresse eines Systems in der normalen IPv4-Notation, also z.b. ::FFFF: Diese Art der Adressen dient der Übersetzung von IPv4-Adressen in eine IPv6-Form. 64:FF:9b::/96 für NAT64/DNS64 vorgesehener Adressbereich, um IPv4-Adressen in IPv6- Netzbereichen zu nutzen. NAT64/DNS64 dient zur Anbindung von IPv6-only-Inseln an IPv4- Infrastrukturen. Die Nutzung dieses Präfixes ist jedoch nicht vorgeschrieben. 2001::/32 dieses Präfix ist für den Tunnelmechanismus Teredo reserviert. Teredo dient zum Transportieren von IPv6-Paketen über IPv4-Netzwerke durch NAT-Strukturen. 2002::/16 reserviertes Präfix für 6to4-Tunnel. Diese Tunneltechnik dient zum Überbrücken des IPv4- Internets zwischen zwei IPv6-Only-Inseln, ist jedoch nicht oder nur sehr beschränkt NAT- fähig. 29

30 Firewall gesperrt werden. Der wichtigste Bereich ist 2000::/3. Alle anderen hier vorgestellten Adressbereiche lernen Sie in ander Beiträgen kennen. Den Aufbau von Global-Unicast-Adressen beschreibt RFC Werfen wir einen Blick auf die Darstellung der Adresse im RFC: IPv6 Adressen (Global-Unicast-Adressen) einer Global Unicast-Adresse Abbildung 1: Aufb Wie bei IPv4-Adressen beginnt die Adresse mit einem Präfix (global routing prefix). Dieses Wie bei IPv4-Adressen beginnt die Adresse mit einem Präfix (global routing prefix). Dieses Präfix wir im Internet Präfix wird zu im dem Internet Standort zu dem geroutet, Standort dem geroutet, der Adressbereich an dem der Adressbereich genutzt werden genutzt soll. Durch das weitgehend werden soll. konsequent Durch das hierarchische weitgehend konsequent Routing von hierarchische IPv6 ergeben Routing sich hier von völlig IPv6 ergeben unterschiedlich lange globale sich Routing-Präfixe. hier völlig unterschiedlich Die IANA lange weist globale den Routing-Präfixe. Regional Internet Die Registries IANA weist (RIRs), den Regional wie z.b. dem RIPE oder Internet der ARIN, Registries in der (RIRs), Regel /23-Präfixe wie z.b. dem zu, RIPE seltener oder der auch ARIN, /20-, in /21- der oder Regel /22-Präfixe, /23-Präfixe wie zu, der folgende Ausschnitt der IPv6-Allocations-Liste auf iana.org zeigt: seltener auch /20-, /21- oder /22-Präfixe, wie der folgende Ausschnitt der IPv6-Allocations- Liste auf iana.org zeigt: 30

31 IPv6 Adressen (Global-Unicast-Adressen) 31

32 IPv6 Adressen (Global-Unicast-Adressen) Zusätzlich hat jede RIR ein /12 Prefix bekommen, aus dem heute die meisten Provider ihre IPv6 Adressen erhalten. Hinter dem globalen Routing-Präfix folgt ein Bereich aus Bits, die für das Subnetting verwendet werden können. Gemäß der flexiblen Aufteilung nach dem VLSM-Prinzip (Variable Length Subnet Mask) können die RIRs ihrerseits nun Präfixe an die Provider ihrer geografischen Region verteilen. Dabei handelt es sich zumeist um /32-Präfixe. Die Provider vergeben dann an ihre Kunden wiederum längere Präfixe aus Hinter dem globalen Routing-Präfix folgt ein Bereich aus Bits, die für das Subnetting verwendet werden können. Gemäß der flexiblen Aufteilung nach dem VLSM-Prinzip (Variable Length Subnet Mask) können die RIRs ihrerseits nun Präfixe an die Provider ihrer geografischen Region verteilen. Dabei handelt es sich zumeist um /32-Präfixe. dem jeweiligen Netzbereich. Hierbei war gemäß RFC 3177 zunächst vorgesehen, an alle Organisationen, angefangen von Privathaushalten und Ein-Mann-Betrieben bis hin zu internationalen Großunternehmen, /48- Die Provider vergeben dann an ihre Kunden wiederum längere Präfixe aus dem jeweiligen Netzbereich. Präfixe Hierbei zu war vergeben. gemäß RFC 3177 Unter zunächst Berücksichtigung vorgesehen, an alle Organisationen, der Tatsache, angefangen dass von die Privathaushalten und Ein-Mann-Betrieben bis hin zu internationalen Großunternehmen, /48-Präfixe zu Interface-ID vergeben. Unter eine Berücksichtung feste Länge der Tatsache, von 64 dass Bits die Interface-ID hat, hat eine die feste Aufteilung Länge von 64 der Bits Global- hat, hat Unicast-Adressen die Aufteilung der Global-Unicast-Adressen in diesem Fall die in diesem folgende Fall die Struktur: folgende Struktur: 3: Struktur einer Standard-Global-Unicast-Adresse Abbildung 32 Demnach stehen an jedem Standort (auch für Privatkunden!) 16 Bits für die Subnetz-Adressierung zur Verfügung das entspricht möglichen Subnetzen. Zum Vergleich: bei IPv4 wäre das eine

33 IPv6 Adressen (Global-Unicast-Adressen) Demnach stehen an jedem Standort (auch für Privatkunden!) 16 Bits für die Subnetz-Adressierung zur Verfügung das entspricht möglichen Subnetzen. Dieser Ansatz ist allerdings inzwischen aufgeweicht worden und einer flexibleren Vergabe gewichen, wonach die Provider mehr Entscheidungsfreiheit hinsichtlich der Präfixlänge haben. So erhalten z.b. öffentliche Verwaltungen und große Institutionen bei Bedarf /40-Präfixe, während normale Kunden eines Providers nur ein /56-Präfix zugewiesen bekommen. Damit verbleiben für die Subnetz-Bildung an jedem Standort immer noch 8 Bits, die bis zu 256 Subnetze ermöglichen. Die kleinstmöglichen Subnetze haben in der Praxis ein /64-Präfix, da die hinteren 64 Bits immer für die Interface-ID reserviert sind. Im Übrigen ist auch für mobile Anschlüsse vorgesehen, komplette Subnetze mit /64-Präfix zu vergeben, um dem oder den Endsystem(en) die Bildung der eigene Adresse durch Autoconfiguration zu ermöglichen. 33

34 IPv6 Adressen (Unique-Local-Adressen ) Eines der wichtigsten Konzepte bei IPv4 ist NAT Network Address Translation. Hierfür wurden die privaten IP-Adressbereiche nach RFC 1918 konzipiert, die im Internet nicht geroutet werden. IPv6 schafft das NAT-Konzept zumindest weitgehend ab. Dennoch ist es in vielen Fällen wünschenswert, weiterhin mit privaten Adressbereichen arbeiten zu können. Hierfür sind die Unique-Local- Adressen (ULA) vorgesehen und im RFC 4193 beschrieben. Sie werden durch das Präfix FC00::/7 definiert und lösen das ältere Konzept der Site-Local- Adressen ab, die durch RFC 3879 als deprecated, also veraltet, gekennzeichnet wurden. Damit wird auch das Präfix FEC0::/10 obsolet, das verschiedentlich noch zu sehen ist, z.b. in Form automatisch eingetragener DNS-Server bei älteren Microsoft- Betriebssystemen. Diese haben die drei Adressen FEC0:0:0: FFFF::1, FEC0:0:0: FFFF::2 und FEC0:0:0: FFFF::3 als DNS-Server-Adressen eingetragen, wenn nichts anderes festgelegt war. Die neuen Unique-Local-Adressen sind für den Einsatz in privaten Netzwerken vorgesehen und sollten im Internet nicht geroutet werden. 34

35 Hierzu kommen verschiedene Mechanismen zu Anwendung. Doch werfen wir zunächst einen Blick auf IPv6 (Unique-Local-Adressen ) den Aufbau der Unique-Local-Adressen: Abbildung Das Präfix einer Unique-Local-Adresse 1: Aufbau besteht einer Unique-Local-Adresse insgesamt aus 48 Bits (/48), gefolgt von einem Bereich von 16 freien Bits für die Subnetze. Während die ersten sieben festgelegten Das Bits Präfix das einer Präfix Unique-Local-Adresse FC00::/7 bilden, folgt anschließend besteht insgesamt ein achtes aus 48 Bit, Bits das (/48), ebenfalls gefolgt eine von einem Bereich von Bedeutung 16 freien Bits hat: für steht die es Subnetze. auf null, wird Während das betreffende die ersten sieben Unique-Local-Präfix festgelegten Bits durch das eine Präfix FC00::/7 bilden, zentrale folgt Instanz anschließend vergeben. ein Der achtes Hintergrund Bit, das ebenfalls zu dieser eine zentralen Bedeutung Instanz hat: ist steht die weltweite es auf null, wird das betreffende Eindeutigkeit Unique-Local-Präfix des Unique-Local-Präfixes. durch eine Damit zentrale kann Instanz effektiv vergeben. verhindert Der werden, Hintergrund dass zu dieser zentralen Instanz ist die weltweite Eindeutigkeit des Unique-Local-Präfixes. Damit kann effektiv Unternehmen, die sich in der einen oder anderen Form zusammenschließen, verhindert werden, dass Unternehmen, die sich in der einen oder anderen Form zusammenschließen, Adresskonflikte erhalten. Adresskonflikte erhalten. Andererseits gibt es diese zentrale Instanz derzeit noch nicht, so dass dieses achte Bit Andererseits immer auf gibt eins es stehen diese wird. zentrale Instanz derzeit noch nicht, so dass dieses achte Bit immmer auf eins stehen Damit wird. ergibt Damit sich ergibt ein effektives sich ein Präfix effektives für Unique-Local-Adressen Präfix für Unique-Local-Adressen von FD00::/8. von FD00::/8. Die nächsten 40 Bits bilden die so genannte Global ID. RFC 4193 empfiehlt verschiedene Die nächsten 40 Bits bilden die so genannte Global ID. RFC 4193 empfielt verschiedene Vorgehensweisen, um diesen 40-Bit-Block zufällig zu generieren, damit mögliche Vorgehensweisen, um diesen 40-Bit-Block zufällig zu generieren, damit mögliche Überschneidungen und Konflikte Überschneidungen vermieden werden und Konflikte können. vermieden Hierzu wird werden unter können. anderem Hierzu die MAC-Adresse wird unter anderem eines beliebigen die Systems MAC-Adresse und der aktuelle eines beliebigen Zeitstempel Systems (Timestamp) und der als aktuelle Eingangsparameter Zeitstempel (Timestamp) genutzt. Auf als cd34.com/4193 finden Eingangsparameter Sie einen ULA-Generator, genutzt der das Prinzip verdeutlicht. 35 Nachfolgend ein Beispiel:

36 Hierzu kommen verschiedene Mechanismen zu Anwendung. Doch werfen wir zunächst einen Blick auf den Aufbau der Unique-Local-Adressen: Beispiel zu Unique-Local-Adressen Abbildung Über einen Algorithmus (s. cd34.com/4193) 1: Aufbau einer Unique-Local-Adresse wird eine ULA gebildet und ergibt z.b. folgendes Das Präfix Präfix einer Unique-Local-Adresse für einen Standort: besteht insgesamt fd77:3291:8761::/48 aus Bits (/48), gefolgt von einem Bereich Dieses wird von 16 innerhalb freien Bits für des die Subnetze. Organisationsnetzwerks Während die ersten sieben zum festgelegten betreffenden Bits das Präfix Standort FC00::/7 geroutet. bilden, Die folgt nachfolgenden anschließend ein 16 achtes Bits Bit, sind das ebenfalls für das eine Subnetting Bedeutung hat: innerhalb steht es auf null, des wird das betreffende Unique-Local-Präfix durch eine zentrale Instanz vergeben. Der Hintergrund zu dieser Standorts zentralen verfügbar. Instanz ist Damit die weltweite ergibt Eindeutigkeit sich für die des Unique-Local-Präfixes. /64-Subnetze der Damit folgende kann effektiv Bereich mit bis zu verhindert werden, Subnetzen: dass Unternehmen, fd77:3291:8761::/64 die sich in der einen bis oder fd77:3291:8761:ffff:/64 anderen Form zusammenschließen, Adresskonflikte erhalten. Unter dem Strich ist das gebildete /48-Bit-Präfix aller Wahrscheinlichkeit nach weltweit Andererseits einzigartig gibt (unique), es diese zentrale wird Instanz aber derzeit trotzdem noch nicht, so dass im dieses Internet achte geroutet, Bit immmer auf um eins die private stehen Nutzung wird. Damit der ergibt Unique-Local-Adressen sich ein effektives Präfix für Unique-Local-Adressen sicherzustellen. von FD00::/8. Unique-Local-Adressen werden insbesondere in den Fällen genutzt, in denen der Großteil der Systeme nicht direkt ins Internet kommunizieren darf. Der Zugriff auf Ressourcen ins Internet geschieht über wenige zentrale Systeme (Proxy-Systeme und/oder Serversysteme), die dann Global-Unicast-Adressen erhalten. Nachfolgend ein Beispiel: Es wäre möglich Rechnern im Enterprise Netzwerk eine ULA Adresse für die interne Kommunikation wird mit dem empfohlenen zu geben, Algorithmus und eine eine ULA Global-Unicast-Adresse gebildet, ergibt das z.b. folgendes um Präfix das für einen Standort: weltweite Netzwerk zu erreichen. Das Konzept der vielen Adressen je Interface Die nächsten 40 Bits bilden die so genannte Global ID. RFC 4193 empfielt verschiedene Vorgehensweisen, um diesen 40-Bit-Block zufällig zu generieren, damit mögliche Überschneidungen und Konflikte vermieden werden können. Hierzu wird unter anderem die MAC-Adresse eines beliebigen Systems und der aktuelle Zeitstempel (Timestamp) als Eingangsparameter genutzt. Auf cd34.com/4193 finden Sie einen ULA-Generator, der das Prinzip verdeutlicht. macht solche fd77:3291:8761::/48 Konfigurationen denkbar. 36 Dieses wird zu innerhalb des Organisationsnetzwerks zum betreffenden Standort geroutet. Die nachfolgenden 16 Bits sind für das Subnetting innerhalb des Standorts verfügbar. Damit ergibt sich für die /64-Subnetze der folgende Bereich mit bis zu Subnetzen:

37 Written März 19th, 2014 by Eric Amberg Multicast hatte bereits bei IPv4 eine große Bedeutung, ist bei diversen IPv6-Features nun aber essentiell geworden. Multicast-Kommunikation wird unter anderem bei der Autoconfiguration und IPv6 Adressen (Multicast Adressen ) beim Neighbor Discovery eingesetzt. Grund genug, sich in diesem Beitrag einmal diesem Adresstyp anzunehmen und Multicast-Adressen näher zu beleuchten. Multicast hatte bereits bei IPv4 eine große Bedeutung, ist bei diversen IPv6-Features nun aber essentiell geworden. Multicast-Kommunikation wird unter anderem bei der Autor: Eric Amberg Autoconfiguration und beim Neighbor Discovery eingesetzt. Multicast-Adressen nutzen das Multicast-Adressen nutzen das Präfix FF00::/8. Der allgemeine Aufbau einer Multicast-Adresse stellt sich folgendermaßen Präfix FF00::/8. dar: Der allgemeine Aufbau einer Multicast-Adresse stellt sich folgendermaßen dar: Abbildung Nach dem Präfix folgen 4 Bits Flags, 1: Aufbau wobei einer nur die Multicast-Adresse drei Low-Order-Bits derzeit verwendet sind. Sie definieren die genaue Art und Nutzung der Multicast-Adresse und können die Nach folgenden dem Präfix Werte folgen annehmen: 4 Bits Flags, wobei nur die drei Low-Order-Bits derzeit verwendet sind. Sie definieren T-Flag (Transient): die genaue 0=Well-Known-Multicast-Adresse Art und Nutzung der Multicast-Adresse (IANA), und 1=transient, können die also folgenden nicht Werte annehmen: permanent T-Flag (Transient): 0=Well-Known-Multicast-Adresse (IANA), 1=transient, also nicht permanent P-Flag (Prefix): Multicast-Adresse basiert auf einem Unicast-Präfix, siehe RFC 3306 P-Flag (Prefix): Multicast-Adresse basiert auf einem Unicast-Präfix, siehe RFC 3306 R-Flag (Rendezvous Point Address): Multicast-Adresse enthält einen Rendezvous-Point R-Flag (Rendezvous Point Address): Multicast-Adresse enthält einen Rendezvous-Point (RFC (RFC 3956) 3956) Für die meisten Standard-Fälle stehen diese vier Bits auf Anders jedoch die nachfolgenden Scope-Bits, die ebenfalls vier Bits umfassen. Sie definieren den Scope (Wirkungsbereich, Region), innerhalb dessen eine Multicast-Adresse gültig ist. 37

38 IPv6 Adressen (Multicast Adressen ) Die folgenden Scopes sind definiert: 1. 1: interfacelokal, diese Pakete verlassen die Schnittstelle nie. Dies ist ggf. für Loopback-Anwendungen gedacht. 2. 2: link-lokal, diese Multicast-Pakete werden nicht von Routern weitergeleitet und verbleiben im lokalen Subnetz (am lokalen Link). 3. 4: adminlokal, ein Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss. 4. 5: sitelokal, Multicast-Pakete, die zwar innerhalb des Standortes, aber nicht von den Border-Routern geroutet werden. 5. 8: organisationslokal, umfasst den Bereich der gesamten Organisation, die Multicast-Pakete dürfen jedoch nicht ins Internet geroutet werden. 6. e: globaler Multicast, der überallhin geroutet werden darf auch ins Internet. 7. 0, 3, F: reservierte Bereiche, die derzeit nicht in Benutzung sind. 8. die restlichen Bereiche sind derzeit nicht zugewiesen und können für weitere Multicast-Regionen definiert werden. 38

39 IPv6 Adressen (Multicast Adressen ) In den meisten Fällen kommen Well-Known-Multicast-Adressen zum Einsatz: Die Abbildung zeigt typische Well-Known-Multicast-Adressen mit den Scopes Interface-Local (1), Link-Local (2) und Site-Local (5). Der wichtigste Bereich ist Link- Local (2), da hier essentielle Funktionen, wie z.b. Autoconfiguration und Neighbor Discovery stattfinden. Außerdem kennt IPv6 kein Broadcast mehr stattdessen wird die Multicast-Adresse FF02::1 (All Nodes-Adresse) angesprochen. 39

40 IPv6 Adressen (Anycast Adressen ) Das Konzept der Anycast-Adressen kommt eigentlich schon bei IPv4 zur Anwendung. Bei IPv6 soll Anycast nun jedoch eine ganz neue Bedeutung gewinnen. Unter einer Anycast-Kommunikation wird das Ansprechen eines Systems im Netzwerk verstanden, das die kürzeste Route vom Absender betrachtet aufweist (one-to-nearest). Während Unicast ein eindeutiges Ziel anspricht, Broadcast alle Systeme im Subnetz und Multicast bestimmte Gruppen von Knoten adressiert, sucht sich die Anycast-Kommunikation via Routing- Information immer ein möglichst nahestehendes Ziel. Dieses Konzept ist vergleichbar mit dem Notruf 112, bei dem die Verbindung zur nächstliegenden Notrufzentrale aufgebaut wird. Dabei nutzt das Anycast-Konzept kein festgelegtes Präfix. Stattdessen wird ein beliebiges Global- Unicast-Präfix verwendet, wobei mehrere Knoten dieselbe Interface-ID erhalten. Auch wenn Anycast- Adressen nicht von anderen Global-Unicast- Adressen unterscheidbar sind, müssen die entsprechenden Systeme, denen diese Adressen zugewiesen werden, darüber informiert werden, dass es sich um eine Anycast-Adresse handelt. 40 Kommunikation Abbildung 1: Anycas Dabei nutzt das Anycast-Konzept kein festgelegtes Präfix. Stattdessen wird ein beliebiges Global-U Präfix verwendet, wobei mehrere Knoten dieselbe Interface-ID erhalten. Auch wenn Anycast-Adres

41 IPv6 Adressen (Anycast Adressen ) In der Praxis bringt eine Anycast-Kommunikation folgende Vorteile: verkürzte Zugriffszeiten durch kürzere Routingwege, Loadbalancing durch Nutzung verschiedener Systeme je nach Standort des Absenders, völlige Transparenz für den Absender, da das Anycast-Präfix sich nicht von anderen Global-Unicast-Adressen unterscheidet. Dabei ist allerdings zu beachten, dass Anycast-Kommunikation den Nachteil hat, dass nicht steuerbar ist, welche Zielsysteme im konkreten Fall angesprochen werden. Sollte während der Kommunikation eine Änderung der Verfügbarkeit oder des Routings stattfinden, werden plötzlich andere Systeme über die verwendete Anycast-Adresse angesprochen, was zum Abbruch der Kommunikation führt. Für größere Datenübertragungen ist Anycast daher nicht geeignet, wohl aber für kurze Abfragen, wie z.b. DNS. So wird Anycast derzeit bei einigen der DNS-Rootservern sowie für den Tunnel- Mechanismus 6to4 eingesetzt. Bei 6to4 werden die 6to4-Relays über die IPv4- Anycast-Adresse angesprochen. 41

42 IPv6 - die Default Address Selection Ursprünglich legte RFC 3484 Regeln bzw. einen Algorithmus fest, nach denen IP- Adressen, die demselben Interface zugeordnet sind, ausgewählt werden. Dieser RFC wurde durch RFC 6724 abgelöst. Hier die neuen Regeln in Kurzform: Adresspaare (Quell- und Zieladresse) mit demselben Scope oder Typ (link-local, global) sind bevorzugt Der kleinere Scope für eine Destination Adresse wird einem größeren Scope vorgezogen Eine bevorzugte (preferred) Adresse ist bevorzugt zu nutzen (anstatt einer abgelaufenen) Adressen für Übergangsmechanismen (ISATAP, 6to4, etc.) sollen nicht genutzt werden, wenn eine native IPv6-Adressen zur Verfügung stehen Wenn alle Kriterien ähnlich sind, sollen Adresspaare mit den längsten übereinstimmenden Präfixen verwendet werden Für die Quell-Adresse sind temporäre Adressen globalen Adressen vorzuziehen Diese Regeln werden immer dann angewendet, wenn nichts anderes definiert ist Betriebssysteme müssen Mechanismen vorsehen, mit denen Applikationen die obenstehenden Regeln ändern können. 42

43 Wenn möglich, nutzen die Knoten demnach ihre Link- Local-Adressen, da diese den kleinsten Scope haben. Ansonsten ist wichtig, dass immer gleichartige Adresspaare genutzt werden: 43

44 Mit Systemen im selben Subnetz wird nach Möglichkeit über die Link-Local-Adresse kommuniziert. Dies gilt auch für die Kommunikation mit dem Default-Gateway. Werden Global-Unicast-Adressen oder Unique-Local-Adressen verwendet, müssen gültige Adressen verwendet werden. Werden die Adressen per Autoconfiguration gebildet, ist diese Gültigkeit in der Regel begrenzt. Im Gültigkeitszeitraum wird eine IPv6-Adresse als bevorzugt (preferred) bezeichnet, während sie im Anschluss für eine bestimmte Zeit in den Status abgelaufen (deprecated) wechselt, bevor sie ungültigt (invalid) wird. Adressen im Status deprecated können noch von anderen Systemen angesprochen werden, sollen jedoch nicht mehr für eigene Verbindungen genutzt werden. Adresspaare sollten immer den gleichen Scope haben: eine Global-Unicast-Adresse und eine Link-Local-Adresse passen nicht zusammen. Auch Unique-Local- und Global-Unicast-Adressen haben einen unterschiedlichen Scope und sollten daher nicht als Adresspaare (Absender-/Empfänger-Adresse) verwendet werden. Wird ein Knoten über eine bestimmte Adresse angesprochen, nutzt er diese Adresse auch immer für die Antwort. Tunnel-Adressen sollten nur dann verwendet werden, wenn keine nativen Adressen mit einem passenden Scope zur Verfügung stehen. Hat ein Knoten sowohl globale Adressen (dies sind feste Global Unicast-Adressen mit einer unbeschränkten Gültigkeit, über die das System jederzeit angesprochen werden kann) also auch temporäre Adressen (via Autoconfiguration gebildet), so sollte laut RFC 3484 die globale Adresse verwendet werden. Allerdings legt RFC 6724 fest, dass dies genau anders herum geschehen soll, also temporäre Adressen bevorzugt werden. Dies ist natürlich auch sinnvoll, da temoräre Adressen mit Hilfe der Privacy-Extensions (siehe RFC 4941) gebildet werden können und damit sicherer sind als statische Adressen. Server sollten keine temporären Adressen bekommen, da diese ja gerade immer unter der gleichen Adresse erreichbar sein sollen. Beachten Sie, dass es sich hier eigentlich um einen Fallback-Mechanismus handelt. Das bedeutet, dass diese Regeln nur dann greifen, wenn von seiten des kommunizierenden Knotens nichts anderes festgelegt wurde. Daher heißt der Titel auch Default Address Selection. 44

45 IPv6 Fragmentierung Zu große Datenpakete werden von IPv6-Routern nicht mehr selber fragmentiert. Ist ein Paket zu groß wird dem Absender eine Fehlermeldung geschickt. Dieser muss dann die maximale Paketgröße anpassen. War in IPv4 dieses Verfahren optional, ist es in IPv6 Pflicht. Kommt es zum Verlust eines Datenpaketes oder kommt es zu Fehlern bei der Fragmentierung schlägt das Path MTU Discovery fehl. IPv6 hat als kleinste einstellbare MTU 1280 Byte. Dadurch werden die Router nicht mehr unnötig belastet. Selbstverständlich können auch kleinere Pakete als 1280 Byte übertragen werden. 45

46 Tunneling 46

47 IPv6-Adressstruktur (Präfixe und "Netzmasken") Bei IPv6 werden die ersten 64 Bit der Adresse nur für das globale und lokale (Siteinterne) Routing verwendet. Diese ersten 64 Bit einer IPv6 Adresse beschreiben also gewissermaßen schon genau, wo (in welchem Subnetz) sich ein Netzknoten topologisch befindet und werden auch als Routing-Präfix bezeichnet. Die letzten 64 Bit einer IPv6-Adresse werden als Host-Identifier bezeichnet und zeichnen einen einzelnen Host (ein einzelnes Netzwerk-Interface) innerhalb eines Subnetzes aus. Bis auf ganz wenige Ausnahmen können und werden Subnetze also nicht kleiner sein als 64 Bit. Netzmasken im Sinne von " " bei IPv4 gibt es bei IPv6 nicht mehr. Hier wird nur noch die im Zuge von CIDR eingeführte Schreibweise <Adresse>/<Präfix- Länge> verwendet. 47

48 IPv6-Adressstruktur (Präfixe und "Netzmasken") IPv6 werden mit Hilfe des Binärwertes gruppiert.. Die Gruppierung erfolgt über einen Präfix. Präfixe sind alle Adressen die mit der gleichen Serie von Bits beginnen. Die Länge der identischen Bits wird am Ende der Adresse, nach einem / angezeigt. Der Präfix 2001:db8::/32 enthält alle Adressen von 2001:0db8:0000:0000:0000:0000:0000:0000 bis 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff Falls die Präfixlänge kein Vielfaches von 4 ist, wird auf Binäreben getrennt. Der Präfix 2001:db8::/61 enthält alle Adressen von 2001:0db8:0000:0000:0000:0000:0000:0000 bis 2001:0db8:0000:0007:ffff:ffff:ffff:ffff 48

49 IPv6-Adressstruktur (Präfixe und "Netzmasken") Notierungen der folgenden Art 2001:638:500::/ :638:500:ff00:/ :638:500:200:/64 bezeichnen dabei also entsprechend Netze, bei denen die ersten 48/56/64 Bit der Adressen wie vorgegeben festgelegt sind. So hat beispielsweise der DFN Verein im Jahr 2001 von RIPE den Adressblock 2001:638::/32 bekommen, und vergibt daraus an seine Kunden (Forschungseinrichtungen und Universitäten in Deutschland) /48er- Adressblöcke wie beispielsweise 2001:638:500::/48 an die Universität Münster. 49

50 IPv6-Adressstruktur (Präfixe und "Netzmasken") IEEE MAC-Adresse (48 Bit) => IPv6-Interface ID Adresse (64 Bit) Bei der Abbildung der 48 Bit langen IEEE auf die 64 Bit langen IPv6-Interface ID Adresse werden die ersten drei Oktette der IEEE MAC-Adresse (OUI = Organizational Unique Identifier) in die Adresse übernommen. In das vierte und das fünfte Oktett wird die Zahlen FF 16 und FE 16 eingefügt. Die letzten 3 Oktette der IEEE MAC-Adresse werden zu den letzten drei Oktetten der Adresse. Zusätzlich wird auch das u-bit invertiert. 50

51 IPv6-Adressstruktur (Präfixe und "Netzmasken") Bei IPv6 werden die ersten 64 Bit der Adresse nur für das globale und lokale (Siteinterne) Routing verwendet. Diese ersten 64 Bit einer IPv6 Adresse beschreiben also gewissermaßen schon genau, wo (in welchem Subnetz) sich ein Netzknoten topologisch befindet und werden auch als Routing-Präfix bezeichnet. MAC: 00:11:22:33:44: :DB08:ABBA:CCDD:0211:22FF:FE33:4455 Subnetz FF:FE werden für zum Auffüllen auf 64 Bit benötigt /56 Provider Präfix Die letzten 64 Bit einer IPv6-Adresse werden als Host-Identifier bezeichnet und zeichnen einen einzelnen Host (ein einzelnes Netzwerk-Interface) innerhalb eines Subnetzes aus. Bis auf ganz wenige Ausnahmen können und werden Subnetze also nicht kleiner sein als 64 Bit. Netzmasken im Sinne von " wie bei IPv4 gibt es bei IPv6 nicht mehr. Hier wird nur noch die im Zuge von CIDR eingeführte Schreibweise <Adresse>/<Präfix-Länge> verwendet. 51

52 IPv6-Adressstruktur (Präfixe und "Netzmasken") Präfix wird vergeben an Anzahl Adressen /32 LIR (Local Internet Registry, normalerweise ein Internet Service Provider) 2 96 /48 Organisation 2 60 /64 Organisation Netzwerk (Subnetz) 2 64 /128 Host (PC, Server etc.) 1 52

53 IPv6 Relative Network Sizes /128: 1 IPv6 address A network interface /64 1 IPv6 subnet / LAN segments Popular prefix size for one subscriber site: /48 65,536 LAN segments Popular prefix size for one subscriber site /32 65,536 /48 subscriber sites Minimum IPv6 allocation /24 16,777,216 subscriber sites 53