IPv6 Adresskonzept : Entstehung und Inhalt

Transkript

1 Direktion ICT / IONN Winterthur, IPv6 Adresskonzept : Entstehung und Inhalt Manuela Roth Netzwerk Managerin

2 Agenda UniversitätsSpital Zürich IPv4 Adressierung IPv6 Adresskonzept - Entwicklungsverlauf - Prefix-Aufteilung - Hostteil-Adressierung - Offene Fragen

3 UniversitätsSpital Zürich

4 Kurzüberblick Personen: - ~ 6500 Mitarbeiter im USZ - ~ 100 Mitarbeiter in der ICT - 6 Mitarbeiter in der Gruppe Netzwerk Standorte: - Campus aus diversen Gebäuden im Zentrum von Zürich - Externes Rechenzentrum in Zürich Altstetten - Externes Rechenzentrum in Rümlang - Forschungsareal in Schlieren

5 Das Netzwerk ~ aktive Endhosts ~ 40 Netz-nahe Serversysteme (DNS, NMS, ACS etc.) Internet: via Uni Zürich an SWITCH MPLS/VPN Backbone mit VRFs für Zonenkonzept acht Client- und zwei Server- Distribution-Blöcken zwei via CWDM erschlossene externe RZ ~ 300 IP Phones im VoIP Pilot ~ 1700 APs, 9 WISM, 7 SSIDs ~ 700 Client Access Switches

6 USZ Aufbau Labor-Umgebung interne Schulung und Lab für Netzwerk- und Perimeter Security Teams Adresskonzept Assessment der Netzwerkkomponenten durch Netcloud

7 IPv4 Adressierung

8 Übersicht der IPv4 Adressen Verwendete Adressbereiche: IP Range Verwendung Unterteilung /16 für alles unstrukturiert (historisch gewachsen) MPLS/VPN DMZ, FWs, NAT Hierarchisches Bit-Schema: VRF Trakt (Distribution-Block) Subnet /16 pro Firewall Hierarchisches Bit-Schema für den MPLS/VPN Bereich: 1. Oktet. 2. Oktet. 3. Oktet. 4. Oktet Prefix. 2 Bit + 6 Bit. 4 Bit + 4 Bit. Hosts 4 Bereiche 64 VRFs 16 Trakte 16 Subnets (/24er)

9 Beispiel: Hierarchische MPLS/VPN Adressierung pro VRF : - /16 IP Range - 16 VLANs VRF med /16 VLANs VRF leita /16 VLAN pro Trakt : - /20 IP Range AUFN /20 OST /20 AUFN /20 pro Subnet : - /22 - /24 IP Range - 1 VLAN AUFN_medTech /24 VLAN 3256 AUFN_Schlaflabor /24 VLAN 3257 OST_medTech /24 VLAN 3256 AUFN_Leitsystem-A /23 VLAN 3368

10 IPv6 Adresskonzept

11 Entwicklungsverlauf des Adresskonzeptes Herbst 2011 bis Frühling 2013 Parallel zum den einzelnen Entwicklungsschritten: - Besuch von Infoveranstaltungen - Austausch mit anderen Firmen (SWITCH, ETH, Uni Zürich) - Consulting durch Netcloud

12 Entwicklungsverlauf 1) Aufnahme des IST Zustand: - Anzahl vorhandener VRFs, Trakte und IPv4 Subnets pro VRF/Trakt - IPv4 Adress- und VLAN-Konzepte - IPv6 Prefix: 2001:620:13::/48 von SWITCH 2) Festlegen der Rahmenbedingungen des IPv6 Adresskonzept: - kompatibel mit dem existierenden Netz - Implementation von IPv6 ohne IPv4 Readressierung der Endsysteme - ausgelegt für mehrjährigen Dual-Stack Betrieb Entscheid: Übernahme der VRF / Trakt / Subnet Hierarchie ins IPv6 Adresskonzept

