Eisen voor IPv6 in ICT-apparatuur

Belangrijke opmerking: Dit document betreft een vertaling van het document “Requirements for IPv6 in ICT Equipment” (ripe-554,  http://www.ripe.net/ripe/docs/ripe‐554 ). De vertaling is uitgevoerd door Forum Standaardisatie en is gecontroleerd door Sander Steffann, die ook bijdroeg aan de totstandkoming van het originele Engelse document. Achtergrondinformatie: The Réseaux IP Européens Network Coordination Centre (RIPE NCC) is een onafhankelijke, not-for-profit lidmaatschapsorganisatie ter bevordering van de internetinfrastructuur. RIPE NCC verzorgt als Regional Internet Registry (RIR) de uitgifte van IP-adressen in Europa en het Midden-Oosten. Forum en College Standaardisatie bevorderen interoperabiliteit van de Nederlandse overheid. IPv6 staat sinds 25 november 2010 op de ‘pas toe of leg uit’-lijst van Forum en College Standaardisatie.

Eisen voor IPv6 in ICT-apparatuur Auteurs: • Merike Käo, <[email protected]> • Jan Žorž, <[email protected]> • Sander Steffann, <[email protected]> Document ref.: ripe-554 Datum: juni 2012 Vorige versie: ripe-501

  Inhoudsopgave: •

Inleiding  o

Algemene informatie over het gebruik van dit document 

o

Hoe moeten eisen worden gespecificeerd 

•

Generiek tekstvoorstel voor de aanbesteder 

•

Lijsten met verplichte en optionele ondersteuning van RFC/3GPP technische specificaties voor diverse hard- en software  o

IPsec: verplicht of optioneel 

o

Definities en omschrijvingen van verschillende soorten apparatuur 

o

Lijsten met verplichte RFC/3GPP normen voor verschillende soorten hardware  Eisen voor "host" apparatuur 

o

Eisen voor "Layer 2 switch" apparatuur op consumentenniveau 

o

Eisen voor "Layer 2 switch" apparatuur op enterprise/ISP niveau 

o

Eisen voor "router of Layer 3 switch" apparatuur 

o

Eisen voor "network security equipment” 

o

Eisen voor CPE-apparatuur 

o

Eisen voor mobiele apparaten 

o

Eisen voor load balancers 

•

Eisen voor IPv6 ondersteuning bij software 

•

Vaardigheidseisen voor de systeemintegrator  o

•

 

o

Verklaring van IPv6-bekwaamheid 

Dankwoord 

 

Inleiding  

Voor een soepele en kostenefficiënte invoering van IPv6 in hun netwerken is het belangrijk dat overheden en grote ondernemingen eisen specificeren ten aanzien van de compatibiliteit met IPv6 wanneer zij een offerte voor Informatie en Communicatie Technologie (ICT) apparatuur en voor ondersteuning aanvragen. Dit document is bedoeld om een Best Current Practice (BCP) te verschaffen en betreft zelf geen standaard of beleid.

 

 

Het kan dienen als een sjabloon dat gebruikt kan worden door overheden, grote ondernemingen en alle overige organisaties die IPv6-ondersteuning willen opnemen in hun aanbestedingen of in hun apparatuur-vereisten, en biedt richtlijnen bij het vragen naar de juiste specificaties. Het kan ook als hulpmiddel dienen voor personen of organisaties die interesse hebben in het meedingen naar aanbestedingen van de overheid of van het bedrijfsleven.

 

 

Houd er rekening mee dat de hier vermelde standaarden hun oorsprong in verschillende organen vinden, die onafhankelijk van de RIPE-gemeenschap opereren en dat elk van deze standaarden in de toekomst zou kunnen wijzigen of worden vervangen door een nieuwere versie. Het is ook mogelijk dat u de aanbevelingen aan uw specifieke lokale behoeften zult moeten aanpassen.

 

 

Sommige onderdelen van dit document zijn min of meer gebaseerd op het NIST/USGv6 profiel dat door de Amerikaanse overheid 1 is ontwikkeld: http://www.antd.nist.gov/usgv6/

  De auteurs hebben deze documenten aangepast zodat ze meer universeel toepasbaar zijn. Deze keuze heeft geleid tot een lijst met in acht apparaatcategorieën verdeelde RFC-standaarden die ondersteund moeten worden.

 

Dit document volgt tevens RFC6434, het IPv6 Node Requirements document. Deze RFC betreft het algemene IETF-richtsnoer voor IPv6-onderdelen die bij verschillende type apparaten geïmplementeerd moeten worden.

 

Algemene informatie over het gebruik van dit document Een IPv6 Ready Logo certificaat kan voor ieder apparaat worden vereist. Dit is de gemakkelijkste manier waarop leveranciers kunnen aantonen dat hun apparatuur aan de IPv6 basiseisen voldoet. De aanbesteder dient ook een lijst met verplicht gestelde en optionele RFC’s te verstrekken om leveranciers wier apparatuur nog niet van het IPv6 Ready Logo testcertificaat is voorzien, niet uit te sluiten. Op deze manier kunnen uitschrijvers van openbare aanbestedingen niet beschuldigd worden van voorkeur voor een bepaald type apparatuur of leverancier.  

 

                                                             1

De USGv6 specificaties ondergaan momenteel wijzigingen die naar verwachting begin 2012 voltooid zullen worden. 

 

 

Wanneer een aanbesteder de lijst met vereiste RFC’s specificeert, dan moeten alle verplichte eisen opgesomd worden, met uitzondering van de items die beginnen met “Indien [functionaliteit] vereist is…” Deze items zijn alleen verplicht indien de aanbesteder een bepaalde functionaliteit vereist. Houd er rekening mee dat de aanbesteder dient te beslissen welke functionaliteit verplicht is, niet de leverancier van de apparatuur.    

Bepaalde functies die in dit document in de sectie “optioneel” zijn opgenomen kunnen voor uw specifieke geval en/of organisatie belangrijk zijn. In dergelijke gevallen moet de aanbesteder de eis in hun offerteaanvraag naar de sectie “verplicht” verplaatsen.

  Hoe moeten eisen worden gespecificeerd Zoals hierboven vermeld, omvat het IPv6 Ready Logo programma niet alle toepasselijke apparatuur die IPv6 op correcte wijze ondersteunt; het kan onwenselijk zijn om dergelijke apparatuur bij voorbaat uit te sluiten. Dit document bepleit dat de aanbesteder aangeeft dat geschikte apparatuur hetzij gecertificeerd is onder het IPv6 Ready programma, of voldoet aan de juiste RFC’s zoals in de hierna volgende lijsten vermeld.  

 

Nadere informatie over het IPv6 Ready Logo programma: http://www.ipv6ready.org/ Houd er ook rekening mee dat er een BOUNDv6 project bestaat met als doel een permanente netwerkomgeving van verscheidene leveranciers te creëren waaraan erkende laboratoria verbonden zijn, waar men IPv6 toepassingen en apparaten in betekenisvolle testscenario’s kan uittesten. Aanbesteders worden aangemoedigd om een kijkje te komen nemen en de resultaten van dit project ook te gebruiken.

 

Nadere informatie over BOUNDv6: http://www.boundv6.org/ Belangrijke opmerking voor de aanbesteder: De IPv6 Ready Logo certificering omvat de fundamentele IPv6 eisen en enkele geavanceerde functies, maar niet allemaal. Indien u een geavanceerde functie wenst die niet in de IPv6 Ready Logo certificering is opgenomen, vereis dan een lijst met RFC’s die betrekking hebben op die specifieke behoeften in aanvulling op de IPv6 Logo Certificering. In de hierna volgende lijsten worden de RFC’s die in de IPv6 Ready Logo certificering zijn opgenomen, gemarkeerd met *.

 

 

Generiek tekstvoorstel voor de aanbesteder De volgende tekst dient in elke offerte opgenomen te worden: Alle ICT-hardware die aangeboden wordt in het kader van deze aanbesteding moet zowel het IPv4 als het IPv6 protocol ondersteunen. De prestaties van beide protocollen met betrekking tot de input, output en/of doorvoersnelheid van gegevensstromen, de overdracht en de verwerking van datapakketten (packets) moeten gelijkwaardig zijn. Ondersteuning van IPv6 kan worden gecontroleerd en gecertificeerd aan de hand van het IPv6 Ready Logo certificaat. Alle software die via het IP protocol communiceert dient beide protocolversies (IPv4 en IPv6) te ondersteunen. Het verschil mag voor gebruikers niet merkbaar zijn.   

Apparatuur die niet getoetst is via de IPv6 Ready testprocedures moet aan onderstaande RFC’s voldoen:  

 

[toepasselijke lijst met verplichte en optionele RFC’s die uit onderstaande lijsten zijn geselecteerd]    

Lijsten met verplichte en optionele ondersteuning van RFC/3GPP technische specificaties voor diverse harden software De eisen zijn onderverdeeld in hardware apparatuur en ondersteuning door de dienstverlener (integrator).  

Men moet ervan uitgaan dat alle IPv4-verkeer naar IPv6 zal migreren. Alle eisen die aan de IPv4 verkeerscapaciteiten worden gesteld, zoals wachttijd (latency), bandbreedte en doorvoersnelheid, moeten ook vereist worden voor IPv6-verkeer.

  IPsec: verplicht of optioneel In de oorspronkelijke IPv6 Node Requirements (RFC4294) standaard werd IPsec beschreven als een 'MUST' implementatie om standaardconform te zijn. De geüpdate RFC (RFC6434) veranderde IPsec in een 'SHOULD' implementatie. De reden voor de wijziging wordt in deze nieuwe RFC vermeld.  

 

De RIPE IPv6 Werkgroep heeft uitvoerig gediscussieerd of de IPsec ondersteuning verplicht of optioneel moet worden. De meest uitgesproken kiezers bleken voorstander te zijn van de verplaatsing van IPsec naar de optionele gedeelten, hetgeen in dit document wordt weerspiegeld.

 

 

 

Terwijl het de consensus van de RIPE-gemeenschap was om IPsec in de meeste gevallen optioneel te maken, heeft het IETF gesteld dat IPsec in de laatste versie van de IPv6 Node Requirements norm (RFC6434) als 'SHOULD' moet worden geïmplementeerd. In de context van het IETF betekent een 'SHOULD' dat er gegronde

 

redenen kunnen bestaan om in bijzondere gevallen een bepaald item te negeren, maar dat de volledige implicaties moeten worden begrepen en zorgvuldig afgewogen voordat een afwijkende koers wordt gekozen.  

 

Organisaties die IPsec gebruiken of verwachten dit in de toekomst te gaan doen, moeten bij het opstellen van de aanbestedingsdocumenten het volgende in het gedeelte van verplichte eisen opnemen: •

IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *  

Definities en omschrijvingen van verschillende soorten apparatuur De volgende definities worden gebruikt voor de indeling van verschillende soorten hardware apparatuur. Hoewel sommige hardware een overlappende functionaliteit kan hebben (d.w.z. een Layer 2 switch kan fungeren als een Layer 3 router of een router kan misschien bepaalde firewall-mogelijkheden hebben), wordt er vanuit gegaan dat in geval van overlappende functionaliteit de eisen van ieder specifiek apparaat worden gecombineerd.  

 

Host: Een host is een deelnemer aan een netwerk die datapakketten (packets) verzendt en ontvangt, maar deze niet namens anderen doorstuurt. Switch, of ‘Layer 2 Switch’: Een switch of ‘Layer 2 switch’ is een apparaat dat voornamelijk wordt gebruikt voor het doorsturen van Ethernet frames op basis van hun kenmerken. Het uitwisselen van Ethernet gegevens met andere Ethernet switches is meestal een onderdeel van zijn functie. Router of ‘Layer 3 Switch’: Een router of ‘Layer 3 switch’ is een apparaat dat voornamelijk wordt gebruikt om IP-pakketten door te sturen op basis van hun kenmerken. Het uitwisselen van routergegevens met andere Routers is meestal een onderdeel van zijn functie. Network Security Equipment: Netwerkbeveiligingsapparatuur zijn apparaten waarvan de primaire functie bestaat uit het toestaan, weigeren en/of controleren van verkeer tussen interfaces om mogelijk schadelijke activiteiten te ontdekken of voorkomen. Deze interfaces kunnen ook VPN’s (SSL of IPsec) zijn. Netwerkbeveiligingsapparatuur is ook vaak een Layer 2 switch of een Router/Layer 3 switch. Customer Premise Equipment (CPE): Een CPE-apparaat is een kleine kantoor- of particuliere router die wordt gebruikt om thuisgebruikers en/of kleine kantoren te verbinden in een divers aantal configuraties. Hoewel een CPE meestal een Router is, verschillen de eisen van een Router of Layer 3 switch op Enterprise/ISP niveau. Mobile Device: In de context van dit document is een mobiel apparaat een node die verbinding maakt met een volgens 3GPP gedefinieerd systeem met behulp van 3GPP toegangstechnologie (zoals 2G, 3G of LTE). Voor situaties waarin de netwerk logica

 

 

uitsluitend wordt verzorgd door een dedicated apparaat A dat is aangesloten op een ander apparaat B, zal de specificatie naar apparaat A verwijzen en niet naar apparaat B. Als de protocol logica is verspreid (bijvoorbeeld een computer met een externe Ethernet interface die de TCP checksum offloading verzorgt), wordt het totale systeem bedoeld. Load Balancer: Een load balancer is een netwerkapparaat dat de werklast over meerdere computers, servers of andere bronnen verdeelt om een optimale of geplande capaciteitsbenutting, maximale doorvoersnelheid, minimale reactietijd te bereiken en overbelasting te voorkomen. De volgende referenties zijn voor dit BCP document van belang. Op het moment van publicatie waren de genoemde uitgaven geldig. Alle referenties zijn onder voorbehoud van wijziging; de gebruikers van dit BCP document worden derhalve aangespoord om na te gaan of het mogelijk is om de meest recente uitgave van onderstaande referenties toe te passen.  

 

Lijsten met verplichte RFC/3GPP normen voor verschillende soorten hardware ICT hardware apparatuur is in zeven verschillende functionele groepen verdeeld: • Host: cliënt of server • Layer 2 switch • Router of Layer 3 switch • Network security equipment (firewalls, IDS, IPS...) • CPE • Mobile device • Load balancer  

 

Wij hebben de volgende eisen in twee categorieën verdeeld, “verplicht” en “optioneel”. Apparatuur moet aan de lijst met verplichte standaarden voldoen. Ondersteuning voor de optionele eisen kan de offerte-aanvrager extra punten opleveren, indien als zodanig door de aanbesteder aangegeven.

 

 

Alle hardware die niet aan alle verplichte standaarden voldoet dient door de offertebeoordelaar als ongeschikt te worden aangemerkt.

 

 

De standaarden die deel uitmaken van de IPv6 Ready Logo testprocedures, die doorgaans door erkende laboratoria worden uitgevoerd, zijn met een asterisk * gemarkeerd.

  Eisen voor "host" apparatuur Verplichte ondersteuning: • IPv6 Basic specification [RFC2460] * • IPv6 Addressing Architecture [RFC4291] *  

 

• • • • • • • • • • • • •

Default Address Selection [RFC3484] Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] ICMPv6 [RFC4443] * DHCPv6 client [RFC3315] * IPv6 Stateless Address Autoconfiguration [RFC4862] * Path MTU Discovery [RFC1981] * Neighbor Discovery [RFC4861] * Indien ondersteuning voor tunneling en dual stack vereist is, dient het apparaat Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] te ondersteunen Indien ondersteuning voor Mobile IPv6 vereist is, dient het apparaat “MIPv6” [RFC6275, RFC5555] en “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877] te ondersteunen DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596] DNS message extension mechanism [RFC2671] DNS message size requirements [RFC3226] Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *

 

 

