MOOC:Compagnon Act43-s7 - Revision history

Vlerouvillois: /* Transposition protocolaire des champs de l'en-tête (RFC 7915) */

2024-01-21T09:58:40Z

‎Transposition protocolaire des champs de l'en-tête (RFC 7915)

Bstevant: /* Pour aller plus loin */

2022-02-25T14:58:08Z

‎Pour aller plus loin

Bstevant: /* Pour aller plus loin */

2022-02-25T14:57:36Z

‎Pour aller plus loin

Vlerouvillois: /* NAT64 : traduction "avec état" RFC 6146 */

2022-02-15T17:54:23Z

‎NAT64 : traduction "avec état" RFC 6146

Vlerouvillois: /* NAT64 : traduction "sans état" RFC 7915 */

2022-02-15T17:51:34Z

‎NAT64 : traduction "sans état" RFC 7915

Vlerouvillois: /* NAT64 : traduction "sans état" RFC 7915 */

2022-02-15T17:49:19Z

‎NAT64 : traduction "sans état" RFC 7915

Vlerouvillois: /* Activité 43 : Interopérer les applications par traduction */

2022-02-15T17:46:45Z

‎Activité 43 : Interopérer les applications par traduction

Vlerouvillois: /* Traduction des adresses */

2022-02-15T17:45:17Z

‎Traduction des adresses

Vlerouvillois: /* Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) */

2022-02-15T17:40:21Z

‎Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052)

Vlerouvillois: /* Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) */

2022-02-15T17:39:59Z

‎Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052)

@@ Line 39: / Line 39: @@
 === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===
-Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.
+Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvel en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.
 Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)

@@ Line 327: / Line 327: @@
 * RFC 7915 IP/ICMP Translation Algorithm [http://www.bortzmeyer.org/7915.html Analyse]
 * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]
 * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]
 * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]

@@ Line 327: / Line 327: @@
 * RFC 7915 IP/ICMP Translation Algorithm [http://www.bortzmeyer.org/7915.html Analyse]
 * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]
 * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]
 * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]

@@ Line 280: / Line 280: @@
 </center>
-Le cas illustré par la figure 6 montre un un échange en IPv6 entre  le client ME  et le serveur web "example.org". Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :
+Le cas illustré par la figure 6 montre un échange en IPv6 entre le client ME et le serveur Web "example.org". Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :
 # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1).
 # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un "résolveur" de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2).

@@ Line 258: / Line 258: @@
 ===NAT64 : traduction "sans état" RFC 7915===
-Le NAT64 "sans état" signifie que les adresses IPv6 du paquet sont traduites '''chacune''' "sans état", à l'aide de l'algorithme de correspondance défini dans le RFC 6052.  Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les nœuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les nœuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un nœud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable "classique" pour communiquer avec les autres nœuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce nœud pour ses communications avec les nœuds de l'internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction "sans état" : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile).
+Le NAT64 "sans état" signifie que les adresses IPv6 du paquet sont traduites '''chacune''' "sans état", à l'aide de l'algorithme de correspondance défini dans le RFC 6052.  Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les nœuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les nœuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement, cela signifie qu'un nœud IPv6 voit son interface réseau configurée avec 2 adresses IPv6 : une adresse IPv6 routable "classique" pour communiquer avec les autres nœuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce nœud pour ses communications avec les nœuds de l'internet v4. On voit là apparaître la principale faiblesse de ce mode de traduction "sans état" : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile).
 La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté "pref64". Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.

@@ Line 21: / Line 21: @@
 </center>
-Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'Internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'Internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager.
+Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager.
 <!--
 Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.
 IPv6 ↔ Ipv4.
 -->
-Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'Internet v4, soit des clients de l'Internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le  traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'Internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'Internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.
+Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'internet v4, soit des clients de l'internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le  traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.
-Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'Internet v4.
+Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.
 Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') <ref>3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]</ref>. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être "double pile" que depuis la ''Release-9''. Pour avoir un support "double pile" sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP.
@@ Line 201: / Line 201: @@
 où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur.  Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais.
-Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'Internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet "retour" contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet "aller" entre l'adresse de transport "source" IPv6 et l'adresse de transport "source" IPv4. La traduction est alors dite "à état" car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :
+Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet "retour" contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet "aller" entre l'adresse de transport "source" IPv6 et l'adresse de transport "source" IPv4. La traduction est alors dite "à état" car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :
   IPv6  --------------> IPv4
@@ Line 258: / Line 258: @@
 ===NAT64 : traduction "sans état" RFC 7915===
-Le NAT64 "sans état" signifie que les adresses IPv6 du paquet sont traduites '''chacune''' "sans état", à l'aide de l'algorithme de correspondance défini dans le RFC 6052.  Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable "classique" pour communiquer avec les autres noeuds de l'Internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'Internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction "sans état" : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile).
+Le NAT64 "sans état" signifie que les adresses IPv6 du paquet sont traduites '''chacune''' "sans état", à l'aide de l'algorithme de correspondance défini dans le RFC 6052.  Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable "classique" pour communiquer avec les autres noeuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction "sans état" : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile).
 La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté "pref64". Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.
@@ Line 304: / Line 304: @@
 Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs "à état", ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].
-Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article<ref>Boucadair, M.; Binet, D. et Jacquenet, C. (2011). Techniques de l'ingénieur. [http://www.techniques-ingenieur.fr/base-documentaire/technologies-de-l-information-th9/reseau-internet-protocoles-multicast-routage-mpls-et-mobilite-42289210/transition-ipv6-te7507/ Transition IPv6 - Outils et stratégies de migration]</ref>, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'Internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'Internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.
+Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article<ref>Boucadair, M.; Binet, D. et Jacquenet, C. (2011). Techniques de l'ingénieur. [http://www.techniques-ingenieur.fr/base-documentaire/technologies-de-l-information-th9/reseau-internet-protocoles-multicast-routage-mpls-et-mobilite-42289210/transition-ipv6-te7507/ Transition IPv6 - Outils et stratégies de migration]</ref>, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.
-Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'Internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.
+Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.
 == Références bibliographiques ==

@@ Line 183: / Line 183: @@
 La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses "source" et "destination" chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet.
-Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et vice-et-versa à la fois pour l'adresse "source" et l'adresse "destination".
+Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse "source" et l'adresse "destination".
 Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.
@@ Line 190: / Line 190: @@
 </center>
-La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le  [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un noeud IPv6.
+La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le  [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.
-Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''"Network-Specific Prefix'' (NSP). Le WKP se définit par <tt>64:ff9b::/96</tt> et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'Internet v6. Il doit être utilisé uniquement en routage interne à un réseau.
+Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''"Network-Specific Prefix'' (NSP). Le WKP se définit par <tt>64:ff9b::/96</tt> et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.
 La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4  est qualifiée de '''sans état'''.  Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :

← Older revision		Revision as of 17:40, 15 February 2022
Line 156:		Line 156:

	=== Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===		=== Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===
−	Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 "avec" ou "sans état". Ce RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du checksum effectué avec le pseudo-entête.	+	Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 "avec" ou "sans état". Ce RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.

← Older revision		Revision as of 17:39, 15 February 2022
Line 156:		Line 156:

	=== Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===		=== Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===
−	Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 "avec" ou "sans état". Ce RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b ::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du checksum effectué avec le pseudo-entête.	+	Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 "avec" ou "sans état". Ce RFC définit un préfixe réservé (''well-known prefix'') '''<tt>64:ff9b::/96</tt>''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du checksum effectué avec le pseudo-entête.