Difference between revisions of "MOOC:Compagnon Act43-s7"

From Livre IPv6
(→‎Transposition protocolaire des champs de l'en-tête (RFC 7915))
 
(289 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
= Mécanime de traduction des entêtes IP =
+
<!--
 +
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_4|Séquence 4]] > [[MOOC:Activité_43-f|Activité 43]]
 +
----
 +
-->
 +
__NOTOC__
 +
= <div id="traduction">Activité 43 : Interopérer les applications par traduction </div>=
 +
<!-- ----------------------------------------- -->
 +
<!-- {{Approfondissement}} -->
 +
== Contexte d'utilisation de la traduction ==
  
−
== Contexte d'utilisation de la traduction des entêtes IP ==
+
Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue  le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante :  "tout le monde en IPv4" ->  "certains réseaux en IPv4 seul et certains en IPv6 seul" -> "tout le monde en IPv6".
  
−
Le besoin de traduction d'un protocole vers un autre apparait si l'on souhaite faire communiquer 2 machines ne parlant chacune qu'un seul de ces 2 protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relai) dans la communication.
+
Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6.
 +
Dans le cadre d'une communication "client vers serveur", il y aura donc 2 cas :
 +
# Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;
 +
# Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.
 +
Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave<ref>Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]</ref> de l'IETF qui avait déjà publié des travaux pour le NAT44.
  
−
Afin de respecter les modèles, la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction niveau applicatif, niveau transport et niveau réseau. Dans le cas qui nous concerne du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer 2 machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6.  
+
<center>
−
Dans le cadre de communication client vers serveur, il y aura donc 2 cas :
+
[[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]
−
* le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4
+
</center>
−
* le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6
+
−
Aujourd'hui le cas le plus fréquent est le premier, les serveurs gardant encore une connectivité IPv4. Il s'agit donc de mettre en place un dispositif permettant la traduction bi-directionnelle entre IPv4 et IPv6 pour permettre à ces machines communiquer.
+
  
−
Un contexte pour lequel ce type de solution est pertinent est celui des réseaux mobiles 3GPP. En effet dans la norme 3GPP, les sessions PDP mises en place pour la connexion de donnée 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 2 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 connecter à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurer par la traduction d'entête IP.  
+
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''.
 +
Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.
  
−
Un tel dispositif devra naturellement se situer en coupure des communications entre les 2 machines, afin d'en intercepter les paquets pour les traduire, et les ré-émettre sur le réseau vers le destinataire, en utilisant le bon protocole. C'est pour cela que ce dispositif est comparable au traditionnel NAT (Network Address Translator) utilisé entre les réseaux IPv4 privés et public. Mais dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'entête.
+
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.  
  
−
Les traducteurs assurant le relai entre un réseau IPv6 et l'Internet IPv4 sont appelés NAT64. Les traducteurs assurant le relai entre un réseau IPv4 et l'Internet IPv6 sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra être d'actualité dans le contexte d'un déploiement majoritaire d'IPv6.
 
  
 
== Principe de la traduction entre protocoles IP ==
 
== Principe de la traduction entre protocoles IP ==
  
−
=== Transposition des champs de l'entête ===
+
La traduction entre protocoles IP comporte essentiellement deux composants<ref>Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]</ref> : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses "source" et "destination" du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.
−
Il faut ici bien situé le problème : le traducteur reçoit un paquet avec une entête IPvX doit créer une nouvelle entête IPvY à partir des informations à sa disposition (les données de l'entête IPvX + données de configuration).
+
  
−
Si l'on observe les entêtes IPv4 et IPv6 comme dans l'activité 21, 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 ci-dessous résument les informations qu'il faut utiliser pour renseigner les différents champs des entêtes IPv4 ou IPv6 que doit créer le traducteur (Voir [http://tools.ietf.org/html/rfc6145#section-4 RFC6145 Section 4])
+
Les traductions peuvent être faites "sans état" (''stateless'') RFC 7915 ou bien "avec état" (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction "sans état", les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction "avec état", le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction "avec état" passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue "sans état", le composant de traduction des adresses fonctionne "avec" ou "sans état".  
  
−
'''Création d'une entête IPv6 à partir d'une entête IPv4'''
+
=== 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 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.
  
−
{| border="1" cellpadding="10" cellspacing="0"
+
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)
−
! Champ de l'entête IPv4
+
 
−
! Champ dans la nouvelle entête IPv6
+
<center>
 +
{| border="1" cellpadding="5" cellspacing="0"
 +
! Champ de l'en-tête IPv4
 +
! Champ dans le nouvel en-tête IPv6
 
! Valeur
 
! Valeur
 
|-
 
|-
Line 37: Line 55:
 
! IHL
 
! IHL
 
|  
 
|  
−
| Ignoré
+
| Ignorer
 
|-
 
|-
 
! Type Of Service
 
! Type Of Service
 
| Traffic Class
 
| Traffic Class
−
| Recopie
+
| Recopier
 
|-
 
|-
 
!
 
!
Line 49: Line 67:
 
! Packet Length
 
! Packet Length
 
| Payload Length
 
| Payload Length
−
| Packet Length - IHL (entête IPv4 + options) + 8 (si extension de fragmentation)
+
| Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)
 
|-
 
|-
 
!  Ident./Flag/Offset
 
!  Ident./Flag/Offset
Line 61: Line 79:
 
! Protocol
 
! Protocol
 
| Next Header
 
| Next Header
−
| Recopie ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).
+
| Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).
 