Optionele ondersteuning: • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] • Extended ICMP for multi-part messages [RFC4884] • SeND [RFC3971] • SLAAC Privacy Extensions [RFC4941] • Stateless DHCPv6 [RFC3736] * • DS (Traffic class) [RFC2474, RFC3140] • Cryptographically Generated Addresses [RFC3972] • IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * • SNMP protocol [RFC3411] • SNMP capabilities [RFC3412, RFC3413, RFC3414] • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en DiffServ [RFC3289] • Multicast Listener Discovery version 2 [RFC3810] * • Packetisation Layer Path MTU Discovery [RFC4821] • IPv6 Host-to-Router Load Sharing [RFC4311] • Default Router Preferences and More-Specific Routes [RFC4191]

Eisen voor "Layer 2 switch" apparatuur op consumentenniveau Optionele ondersteuning (management) • MLDv2 snooping [RFC4541] • IPv6 Basic specification [RFC2460] * • IPv6 Addressing Architecture [RFC4291] * • Default Address Selection [RFC3484] • ICMPv6 [RFC4443] * • IPv6 Stateless Address Autoconfiguration [RFC4862] * • SNMP protocol [RFC3411] • SNMP capabilities [RFC3412, RFC3413, RFC3414] • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en DiffServ [RFC3289]  

 

