Voir la source de Public:ExigencesAppelsOffresIPv6

De Wiki G6

Vous ne pouvez pas modifier cette page, pour les raisons suivantes :
L’action que vous essayez de réaliser n’est permise qu’aux utilisateurs d’un des groupes : Utilisateurs, Administrateurs.
L’action que vous essayez de réaliser n’est permise qu’aux utilisateurs du groupe : Utilisateurs.
Vous pouvez voir et copier le contenu de cette page.
= Préambule =

Le présent document est une traduction et adaptation au contexte français, de la politique technique [http://www.ripe.net/docs/ripe-501.html "RIPE-501"] élaborée par la [http://www.ripe.net/ripe/  communauté RIPE] : [http://www.ripe.net/docs/ripe-501.html  "Requirements For IPv6 in ICT Equipment"].

== Attention : == 
Le document RIPE-501 a été mis à jour et rendu obsolète par le nouveau document RIPE-554 (http://www.ripe.net/ripe/docs/current-ripe-documents/ripe-554). La traduction en français de ce dernier n'est pas disponible pour l'instant.*

= Introduction =


Gouvernements, entreprises publiques et privées font des appels d'offres pour des solutions matérielles et logicielles afin de maintenir en bon fonctionnement leurs réseaux informatiques et de télécommunication et aussi de les mettre à niveau. L'arrivée d'IPv6 étant une réalité, en vue de son intégration fluide et efficace, il est important que ces acteurs spécifient les exigences en matière de compatibilité IPv6 dans leur cahier des charges.

Ce document vise à fournir un modèle de bonnes pratiques que les gouvernements et entreprises peuvent utiliser lors de l'élaboration des documents d'appel d'offres. Inversement, il peut également servir de guide aux fournisseurs de solutions réseaux souhaitant soumettre un dossier de candidature à ces appels d'offres.

Il est possible de formuler des exigences en termes de compatibilité
IPv6 de plusieurs façons. Ce document présente les trois options
suivantes :

* "Option 1" : inspirée du [http://www.antd.nist.gov/usgv6/ profil NIST/USGv6 élaboré par le gouvernement des États-Unis]. Le conseil des experts de Go6 et le groupe de travail IPv6 slovène ont modifié ces documents pour les rendre plus largement applicables. La nouvelle proposition comprend une liste de normes (RFC) qui doivent être respectées, répartie sur quatre catégories de dispositifs.
* "Option 2" : s'appuie sur la conformité au exigences du [http://www.ipv6ready.org/  programme "IPv6 Ready"], tel que spécifié par l'[http://www.ipv6forum.org/ IPv6 Forum]. Ce programme se déroule en deux phases : 
** Phase 1 : comporte le test et la certification des protocoles de base ("core protocols") ;
** Phase 2 : couvre le test et la certification des fonctionnalités avancées d'IPv6.
* Option 3 : une combinaison des deux premières options.

= Option 1 =

Les exigences concernent les équipements ainsi que les compétences des
intégrateurs (issues du groupe de travail IPv6 de Go6).

Ce qui suit est une proposition de texte à inclure dans les appels
d'offres publics pour l'acquisition d'équipements TIC, texte qui
précise les exigences en matière de compatibilité et de prise en
charge fonctionnelle d'IPv6 :

<i>
Tout matériel TIC doit être compatible avec les protocoles IPv4 et
IPv6. Des performances similaires doivent être fournies pour les deux
protocoles. Il ne devrait pas y avoir plus de ... % de différence de
performance entre les deux protocoles en entrée, sortie et/ou de débit
de données, de transmission et de traitement des paquets.

(Notes pour les auteurs d'appels d'offres : pour des équipements haut
de gamme (typiquement pour le coeur du réseau), il est recommandé
d'indiquer une différence maximum de 15%. Pour des équipements à usage
dans l'entreprise, il est recommandé que la différence ne dépasse pas
30%. Enfin pour des équipements de grande consommation la différence
ne devrait pas dépasser 40%.
</i>

Tout logiciel qui communique via le protocole IP doit être compatible
avec les deux versions du protocole (IPv4 et IPv6). La différence ne
doit pas être visible pour les utilisateurs.

== Exigences pour le respect des normes ==

Les équipements matériels pour les TIC peuvent être classés sous
quatre groupes :

* Hôte : client ou serveur
* Commutateur de niveau 2
* Routeur ou commutateur de niveau 3
* Équipement assurant la sécurité réseau (pare-feu, IDS, IPS...)

Les exigences suivantes sont réparties en deux catégories,
«obligatoire» et «optionnelle». L'équipement doit répondre à la liste
d'exigences obligatoires des normes. Répondre aux critères
optionnels est un plus appréciable pouvant faire gagner
des points au soumissionnaire, si c'est précisé par l'auteur de l'appel
d'offres.

Merci de noter que les RFC référencés ci-dessous sont susceptibles
d'être mis à jour, voire remplacés par d'autres [http://fr.wikipedia.org/wiki/RFC RFC] dans le cadre de l'évolution
des standards de l'Internet au sein de [http://www.ietf.org/ l'IETF]. Pour toutes les mises à jour, merci de se référer à http://www.rfc-editor.org/

== Matériel ==

Tout matériel qui n'est pas conforme à toutes les normes obligatoires
est marqué comme inapproprié.

=== Exigences pour les équipements du type "hôte" ===

==== Compatibilité obligatoire ====

* IPv6 Basic specification [RFC 2460]
* IPv6 Addressing Architecture basic [RFC 4291]
* Default Address Selection [RFC 3484]
* ICMPv6 [RFC 4443]
* DHCPv6 client [RFC 3315]
* SLAAC [RFC 4862]
* Path MTU Discovery [RFC 1981]
* Neighbour Discovery [RFC 4861]
* Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213]
* IPsec-v2 [RFC2401], [RFC 2406], [RFC  2402]
* IKE version 2 (IKEv2) [RFC 4306], [RFC 4718] 
* If support for mobile IPv6 is required, the device needs to comply to "MIPv6" [RFC 3775], [RFC 5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture" [RFC 4877]
* DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
* DNS message extension mechanism [RFC 2671]
* DNS message size requirements [RFC 3226]

==== Compatibilité optionnelle ====

* Revised ICMPv6 [RFC 5095]
* Extended ICMP for multi-part messages [RFC 4884]
* SEND [RFC 3971]
* SLAAC Privacy Extensions [RFC 4941]
* Stateless DHCPv6 [RFC 3736]
* DS (Traffic class) [RFC 2474, RFC 3140]
* Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
* Cryptographically Generated Addresses [RFC 3972]
* IPsec-v3 [RFC 4301], [RFC 4303], [RFC 4302]
* SNMP protocol [RFC 3411]
* SNMP capabilities [RFC 3412], [RFC 3413], [RFC 3414]
* Multicast Listener Discovery version 2 [RFC 3810]
* Packetization Layer Path MTU Discovery [RFC 4821]

=== Exigences pour les "commutateurs de niveau 2" de grande consommation  ===

==== Compatibilité obligatoire ====

* MLDv2 snooping [RFC 4541]

==== Compatibilité optionnelle (management) ==== 

* IPv6 Basic specification [RFC 2460]
* IPv6 Addressing Architecture basic [RFC 4291]
* Default Address Selection [RFC 3484]
* ICMPv6 [RFC 4443]
* SLAAC [RFC 4862]
* SNMP protocol [RFC 3411]
* SNMP capabilities [RFC 3412], [RFC 3413], [RFC 3414]

=== Exigences pour les "commutateurs de niveau 2" pour entreprise/FAI  ===

==== Compatibilité obligatoire ====

* MLDv2 snooping [RFC 4541]
* DHCPv6 snooping [RFC 3315] DHCPv6 messages must be blocked between subscribers and the network so that false DHCPv6 servers cannot distribute addresses.
* Router Advertisement (RA) filtering [RFC 4862], [RFC 5006]. RA filtering must be used in the network to block unauthorised RA messages.
* Dynamic "IPv6 neighbour solicitation/advertisement" inspection [RFC 4862]. There must be an IPv6 neighbour solicitation/advertisement inspection, as in IPv4 "Dynamic ARP Inspection". The table with MAC-address and link-local and other assigned IPv6-addresses must be dynamically created by SLAAC or DHCPv6 messages.
* Neighbour Unreachability Detection (NUD), [RFC 4861] filtering. There must be a NUD filtering function to ensure that false NUD messages cannot be sent.
* Duplicate Address Detection (DAD), [RFC 4429] snooping and filtering. Only authorised addresses may be allowed as source IPv6 addresses in DAD messages from each port.

==== Compatibilité optionnelle (management) ==== 

* Pv6 Basic specification [RFC 2460]
* IPv6 Addressing Architecture basic [RFC 4291]
* Default Address Selection [RFC 3484]
* ICMPv6 [RFC 4443]
* SLAAC [RFC 4862]
* SNMP protocol [RFC 3411]
* SNMP capabilities [RFC3412], [RFC 3413], [RFC 3414]
* IPv6 Routing Header ([RFC 2460], Next Header value 43) snooping
* IPv6 Routing Header messages must not be allowed between subscriber ports and subscriber and uplink to prevent routing loops (See also [RFC 5095], Deprecation of Type 0 Routing Headers in IPv6)
* UPnP filtering
* UPnP messages must always be blocked between customer ports. There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0×800 and 0×806 for IPv4.

=== Exigences pour les "routeurs ou commutateurs de niveau 3" ===

==== Compatibilité obligatoire ====

* IPv6 Basic specification [RFC 2460]
* IPv6 Addressing Architecture basic [RFC 4291]
* Default Address Selection [RFC 3484]
* ICMPv6 [RFC 4443]
* SLAAC [RFC 4862]
* MLDv2 snooping [RFC 4541]
* Router-Alert option [RFC 2711]
* Path MTU Discovery [RFC 1981]
* Neighbour Discovery [RFC 4861]
* Classless Inter-domain routing [RFC 4632]
* If dynamic internal guidance protocol (IGP) is requested, then RIPng [RFC 2080], OSPF-v3 [RFC 5340] or IS-IS [RFC 5308] must be supported. The contracting authority shall specify the required protocol.
* If OSPF-v3 is requested, the equipment must comply with "Authentication/Confidentiality for OSPF-v3" [RFC 4552]
* If BGP4 protocol is requested, the equipment must comply with [RFC 4271], [RFC 1772], [RFC 4760], [RFC 1997], [RFC 3392] and [RFC 2545]
* Support for QoS [RFC 2474], [RFC 3140] 
* Support for QoS [RFC 2474], [RFC 3140]
* Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213]
* Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC 4891]
* Generic Packet Tunneling and IPv6 [RFC 2473] : If 6PE is requested, the equipment must comply with "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798]
* Multicast Listener Discovery version 2 [RFC 3810]
* If mobile IPv6 is requested, the equipment must comply with MIPv6 [RFC 3775], [RFC 5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture" [RFC 4877]
* If MPLS functionality (for example, BGP-free core, MPLS TE, MPLS FRR) is requested, the PE-routers and route reflectors must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798]
* If layer-3 VPN functionality is requested, the PE-routers and route reflectors must support "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC 4659]
* If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment must support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]

==== Compatibilité optionnelle ====

* Revised ICMPv6 [RFC 5095]
* DHCPv6 client / server [RFC 3315]
* Extended ICMP for multi-part messages [RFC 4884]
* SEND [RFC 3971]
* SLAAC Privacy Extensions [RFC 4941]
* Stateless DHCPv6 [RFC 3736]
* DHCPv6 PD [RFC 3633]
* Route Refresh for BGP Capabilities-4 [RFC 2918]
* BGP Extended Communities Attribute [RFC 4360]
* (QOS), Assured Forwarding [RFC 2597]
* (QOS) Expedited Forwarding [RFC 3246]
* Generic Routing Encapsulation [RFC 2784]
* Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
* Cryptographically Generated Addresses [RFC 3972]
* ProSafe-v3 [RFC 4301], [RFC 4303], [RFC 4302]
* IPSec-v2 [RFC 2401], [RFC 2406], [RFC 2402]
* IKE version 2 (IKEv2) [RFC 4306], [RFC 4718]
* SNMP protocol [RFC 3411]
* SNMP capabilities [RFC 3412], [RFC 3413], [RFC 3414]
* Mibsam SNMP for IP [RFC 4293] Forwarding [RFC 4292], IPsec [RFC 4807] and DiffServ [RFC 3289]
* DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
* DNS message extension mechanism [RFC 2671]
* DNS message size Requirements [RFC 3226]
* 127-bit IPv6 Prefixes on Inter-Router Links: http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-01
* Packetization Layer Path MTU Discovery [RFC 4821]
* When IS-IS routing protocol is requested, the equipment should support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] (this support is highly recommended)

=== Exigences pour les équipements de "sécurité réseau" ===

Les équipements dans cette section se déclinent en trois sous-groupes :

* Pare-feu (FW)
* Dispositif de prévention d'intrusion (IPS)
* Pare-feu applicatif (APFW)

Pour chaque norme obligatoire, les sous-groupes applicables sont
précisés entre parenthèses à la fin de la ligne.

==== Compatibilité obligatoire ====

* IPv6 Basic specification [RFC 2460] (FW, IPS, APFW)
* IPv6 Addressing Architecture basic [RFC 4291] (FW, IPS, APFW)
* Default Address Selection [RFC 3484] (FW, IPS, APFW)
* ICMPv6 [RFC 4443] (FW, IPS, APFW)
* SLAAC [RFC 4862] (FW, IPS)
* Router-Alert option [RFC 2711] (FW, IPS)
* Path MTU Discovery [RFC 1981] (FW, IPS, APWF)
* Neighbour Discovery [RFC 4861] (FW, IPS, APFW)
* If the request is for the BGP4 protocol, the equipment must comply with [RFC 4271], [RFC 1772], [RFC 4760] and [RFC 2545] (FW, IPS, APFW)
* If the request is for a dynamic internal guidance protocol (IGP), then the required RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC 5308]. The contracting authority shall specify the required protocol. (FW, IPS, APFW)
* If the requested OSPF-v3, the device must support   "Authentication/Confidentiality for OSPFv3" [RFC 4552] (FW, IPS, APFW)
* Support for QoS [RFC 2474], [RFC 3140] (FW APFW)
* Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213] (FW)
* Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC 4891] (FW)