|-
 
|-
 
! Checksum
 
! Checksum
 
|  
 
|  
−
| Ignoré
+
| Ignorer
 
|-
 
|-
 
! Source Address
 
! Source Address
Line 79: Line 97:
 
| Les options IPv4 ne sont pas traduites.
 
| Les options IPv4 ne sont pas traduites.
 
|}
 
|}
 +
Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4
  
−
'''Création d'une entête IPv4 à partir d'une entête IPv6'''
+
{| border="1" cellpadding="5" cellspacing="0"
−
 
+
! Champ de l'en-tête IPv6
−
{| border="1" cellpadding="10" cellspacing="0"
+
! Champ dans le nouvel en-tête IPv4
−
! Champ de l'entête IPv6
+
−
! Champ dans la nouvelle entête IPv4
+
 
! Valeur
 
! Valeur
 
|-
 
|-
Line 97: Line 114:
 
! Traffic Class
 
! Traffic Class
 
| Type of Service
 
| Type of Service
−
| Recopie
+
| Recopier
 
|-
 
|-
 
! IPv6 Flowlabel
 
! IPv6 Flowlabel
 
|  
 
|  
−
| ignoré
+
| Ignorer
 
|-
 
|-
 
! Payload Length
 
! Payload Length
Line 117: Line 134:
 
! Next Header
 
! Next Header
 
| Protocol
 
| Protocol
−
| Recopie. ICMPv6 (58) devient ICMPv4 (1)
+
| Recopier. ICMPv6 (58) devient ICMPv4 (1)
 
|-
 
|-
 
!  
 
!  
 
| Checksum
 
| Checksum
−
| Calcul une fois l'entête créée
+
| Calculer une fois l'en-tête créé
 
|-
 
|-
 
! Source Address
 
! Source Address
Line 133: Line 150:
 
! Extensions IPv6
 
! Extensions IPv6
 
|
 
|
−
| Les extensions d'entête IPv6 ne sont pas traduites.
+
| Les extensions d'en-tête IPv6 ne sont pas traduites.
 
|}
 
|}
 +
Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6
 +
</center>
  
−
=== Traduction des adresses ===
+
=== 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.
  