Eisen voor "Layer 2 switch" apparatuur op enterprise/ISP niveau Verplichte ondersteuning: • MLDv2 snooping [RFC4541] • DHCPv6 filtering [RFC3315] • Router Advertisement (RA) filtering [RFC6105] • Dynamic "IPv6 Neighbor solicitation/advertisement" inspection [RFC4861] • Neighbor Unreachability Detection [NUD, RFC4861] filtering • Duplicate Address Detection [DAD, RFC4429] snooping and filtering. 2  

 

Optionele ondersteuning (management): • IPv6 Basic specification [RFC2460] * • IPv6 Addressing Architecture [RFC4291] * • Default Address Selection [RFC3484] • ICMPv6 [RFC4443] * • IPv6 Stateless Address Autoconfiguration [RFC4862] * • SNMP protocol [RFC3411] • SNMP capabilities [RFC3412, RFC3413, RFC3414] • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en DiffServ [RFC3289] • IPv6 Routing Header [RFC2460, Next Header value 43] filtering * • Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * • UPnP filtering

Eisen voor "router of Layer 3 switch" apparatuur Verplichte ondersteuning: • IPv6 Basic specification [RFC2460] * • IPv6 Addressing Architecture [RFC4291] * • Default Address Selection [RFC3484] • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] • ICMPv6 [RFC4443] * • IPv6 Stateless Address Autoconfiguration [RFC4862] * • MLDv2 snooping [RFC4541] • Multicast Listener Discovery version 2 [RFC3810] * • Router-Alert option [RFC2711] • Path MTU Discovery [RFC1981] * • Neighbor Discovery [RFC4861] * • Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * • Indien een dynamic interior gateway protocol (IGP) is vereist, moeten RIPng [RFC2080], OSPF-v3 [RFC5340] of IS-IS [RFC5308] worden ondersteund. De aanbestedende partij dient het verplichte protocol dienovereenkomstig te specificeren. • Indien OSPF-v3 is vereist, moet de apparatuur voldoen aan "Authentication/Confidentiality for OSPF-v3" [RFC4552] • Indien BGP4 protocol is vereist, moet de apparatuur voldoen aan RFC4271, RFC1772, RFC4760, RFC1997, RFC3392 en RFC2545                                                              2

 De IETF Source Address Validation Improvements (SAVI) Werkgroep werkt momenteel aan RFC’s die een kader voor “source address validation” scheppen. Zodra deze RFC’s worden gepubliceerd kunnen de NUD en DAD filterverwijzingen dienovereenkomstig worden gewijzigd. 

 

 