Les fonctionnalités qui sont rendues sur IPv4 doivent être comparables
avec celles rendues sur IPv6. Il s'agit de parité fonctionnelle
IPv4-IPv6. Par exemple, si un système de prévention d'intrusion (IPS)
peut fonctionner sur IPv4 en mode niveau 2 et mode niveau 3, alors il
devrait aussi offrir cette fonctionnalité sur IPv6. Ou encore, si un
pare-feu est opérationnel dans un cluster dans lequel il peut synchroniser des sessions IPv4
entre tous les membres du cluster, alors cela doit être possible avec
les sessions IPv6.

==== Compatibilité optionnelle ====

* Revised ICMPv6 [RFC 5095]
* DHCPv6 client / server [RFC 3315]
* Extended ICMP for Multipart Messages [RFC 4884]
* SEND [RFC 3971]
* SLAAC Privacy Extensions [RFC 4941]
* Stateless DHCPv6 [RFC 3736]
* DHCPv6 PD [RFC 3633]
* BGP Communities Attribute [RFC 1997]
* BGP Capabilities Advertisement WITH-4 [RFC 3392]
* (QOS), Assured Forwarding [RFC 2597]
* (QOS) Expedited Forwarding [RFC 3246]
* Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]
* Cryptographically Generated Addresses [RFC 3972]
* IPsec-v3 [RFC 4301], [RFC 4303], [RFC 4302]
* OSPF-v3 [RFC 5340]
* Authentication / Confidentiality for OSPF-v3 [RFC 4552]
* Generic Packet Tunneling and IPv6 [RFC 2473]
* IPsec-v2 [RFC 2401], [RFC 2406], [RFC 2402]
* IKE version 2 (IKEv2) [RFC 4306], [RFC 4718]
* SNMP protocol [RFC 3411]
* SNMP capabilities [RFC 3412], [RFC 3413], [RFC 3414]
* DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]
* DNS message extension mechanism [RFC 2671]
* DNS message size requirements [RFC 3226]
* Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC 4891]
* Multicast Listener Discovery version 2 [RFC 3810]
* MLDv2 snooping [RFC 4541] (when in L2 or passthrough mode)
* Packetization Layer Path MTU Discovery [RFC 4821]

