MOOC:Compagnon Act46 - Revision history

Jlandru at 11:02, 17 January 2023

2023-01-17T11:02:01Z

Jlandru at 10:56, 17 January 2023

2023-01-17T10:56:22Z

Jlandru at 10:54, 17 January 2023

2023-01-17T10:54:48Z

Jlandru: /* Etape 2 : Connectivité IPv6 par tunnel */

2023-01-17T10:38:23Z

‎Etape 2 : Connectivité IPv6 par tunnel

Jlandru at 10:37, 17 January 2023

2023-01-17T10:37:50Z

Jlandru: /* Activité 46: Faites interopérer des applications IPv6 et IPv4 */

2022-02-24T14:09:08Z

‎Activité 46: Faites interopérer des applications IPv6 et IPv4

Jlandru: /* Mise en oeuvre de NAT64 sur R1 */

2022-02-24T09:11:59Z

‎Mise en oeuvre de NAT64 sur R1

Jlandru: /* Configuration de PC1 */

2022-02-24T08:27:06Z

‎Configuration de PC1

Jlandru: /* Allocation d'adresses */

2022-02-23T15:58:34Z

‎Allocation d'adresses

Jlandru: /* Etape 1 : Configuration de NAT64/DNS64 */

2022-02-23T15:52:01Z

‎Etape 1 : Configuration de NAT64/DNS64

@@ Line 504: / Line 504: @@
   Copyright 1996-2005 Kunihiro Ishiguro, et al.
-  r1.tp# '''show interface'''
+  r1# '''show interface'''
@@ Line 510: / Line 510: @@
 Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :
-  r1.tp# '''show ipv6 route'''
+  r1# '''show ipv6 route'''
 Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.
@@ Line 536: / Line 536: @@
   Copyright 1996-2005 Kunihiro Ishiguro, et al.
-  r2.tp# '''show interface'''
+  r2# '''show interface'''
 Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.
 Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :
-  r2.tp# '''show ipv6 route'''
+  r2# '''show ipv6 route'''
 Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :

@@ Line 536: / Line 536: @@
   Copyright 1996-2005 Kunihiro Ishiguro, et al.
-  r2# '''show interface'''
+  r2.tp# '''show interface'''
 Vous devez retrouver sur l'interface <tt>tun0</tt> l'adresse IPv6 que vous venez d'attribuer.
 Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :
-  r2# '''show ipv6 route'''
+  r2.tp# '''show ipv6 route'''
 Depuis R1, toujours en mode Quagga, vérifiez que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel :

@@ Line 504: / Line 504: @@
   Copyright 1996-2005 Kunihiro Ishiguro, et al.
-  r1# '''show interface'''
+  r1.tp# '''show interface'''
@@ Line 510: / Line 510: @@
 Vérifiez la configuration des routes en affichant le contenu de la table de routage; une entrée indexée par le préfixe du tunnel et pointant sur tun0 doit avoir été ajoutée :
-  r1# '''show ipv6 route'''
+  r1.tp# '''show ipv6 route'''
 Recommencez la même série de commandes, en ajustant les paramètres, pour l'autre extrémité du tunnel ; à savoir, sur le routeur R2.

@@ Line 452: / Line 452: @@
 Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel.
 Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.
-Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extremités du tunnel sont indiqués par la figure 4. -->
+Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extrémités du tunnel sont indiqués par la figure 4. -->
 <!--<center>

@@ Line 450: / Line 450: @@
 = Etape 2 : Connectivité  IPv6 par tunnel =
-Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supoortant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel.
+Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Sur notre plateforme, cette connectivité IPv6 va être étendue jusqu'au réseau supportant notre service web (srv.tp) sur SRV-3 au moyen d'un tunnel.
 Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.
 Le tunnel aura un préfixe extrait du préfixe <tt>fd75:e4d9:cb77::/48</tt> et complété avec le SID à la valeur <tt>fff</tt> pour former un préfixe de 64 bits ''(cf figure 4)''. <!-- Les identifiants d'interfaces des extremités du tunnel sont indiqués par la figure 4. -->

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Activité 46:  Faites interopérer des applications IPv6 et IPv4=
+= Activité 46:  Faites inter-opérer des applications IPv6 et IPv4=
 Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. À ce stade du déploiement, nous avons 2 Internets :
@@ Line 6: / Line 6: @@
 * un Internet en IPv6 en croissance mais néanmoins, pour le moment, moins développé en terme de services car il connecte aujourd'hui essentiellement des clients.