• • • • • • • • •

Support for QoS [RFC2474, RFC3140] Indien ondersteuning voor tunneling en dual stack vereist is, moet het apparaat Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] ondersteunen Indien ondersteuning voor tunneling en dual stack vereist is, moet het apparaat Generic Packet Tunneling and IPv6 [RFC2473] ondersteunen Indien 6PE is vereist, moet de apparatuur "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)” [RFC4798] ondersteunen Indien Mobile IPv6 is vereist, moet de apparatuur MIPv6 [RFC6275, RFC5555] en "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877] ondersteunen Indien het IS-IS routing protocol is vereist, moet de apparatuur "M-ISIS: MultiTopology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC5120] ondersteunen Indien MPLS functionaliteit (bijvoorbeeld BGP-free core, MPLS TE, MPLS FRR) is vereist, moeten de PE-routers en route reflectors "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC4798] ondersteunen Indien Layer 3 VPN functionaliteit is vereist, moeten de PE-routers en route reflectors "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC4659] ondersteunen Indien MPLS Traffic Engineering wordt toegepast in combinatie met IS-IS routing protocol, moet de apparatuur "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC5120] ondersteunen

 

 

 

Optionele ondersteuning: • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] • DHCPv6 client/server/relay [RFC3315] * • Extended ICMP for multi-part messages [RFC4884] • SeND [RFC3971] • SLAAC Privacy Extensions [RFC4941] • Stateless DHCPv6 [RFC3736] * • DHCPv6 PD [RFC3633] * • Route Refresh for BGP-4 Capabilities [RFC2918] • BGP Extended Communities Attribute [RFC4360] • (QOS) Assured Forwarding [RFC2597] • (QOS) Expedited Forwarding [RFC3246] • Generic Routing Encapsulation [RFC2784] • Cryptographically Generated Addresses [RFC3972] • IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * • Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC4891] • SNMP protocol [RFC3411] • SNMP capabilities [RFC3412, RFC3413, RFC3414] • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en 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 [RFC6164] • Packetisation Layer Path MTU Discovery [RFC4821]

 