== Exigences pour la compatibilité IPv6 des les logiciels ==

Tous les logiciels doivent être compatibles IPv4 et IPv6 et être en
mesure de communiquer sur les deux types de réseaux. Si un logiciel
inclut des paramètres IPv4 dans sa configuration locale ou de serveur
distant, il devrait aussi offrir la même possibilité en IPv6.

La différence fonctionnelle ne doit pas être significative entre IPv4
et IPv6. L'utilisateur ne devrait percevoir/rencontrer aucune différence
significative lorsque son logiciel communique sur IPv4 ou IPv6.

== Compétences requises chez les intégrateurs de systèmes ==

Les équipementiers et revendeurs de matériel qui offrent des services
d'intégration de systèmes, doivent avoir au moins trois employés
disposant de certificats valides attestant de leurs compétences,
délivrés par par le fabricant de l'équipement vendu dans le cadre de
la réponse à l'appel d'offres. Ces certificats doivent indiquer une
connaissance générale du protocole IPv6, la planification des réseaux
IPv6 et la sécurité IPv6. S'il devient évident au cours de
l'installation d'équipement et de l'intégration que la connaissance de
l'intégrateur, la compétence et l'expérience ne suffisent pas pour
installer et configurer le matériel en vue d'établir une communication
IPv4 et IPv6 normale avec le réseau, l'accord doit être annulé et
deviendra nul et non avenu.

