Motivation für IPv6 (warum ein neue IP Version) Autokonfigurationsmechanismen. weitere Änderungen aus Benutzersicht

Transkript

1 Agenda Motivation für IPv6 (warum ein neue IP Version) Protokollübersicht Autokonfigurationsmechanismen weitere Änderungen aus Benutzersicht DNS Transition / CoExistence Routing / Multihoming / Mobility Security inkl. Situation Firewalls et al. 42

2 Transition Transition im Sinne von IPv6 ersetzt IPv4 wird es wohl nie bzw. noch sehr lange nicht geben. 3 Phasen wahrscheinlich: beginnender Einsatz von Dual-Stack Zwischenphase: grosse Teile IPv6, aber auch noch grosse Teile IPv4 Abschluss: grossteils IPv6, IPv4 Inseln die mittels NAT-PT am IPv6 Netz teilnehmen IETF Arbeitsgruppe für Transition (ngtrans) hat 02/2003 ihre Arbeit für beendet erklärt, ie. keine neuen Transition-Mechanismen Aktuelle Entwicklungen (hptsl. Security/Evaluation) werden in der v6ops Arbeitsgruppe behandelt. 43

3 CoExistence Dual Stack IPv4 und IPv6 parallel aktiv gewohnter, bekannter Ansatz und altbekannte Probleme IPv6 bei allen aktuellen Betriebssystemen inkludiert beide Welten erreichbar, Host wählt (hoffentlich) das richtige Protokoll mittels DNS, zuerst AAAA-Record (IPv6), wenn keine Antwort A Record (IPv4) erlaubt langsamen, sanften Übergang löst allerdings nicht das Problem der Adressknappheit 44

