Anforderungen an IPv6 ICT Ausrüstung

Anforderungen an IPv6 ICT Ausrüstung Jan Žorž Sander Steffann Document ID: ripe-501 Date: November 2010 Übersetzung: Wilhelm Boeddinghaus, Strato AG, Deutscher IPv6 Rat Mai 2011 Einleitung Um eine sanfte und kostengünstige Einführung von IPv6 in ihren Netzwerken zu erreichen, ist es wichtig, dass Regierungen und Unternehmen in Ausschreibungen für Projekte mit Informations- und Computer-Technologie (ICT) Anforderungen zu IPv6 aufnehmen. Dieses Dokument soll Best Common Practices (BCP) beschreiben, die bei Ausschreibungen von Regierungen und Unternehmen als Vorlage dienen können. Es kann auch als Handreichung für Unternehmen dienen, die als Anbieter an Ausschreibungen teilnehmen. Das Dokument stellt 3 mögliche Optionen zur Auswahl, wie IPv6-Anforderungen in Ausschreibungen spezifiziert werden können: Option 1 basiert im wesentlichen auf dem vom National Institute für Standards and Technology entwickelten IPv6-Anforderungskatalog für die US-Verwaltung (NIST/USGv6) http://www.antd.nist.gov/usgv6/ Die Autoren haben diesen Katalog zugunsten einer universelleren Anwendbarkeit angepasst. Der neue Entwurf enthält eine Liste von RFC Spezifikationen, die unterstützt werden müssen, aufgeteilt in 4 Kategorien. Option 2 basiert auf den zwei Phasen des IPv6 Ready Programm des World IPv6 Forum. Phase 1 beinhaltet einen Test und eine Zertifizierung der grundlegenden IPv6 Funktionalität. Phase 2 beinhaltet einen Test und eine Zertifizierung weitergehender IPv6 Funktionalität. Option 3 kombiniert die Ansätze aus den beiden erstgenannten Optionen. 1

Option 1 Die Anforderungen sind unterteilt in Anforderungen an Hardware und an einen Systemintegrator ( basierend auf Ergbnissen der go6 IPv6 Arbeitsgruppe, Slowenien) Der folgende Text ist ein Vorschlag, der in Ausschreibungen für ICT Equipment aufgenommen werden kann und die Anforderungen für IPv6 definiert: Jegliche ICT Hardware muss IPv4 und IPv6 als Protokoll unterstützen, wobei für beide Protokolle eine in etwa gleiche Leistung vorhanden sein muss. Es sollten weniger als...% Unterschied zwischen den beiden Protokollen bei Input, Output, Durchsatz, Weiterleitung und Verarbeitung vorhanden sein. (Hinweis: Für Hochleistungsgeräte sollte der Unterschied maximal bei 15% liegen, für mittlere Geräte bei maximal 30% und für Endkundenhardware bei maximal 40%) Alle Software, die über IP kommuniziert, muss beide Protokolle beherrschen, ohne dass der Anwender einen Unterschied bemerkt. Anforderungen zur Unterstützung von Standards ICT Hardware kann grob in 4 Gruppen eingeteilt werden: Host: Client oder Server Layer 2 Switch Router oder Layer3 Switch Network Security (Firewall, IDS, IPS,...) Die Anforderungen sind ihrerseits wieder in 2 Kategorien eingeteilt, verpflichtend und optional. Alle Hardware muss die Pflichtanforderungen erfüllen. Die Erfüllung von optionalen Anforderungen kann dem Angebot eines Anbieters Pluspunkte in einer Ausschreibung einbringen, sofern es der Ausschreibende so definiert hat. Alle Verweise auf RFCs sind zum Zeitpunkt der Erstellung dieses Dokumentes aktuell, können sich aber mit der Zeit ändern, wenn die IETF neue Dokumente veröffentlicht, die die genannten Dokumente ablösen. Die jeweils aktuellenrfc Dokumente sind unter http://www.rfc-editor.org/ zu finden. Hardware Jede Hardware, die nicht allen Pflichtanforderungen genügt, wird als ungeeignet gekennzeichnet und scheidet aus dem Auswahlprozess aus.