• •

IPv6 Host-to-Router Load Sharing [RFC4311] Default Router Preferences and More-Specific Routes [RFC4191]

Eisen voor "network security equipment” De apparatuur in deze sectie is in drie subgroepen onderverdeeld: • Firewall (FW) • Intrusion prevention device (IPS) • Application firewall (APFW)  

 

Bij elke verplichte norm worden de van toepassing zijnde subgroepen tussen haakjes aan het einde van de regel vermeld. Verplichte ondersteuning: • IPv6 Basic specification [RFC2460] (FW, IPS, APFW) * • IPv6 Addressing Architecture [RFC4291] (FW, IPS, APFW) • Default Address Selection [RFC3484] (FW, IPS, APFW) • ICMPv6 [RFC4443] (FW, IPS, APFW) * • IPv6 Stateless Address Autoconfiguration [RFC4862] (FW, IPS) * • Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] * • Inspecting IPv6-in-IPv4 protocol-41 traffic, hetgeen nader wordt gespecificeerd in: Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] (IPS) • Router-Alert option [RFC2711] (FW, IPS) • Path MTU Discovery [RFC1981] (FW, IPS, APFW) * • Neighbor Discovery [RFC4861] (FW, IPS, APFW) * • Indien het BGP4 protocol is vereist, moet de apparatuur voldoen aan RFC4271, RFC1772, RFC4760 en RFC2545 (FW, IPS, APFW) • Indien een dynamic internal gateway protocol (IGP) is vereist, moet het verplichte RIPng [RFC2080], OSPF-v3 [RFC5340] of IS-IS [RFC5308] worden ondersteund. De aanbestedende partij dient het verplichte protocol dienovereenkomstig te specificeren. (FW, IPS, APFW) • Indien OSPF-v3 is vereist, moet het apparaat "Authentication/Confidentiality for OSPFv3" [RFC4552] ondersteunen (FW, IPS, APFW) • Support for QoS [RFC2474, RFC3140] (FW, APFW) • Indien tunneling vereist is, moet het apparaat Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] ondersteunen (FW)

 

 

Een Network Security Device (netwerkbeveiligingsapparaat) wordt vaak daar geplaatst waar normaliter een Layer 2 switch of a router/Layer 3 switch zou worden geplaatst. Afhankelijk van de plaatsing zouden de betreffende eisen uit die categorie ook moeten worden opgenomen.

 

 

 

 