13 Entwicklungsverlauf 3) Reserveplanung: - Reserven pro Abschnitt festlegen - Addition der Reserven zum IST Zustand ergibt SOLL Menge 4) Erstellen von Aufteilungsmöglichkeiten basierend auf der SOLL Menge: - /48 Prefix : 16 Bits für Strukturierung - in jedem Szenario mussten gewünschte Reserven verkleinert werden (Aufrunden auf die nächste binäre Grenzen braucht Platz) - Grenzen der Abschnitte lagen nie alle auf Nibble- oder Byte-Grenze (ein Nibble entspricht einer Hex-Stelle) - Beispiel: 1. Nibble 2. Nibble 3. Nibble 4. Nibble 1 Bit 6 Bit 4 Bit 5 Bit Reserve VRF Trakt Subnet

14 Entwicklungsverlauf 5) Feststellungen: - Abschnittsübergänge neben den Nibble-Grenzen ist betrieblich ungünstig, da für das menschliche Auge keine Struktur erkennbar - der Prefix von SWITCH ist nicht Provider-Independent (Gefahr von Readressierung bei zukünftigem Dual-Homing) 6) Lösung: - USZ registriert sich direkt bei RIPE als LIR (Local Internet Registry) - 2a02:7dc0::/32 Provider-Independent IPv6 Prefix erhalten 32 Bits (4 Byte) für Subnettierung auf diesem Prefix basiert nun das IPv6 Adresskonzept weitere neue Rahmenbedingungen: - SOLL Menge ohne Abstriche umsetzen - Abschnittsgrenzen auf Nibble- oder Byte-Grenzen legen

15 Abschnittsgrössen und Prefix-Struktur Aufrunden der SOLL Mengen auf die nächste Nibble-Grenze: - alle drei Abschnitte gleich gross: 1 Byte Differenz von verfügbaren und verplanten Bytes: 1 Byte - neuer Abschnitt "Bereich" erstellt, der v.a. die grossen Reserven enthält Definitive Abschnittsgrössen: Bereich VRF Trakt Subnet 1 Byte 1 Byte 1 Byte 1 Byte Prefix-Struktur für ein /64: PPPP:PPPP:BBVV:TTSS::/64

16 Hostteil der Adressen : Vorbereitung bei manueller Adressvergabe müssen in einem /64 Prefix die per RFCs reservierten Bereiche berücksichtigt werden manuelle Adressvergabe bedeutet: - statische Adressierung - Adressierung via DHCPv6 - Verwendung von Prefix-Längen grösser als /64 (z.b. /128 für Loopbacks) RFC 5375: die Liste der RFCs, die Adressbereiche für spezielle Zwecke reservieren [Stand: Dezember 2008]

17 Reservierte Adressen (I) RFC 4291 : IP Version 6 Addressing Architecture Subnet Router Anycast Address: Prefix n Bits Interface ID (128-n) Bits EUI-64 U and G Bits (für Interface ID Format nach EUI-64): Bit Funktion Bit-Nr Wert = 0 Wert = 1 Universal/Local Bit 71 lokal verwaltet global verwaltet (eigentlich nur bei SLAAC) Group/Individual Bit 72 Unicast Adresse Multicast Adresse bei Prefix-Längen grösser als /64 und manuell vergebenen (Unicast) Adressen müssen beide Bits auf 0 gesetzt sein!

18 Reservierte Adressen (II) RFC 2526 : Reserved IPv6 Subnet Anycast Addresses für Prefixe von 2xxx:: bis fxxx:: (ausser Multicast Adressen): Prefix Interface ID 64 Bits 64 Bits 57 Bits 7 Bits Anycast ID Universal Bit auf 0 gesetzt

19 Reservierte Adressen (III) RFC 3956 : Embedding the Rendezvous Point Address in an IPv6 Multicast Address Prefix Interface ID 64 Bits 64 Bits 60 Bits 4 Bits RIID RFC 5214 : Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Prefix Interface ID 64 Bits 64 Bits 32 Bits 32 Bits 0000:5efe IPv4 Address