−
La traduction d'adresse d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec une adresse source et destination chacune dans un des espaces d'adressages et doit traduire ces adresses dans un autre espace d'adressage pour pouvoir le ré-émettre.
 
  
−
Un NAT44 reçoit du réseau privé des paquets avec une adresse IPv4 source dans l'espace d'adressage public. Pour pouvoir émettre ce paquet vers l'Internet IPv4, le mécanisme de NAT remplace cette adresse source par une adresse IPv4 de l'espace d'adressage public, adresse étant une de celles routées vers lui.
+
{{HorsTexte|Tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 96 à 127), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}
  
−
La traduction de l'entête IP d'un paquet d'une version à une autre du protocole nécessite la traduction des deux champs IP source et destination. Le traducteur doit donc décider d'une correspondance routable entre une adresse de l'espace d'adressage IPv4 vers une adresse de l'espace d'adressage IPv6. Le cadre général de cette traduction d'adresse est précisé par la RFC 6052.
 
  
−
La traduction d'une adresse IPv4 en IPv6 est simple car l'espace d'adressage IPv6 est assez large pour y trouver une adresse IPv6 à faire correspondre avec une adresse IPv4. La technique pour créer une adresse IPv6 à partir d'une adresse IPv4 est d'inclure les 32 bits de cette adresse à la suite d'un préfixe IPv6. Selon la taille du préfixe à utiliser, le mécanisme d'inclusion est différent, comme précisé dans le RFC 6052 section 2.2. Le préfixe utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relai. L'adresse ainsi créée permet d'adresser un noeud IPv4 dans l'espace d'adressage IPv6. La traduction effectuée par le relai est alors sans état.
+
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 +
|PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|
 +
  +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
 +
|32|    prefix    '''|v4(32)        | u |''' suffix                    |
 +
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
 +
|40|    prefix        '''|v4(24)    | u |(8)|''' suffix                |
 +
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
 +
|48|    prefix            '''|v4(16) | u | (16)  |''' suffix            |
 +
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
 +
|56|    prefix                '''|(8)| u |  v4(24)  |''' suffix        |
 +
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
 +
|64|    prefix                    '''| u |'''  v4(32)      | suffix    |
 +
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
 +
|96|    prefix                                    '''|    v4(32)    |'''
 +
+--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+
  
−
La traduction d'une adresse IPv6 en adresse IPv4 est plus complexe car il est impossible de représenter l'espace d'adressage IPv6 dans celui d'IPv4. Le traducteur aura besoin d'une information supplémentaire, obtenue au préalable, afin de pouvoir désigner l'adresse IPv6 pertinente dans le contexte du paquet IPv4 à traduire. Par exemple dans le cas d'un traducteur entre un réseau local IPv6 et l'Internet IPv4, le traducteur ne sait pas comment traduire l'adresse source du paquet sortant. Il doit utiliser une de ces propres adresses. Le paquet retour contient alors cette adresse comme destination. Le traducteur a besoin ici d'une information contextuelle : la correspondance choisie entre les adresses source IPv6 et IPv4 du paquet sortant (plus des informations de niveau transport pour distinguer les flux). La traduction effectuée par le relai est dans ce cas avec état.
+
Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.
  
−
== Mécanismes complémentaires ==
+
=== Traduction des adresses ===  
  
 +
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-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.
 +
 +
<center>
 +
[[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]
 +
</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 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.
 +
 +
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 :
 +
 +
IPv6  <-------> IPv4
 +
pref64:H4        H4         
 +
 +
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 :
 +
 +
IPv6  --------------> IPv4
 +
  H6  (état  H6->N4)  N4
 +
IPv6  <-------------  IPv4
 +
  H6  (état  H6<-N4)  N4
 +
 +
La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.
 +
 +
== Mécanismes complémentaires ==
 
=== Traduction des paquets ICMP ===
 
=== Traduction des paquets ICMP ===
  
−
Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'au rapports d'erreur d'acheminement sur le chemin du paquet. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en message ICMPv6 et inversement pour être ainsi transparent dans ces échanges.  
+
Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges.  
  
−
Le traducteur recevant donc un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à émettre. L'entête IP est traduite selon les mécanismes présentés plus haut. L'entête ICMPv4 (resp. ICMPv6) doit donc être transformée par le traducteur en entête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces 2 protocoles ne sont pas très éloignées : les fonctions supplémentaires de découvertes de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dites sans état. La RFC 6145 définit le mécanisme pour effectuer cette traduction.
+
Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.
  
−
Le champ ICMP <tt>type</tt> devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les versions du protocole. Par exemple les messages Echo Request et Reply sont identifiés par la valeur du champ ICMP <tt>type</tt> 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique n'a pas été transposée dans ICMPv6 (parce qu'obsolète).  
+
Le champ ICMP <tt>type</tt> devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP <tt>type</tt> : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6.  
  