Functionaliteit en functies die worden ondersteund via IPv4 moeten vergelijkbaar zijn met de functionaliteit die via IPv6 wordt ondersteund. Als een intrusion prevention system bijvoorbeeld via IPv4 in de Layer 2 en Layer 3 modus kan werken, dan moet het deze functionaliteit ook via IPv6 bieden. Of als een firewall in een cluster draait die de IPv4sessies tussen alle leden van de cluster synchroon kan laten draaien, dan zou dit ook met IPv6-sessies mogelijk moeten zijn.

   

Optionele ondersteuning: • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] • DHCPv6 client/server/relay [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/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * • Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW) • OSPF-v3 [RFC5340] • Authentication/Confidentiality for OSPF-v3 [RFC4552] • Generic Packet Tunneling and IPv6 [RFC2473] • SNMP protocol [RFC3411] • SNMP capabilities [RFC3412, RFC3413, RFC3414] • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en DiffServ [RFC3289] • DNS extensions to support IPv6 [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) * • Packetisation Layer Path MTU Discovery [RFC4821] • IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5739] • IPv6 Host-to-Router Load Sharing [RFC4311] • Default Router Preferences and More-Specific Routes [RFC4191]

 

 

Eisen voor CPE-apparatuur Verplichte ondersteuning: • RFC6204 (Basic Requirements for IPv6 Customer Edge Routers) *  

 

Optionele ondersteuning: • IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * • Indien ondersteuning voor Mobile IPv6 vereist is, moet het apparaat voldoen aan “MIPv6” [RFC6275, RFC5555] en “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877] • Extended ICMP for multi-part messages [RFC4884] • SeND [RFC3971] • SLAAC Privacy Extensions [RFC4941] • DS (Traffic class) [RFC2474, RFC3140] • Cryptographically Generated Addresses [RFC3972]

 

• • • • • • •

• • • •

SNMP protocol [RFC3411] SNMP capabilities [RFC3412, RFC3413, RFC3414] SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en DiffServ [RFC3289] Multicast Listener Discovery version 2 [RFC3810] * Packetisation Layer Path MTU Discovery [RFC4821] IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969] Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC6333]. Indien dit wordt ondersteund dan moet eveneens het Dynamic Host Configuration protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [RFC6334] worden ondersteund The A+P Approach to the IPv4 Address Shortage [RFC6346] IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5739] IPv6 Host-to-Router Load Sharing [RFC4311] Default Router Preferences and More-Specific Routes [RFC4191]

 

 

Eisen voor mobiele apparaten Verplichte ondersteuning: • IPv6 basic specification [RFC2460] * • Neighbor Discovery for IPv6 [RFC4861] * • IPv6 Stateless Address Autoconfiguration [RFC4862] * • IPv6 Addressing Architecture [RFC4291] * • ICMPv6 [RFC4443] * • IPv6 over PPP [RFC2472] • Multicast Listener Discovery version 2 [RFC3810] * • IPv6 Router Alert Option [RFC2711] • DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]  

 

 

 

Optionele ondersteuning: • Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC4941] • Path MTU Discovery for IPv6 [RFC1981] * • Generic Packet Tunneling for IPv6 [RFC2473] • DHCPv6 [RFC3315] * • Stateless DHCPv6 [RFC3736] • DHCPv6 option for SIP servers [RFC3319] • IPv6 Prefix Options for DHCPv6 [RFC3633] • Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pdexclude] • Default Address Selection [RFC3484] • IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * • IKEv2 Mobility and Multihoming Protocol MOBIKE [RFC 4555] • IPv6 Host-to-Router Load Sharing [RFC4311] • Default Router Preferences and More-Specific Routes [RFC4191] Referenties: • 3GPP • Internetworking Between Public Land Mobile Network (PLMN) supporting packet

 

• • • • • • • • • • • • • •

based services and Packet Data Networks (PDN) [3GPP TS 29.061] GPRS Service Description [3GPP TS 23.060] General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access [3GPP TS 23.401] Signaling flows for IP multimedia Call control based on SIP and SDP [3GPP TS 24.228] IP multimedia call control protocol based on SIP and SDP [3GPP TS 24.229] IP Based Multimedia Framework [3GPP TS 22.941] Architectural Requirements [3GPP TS 23.221] Packet domain; Mobile Stations (MS) Supporting Packet Switching Service [3GPP TS 27.060] IPv6 migration guidelines [3GPP TR 23.975] IETF IPv6 for Some Second and Third Generation Cellular Hosts [RFC3316] Recommendations for IPv6 in 3GPP Standards [RFC3314] IPv6 in 3rd Generation Partnership Project (3GPP) [RFC6459]

 

Eisen voor load balancers Een load balancer verdeelt inkomende verzoeken en/of verbindingen van cliënten over meerdere servers. Load balancers zullen verschillende combinaties van verbindingen tussen IPv4 en IPv6 moeten ondersteunen:  

 

• • • • • •

