MOOC:Compagnon Act41-s7 - Revision history

Bstevant: /* Pour aller plus loin */

2023-01-10T08:17:20Z

‎Pour aller plus loin

Bstevant: /* Pour aller plus loin */

2023-01-09T11:29:31Z

‎Pour aller plus loin

Bstevant: /* Déploiement d'IPv6 pour les services */

2023-01-09T11:28:17Z

‎Déploiement d'IPv6 pour les services

Bstevant: /* Les adresses IPv4 imbriquées dans une adresse IPv6 */

2023-01-09T11:26:00Z

‎Les adresses IPv4 imbriquées dans une adresse IPv6

Bstevant: /* Pour aller plus loin */

2023-01-09T11:21:44Z

‎Pour aller plus loin

Bstevant: /* Administration du réseau */

2023-01-09T11:20:28Z

‎Administration du réseau

Bstevant: /* Pour aller plus loin */

2023-01-09T11:19:02Z

‎Pour aller plus loin

Bstevant: /* Configuration d'adresses */

2023-01-09T11:17:54Z

‎Configuration d'adresses

Bstevant: /* Pour aller plus loin */

2023-01-09T11:15:31Z

‎Pour aller plus loin

Bstevant: /* Configuration d'adresses */

2023-01-09T11:14:30Z

‎Configuration d'adresses

@@ Line 414: / Line 414: @@
 * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]
 * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]
 * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]
 * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]
@@ Line 438: / Line 437: @@
 * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]
 * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]
 Présentations sur le déploiement d'IPv6 :

@@ Line 433: / Line 433: @@
 * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]
 * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]
 * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]
 * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]
 * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]
 * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]
 Présentations sur le déploiement d'IPv6 :

@@ Line 291: / Line 291: @@
 * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513)  <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresses ont été dépréciées par le RFC 4291.
 * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un nœud supportant uniquement IPv4.
-* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0:xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.
+* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0:xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole de traduction sans état entre IPv4 et IPv6 (IP/ICMP Translation Algorithm SIIT, RFC 7915). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.
 Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).

@@ Line 289: / Line 289: @@
 === Les adresses IPv4 imbriquées dans une adresse IPv6 ===
 Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :
-* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513)  <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresse ont été dépréciées par le RFC 4291.
+* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513)  <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresses ont été dépréciées par le RFC 4291.
 * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un nœud supportant uniquement IPv4.
-* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0:xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.
+* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0:xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.
 Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).

@@ Line 401: / Line 401: @@
 RFC et leur analyse par S. Bortzmeyer :
 * RFC 1918 Address Allocation for Private Internets
 * RFC 3587 IPv6 Global Unicast Address Format
 * RFC 3596 DNS Extensions to Support IP Version 6
 * RFC 4038 Application Aspects of IPv6 Transition
 * RFC 4057 IPv6 Enterprise Network Scenarios

@@ Line 262: / Line 262: @@
 L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.
-La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 2851 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.
+La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.
 Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.

@@ Line 245: / Line 245: @@
 * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association "adresse MAC - adresse IP". Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.
-Avec DHCPv6 [RFC 3315], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.
+Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.
-Lorsque DHCP est utilisé dans sa version "sans état", comme le permet le RFC 3736, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP "sans état".
+Lorsque DHCP est utilisé dans sa version "sans état", comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP "sans état".
 Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.

@@ Line 424: / Line 424: @@
 * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]
 * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]
 * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]
 * RFC 6177 IPv6 Address Assignment to End Sites
@@ Line 436: / Line 435: @@
 * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]
 * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]
 * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]
 * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]

@@ Line 242: / Line 242: @@
 Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :
-* absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 6106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;
+* absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;
 * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association "adresse MAC - adresse IP". Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.