20 Beispiel eines /64 Hostteile erlaubt für: - statische Adressierung - DHCPv6 - Prefix-Länge grösser /64 Bits Bits Bits Bits Regel Router Anycast [1-f] Embedded RP x EUI-64 U/G-Bit efd xxxx xxxx EUI-64 U/G-Bit efe xxxx xxxx ISATAP eff xxxx xxxx EUI-64 U/G-Bit... 00ff xxxx xxxx xxxx EUI-64 U/G-Bit 0[1-3]xx xxxx xxxx xxxx EUI-64 U/G-Bit 04xx EUI-64 U/G-Bit 0[5-7]xx xxxx xxxx xxxx EUI-64 U/G-Bit 08xx EUI-64 U/G-Bit 0[9b]xx xxxx xxxx xxxx EUI-64 U/G-Bit 0cxx EUI-64 U/G-Bit 0[d-f]xx xxxx xxxx xxxx EUI-64 U/G-Bit [1-e][0,4,8,c]xx xxxx xxxx xxxx EUI-64 U/G-Bit [1-e][1-3,5-7,9-b,d-f]xx xxxx xxxx xxxx EUI-64 U/G-Bit f[0,4,8,c]xx xxxx xxxx xxxx EUI-64 U/G-Bit f[1-3,5-7,9-b]xx xxxx xxxx xxxx EUI-64 U/G-Bit fd0x xxxx xxxx xxxx EUI-64 U/G-Bit... fdff ffff ffff ff7x EUI-64 U/G-Bit fdff ffff ffff ff[8-f]x Subnet Anycast f[e-f]x xxxx xxxx xxxx EUI-64 U/G-Bit

21 Adressierung des Hostteils globaler Adressen automatische Generierung von globalen Adressen wird nicht eingesetzt Adressbereich für manuelle Adressvergabe: 2a02:7dc0:x:x:0:0:0:0010 bis 2a02:7dc0:x:x:0:0:0:ffff Unterteilung in verschiedene Anwendungsfälle: Anwendungsfälle Bits Subnet-Gateways (inkl. HSRP) 0x0010-0x0fff statisch adressierte Dual-Stack Systeme 0x1000-0x1fff statisch adressierte IPv6-only Systeme 0x2000-0x2fff Dynamic Statefull DHCPv6 0x3000-0x3fff Manual Statefull DHCPv6 0x4000-0x4fff for future use 0x5000-0xffff

22 Adressierung des Hostteils von Link-Local Adressen Endsysteme: - automatisch generiert (entsprechend dem OS) Routers: - manuell gesetzt (analog der Regel für globale Adressen)

23 Prefix Längen drei Anwendungsfälle mit unterschiedlichen Prefix Längen: Anwendungsfall Zugewiesene Länge Konfigurierte Länge Loopbacks /64 /128 Point-to-Point Links (Router only) /64 /126 Endsysteme /64 /113 Hintergründe: - Gefahr für Router bei Scan eines /64: Verarbeiten und Speichern offener Neighbor Einträge kann CPU und Memory überlasten - Ready for the Future: immer /64 zuweisen falls zukünftige Technologien zwingend /64 benötigen auf /64 umkonfigurieren: nur Prefix-Längenen umkonfigurieren, keine Änderung an den Adressen selber

24 Offene Fragen erst die Praxis zeigt's Umgang mit Systemen, die nur /64 Prefix-Länge kennen - Windows XP - vermutlich Medizinsysteme, Haustechnik etc. Default-Gateway für statisch adressierte Endsysteme (z.b. Servers): - entweder: virtuelle globale HSRP-Adresse manuell eintragen - oder: virtuelle Link-Local HSRP-Adresse manuell eintragen» lässt das System das überhaupt konfigurieren?» Vorteil: alle Endsysteme haben den gleichen Default-Gateway» Nachteil: Verwirrung durch Mischen von Global und Link-Local Scopes - und: aus Router Advertisments automatisch bezogener Default-Gateways» ist die virtuelle Link-Local HSRP-Adresse» RA Versand auf diesen VLANs unterdrücken?

25 Hinweis zu DNS DNSv4 und DNSv6 sind völlig unabhängige Services ein Name löst für IPv4 und IPv6 nicht zwingend auf den gleichen Server auf Nachteil: - kann zu Missverständnissen führen - muss bei Troubleshooting miteinkalkuliert werden Vorteil: - IPv6 Version eines Service kann auf anderem Server als die IPv4 Version implementiert werden proxy.usz.ch DNSv4 DNSv6 sv00123 sv00456

26

27 Danke für Ihre Aufmerksamkeit