Load balancing IPv6-cliënten naar IPv6-servers (6-to-6) moet worden ondersteund Load balancing IPv6-cliënten naar IPv4-servers (6-to-4) moet worden ondersteund Load balancing IPv4-cliënten naar IPv4-servers (4-to-4) zou ondersteund moeten worden Load balancing IPv4-cliënten naar IPv6-servers (4-to-6) zou ondersteund moeten worden Load balancing van één extern/virtueel IPv4-adres naar een gemengd aantal IPv4en IPv6-servers zou ondersteund moeten worden Load balancing van één extern/virtueel IPv6-adres naar een gemengd aantal IPv4en IPv6-servers zou ondersteund moeten worden

 

 

Als een load balancer Layer 7 load balancing biedt (applicatieniveau / reverse proxy, gedefinieerd als ‘surrogate’ in sectie 2.2 van RFC3040) dan moet de load balancer de Xforwarded-for (of gelijkwaardige) header in HTTP ondersteunen om het bron IP-adres van de cliënt zichtbaar te maken voor de servers.  

 

Verplichte ondersteuning: • IPv6 Basic specification [RFC2460] * • IPv6 Addressing Architecture [RFC4291] * • Default Address Selection [RFC3484] • Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] • ICMPv6 [RFC4443] * • Path MTU Discovery [RFC1981] * • Neighbor Discovery [RFC4861] * • DNS protocol extensions for incorporating IPv6 DNS resource records

 

• • •  

[RFC3596] DNS message extension mechanism [RFC2671] DNS message size requirements [RFC3226] Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *

Optionele ondersteuning: • IPv6 Router Advertisement Options for DNS Configuration [RFC6106] • Extended ICMP for multi-part messages [RFC4884] • SeND [RFC3971] • DS (Traffic class) [RFC2474, RFC3140] • Cryptographically Generated Addresses [RFC3972] • SNMP protocol [RFC3411] • SNMP capabilities [RFC3412, RFC3413, RFC3414] • SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] en DiffServ [RFC3289] • Multicast Listener Discovery version 2 [RFC3810] * • Packetisation Layer Path MTU Discovery [RFC4821] • NAT64/DNS64 [RFC6146, RFC6147] • Indien ondersteuning voor IPsec vereist is, moet het apparaat IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * en Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5685] ondersteunen • Indien ondersteuning voor BGP4 vereist is, moet de apparatuur voldoen aan RFC4271, RFC1772, RFC4760 en RFC2545 • Indien ondersteuning voor een dynamic internal gateway protocol (IGP) vereist is, moet de RIPng [RFC2080], OSPF-v3 [RFC5340] of IS-IS [RFC5308] worden ondersteund. De aanbestedende partij dient het verplichte protocol dienovereenkomstig te specificeren. • Indien OSPF-v3 vereist is, moet het apparaat "Authentication / Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW) ondersteunen. • IPv6 Host-to-Router Load Sharing [RFC4311] (FW) • Default Router Preferences and More-Specific Routes [RFC4191] (FW)

     

Eisen voor IPv6 ondersteuning bij software Alle software moet IPv4 en IPv6 ondersteunen en in staat zijn om te kunnen communiceren via IPv4-only, via IPv6-only en via dual-stack netwerken. Als de software netwerkparameters in haar lokale of remote server-instellingen bevat, dan moet de software ook de configuratie van IPv6-parameters ondersteunen.  

 

 

 

   

Alle functies die via IPv4 worden aangeboden moeten ook via IPv6 beschikbaar zijn. De gebruiker mag geen merkbaar verschil ervaren wanneer de software via IPv4 of IPv6 communiceert, tenzij dit een expliciet voordeel voor de gebruiker oplevert. Het wordt ten zeerste afgeraden om vaste adressen in de softwarecode op te nemen, zoals beschreven in “Default Address Selection for Internet Protocol version 6” [RFC3484].

 

Vaardigheidseisen voor de systeemintegrator Leveranciers en wederverkopers die systeemintegratiediensten aanbieden moeten ten minste over drie medewerkers beschikken die in het bezit zijn van geldige bekwaamheidscertificaten van de fabrikanten voor de apparatuur die als onderdeel van de offerte wordt verkocht. Deze medewerkers dienen ook over algemene kennis van het IPv6-protocol, IPv6-netwerkplanning en IPv6-beveiliging te beschikken (zoals mede bepaald door de certificering van deze vaardigheden). Als tijdens de installatie en integratie van de apparatuur mocht blijken dat de kennis, vaardigheid en ervaring van de integrator onvoldoende is om de apparatuur met succes te installeren en configureren om een normale IPv4- en IPv6-communicatie met het netwerk tot stand te brengen, zal de overeenkomst worden ontbonden en komen te vervallen.  

 

De definitie van goede integratie, timing en mate van verstoring van het netwerk tijdens de montage is een kwestie van afspraak tussen de cliënt en de systeemintegrator.

 

 