4 CoExistence Tunnel zur Verbindung von Inseln der einen IP-Version über Netze der anderen IP-Version, ie. IPv6-in-IPv4 Tunnel oder IPv4-in-IPv6 Tunnel manuell konfiguriert nur sehr begrenzt sinnvoll, Skalierbarkeit, Wartbarkeit tunnel broker Spezialfall, wo eine zentrale Entität Tunnel-Infrastruktur zur Verfügung stellt, meist gescriptet/automatisiert (z.b. 45

5 CoExistence Tunnel - 6to4 - RFC Automatischer Tunnelaufbau, zur Verbindung von IPv6 Inseln über das IPv4 Netz definierter Prefix 2002::/16 Eine global eindeutige IPv4-Adresse (am Border-Router) genügt, um eine ganze Site IPv6-fähig zu machen erstellt automatisch die notwendigen IPv6-in-IPv4 Tunnel, ie. verwendet das IPv4-Netz als Point-to-Point link erfordert 6to4-Relays um auch die Kommunikation zum eigentlichen IPv6- Netz zu gewährleisten RFC3068 definiert einen anycast prefix für 6to4-relays, d.h. man muss sich keinen offenen relay suchen, sondern die anycast Adresse (in 6to4 2002:c058:6301::) sorgt dafür, dass das nächste 6to4-relay verwendet wird. Wien21#sho bgp BGP routing table entry for /24, version Paths: (3 available, best #2, table Default-IP-Routing-Table) from ( ) Origin IGP, localpref 100, valid, external from ( ) Origin IGP, localpref 130, valid, external, best Community: 20965:155 46

6 CoExistence Tunnel - 6to4 Wie kommt der (global eindeutige) 6to4-Prefix zustande: IPv4 Adr. des Border-Routers dezimal hex C0 99 AE C099:AE15 subnet ID Interface ID 16 bits 32 bits 16 bits 64 bits z.b.: 2002:C099:AE15:0001:216:cbff:fe96:a591/64 47

7 CoExistence Tunnel - 6to4 48

8 CoExistence Tunnel - Hostbasiert isatap (Intra-Site Automatic Tunnel Addressing Protocol) Ermöglicht innerhalb einer Site einzelne IPv6-fähige isolierte Hosts, durch das IPv4-Netz getunnelt, an das IPv6-Netz anzuschließen. teredo - RFC4380 Erlaubt es IPv4 Rechnern hinter einem NAT System mittels eines TEREDO Servers das IPv6 Internet zu erreichen. Dazu werden die IPv6 Pakete in IPv4 UDP Pakete verpackt, die das NAT System traversieren können. 49

9 CoExistence weitere CoExistence-Mechanismen NAT-PT (RFC2766 bzw. RFC4966) Probleme mit Diensten die IPv4 Adressen in der Payload mitführen fragmentation Probleme mobility Probleme kein Multicast Probleme mit Application Layer Gateways... Empfehlung RFC2766 als historic zu definieren, bereits geschehen MPLS - 6PE (RFC4798) analog zu MPLS VPN Service Provider Edge Router müssen Dual-Stack und MP-BGP fähig sein Core ist IPv4-only BGP Next-Hop Field enthält die IPv4 Adresse des 6PE Routers, um den Label Switched Path zu erstellen (ohne explizite Tunnelkonfiguration) 50

10 Transition / CoExistence?? Fragen?? 51

11 Agenda Motivation für IPv6 (warum ein neue IP Version) Protokollübersicht Autokonfigurationsmechanismen weitere Änderungen aus Benutzersicht Transition / CoExistence DNS Routing / Multihoming / Mobility Security inkl. Situation Firewalls et al. 52

12 Routing statisch wie gehabt RIP RIPng für IPv6, RIPv2 für IPv4, keine sonstigen Neuerungen OSPF OSPFv3 unterstützt nur IPv6, d.h. im Dual-Stack Szenario müssen OSPFv2 (für IPv4) und OSPFv3 (für IPv6) parallel betrieben werden IS-IS Multiprotokoll-fähig, daher problemlose Unterstützung von IPv6 EIGRP ebenfalls Multiprotocol fähig, ab 12.4(6)T bzw. 12.2(33)SXI oder 12.2(33)SRB, keine sonstigen Neuerungen 53

13 Routing BGP MultiProtocol-BGP (BGP4+) notwendig, RFC4760 definiert die Multi-Protokoll Erweiterungen unterstützt diverse Adressfamilien, IPv4 und IPv6, jeweils Unicast und Multicast, MPLS,... Transportprotokoll und Routinginformation müssen nicht aus der gleichen Protokollfamilie sein Konfiguration des richtigen Peerings in der richtigen address-family 54

14 Änderungen aus Benutzersicht Multihoming Mehrere Ansätze, oft ähnlich oder gleich wie IPv4, work in progress : Provider Independent Adressen (routing table explodiert ): oft nur /48 von der RIR (Micro-Allocations), aber Backbone Filter oft </32 Vorteil mehrere Adressen pro Host Erreichbarkeit: mehrere Adressen im DNS notwendig Verbindungsaufbau: welche Adresse wird verwendet? weitere nicht sehr vielversprechende Ansätze Überlegungen für next-generation Routing in der IETF Locator - Identifier Split ein global eindeutiger Identifier, aber Locator je nach aktuellem Standort (abhängig von Netzwerk, Provider, usw.) dzt. noch keine Implementierung, einige gute Ansätze IRTF - Host Identity Protocol Research Group 55

15 Mobility - RFC3775 Voraussetzungen für Mobile IPv6 (MIPv6): Mobile Node (MN) hat eine global gültige Unicast Adresse, bezeichnet als seine Home Address (HoA), mit der er global erreichbar ist Die Home Address (HoA) wird von der Correspondent Node (CN) als Zieladresse verwendet Der Correspondent Node (CN) kann mittels Binding Updates (BU) die neue Position einer Mobile Node (MN) lernen und diese direkt erreichen Der Home Agent (HA) übernimmt die Erreichbarkeit der MN im Heimnetz, ie. leitet Pakete die an den MN adressiert sind mittels dynamisch aufgebautem Tunnel (IPv6-in-IPv6) an den MN weiter Änderungen im Protokoll notwendig 56

16 Mobility - RFC3775 Um das Routing effizienter zu machen sind mehrere Änderungen im IPv6 Stack notwendig: neuer extension-header: Mobility Header für alle Nachrichten bezüglich Bindings und return routability neue Option im Destination Option Header: Home Address in Paketen von MN zu CN neuer Routing Header Typ: Type 2 Transport der Home Address bei Paketen von CN zu MN neue ICMP Messages für Home Agent Address Discovery und Konfiguration 57

17 Mobility - RFC3775 simpler Ansatz: bidirectional tunneling Mobile Node Correspondent Node 1. HA Binding registration 2. Verbindungsaufbau CN HoA von MN 3. Tunnel von HA zu MN Home Agent Heimnetz des mobilen Host 4. Antwort von MN via Tunnel zu HA 5. HA sendet Paket normal an CN 58

18 Mobility - RFC3775 aufwendiger Ansatz: direct routing Mobile Node Correspondent Node 1. HA Binding registration 2. Verbindungsaufbau CN HoA von MN 3. Tunnel von HA zu MN Home Agent Heimnetz des mobilen Host 4. CN Binding registration 5. normales Routing zwischen CN & MN 59

19 Mobility - RFC3775 MIPv6 und Sicherheit return routability procedure zwischen MN und CN - Home und Care-of Test verhindert keine Man-in-the-Middle Attacken, aber verhindert gespoofte Binding-Updates IPsec speziell zw. MN und HA, da beide im Normalfall in der gleichen Management-Domain liegen 60

20 Routing?? Fragen?? 61