Anforderungen für Hosts Pflichtanforderungen IPv6 Basic specification [RFC2460] IPv6 Addressing Architecture basic [RFC4291] Default Address Selection [RFC3484] ICMPv6 [RFC4443] DHCPv6 client [RFC3315] SLAAC [RFC4862] Path MTU Discovery [RFC1981] Neighbour Discovery [RFC4861] Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] IPsec-v2 [RFC2401, RFC2406, RFC2402] IKE version 2 (IKEv2) [RFC4306, RFC4718] Sollte Mobile IPv6 gefordert sein, müssen die Geräte den Spezifikationen aus MIPv6 [RFC3775, RFC5555], und Mobile IPv6 Operation With IKEv2 Revised IPsec Architecture [RFC4877] genügen. DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596] DNS message extension mechanism [RFC2671] DNS message size requirements [RFC3226] Optionale Anforderungen Revised ICMPv6 [RFC5095] Extended ICMP for multi-part messages [RFC4884] SEND Secure Neighbour Discovery[RFC3971] SLAAC Privacy Extensions [RFC4941] Stateless DHCPv6 [RFC3736] DS (Traffic class) [RFC2474, RFC3140] Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] Cryptographically Generated Addresses [RFC3972] IPsec-v3 [RFC4301, RFC4303, RFC4302] SNMP protocol [RFC3411] SNMP capabilities [RFC3412, RFC3413, RFC3414] Multicast Listener Discovery version 2 [RFC3810] Packetization Layer Path MTU Discovery [RFC4821] 3

Anforderungen an Layer2 Switches für den Bereich Small Office/Home Office (SOHO) Pflichtanforderungen MLDv2 snooping [RFC4541] Optionale Anforderungen (Management) IPv6 Basic specification [RFC2460] IPv6 Addressing Architecture basic [RFC4291] Default Address Selection [RFC3484] ICMPv6 [RFC4443] SLAAC [RFC4862] SNMP protocol [RFC3411] SNMP capabilities [RFC3412, RFC3413, RFC3414] Anforderungen für Enterprise/ISP Layer 2 Switches Pflichtanforderungen MLDv2 snooping [RFC4541] DHCPv6 snooping [RFC3315] DHCPv6 Pakete müssen verworfen werden, wenn diese zwischen Client /Host Systemen ausgetauscht werden sollen. So wird verhindert, dass ein falscher DHCPv6 Server Informationen ins Netzwerk geben kann. Router Advertisement (RA) filtering [RFC4862, RFC5006] Nur Router dürfen RA schicken. Daher müssen auf Client Ports eines Switches eingehende RA verworfen werden. Dynamic "IPv6 neighbour solicitation/advertisement" inspection [RFC4861] Es muss eine Überprüfung der IPv6 Neighbour Solicitation/Advertisements geben, vergleichbar mit der IPv4 "Dynamic ARP Inspection". Die Tabelle mit den MAC Adressen muss dynamisch aus SLAAC oder DHCPv6 Meldungen generiert werden. Neighbour Unreachability Detection [NUD, RFC4861] filtering NUD Meldungen müssen gefiltert werden können, um gefälschte NUD Meldungen zu verwerfen. Duplicate Address Detection [DAD, RFC4429] snooping and filtering Nur autorisierte Adressen dürfen als IPv6 Source Adresse in DAD Meldungen von einzelnen Ports verwendet werden. Optionale Anforderungen (Management) IPv6 Basic specification [RFC2460] IPv6 Addressing Architecture basic [RFC4291]