−
La traduction de l'entête ICMP modifie les entêtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces entêtes. Le champ <tt>checksum</tt> doit donc être recalculé suite à la traduction.
+
La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ <tt>checksum</tt> doit donc être recalculé suite à la traduction.
  
−
=== Relai-Traducteur DNS auxiliaire ===
+
=== Relais-traducteur DNS auxiliaire (RFC 6147) ===
−
Afin d'assurer la transparence aux protocoles applicatifs et aux utilisateurs, les mécanismes de traduction s'appuyer sur les services d'un relais DNS auxiliaire (DNS-ALG DNS Application Layer Gateway). Celui ci permet de convertir les résolution d'adresses IPv4 en adresses IPv6 ou inversement avec un préfixe particulier qui sera routé vers le relais transport ou réseau.  
+
{{HorsTexte|Auto-découverte des préfixes de traduction|
 +
Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe  est découvert de manière automatique selon une des deux méthodes suivantes :
 +
* déduction heuristique selon l'algorithme décrit dans le RFC 7050 (''Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' ,  sur lequel deux adresses IPv4 réservées ''<tt>192.0.0.170</tt>'' et ''<tt>192.0.0.171</tt>'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;
 +
* déduite des annonces de routeurs RA (''Router Advertisment'') si celles contiennent l'option PREF64 définies dans le RFC 8781 (''Discovering PREF64 in Router Advertisements'').  
 +
'''''Nota :''''' ''Au moment de la rédaction de ce document, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].''
  
−
Du point de vue du client, il se comporte comme n'importe quel serveur DNS de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose déjà pas de l'information dans son cache local. Mais ce DNS est dit menteur car il est capable de répondre positivement à la demande d'une ressource inexistante.
+
L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6  car:
 +
* il veut faire la validation DNSSEC ;
 +
* ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;
 +
* il ne fournit tout simplement pas de résolveur DNS64 ;
 +
* il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;
 +
* il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;
 +
}}
  
−
Par exemple, lorsqu'un 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, le relai DNS applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans la RFC 6052. Il combine un préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA. Un DNS permettant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé DNS64.
+
Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi "forgée" à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.
 +
Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. 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. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.
  
