1. Présentation générale et guide d'usage.

1.1. Objet du document.

Cette directive définit les règles applicables au sein du ministère de la défense pour la prise en compte du protocole internet protocol version 6 (IPv6) dans les réseaux, infrastructures et applications de défense, elle définit également la stratégie de transition vers ce protocole. Elle s\'inscrit dans les missions de la direction générale des systèmes d\'information et de communication (DGSIC), aux termes du décret n° 2006-497 du 2 mai 2006 portant création de la direction générale des systèmes d\'information et de communication et fixant l\'organisation des systèmes d\'information et de communication du ministère de la défense.

1.2. Niveaux de préconisation.

Les règles présentées dans ce document ont différents niveaux de préconisation et sont conformes au référentiel général d\'intéropérabilité (RGI) et à la request for comment (RFC) 2119 :

• obligatoire : ce niveau de préconisation signifie que la règle édictée indique une exigence absolue de la directive ;

•  recommandé : ce niveau de préconisation signifie qu\'il peut exister des raisons valables, dans des circonstances particulières, pour ignorer la règle édictée, mais les conséquences doivent être comprises et pesées soigneusement avant de choisir une voie différente ;

• déconseillé : ce niveau de préconisation signifie que la règle édictée indique une prohibition qu\'il est toutefois possible, dans des circonstances particulières, de ne pas suivre, mais les conséquences doivent être comprises et le cas soigneusement pesé ;

• interdit : ce niveau de préconisation signifie que la règle édictée indique une prohibition absolue de la directive.

1.3. Gestion du document.

Ce document est maintenu et mis à jour par le sous-comité architecture et services du comité directeur des intranets. Les modifications sont soumises pour approbation au directeur général des systèmes d\'information et de communication.

Ce document est disponible sur le site DGSIC.

1.4. Modalités d'application.

La présente directive s\'applique à l\'ensemble des intranets utilisés par le ministère de la défense. Elle concerne les aspects techniques et organisationnels relatifs aux équipements matériels de réseaux et ordinateurs, aux logiciels, aux éléments de sécurité, et aux applications.

Ces règles définissent la cible et sont applicables à tout nouveau projet ou toute évolution majeure concernant les réseaux internet protocol (IP) du ministère de la défense.

Les directions et services transposent les exigences de la présente directive dans les cahiers des charges des marchés publics.

1.5. Gestion des dérogations pour les projets.

Les dérogations sont présentées par un expert de haut niveau ou un directeur de projet au sous-comité architecture et services (SC2) qui statue sur la demande.

La commission ministérielle technique des systèmes d\'information et de communication (CMTSIC) peut également être saisie en dernier ressort. Ces dérogations font l\'objet d\'une approbation par le directeur général des systèmes d\'information et de communication. Elles concernent :

• les circonstances et justifications du non respect d\'une règle recommandée ;

• les circonstances et justifications du non respect d\'une règle déconseillée ;

• les justifications des exceptions à toute règle absolue (obligatoire ou interdit). Dans ce dernier cas, une instruction préalable des services de la DGSIC est nécessaire.

2. Cadre documentaire.

2.1. Documents applicables.

DIR-ARCHI : directive n° 20/DEF/DGSIC du 24 août 2011 portant sur l\'architecture des réseaux internet protocol.

DIR-WIFI : directive DEF/DGSIC ⁽¹⁾ sur l\'utilisation du Wi-Fi au sein du ministère de la défense.

PROC-ADR : procédure de demande d\'adressage IP - note n° 921354/DEF/DIRISI/SCOL/B.EMP du 12 mai 2009 ⁽¹⁾.

RGI : référentiel général d\'interopérabilité version 1.0 du 12 mai 2009 ⁽¹⁾.

2.2. Normes et standards applicables.

RFC 2119 : request for comment - key words for use in RFCs to indicate requirement levels S. Bradner (March 1997).