Default Address Selection [RFC3484] ICMPv6 [RFC4443] SLAAC [RFC4862] SNMP protocol [RFC3411] SNMP capabilities [RFC3412, RFC3413, RFC3414] IPv6 Routing Header [RFC2460, Next Header value 43] snooping Pakete mit IPv6 Routing Headern (Typ 0) dürfen nicht zwischen Ports von Endhosts und zwischen Endhost und Uplinks erlaubt sein, um Routing Loops zu verhindern. Siehe RFC5095, Deprecation of Type 0 Routing Headers in IPv6. UPnP filtering UPnP Meldungen zwischen Endhosts müssen gefiltert werden. Eventuell kann auf Ethertype 0x86dd gefiltert werden. Wahrscheinlich müssten dann für IPv4 Ethertypes 0x800 und 0x806 freigegeben werden. Anforderungen an Router oder Layer 3 Switches Pflichtanforderungen IPv6 Basic specification [RFC2460] IPv6 Addressing Architecture basic [RFC4291] Default Address Selection [RFC3484] ICMPv6 [RFC4443] SLAAC [RFC4862] MLDv2 snooping [RFC4541] Router-Alert option [RFC2711] Path MTU Discovery [RFC1981] Neighbour Discovery [RFC4861] Classless Inter-domain routing [RFC4632] Sollte ein internes Routing Protokoll (IGP) erforderlich sein, müssen RIPng [RFC2080], OSPF-v3 [RFC5340] oder IS-IS [RFC5308] unterstützt werden. Der Anbieter in der Ausschreibung muss die Wahl treffen, sofern die ausschreibende Partei keine Vorgabe gemacht hat. Sollte OSPF-v3 erforderlich sein, muss "Authentication/Confidentiality for OSPF-v3" [RFC4552] unterstützt werden. Sollte BGP4 erforderlich sein, müssen die RFCs RFC4271, RFC1772, RFC4760, RFC1997, RFC3392 und RFC2545 unterstützt werden. Support for QoS [RFC2474, RFC3140] Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC4891] 5

Generic Packet Tunneling and IPv6 [RFC2473] Wenn 6PE gefordert ist, ist der Standard "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) [RFC4798] einzuhalten. Multicast Listener Discovery version 2 [RFC3810] Wenn Mobile IPv6 erwünscht ist, muss MIPv6 [RFC3775, RFC5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture" [RFC4877] unterstützt werden. Wenn MPLS Funktionalität (z.b. BGP-free core, MPLS TE, MPLS FRR) gefordert ist, muss "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798] unterstützt werden. Sollte Layer-3 VPN Funktionalität erforderlich sein, müssen die PE Router und die Route Reflektoren "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC 4659] unterstützten. Wenn MPLS Traffic Engineering in Kombination mit IS-IS Routing zum Einsatz kommen soll, muss "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] unterstützt werden. Optionale Anforderungen Revised ICMPv6 [RFC5095] DHCPv6 client / server [RFC3315] Extended ICMP for multi-part messages [RFC4884] SEND [RFC3971] SLAAC Privacy Extensions [RFC4941] Stateless DHCPv6 [RFC3736] DHCPv6 PD [RFC3633] Route Refresh for BGP Capabilities-4 [RFC2918] BGP Extended Communities Attribute [RFC4360] (QOS), Assured Forwarding [RFC2597] (QOS) Expedited Forwarding [RFC3246] Generic Routing Encapsulation [RFC2784] Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] Cryptographically Generated Addresses [RFC3972] ProSafe-v3 [RFC4301, RFC4303, RFC4302] IPSec-v2 [RFC2401, RFC2406, RFC2402] IKE version 2 (IKEv2) [RFC4306, RFC4718] SNMP protocol [RFC3411] SNMP Eigenschaften [RFC3412, RFC3413, RFC3414] Mibsam SNMP für IP [RFC4293], Forwarding [RFC4292], IPsec [RFC4807] und DiffServ [RFC3289]

DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596] DNS message extension mechanism [RFC2671] DNS message size Requirements [RFC3226] 127-bit IPv6 Prefixes on Inter-Router Links: http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-01 Packetization Layer Path MTU Discovery [RFC4821] Sollte IS-IS Routing gewünscht sein, sollte "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (ISISs)" [RFC 5120] unterstützt werden. Diese Funktionalität in IS-IS Netzwerken ist sehr wichtig. Anforderungen für Ausrüstung im Bereich Network Security Die Anforderungen sind in drei Bereiche aufgeteilt: Firewall (FW) Intrusion Prevention System (IPS) Application Firewall (APFW) In Klammern am Ende jeder Zeile ist der Bereich angegeben, für den die Pflichtanforderung gilt. Pflichtanforderungen IPv6 Basic specification [RFC2460] (FW, IPS, APFW) IPv6 Addressing Architecture basic [RFC4291] (FW, IPS, APFW) Default Address Selection [RFC3484] (FW, IPS, APFW) ICMPv6 [RFC4443] (FW, IPS, APFW) SLAAC [RFC4862] (FW, IPS) Router-Alert option [RFC2711] (FW, IPS) Path MTU Discovery [RFC1981] (FW, IPS, APWF) Neighbour Discovery [RFC4861] (FW, IPS, APFW) Sollte BGP4 gefordert sein, müssen RFC4271, RFC1772, RFC4760 und RFC2545 unterstützt werden (FW, IPS, APFW) Sollte ein internes Routing Protokoll erforderlich sein, müssen RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] unterstützt werden. Der Anbiter wählt das Protokoll, das zum Einsatz kommen soll. (FW, IPS, APFW) Wenn OSPF-v3 genutzt werden soll, muss "Authentication/Confidentiality for OSPFv3" [RFC4552] unterstützt werden. (FW, IPS, APFW) 7