−
Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel Trick or Treat Deamon (TOTD) peut également être utilisé pour cet usage.
+
La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 "IPv4-convertible" est le WKP (''Well Known Prefix'') de longueur 96 bits (<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 Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe.  
  
−
== Pour aller plus loin : Limitations de la traduction ==
+
Les opérations sont les suivantes :
−
{{TODO|Section à écrire}}
+
# Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.
−
(MTU/Fragmentation, Sécurité, Compatibilité des applications)
+
# Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.
 +
# Le DNS64 reçoit une réponse à sa requête de type A.
 +
# Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.
  
 +
<center>
 +
[[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]
 +
</center>
  
−
== Exemple d'un déploiement de NAT64 sur le réseau mobile==
+
Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.
  
−
Comme décrit en début de chapitre, le déploiement d'un réseau seulement IPv6 peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisé en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un DNS64. L'intérêt du dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci connaisse l'adresse du DNS64.
+
==Mécanisme de transition NAT64/DNS64==
  
−
[[Image:NAT64_1.png]]
+
NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau.  Le fonctionnement  du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse "source" et de l'adresse "destination" du paquet reçu par le traducteur<ref>Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]</ref>.
  
−
Le client cherche ici à joindre le service hébergé sur le serveur g6.asso.fr. Pour en connaitre l'adresse IP, il interroge donc le serveur de résolution de nom, en l'occurence 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.
+
===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é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).  
  
−
[[Image:NAT64_2.png]]
+
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.
 +
<center>
 +
[[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 "sans état".]]
 +
</center>
  
−
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 serveur DNS récursif normal et transfert cette enregistrement au client en guise de réponse. Le client peut alors se connecter directement au service.
+
Du fait de son caractère "sans état", ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile<ref>Pepelnjak, I.  (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]</ref>. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur "avec état".
  
−
[[Image:NAT64_3.png]]
+
===NAT64 : traduction "avec état" RFC 6146===
 +
Décrit par le RFC 6146, le NAT64 "avec état" possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que  l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur "sans état" porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de  traduction "sans état". Comme le décrit la figure 5, le NAT64 "avec état" utilise à la fois une traduction "avec état" et une traduction "sans état". Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse  IPv4 partagée que le traducteur utilise pour la représentation des adresses "source" IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.
  
−
Si le client cherche à joindre un  
+
<center>
 +
[[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 "avec état".]]
 +
</center>
  
−
[[Image:NAT64_4.png]]
+
Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 "à état" sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau "seulement IPv6" peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom.  La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').
  
−
[[Image:NAT64_5.png]]
+
<center>
 +
[[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]
 +
</center>
  
−
[[Image:NAT64_6.png]]
+
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).
 +
# Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).
  
−
[[Image:NAT64_7.png]]
 
  
−
= Conclusion =
+
<center>
−
* Avantages et inconvénients de ce mécanisme
+
[[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]
−
* Cas d'usage où ce mécanisme est pertinent (et où il ne l'est pas).
+
</center>
 +
 
 +
Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme "old.org" fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les  différentes étapes pour réaliser la connectivité entre le client et ce serveur :
 +
# Comme précédemment, le client va interroger son "résolveur" de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1).
 +
# Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.
 +
# Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3).
 +
# Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe <tt>64:ff9b::/96</tt> avec l'adresse IPv4 obtenue (étape 4).
 +
# Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme  adresse de destination, l'adresse ayant le préfixe <tt>64:ff9b::/96</tt>. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5).
 +
# Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence <tt>64:ff9b::/96</tt>. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état.  L'adresse IPv6 du client mobile doit être mise en correspondance avec  une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME.  On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6.  Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service "old.org" (étape 6).
 +
 
 +
Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article<ref>Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]</ref>.
 +
 
 +
== Conclusion ==
 +
 
 +
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.
 +
 
 +
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 ==
 +
<references />
 +
 
 +
== Pour aller plus loin ==
 +
 
 +
RFC et leur analyse par S. Bortzmeyer
 +
* RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]
 +
* RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]
 +
* RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]
 +
* RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]
 +
* RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]
 +
* RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]
 +
* RFC 6877 464XLAT: Combination of Stateful and Stateless Translation
 +
* RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
 +
* RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]
 +
* RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]
 +
* RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation
 +
* 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]
 +
<!--
 +
Limitations de la traduction
 +
{{TODO|Section à écrire}}
 +
(MTU/Fragmentation, Sécurité, Compatibilité des applications)
 +
--!>

Latest revision as of 10:58, 21 January 2024


Activité 43 : Interopérer les applications par traduction

Contexte d'utilisation de la traduction

Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : "tout le monde en IPv4" -> "certains réseaux en IPv4 seul et certains en IPv6 seul" -> "tout le monde en IPv6".

Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. Dans le cadre d'une communication "client vers serveur", il y aura donc 2 cas :

  1. Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;
  2. Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.

Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (Network Address Translator) utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple translation d'un espace d'adressage à un autre, mais une véritable traduction de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave[1] de l'IETF qui avait déjà publié des travaux pour le NAT44.