RFC 4029 : request for comment - scenarios and analysis for introducing IPv6 into ISP networks M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola (March 2005).

RFC 4292 : request for comment - IP forwarding table management information base (MIB) B. Haberman (April 2006).

RFC 4293 : request for comment - management information base for the internet protocol (IP) S. Routhier (April 2006).

RFC 5132 : request for comment - IP multicast MIB D. McWalter, D. Thaler, A. Kessler (December 2007).

RFC 5132 : request for comment - management information base for OSPFv3 D. Joyal, V. Manral (August 2009).

2.3. Autres documents et sites de référence.

Site DGSIC : site intranet défense DGSIC (http://www.dgsic.defense.gouv.fr/).

3. Domaine couvert et emploi.

3.1. Services attendus.

3.1.1. Contexte.

Au plan des réseaux nationaux et internationaux sur internet, la gestion des adresses du protocole internet protocol version 4 (IPv4) se trouve confrontée à une demande croissante qui conduit à l\'épuisement des adresses disponibles en 2011. Cette contrainte qui porte surtout sur les fournisseurs d\'accès internet (FAI) a deux effets majeurs : une mobilisation des instances décisionnelles ⁽²⁾ pour amplifier le développement du protocole IPv6 et une offre industrielle qui s\'accroît désormais rapidement.

De leur côté, les réseaux du ministère de la défense sont exclusivement basés sur le protocole IPv4 avec un plan d\'adressage interne construit avec des plages d\'adresses déjà utilisées publiquement. Cet usage privé de larges plages d\'adresses publiques met à l\'abri le ministère d\'une pénurie. Cependant, pour échanger avec les partenaires gouvernementaux ou alliés, il est nécessaire de pratiquer des traductions d\'adresses qui nécessitent des accords préalables, alourdissent les configurations, rigidifient les architectures et qui sont mal supportées par certains services comme par exemple la voix sur IP (VoIP).

3.1.2. Objectifs.

Dans un environnement de plus en plus interconnecté, que ce soit dans le cadre de coalitions sur les théâtres d\'opérations ou bien dans celui de réseaux d\'échange interministériels, les relations doivent pouvoir s\'établir de façon souple et sécurisée. Le protocole IPv6 a été conçu pour répondre à ce besoin car il fournit un large espace d\'adressage offrant la possibilité à tout objet connecté de disposer d\'une adresse unique globale, ce qui permet de s\'affranchir des mécanismes de traduction d\'adresses (NAT). IPv6 apporte également des dispositifs d\'auto-configuration qui simplifient l\'exploitation et la mobilité des usagers ; il standardise internet protocol security (IPsec) comme mécanisme de sécurité réseau unifié et facilite la mobilité.

L\'objectif est de pouvoir bénéficier de ces avancées. Néanmoins, bien que la démarche ait été initiée depuis plusieurs années, cette transformation sera longue ; elle impacte les équipements matériels de réseaux et ordinateurs, les logiciels, les éléments de sécurité, les applications. Les règles de la présente directive visent à fournir un cadre qui facilitera cette transition.

3.1.3. Périmètre et limites.

Cette directive s\'applique à l\'ensemble des réseaux IP utilisées par le ministère de la défense. Elle concerne les nouvelles acquisitions et évolutions majeures de système d\'information opérationnels, de communication, d\'administration et de gestion, scientifique et technique [(système d\'information opérationnel et de commandement (SIOC), système d\'information d\'administration et de gestion (SIAG), système d\'information scientifique et technique (SIST)], de logiciels de services communs, d\'exploitation et de sécurité.

Toutefois le principe général retenu pour la transition est de maintenir une double pile IPv4 et IPv6 jusqu\'à l\'extinction des objets IPv4. Ainsi les applications, systèmes ou équipements en voie d\'obsolescence à moyen terme ne sont pas tenus d\'assurer une compatibilité au protocole IPv6.

3.2. Stratégie de migration.

Pour mettre en place une transition vers IPv6, trois familles de mécanismes sont disponibles :

• la double pile, basée sur une mise en œuvre simultanée et indépendante des deux piles IPv4 et IPv6, permet une transition progressive en faisant cohabiter les deux protocoles. La principale contrainte pour ce type de transition est de disposer d\'adresses IPv4 en nombre suffisant. Elle ne représente pas une solution adaptée en cas d\'épuisement de l\'espace d\'adressage IPv4. Dans un réseau double pile, un échange entre deux entités (deux chiffreurs, un client et un serveur, etc.) se fait en IPv4 si au moins l\'une des extrémités est uniquement IPv4, en IPv6 si les deux extrémités sont compatibles IPv6 ;

• la traduction de protocole permet de traduire un paquet IPv4 en paquet IPv6 et vice versa. Elle permet également de traduire les messages de signalisation interface control message protocol (ICMP). Cette traduction peut être faite par un équipement en coupure sur le réseau ou directement dans la pile système des terminaux. Elle nécessite une mise en correspondance, champ par champ, des entêtes IP. Les deux protocoles étant sensiblement différents, cette traduction génère le plus souvent une perte d\'informations. De plus, certains protocoles applicatifs ne sont pas nativement compatibles avec cette traduction qui cause alors des dysfonctionnements au niveau des applications ;

• l\'encapsulation de protocoles (IPv6 dans IPv4) va permettre d\'établir, au dessus de réseaux purement IPv4, des tunnels reliant ente eux des réseaux IPv6 ou des machines IPv6 isolées. Ces tunnels peuvent être créés manuellement ou bien automatiquement grâce à de nombreux mécanismes.

Aujourd\'hui, le ministère de la défense ne manque pas d\'adresses IPv4 car il utilise potentiellement pour son usage privé, l\'ensemble de l\'adressage internet. Il peut donc continuer à utiliser IPv4 pendant la phase de montée en puissance du protocole IPv6. La double pile est donc la méthode de transition à privilégier pour le ministère de la défense.

Ce fonctionnement en double pile n\'exclut pas le passage par des encapsulations de protocoles mais ces encapsulations n\'ont pas vocation à perdurer. Ces mécanismes permettront au flux IPv6 de traverser un réseau qui n\'offre pas encore de service d\'acheminement IPv6 en encapsulant temporairement ces flux IPv6 dans un tunnel IPv4.

Les mécanismes de traduction de protocoles devront être, quant à eux, réservés éventuellement pour connecter des équipements ou systèmes qui n\'auront pas la possibilité de migrer en IPv6.

3.2.1. Les deux phases de transition.

La transition vers IPv6 va connaitre deux phases bien distinctes :

• une phase de montée en puissance d\'IPv6 ;
  

• une phase de mise en obsolescence du protocole IPv4.

Phase 1 : montée en puissance d\'IPv6.

Durant la phase 1, les systèmes (réseaux, systèmes d\'information, équipements de sécurité) intégreront IPv6 au fur et à mesure de leurs évolutions et des nouvelles acquisitions. La proportion de flux IPv6 dans les réseaux de défense devrait ainsi augmenter progressivement pour devenir majoritaire. Cette phase permettra une cohabitation des nouveaux systèmes double pile et des anciens systèmes IPv4.

Dans le cas du ministère de la défense, même si tous les systèmes doivent engager au plus tôt leur transition, l\'effort doit être particulièrement porté sur les moyens de chiffrement IP et sur les réseaux de transit. En effet, le fait que ces éléments supportent rapidement IPv6 permet de simplifier grandement la transition pour les autres éléments du système comme les terminaux et les applications qu\'ils hébergent.

La directive ministérielle n° 20/DEF/DGSIC du 24 août 2011 définit une architecture cible dans laquelle tous les systèmes utilisateurs constituent des enclaves protégées par des moyens de chiffrement IP, eux-mêmes interconnectés entre eux par un ensemble de réseaux de transit élémentaires (socrate, syracuse, rita, etc.).

Les moyens de chiffrement IP doivent pouvoir encapsuler dans des tunnels IPsec tout type de flux qu\'ils soient IPv4 ou IPv6. Les tunnels IPsec doivent eux-mêmes pouvoir être établis en IPv4 ou en IPv6.

Les réseaux de transit élémentaires sont également cruciaux dans la mesure où le choix du protocole IP utilisés pour la connexion IPsec entre deux chiffreurs est fonction de l\'offre des opérateurs des réseaux de transit traversés.

Phase 2 : mise en obsolescence du protocole IPv4.

La phase 1 doit être la plus courte possible. Il peut, en effet, s\'avérer coûteux de conserver deux piles en parallèle (duplication de certaines fonctions, phase de qualification plus lourde). La fin de la phase de double pile ne peut être déterminée dans cette version du document mais devra être fixée ultérieurement en fonction de la montée en puissance d\'IPv6.

Le ministère de la défense entrera alors dans la phase 2 dans laquelle seule la pile IPv6 sera utilisée pour le routage des paquets. Les piles IPv4 pourront alors être désactivées. Les systèmes n\'ayant pas eu la capacité de migrer devront être équipés de mécanismes de traduction pour pouvoir continuer à fonctionner en réseau. Ces mécanismes seront conservés jusqu\'à la mise hors-service de ces équipements ou systèmes.

3.2.2. Les différents cas de figure.

Conformément à la directive n° 20/DEF/DGSIC du 24 août 2011, tous les flux utilisateurs sont protégés en confidentialité par un moyen de chiffrement de type IPsec.

Il est donc nécessaire de prendre en compte deux types de bout en bout. Le premier bout en bout à considérer est le tunnel entre équipements de chiffrement IPsec, le second est celui situé entre 2 machines terminales, par exemple un client et son serveur. La Figure ci-dessous positionne, sur une interconnexion type entre deux enclaves, ces deux bout-en-bouts.

---

Les deux types de bout-en-bout.

Hypothèses retenues pour la cible :

• pour un niveau de confidentialité donné, tous les chiffreurs sont homogènes (même comportement vis-à-vis de la double pile) ;

• un moyen de chiffrement double pile sait transporter les deux protocoles au dessus des deux protocoles (tous les cas sont possibles).

3.2.2.1. Bout en bout entre moyens de chiffrement.

Les flux issus d\'un moyen de chiffrement vont traverser potentiellement plusieurs réseaux de transit élémentaires avant de joindre l\'enclave destination.

Le protocole IP utilisé de bout en bout va être fonction de la politique de sécurité qui doit tenir compte de la disponibilité d\'IPv6 sur le moyen de chiffrement et des capacités IPv6 du réseau connecté à ce moyen.

Le tableau 1 présente plusieurs cas de figure que l\'on pourrait rencontrer lors de la transition, en fonction de la prise en compte progressive d\'IPv6 par les systèmes composant le bout en bout. Il n\'y a pas de notion de chronologie stricte dans ce tableau.

Dans ce tableau :

• IPv4/IPv6 indique que le réseau [dans son ensemble : équipements réseau, équipement de sécurité, DNS (domain name system)] ou l\'équipement est en mesure d\'acheminer ou de traiter des paquets IPv6 ;

• IPv4 signifie que le réseau ou l\'équipement n\'est pas en mesure d\'acheminer ou de traiter des paquets IPv6 ;

• la nature du bout-en-bout indique avec quelle version du protocole IP sont véhiculés les flux entre les extrémités de ce bout-en-bout.

---

CAS.	MOYEN DE CHIFFREMENT 1.	TRANSIT ÉLÉMENTAIRE 1.	TRANSIT ÉLÉMENTAIRE I.	TRANSIT ÉLÉMENTAIRE N.	MOYEN DE CHIFFREMENT 2.	NATURE DU BOUT-EN-BOUT.	MÉCANISMES COMPLÉMENTAIRES À DOUBLE PILE.
1.1		IPv4
1.2		IPv4
1.3		IPv4
1.4		IPv6	Tunnel sur le transit élémentaire IPv4.
1.5		IPv6

Tableau 1 - bout en bout entre chiffreurs (type 1) - cas de figure.

1.1 Solution initiale : tout est IPv4.

1.2 Un ou plusieurs réseaux de transit sont double pile mais les moyens de chiffrement sont IPv4.

1.3 Les moyens de chiffrement sont double pile mais tous les réseaux d\'accueil de ces moyens de chiffrement ne le sont pas.

1.4 Les moyens de chiffrement sont double pile, tous les réseaux d\'accueil de ces moyens de chiffrement aussi mais pas forcément tous les réseaux de transit  intermédiaires. Nécessite une prise en compte des flux IPv6 par ces réseaux par encapsulation IPv6 dans IPv4.

1.5 Les moyens de chiffrement sont double pile, tous les réseaux de transit élémentaires aussi. IPv6 est la seule pile utilisée.

3.2.2.2. Bout en bout entre machines terminales.

Les flux issus d\'une machine terminale source vont traverser le réseau d\'enclave puis sont encapsulés par les chiffreurs. Après déchiffrement, les flux traversent le réseau d\'enclave destination et sont reçus par la machine destination. Un réseau d\'enclave peut comporter des équipements réseau (routeurs, commutateurs, optimiseurs de performances), des équipements de sécurité (pare-feu, relais applicatifs, passerelles, sondes de détection ou de prévention d\'intrusion) ainsi que des services associés [(DNS, DHCP (dynamic host configuration protocol)].

Le tableau 2 présente plusieurs cas de figure que l\'on pourrait rencontrer lors de la transition en fonction de la prise en compte progressive d\'IPv6 par les systèmes composant le bout en bout. Il n\'y a pas de notion de chronologie stricte dans ce tableau.

Dans ce tableau :

• IPv4/IPv6 indique que le réseau (dans son ensemble : équipements réseau, équipement de sécurité, DNS) ou l\'équipement est en mesure d\'acheminer ou de traiter des paquets IPv6 ;
  
• IPv4 signifie que le réseau ou l\'équipement n\'est pas en mesure d\'acheminer ou de traiter des paquets IPv6 ;
  
• la nature du bout-en-bout indique avec quelle version du protocole IP sont véhiculés les flux entre les extrémités de ce bout-en-bout.

---

CAS.	MACHINE TERMINALE 1.	RÉSEAU D\'ENCLAVE 1.	MOYENS DE CHIFFREMENT.	RÉSEAU D\'ENCLAVE  2.	MACHINE TERMINALE 2.	NATURE DU BOUT-EN BOUT.	MÉCANISMES COMPLÉMENTAIRE À LA DOUBLE PILE.
2.1		IPv4
2.2		IPv4
2.3		IPv4
2.4		IPv4
2.5		IPv4 ou IPv6 suivant disponibilité des services.
2.6		IPv6	Traduction de     protocole pour les applications ou matériels ne pouvant migrer.

tableau 2 - bout en bout entre machines terminales (type 2) - cas de figure.

2.1 Solution initiale: tout est IPv4.

2.2 Les réseaux d\'enclave sont double pile mais pas les machines terminales/applications ni les moyens de chiffrement.

2.3 Les machines terminales/applications et les moyens de chiffrement sont double pile mais pas le réseau d\'enclave. Il est préférable de ne pas activer les piles IPv6 des terminaux si les constituants du réseau d\'enclave ne sont pas encore double pile.

2.4 Certaines enclaves sont double pile, d\'autres ne le sont pas. Les échanges entre les deux types d\'enclaves se font en IPv4.

2.5 Les enclaves sont double pile mais certains services ne sont disponibles qu\'en IPv4.

2.6 Tout est double pile. IPv6 est la seule pile utilisée. IPv4 peut être désactivé. Les matériels ne pouvant pas migrer restent en IPv4 mais les flux qu\'ils génèrent ou reçoivent sont pris en charge par des mécanismes de traduction de protocole.

4. Les règles.

La mise en œuvre des principes décrits pour la stratégie de migration nécessite de respecter un certain nombre de règles à la fois techniques et organisationnelles.

4.1. Règles techniques.

Les règles techniques sont classées en 6 domaines :

• les matériels /logiciels ;

• le routage ;
  
• la qualité de service ;

• la gestion de réseau ;

• l\'adressage ;

• les services réseau.

---

4.1.1. Matériels / logiciels.

4.1.1.1. Généralités.

RT 01 : il est obligatoire pour un matériel/logiciel double pile d\'être en mesure de faire fonctionner les deux piles simultanément mais aussi de manière indépendante.

Précision : cette règle a pour objectif de s\'assurer que les matériels/logiciels peuvent fonctionner sans modification dans les différentes phases du déploiement.

RT 02 : il est recommandé, pour toute acquisition de matériel/logiciel, de privilégier la conformité au niveau Gold du logo « IPv6 Ready Logo » pour les « Core protocols ».

Précision : le logo « IPv6 Ready Logo » est un programme de certification initié par l\'IPv6 Forum dont l\'objectif est de valider l\'interopérabilité entre produits venant de constructeurs différents. La partie « Core protocols » couvre IPv6 lui-même et les mécanismes de base comme l\'auto-configuration. Le niveau phase 2 ou « Gold » est le niveau actuel de certification.

RT 03 : il est obligatoire pour les systèmes d\'exploitation des postes utilisateurs et des serveurs de supporter et de pouvoir mettre en œuvre les deux piles IPv4 et IPv6.

RT 04 : il est obligatoire pour les équipements réseaux de supporter et de pouvoir mettre en œuvre les deux piles IPv4 et IPv6.

Précision : la catégorie « équipements réseaux » comprend les équipements de routage, de commutation, et d\'amélioration des performances réseau (sondes passives, optimiseurs et accélérateurs de flux).

4.1.1.2. Logiciels applicatifs.

RT 05 : pour tout logiciel applicatif développé au profit du ministère de la défense, il est obligatoire que celui-ci soit développé pour fonctionner sur les deux piles IPv4 et IPv6.

RT 06 : pour tout logiciel applicatif acheté sur étagère [COTS (commercial-off-the-shelf)], il est recommandé que celui-ci fonctionne sur les deux piles IPv4 et IPv6.

Précision : l\'acquisition d\'une application sur étagère fonctionnant uniquement au-dessus d\'IPv4 n\'est justifiée que dans le cas où aucun autre logiciel double pile ne couvre le besoin.

RT 07 : il est recommandé pour toute application double pile utilisant la diffusion IPv4 sur le réseau local d\'évoluer pour utiliser le « multicast » en lieu et place du « broadcast ».

Précision : IPv6 ne gérant pas la diffusion « broadcast », cette directive vise à rendre cohérent le comportement d\'une application en double pile.

4.1.1.3. Équipements de sécurité.

Précision : la catégorie « équipements de sécurité» comprend les moyens de chiffrement IP, les pare-feu, les relais applicatifs, les passerelles, les sondes de détection ou de prévention d\'intrusion.

RT 08 : il est obligatoire pour les équipements de sécurité de supporter et de pouvoir mettre en œuvre les deux piles IPv4 et IPv6.

RT 09 : il est obligatoire pour les moyens de chiffrement IP de pouvoir protéger des flux utilisateurs qu\'ils soient IPv4 ou IPv6.

RT 10 : il est obligatoire pour les moyens de chiffrement IP de pouvoir établir des tunnels IPsec de types IPv4 et IPv6.

RT 11 : il est recommandé que la qualité du filtrage obtenue avec les fonctions de filtrage IPv6 soit au minimum d\'un niveau équivalent à celle obtenue avec IPv4.

4.1.2. Routage.

RT 12 : il est obligatoire pour tout équipement disposant d\'une fonction de routage mettant en œuvre un protocole de routage interne IPv6 d\'implémenter OSPFv3 (open shortest path first version 3) ou IS-IS (intermediate system to intermediate system) comme indiqué dans la RFC 4029.

RT 13 : il est obligatoire pour tout équipement disposant d\'une fonction de routage mettant en œuvre un protocole de routage externe IPv6 d\'implémenter MP-BGP (multi protocol - border gateway protocol) comme indiqué dans la RFC 4029.

RT 14 : il est recommandé pour tout équipement disposant d\'une fonction de routage mettant en œuvre un protocole de routage « multicast » IPv6 d\'implémenter PIM-SM (protocol independent multicast sparse mode) ou PIM-SSM (protocol independent multicast source-specific multicast) comme indiqué dans la RFC 4029.

4.1.3. Qualité de service.

RT 15 : il est obligatoire que le niveau de qualité de service fourni pour les flux IPv6 soit au minimum identique à celui fourni pour les flux IPv4.

RT 16 : il est obligatoire que l\'introduction d\'IPv6 ne remette pas en cause les accords de service [SLA (service level agreement)] déjà mis en place pour IPv4.

4.1.4. Gestion réseau.

Précision : la gestion recouvre des activités nécessaires à l\'opération d\'un réseau : son administration et sa supervision. L\'administration de réseau consiste à effectuer toutes les opérations de configuration et de maintenance nécessaires à la mise en œuvre et au maintien en condition opérationnelle d\'un réseau. La supervision de réseau vise à obtenir une vision globale du fonctionnement du réseau de façon à en assurer la maîtrise.

RT 17 : il est recommandé pour les applications de gestion de supporter IPv4 et IPv6 pour l\'ensemble des fonctionnalités offertes.

RT 18 : il est recommandé pour les applications de gestion supportant IPv4 et IPv6 de pouvoir effectuer les requêtes en IPv4 et en IPv6.

RT 19 : il est obligatoire que la configuration de chacune des deux piles d\'un système puisse s‘effectuer de manière indépendante de l\'autre pile.

RT 20 : il est obligatoire pour tout système supportant IPv6 et devant être supervisé par un système de gestion de supporter au minimum les MIB (management information base) IPv6 définies par la RFC 4293.

RT 21 : il est recommandé que tout équipement disposant d\'une fonction de routage supportant IPv6 implémente la MIB IP forwarding (RFC 4292).

RT 22 : il est recommandé que tout équipement disposant d\'une fonction de routage supportant OSPFv3 implémente la MIB OSPF v3 (RFC 5643).

RT 23 : il est recommandé que tout système supportant le multicast IPv6 implémente la MIB IP multicast (RFC 5132).

4.1.5. Adressage.

RT 24 : il est recommandé de mettre en place un adressage géographique avec comme entité élémentaire le site géographique.

Précision : ce découpage représente le meilleur compromis pour limiter la taille des tables de routage et éviter la renumérotation de réseau. La notion de site géographique couvre non seulement une emprise en métropole ou en outremer mais également un site de théâtre, un bâtiment de la marine.

RT 25 : il est recommandé d\'attribuer à chaque site du ministère un préfixe IPv6 d\'une longueur minimum de 48 bits. (/48)

Précision : suivant sa taille, un site pourra se voir alloué plusieurs préfixes/48 contigus.

RT 26 : il est recommandé d\'attribuer à chaque connexion inter-routeurs dans un réseau de transit un préfixe d\'une longueur adaptée au juste besoin. Un lien point à point entre deux routeurs devra se contenter d\'un préfixe de taille/127.

Précision : la limitation de la longueur du préfixe permet de limiter les possibilités d\'ajout d\'équipements réseaux non désirés.

RT 27 : il est recommandé, pour les postes utilisateurs, d\'utiliser une auto-configuration sans état pour construire les adresses IPv6 des interfaces réseau.

Précision : le préfixe réseau est fourni par un routeur sur le lien local. La partie identifiant d\'interface [IID (interface identifier)] peut être aléatoire ou basée sur l\'adresse MAC (medium access control).

RT 28 : il est obligatoire pour une auto-configuration sans état sur un réseau filaire de mettre en place une authentification 802.1x.

Précision : cette directive vise à réduire les risques liés à la phase d\'auto-configuration IP.

RT 29 : il est obligatoire pour une auto-configuration sans état sur un réseau sans-fil de mettre en place une authentification 802.1x comme précisé dans la directive WiFi ⁽³⁾.

RT 30 : il est obligatoire pour les serveurs d\'avoir un identifiant d\'interface (IID) fixe (excluant l\'IID aléatoire ou basé sur l\'adresse MAC).

Précision : le but est d\'éviter tout problème de changement d\'adresse (lors d\'un remplacement de carte réseau par exemple).

RT 31 : il est obligatoire de limiter l\'utilisation du service DHCPv6 à l\'obtention des informations de configuration non disponibles par auto-configuration sans état.

Précision : l\'objectif est de tirer profit au maximum de l\'auto-configuration sans état.

RT 32 : il est recommandé de généraliser l\'emploi de noms génériques, pour les deux piles IPv4 et IPv6, en lieu et place d\'adresses réseau.

Précision : l\'objectif est de rendre la transition la plus transparente possible aux utilisateurs.

4.1.6. Service réseau.

RT 33 : il est obligatoire pour tout système de résolution de noms DNS de pouvoir être interrogé en IPv4 et en IPv6, et de pouvoir gérer les enregistrements de type A et AAAA.

4.2. Règles organisationnelles.

RO 01 : pendant la phase 1 de montée en puissance d\'IPv6, il est déconseillé de déployer des services ou des équipements uniquement IPv6.

Précision : cette règle a pour but d\'assurer la continuité de service avec les clients n\'ayant pas encore migré.

RO 02 : il est recommandé de planifier une phase d\'arrêt progressif des piles IPv4.

Précision : la double pile est un mécanisme transitoire dans le processus de migration vers IPv6. La phase de coexistence IPv4/IPv6 (double pile) devra être aussi courte que possible, afin de limiter l\'incidence induite par la contrainte de gestion des deux protocoles.

RO 03 : il est recommandé de planifier, pour chaque enclave, l\'activation de la pile IPv6 des machines terminales (clients, serveurs) de l\'enclave (et donc leur ajout dans le DNS) en cohérence avec le passage en double pile des réseaux de cette enclave (équipements réseau, équipements de sécurité).

Précision : l\'objectif est d\'éviter d\'avoir des machines déclarées en IPv6 mais non accessibles avec cette version du protocole.

RO 04 : il est obligatoire que les préfixes IPv6 utilisées soient conformes au « plan IPv6 Défense » géré par la direction interarmées des réseaux d\'infrastructure et des systèmes d\'information (DIRISI). Les préfixes doivent être demandés conformément à la procédure de demande d\'adressage IP ⁽⁴⁾.

RO 05 : il est déconseillé de multiplier les encapsulations de protocoles (tunnels IP dans IP, tunnel IPsec) afin de ne pas rencontrer de problèmes liés à la MTU (maximum transmission unit) minimum imposée par IPv6. Il est notamment déconseillé de mettre en cascade des fonctions de chiffrement IP.

Précision : le protocole IPv6 impose une MTU minimale de 1280 octets. Cette limite pourrait être atteinte rapidement avec un surchiffrement notammement sur des liaisons d\'opérateurs.