La définition de l'intégration correcte, la maîtrise du temps et le
degré de perturbation du réseau lors de l'opération d'intégration doit
faire l'objet d'un accord entre le client et l'intégrateur de
systèmes.

Il est également recommandé qu'un intégrateur de systèmes et ses
employés aient une vaste connaissance d'IPv6 et des certificats
génériques IPv6 autres que ceux spécifiquement délivrés par les
fabricants d'équipement. Ces certificats peuvent être obtenus auprès
de fournisseurs formation IPv6 indépendants. Une telle connaissance
peut rapporter des points supplémentaires au soumissionnaire dans le
processus d'appel d'offres.

Tous les soumissionnaires dans le processus d'appel d'offres doivent
signer le formulaire ci-dessous, qui indique que l'entreprise et ses
employés ont bénéficié de formations techniques à la conception, la
construction et l'intégration d'équipements dans des réseaux IPv4 et
IPv6.

== DÉCLARATION == 

Déclaration de compétence technique pour la planification, la
construction et l'intégration d'équipements de TIC dans les réseaux et
environnements IPv4 et IPv6.

Société : ________________________________________

Adresse : ________________________________________ 

déclare, en vertu de la responsabilité pénale et matérielle :

* Que nous avons un nombre suffisant de personnes employées pour délivrer les services prévus ;
* Que les employés sont formés professionnellement pour leur travail - la conception, la construction et l'intégration des équipements de TIC dans des réseaux et environnements IPv4 et IPv6 ;
* Que la qualité des services fournis répond aux exigences énoncées dans les documents d'appel d'offres.