Tevens wordt aanbevolen dat een systeemintegrator en diens medewerkers een brede kennis van IPv6 en generieke IPv6-certificaten hebben die niet specifiek door de fabrikanten van de apparatuur worden aangeboden. Deze certificaten kunnen worden verkregen bij onafhankelijke onderwijsinstellingen. Voor dergelijke kennis kan bij de aanbesteding extra punten worden toegekend.

 

 

Alle bieders in de aanbestedingsprocedure dienen een verklaring te ondertekenen waarin staat dat de onderneming en haar medewerkers een technische opleiding hebben genoten voor het ontwerp, de bouw en integratie van ICT apparatuur in IPv4- en IPv6-netwerken. Een voorbeeld van een dergelijke verklaring wordt hieronder weergegeven.

 

  Verklaring van IPv6-bekwaamheid Aanbesteders moeten van de leverancier van de apparatuur of de integrator een technische verklaring voor bekwaamheid met IPv6 eisen. IPv6-kennis en -ervaring is noodzakelijk om een goede installatie en integratie van IPv6 in de ICT-omgeving te verzekeren.  

 

De verklaring moet stellen dat de leverancier van de apparatuur of de systeemintegrator, met inachtneming van strafrechtelijke en civiele aansprakelijkheid, verklaart:

 

 

Dat zij voldoende werknemers heeft om de aangeboden diensten uit te voeren; ● Dat deze werknemers professioneel zijn opgeleid voor hun werk d.w.z. het ontwerp, de bouw en integratie van ICT-apparatuur in zowel IPv4- als IPv6netwerken en -omgevingen; ● Dat de kwaliteit van de aangeboden diensten voldoet aan de eisen die in het ●

 

 

aanbestedingsdocument zijn vastgelegd, en dat deze eisen van toepassing zijn op zowel IPv4 als IPv6.  

 

 

Houd er rekening mee dat dergelijke verklaringen kunnen verschillen afhankelijk van de lokale wetgeving. Daarom dienen vertalers en aanbesteders juridisch advies te krijgen over de exacte formulering van deze eisen.

 

Dankwoord De eerste versie van dit document werd verzorgd door de Go6 Expert Council en de Sloveense IPv6 werkgroep.

 

 

De auteurs willen iedereen bedanken die heeft meegeholpen aan de totstandkoming en wijziging van de vorige versie van dit document. Allereerst bedanken wij Janez Sterle, Urban Kunc, Matjaz Straus, Simeon Lisec, Davor Sostaric en Matjaz Lenassi van de Go6 Expert Council voor hun enthousiaste beheer van dit document. Wij spreken onze waardering uit voor het werk van de Sloveense IPv6 werkgroep ten aanzien van hun toetsing en nuttige inbreng. Bijzondere waardering gaat uit naar Ivan Pepelnjak, Andrej Kobal en Ragnar Us voor hun inzet en werk aan dit document. Dank ook aan de medevoorzitters van de RIPE IPv6 Werkgroep, David Kessens, Shane Kerr en Marco Hogewoning voor hun steun en aanmoediging. Wij zouden ook graag Patrik Fältström, Torbjörn Eklöv, Randy Bush, Matsuzaki Yoshinobu, Ides Vanneuville, Olaf Maennel, Ole Trøan, Teemu Savolainen en de mensen van de RIPE IPv6 Werkgroep (waaronder Joao Damas, S.P. Zeidler, Gert Doering) willen bedanken voor hun inbreng, opmerkingen en herziening van dit document. Niet in de laatste plaats willen wij graag Chris Buckridge en het Communicatieteam van RIPE NCC bedanken voor het corrigeren van onze grammatica en de formulering van dit document. En verder iedereen die heeft bijgedragen aan dit stuk. De auteurs van dit document willen de RIPE IPv6 Werkgroep en haar voorzitters bedanken voor alle steun en aanmoediging om een volgende versie van dit document te ontwikkelen. Speciale dank gaat uit naar Ole Trøan, de redacteur van RFC6204 voor zijn hulp bij het CPE onderdeel en suggesties voor andere wijzigingen in het document. Onze dank aan Marco Hogewoning, Ivan Pepelnjak en S.P. Zeidler voor hun grote inbreng van ideeën om de opbouw en inhoud van dit document te verbeteren, Timothy Winters en Erica Johnson (beiden van de IPv6 Ready Logo commissie, UNH) voor hun hulp bij de markering van de RFC’s die zij testen en constructieve voorstellen. Ook dank aan Yannis Nikolopoulos en Frits Nolet. Speciale dank gaat uit naar Jouni Korhonen, Jari Arkko, Eric Vyncke, David Freedman, Tero Kivinen en Michael Richardson voor enkele zeer nuttige opmerkingen en suggesties die dit document veel beter hebben gemaakt.

 

 

Suggesties voor de verbetering van dit document en andere opmerkingen kunt u sturen naar de mailinglist van de RIPE IPv6 Werkgroep .