-L'objectif de cette activité est de présenter les solutions d'interopération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours.
+L'objectif de cette activité est de présenter les solutions d'inter-opération d'applications distribuées qui ne fonctionnent pas au-dessus de la même version du protocole IP. Comme nous l'avons dit, le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours.
 Les différentes étapes de cette activité vont représenter une évolution temporelle de l'Internet. Pour chacune de ces évolutions, nous montrerons quelle technique de transition appliquer et comment l'appliquer.
-La plateforme mise en oeuvre dans ce TP est représentée par la figure 1. Elle comporte :
+La plateforme mise en œuvre dans ce TP est représentée par la figure 1. Elle comporte :
-* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le noeud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;
+* un client 'IPv6 uniquement' disposant seulement d'une adresse IPv6. Ce client, localisé sur le nœud PC-1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appellera par la suite l'Internet en IPv6 ;
-* un routeur R1 en double pile : c'est un noeud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;
+* un routeur R1 en double pile : c'est un nœud qui a une connectivité avec l'Internet en IPv6 et en IPv4 ;
 * un routeur R2 en IPv4 : c'est un noeud  représentant l'Internet en IPv4 ;
 * un client 'IPv4 uniquement' localisé sur PC-2, représente les machines héritées de l'internet de la génération précédente ;

@@ Line 418: / Line 418: @@
   root@r1:/home/vyos# '''ip -6 addr add fd75:e4d9:cb77:1::1 dev nat64'''             # IPv6 router address
   root@r1:/home/vyos# '''ip route add 192.0.1.0/24 dev nat64'''                      # route to IPv6 nodes (nodes with IPv4-tranlsatable address)
-  root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''         #  global route to IPv4 nodes (nodes with IPv4-converted address)
+  root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64'''         # global route to IPv4 nodes (nodes with IPv4-converted address)
   root@r1:/home/vyos# '''ip -6 route add fd75:e4d9:cb77:64::c000:101/120 dev eth0''' # route to PC-1 and other nodes with IPv4 converted adress on NET1
 '''''Nota 1 :''''' ''les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.''

@@ Line 246: / Line 246: @@
 Vérifiez que l'adresse IPv6 de l'interface eth0 de PC-1 a bien son IID fixé à la valeur '''<tt>c1</tt>''', conformément au tableau 1.
   root@PC-1~# '''ifconfig eth0'''
-Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4. La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien.
+Puis, ajoutez sur PC-1 l'adresse IPv6 traduisible en IPv4 (''IPv4-translatable''). La longueur du préfixe est ici fixée à 128 bits car le préfixe n'identifie pas un lien.
 <!-- apprenant@MOOCIPv6:~$ '''sudo ifconfig eth0 add fd75:e4d9:cb77:64::192.0.3.3/128''' -->
   root@PC-1:~# '''ip -6 addr add fd75:e4d9:cb77:64::192.0.1.1/128 dev eth0'''

@@ Line 129: / Line 129: @@
 Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.'''1'''.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.
-La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hote pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.
+La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte, au niveau du réseau IPv4 central, sont <tt>1</tt> pour R1 et <tt>2</tt> pour R2. Les identifiants d'hôte pour R2 sur les réseaux Net2 (192.0.2.0/24) et Net3 (192.0.3.0/24) sont fixés à 254.
 <!--<center>
 [[Image:46-fig3-v3.png|450px|thumb|center|Figure 3 : Allocation des préfixes et identifiants.]]

@@ Line 114: / Line 114: @@
 Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. Cette transformation est indispensable pour rendre IPv4 transparent aux protocoles applicatifs et aux utilisateurs IPv6. C'est ici que nous avons besoin des services d'un relais DNS auxiliaire (''DNS Application Layer Gateway''), communément appelé DNS64.
 Celui-ci traduira, à la volée, les adresses IPv4 en adresses IPv6 avec un préfixe particulier qui sera routé vers le relais réseau NAT64. L'adresse IPv6 ainsi créée à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.
-Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.
+Du point de vue du client, DNS64 se comporte comme n'importe quel relai DNS récursif de proximité. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Lorsque le client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, il ajoute un préfixe particulier, conforme au RFC 6052, aux 32 bits de l'adresse IPv4. Les paquets du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relais réseau (NAT64). Le préfixe habituellement réservé pour cet usage par le RFC 6052 est le préfixe bien connu WKP (''Well Known Prefix'') (<tt>64:ff9b::/96</tt>). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Prefix'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. Dans la figure 2, le préfixe utilisé noté <tt>pref64::</tt> indique un préfixe IPv6 réservé à l'usage de la traduction.
 <!--<center>