Lieu ____________________

Date ____________________ 

Cachet et signature de l'Intégrateur de Systèmes

= Option 2 =

L'auteur d'appel d'offres peut exiger des équipements de TIC certifiés
en vertu du programme "IPv6 Ready" «Phase 1» ou «Phase 2». Les tests
pour les deux phases de la certification peuvent être faits dans cinq
laboratoires accrédités dans le monde : TTA (Corée), BII (Chine),
CHT-TL (Taiwan), IRISA (France) et UNH-IOL (États-Unis). Ces tests
déterminent la conformité aux protocoles IPv6 de base (phase 1, environ 150
tests) et les fonctionnalités IPv6 avancées (phase 2, plus de 450
tests).

* [[ http://www.ipv6ready.org/ | À propos de l'IPv6 Ready Program ]]
* [[ http://ipv6ready.org/?page=phase-1-about | À propos de la phase 1 ]]
* [[ http://ipv6ready.org/?page=phase-2-about | À propos de la phase 2 ]]


Toutes autres exigences sur l'intégrateur de systèmes restent les
mêmes que dans la première option.

== Texte proposé pour les auteurs d'appels d'offres ==

<i> Les équipements informatiques qui prennent en charge et
communiquent via le protocole IPv4 doivent également prendre en charge
le protocole IPv6 et être capables de communiquer avec d'autres
appareils via IPv6. La compatibilité IPv6 de base doit être vérifiée
et certifiée par le programme "IPv6 Ready" avec un logo "phase 1". Un
logo "phase 2" rapportera des points supplémentaires (+10%) dans la
procédure d'évaluation des offres.
</i>

= Option 3 =

La troisième option est une combinaison des deux options
précédentes. Le programme "IPv6 Ready" ne couvre pas tous les
équipements qui prennent en charge IPv6 correctement. Par conséquent,
déclarer inéligible un équipement non couvert par ce programme peut ne
pas être souhaitable. 

Cette option suggère à l'auteur de l'appel d'offres de préciser que les équipements
éligibles peuvent être soit certifiés "phase 1" ou 2 dans le cadre du
programme "IPv6 Ready", soit être conformes aux normes RFC appropriées
énumérées sous l'Option 1 ci-dessus.

== Texte proposé pour les auteurs d'appels d'offres ==

<i> Les équipements informatiques qui prennent en charge et
communiquent via le protocole IPv4 doivent également prendre en charge
le protocole IPv6 et être capables de communiquer avec d'autres
appareils via IPv6. La compatibilité IPv6 de base doit être vérifiée
et certifiée par le programme "IPv6 Ready" avec un logo "phase 1". Un
logo "phase 2" rapportera des points supplémentaires (+10%) dans la
procédure d'évaluation des offres.

Les équipements qui n'ont fait l'objet de tests du programme "IPv6
Ready" doivent se conformer aux RFC énumérés ci-dessous :

[Liste appropriée de RFC obligatoires ou optionnels issue de l'option 1]
</i>
Revenir à la page Public:ExigencesAppelsOffresIPv6.
Récupérée de « http://wiki.g6.asso.fr/index.php?title=Public:ExigencesAppelsOffresIPv6 »
Association G6

Voir la source de Public:ExigencesAppelsOffresIPv6

De Wiki G6

Affichages

Outils personnels

Rechercher

Outils