Support for QoS [RFC2474, RFC3140] (FW APFW) Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] (FW) Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW) Funktionen, die unter IPv4 unterstützt werden, sollten in vergleichbarer Weise auch unter IPv6 zur Verfügung stehen.. Wenn z.b. ein Intrusion Prevention System mit IPv4 sowohl auf Layer 2 als auch auf Layer 3 arbeitet, sollten diese Möglichkeiten auch mit IPv6 vorhanden sein. Wenn eine Firewall als Cluster betrieben werden kann, sollte die Synchronisierung der Sessions zwischen den Clusterpartnern mit IPv4 und IPv6 funktionieren. Optionale Anforderungen Revised ICMPv6 [RFC5095] DHCPv6 client / server [RFC3315] Extended ICMP for Multipart Messages [RFC4884] SEND [RFC3971] SLAAC Privacy Extensions [RFC4941] Stateless DHCPv6 [RFC3736] DHCPv6 PD [RFC3633] BGP Communities Attribute [RFC1997] BGP Capabilities Advertisement WITH-4 [RFC3392] (QOS), Assured Forwarding [RFC2597] (QOS) Expedited Forwarding [RFC3246] Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] Cryptographically Generated Addresses [RFC3972] IPsec-v3 [RFC4301, RFC4303, RFC4302] OSPF-v3 [RFC5340] Authentication / Confidentiality for OSPF-v3 [RFC4552] Generic Packet Tunneling and IPv6 [RFC2473] IPsec-v2 [RFC2401, RFC2406, RFC2402] IKE version 2 (IKEv2) [RFC4306, RFC4718] SNMP protocol [RFC3411] SNMP capabilities [RFC3412, RFC3413, RFC3414] DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596] DNS message extension mechanism [RFC2671] DNS message size requirements [RFC3226] Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC4891] Multicast Listener Discovery version 2 [RFC3810] MLDv2 snooping [RFC4541] (when in L2 or passthrough mode) Packetization Layer Path MTU Discovery [RFC4821]

Anforderungen für IPv6-Unterstützung in Software Alle Software muss über IPv4 und IPv6 in beiden Netzwerken kommunizieren können. Sind in einer Software Parameter für das lokale Netzwerk oder Server enthalten, müssen diese Parameter mit beiden Protokollen konfigurierbar sein. Zwischen IPv4 und IPv6 dürfen die funktionalen Unterschieden nicht groß sein, da der Anwender keine oder allenfalls geringfügige Unterschiede bei der Kommunikation bemerken soll. Anforderungen an den Integrator Hersteller und Wiederverkäufer, die Integrationsleistungen anbieten, müssen mindestens drei (je nach Projektgröße Zahl anpassen) Mitarbeiter haben, die durch Zertifikate des jeweiligen Herstellers als Fachleute für die in der Auschreibung angbotenen Geräte ausgewiesen sind. Diese Zertifikate sollen als Nachweis dienen, dass die Mitarbeiter über Erfahrung und Wissen in den Bereichen IPv6 Protokoll, IPv6 Netzwerkdesign und IPv6 Sicherheit verfügen. Sollte sich während der Installation der Geräte zeigen, dass Erfahrung und Wissen des Integrators nicht ausreichen, um eine erfolgreiche Installation durchzuführen und die Kommunikation über IPv4 und IPv6 sicherzustellen, kann der Auftraggeber vom Vertrag zurücktreten. Der Vertrag zwischen dem Auftraggeber und dem Intregrator definiert Funktionalitäten, Fristen und maximale Ausfallzeiten des Kundennetzwerkes während der Arbeiten. Es ist wünschenswert, dass der Integrator und seine Mitarbeiter neben den Herstellerzertifikaten unabhängige Zertifikate erworben haben, um ein breites Wissen über IPv6 nachzuweisen. Dafür könnte der Auftraggeber im Ausschreibungsverfahren einen Bonus gewähren. Der Auftraggeber sollte sich den guten Wissenstand des Integrators und seiner Mitarbeiter im Vertrag zusichern lassen. 9