Figure 1 : Topologie d'utilisation du NAT64.

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 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.

Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP 3rd Generation Partnership Project) [2]. 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.


Principe de la traduction entre protocoles IP

La traduction entre protocoles IP comporte essentiellement deux composants[3] : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses "source" et "destination" du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.

Les traductions peuvent être faites "sans état" (stateless) RFC 7915 ou bien "avec état" (stateful) RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction "sans état", les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction "avec état", le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction "avec état" passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue "sans état", le composant de traduction des adresses fonctionne "avec" ou "sans état".

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 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 RFC 7915 section 4)

Champ de l'en-tête IPv4 Champ dans le nouvel en-tête IPv6 Valeur
Version Version 6
IHL Ignorer
Type Of Service Traffic Class Recopier
Flow label 0
Packet Length Payload Length Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)
Ident./Flag/Offset Extension Fragmentation Créer une extension de fragmentation à partir des valeurs IPv4
TTL Hop Limit Décrémenter de 1
Protocol Next Header Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).
Checksum Ignorer
Source Address Source Address Voir le paragraphe Traduction des adresses
Destination Address Destination Address Voir le paragraphe Traduction des adresses
Options IPv4 Les options IPv4 ne sont pas traduites.

Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4

Champ de l'en-tête IPv6 Champ dans le nouvel en-tête IPv4 Valeur
Version Version 4
IHL 5
Traffic Class Type of Service Recopier
IPv6 Flowlabel Ignorer
Payload Length Packet Length Payload Length + IHL
Ident./Flag/Offset 0
Hop Limit TTL Décrémenter de 1
Next Header Protocol Recopier. ICMPv6 (58) devient ICMPv4 (1)
Checksum Calculer une fois l'en-tête créé
Source Address Source Address Voir le paragraphe Traduction des adresses
Destination Address Destination Address Voir le paragraphe Traduction des adresses
Extensions IPv6 Les extensions d'en-tête IPv6 ne sont pas traduites.

Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6

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) 64:ff9b::/96 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.


Tolérance de notation (rappel)

Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 96 à 127), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse 2001:db8:900d:cafe::c0a8:a05 peut être notée 2001:db8:900d:cafe::192.168.10.5 lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) 2001:db8:900d:cafe::c0a8:a05 dans le journal de bord (log system) de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage. 


+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32|     prefix    |v4(32)         | u | suffix                    |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40|     prefix        |v4(24)     | u |(8)| suffix                |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48|     prefix            |v4(16) | u | (16)  | suffix            |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56|     prefix                |(8)| u |  v4(24)   | suffix        |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64|     prefix                    | u |   v4(32)      | suffix    |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96|     prefix                                    |    v4(32)     |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.

Traduction des adresses

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-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.

Figure 2 : Les adresses utilisées pour la traduction.

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 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 64:ff9b::/96 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 : 

IPv6  <-------> IPv4
pref64:H4        H4

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 : 

IPv6  --------------> IPv4
  H6  (état  H6->N4)  N4 
IPv6  <-------------  IPv4
  H6  (état  H6<-N4)  N4

La traduction avec état est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.

Mécanismes complémentaires

Traduction des paquets ICMP

Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges.

Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite sans état. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.

Le champ ICMP type devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages Echo Request et Reply sont identifiés par la valeur du champ ICMP type : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6.

La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ checksum doit donc être recalculé suite à la traduction.

Relais-traducteur DNS auxiliaire (RFC 6147)

Auto-découverte des préfixes de traduction

Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert de manière automatique selon une des deux méthodes suivantes :

  • déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis), complété par le RFC 8880 (Special Use Domain Name 'ipv4only.arpa' ) qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial ipv4only.arpa , sur lequel deux adresses IPv4 réservées 192.0.0.170 et 192.0.0.171 ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;
  • déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements).