Option 2 Der Ausschreibende kann verlangen, dass ICT Geräte innerhalb des IPv6 Ready Programmes nach Phase 1 oder Phase 2 zertifiziert sind. Die Tests für beide Phasen der Zertifizierung können in fünf zugelassenen Laboren absolviert werden: TTA (Korea), BII (China), CHT-TL (Taiwan), IRISA (Frankreich) and UNH-IOL (USA). Diese Tests prüfen die IPv6 Fähigkeiten von Geräten, in Phase 1 mit ca. 150 Tests, in Phase 2 mit ca. 450 Tests. About the IPv6 Ready program : http://www.ipv6ready.org/ About Phase 1 : http://www.ipv6ready.org/?page=phase-1 About Phase 2 : http://www.ipv6ready.org/?page=phase-2 Alle anderen Anforderungen an den System Integrator sind mit den Anforderungen aus Option 1 gleich. Textvorschlag für die Ausschreibung: ICT Ausrüstung, die über IPv4 kommuniziert, muss auch das Protokoll IPv6 beherrschen und mit anderen Geräten über IPv6 arbeiten können. Grundlegende Unterstützung für IPv6 muss durch das Phase 1 Logo und Zertifikat aus dem IPv6 Ready Programm nachgewiesen werden. Für das Phase 2 Logo und Zertifikat wird im Ausschreibungsverfahren ein Bonus gegeben. Option 3 Die dritte Option enthält Elemente aus den beiden oben beschriebenen Optionen. Unter dem IPv6 Ready Programm sind nicht alle Geräte erfasst, die IPv6 vollständig und korrekt unterstützen, daher wäre es nicht wünschenswert, diese Geräte als für IPv6 untauglich aus dem Verfahren auszuschließen. Diese Option schlägt vor, dass Geräte entweder die Logos Phase 1 oder Phase 2 tragen oder den aufgelisteten Standards aus Option 1 genügen. Textvorschlag für die Ausschreibung: ICT Ausrüstung, die über IPv4 kommuniziert, muss auch das Protokoll IPv6 beherrschen und mit anderen Geräten über IPv6 arbeiten können. Grundlegende Unterstützung für IPv6 muss durch das Phase 1 Logo und Zertifikat aus dem IPv6 Ready Programm nachgewiesen werden. Für das Phase 2 Logo und Zertifikat wird im Ausschreibungsverfahren ein Bonus gegeben. Ausrüstung, die nicht im IPv6 Ready Programm zertifiziert worden ist, muss folgende Standards beherrschen: [Liste der Standards aus Option 1]

Danksagung Die Autoren danken allen, die an der Erstellung und der Weiterentwicklung des Dokumentes mitgewirkt haben. Unser Dank geht an Janez Sterle, Urban Kunc, Matjaz Straus, Simeon Lisec, Davor Sostaric und Matjaz Lenassi vom go6 Forum für ihre engagierte Mitarbeit an diesem Dokument. Wir danken insgesamt für die Arbeit, die in der Slowenischen IPv6 Arbeitsgruppe geleistet wurde, besonders für die Anmerkungen und Korrekturen, von Ivan Pepelnjak, Andrej Kobal und Ragnar Us. Wir danken den Vorsitzenden der IPv6 Arbeitsgruppe des RIPE, David Kessens, Shane Kerr and Marco Hogewoning für ihre Unterstützung. Weiterer Dank gilt Patrik Fältström, Torbjörn Eklöv, Randy Bush and Matsuzaki Yoshinobu, Ides Vanneuville, Olaf Maennel, Ole Troan, Teemu Savolainen und allen Freunden der IPv6 Arbeitsgruppe (Joao Damas, S.P.Zeidler, Gert Döring und anderen) für die Zuarbeit, Anmerkungen und Korrekturen. Den Mitarbeitern des RIPE NCC danken wir für die sprachlichen Korrekturen (der englischen Fassung) dieses Dokumentes. Danke an alle, die mitgeholfen haben. Danksagung des Übersetzers Mein Dank gilt Gert Döring, der mich in der Übersetzung unterstützt hat und viele Formulierungen erst lesbar gemacht hat. 11