Nota : Au moment de la rédaction de ce document, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, par contre Wireshark sait déjà le décoder.

L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:

  • il veut faire la validation DNSSEC ;
  • ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;
  • il ne fournit tout simplement pas de résolveur DNS64 ;
  • il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;
  • il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;

Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (DNS Application Layer Gateway : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi "forgée" à partir de l'adresse IPv4 du serveur est qualifiée IPv4-converted. Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. 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. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé DNS64.

La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 "IPv4-convertible" est le WKP (Well Known Prefix) de longueur 96 bits (64:ff9b::/96). 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 Préfixe) non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe.

Les opérations sont les suivantes :

  1. Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.
  2. Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.
  3. Le DNS64 reçoit une réponse à sa requête de type A.
  4. Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.
Figure 3 : Opérations du DNS64.

Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel Trick or Treat Deamon (TOTD) peut également être utilisé pour cet usage.

Mécanisme de transition NAT64/DNS64

NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne sans état ou avec état en fonction du mode de traduction de l'adresse "source" et de l'adresse "destination" du paquet reçu par le traducteur[4].

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é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.

Figure 4 : Type des adresses utilisées pour un NAT64 "sans état".

Du fait de son caractère "sans état", ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile[5]. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur "avec état".

NAT64 : traduction "avec état" RFC 6146

Décrit par le RFC 6146, le NAT64 "avec état" possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur "sans état" porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction "sans état". Comme le décrit la figure 5, le NAT64 "avec état" utilise à la fois une traduction "avec état" et une traduction "sans état". Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses "source" IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.

Figure 5 : Type des adresses utilisées pour un NAT64 "avec état".

Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 "à état" sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau "seulement IPv6" peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (Mobile Equipment) connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (Gateway GPRS Support Node).

Figure 6 : Accès à un serveur en IPv6.

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 :

  1. 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).
  2. 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).
  3. Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).


Figure 7 : Accès à un serveur en IPv4.

Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme "old.org" fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :

  1. Comme précédemment, le client va interroger son "résolveur" de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1).
  2. Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.
  3. Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3).
  4. Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe 64:ff9b::/96 avec l'adresse IPv4 obtenue (étape 4).
  5. Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe 64:ff9b::/96. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5).
  6. Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence 64:ff9b::/96. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (pool d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service "old.org" (étape 6).

Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article[6].

Conclusion

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[7], 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.

Références bibliographiques

  1. ↑ Bortzmeyer, S. (2008). Le groupe de travail BEHAVE de l'IETF
  2. ↑ 3GPP 3rd Generation Partnership Project 3GPP
  3. ↑ Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. The NAT64/DNS64 tool suite for IPv6 transition
  4. ↑ Cisco. (2011). White paper. NAT64—Stateless versus Stateful
  5. ↑ Pepelnjak, I. (2011). Blog IP space. Stateless NAT64 is useless
  6. ↑ Cisco. (2012). White paper. NAT64 Technology: Connecting IPv6 and IPv4 Networks
  7. ↑ Boucadair, M.; Binet, D. et Jacquenet, C. (2011). Techniques de l'ingénieur. Transition IPv6 - Outils et stratégies de migration

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer

  • RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators Analyse
  • RFC 6144 Framework for IPv4/IPv6 Translation Analyse
  • RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Analyse
  • RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Analyse
  • RFC 6269 Issues with IP Address Sharing Analyse
  • RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion Analyse
  • RFC 6877 464XLAT: Combination of Stateful and Stateless Translation
  • RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
  • RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Analyse
  • RFC 7269 NAT64 Deployment Options and Experience Analyse
  • RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation
  • RFC 7915 IP/ICMP Translation Algorithm Analyse
  • RFC 8106 IPv6 Router Advertisement Options for DNS Configuration Analyse
  • RFC 8781 Discovering PREF64 in Router Advertisements Analyse
  • RFC 8880 Special Use Domain Name 'ipv4only.arpa' Analyse
Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&oldid=20585"
Personal tools