|
|
| Line 1: |
Line 1: |
| − | == Contexte d'utilisation de la traduction d'entête IP ==
| |
| | | | |
| − | 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, 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.
| |
| − | Dans le cadre de 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 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.
| |
| − |
| |
| − | 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.
| |
| − |
| |
| − | == Principe de la traduction d'entête IP ==
| |
| − |
| |
| − | Il faut ici bien situé le problème : le relai recevant 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 proches (TTL/Hop limit, DiffServ, Payload Length). Pour ces derniers, la transposition est évidente. Le tableau ci-dessous résume 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])
| |
| − |
| |
| − | {| border="1" cellpadding="10" cellspacing="0"
| |
| − | ! Champ
| |
| − | ! IPv4 vers IPv6
| |
| − | ! IPv6 vers IPv4
| |
| − | |-
| |
| − | ! Version
| |
| − | | Changer la valeur de 4 à 6
| |
| − | | Changer la valeur de 6 à 4
| |
| − | |-
| |
| − | ! IPv4 IHL
| |
| − | | Vérifier s'il y a des options
| |
| − | | Fixer à 20, ou plus si besoin d'options
| |
| − | |-
| |
| − | ! IPv6 Flowlabel
| |
| − | | Pas de correspondance, mettre à 0
| |
| − | | Ignorer ce champs
| |
| − | |-
| |
| − | ! Packet/Payload Length
| |
| − | | Si pas de fragmentation, transposer
| |
| − | | Si pas de fragmentation, transposer
| |
| − | |-
| |
| − | ! IPv4 Ident./Flag/Offset
| |
| − | | Réassembler ou créer une extension de fragmentation
| |
| − | | Réassembler ou renseigner ces champs en fonction de l'extension de fragmentation
| |
| − | |-
| |
| − | ! TTL / Hop Limit
| |
| − | |
| |
| − | |
| |
| − | |-
| |
| − | ! Protocol / Next Header
| |
| − | |
| |
| − | |
| |
| − | |-
| |
| − | ! Checksum
| |
| − | |
| |
| − | |
| |
| − | |-
| |
| − | ! Source Address
| |
| − | |
| |
| − | |
| |
| − | |-
| |
| − | ! Destination Address
| |
| − | |
| |
| − | |
| |
| − | |-
| |
| − | ! IPv6 Extensions
| |
| − | |
| |
| − | |
| |
| − | |}
| |
| − |
| |
| − |
| |
| − |
| |
| − | Traduction des adresses
| |
| − |
| |
| − | Utilité du DNS64
| |
| − |
| |
| − | Statefull / Stateless ?
| |
| − |
| |
| − | Problèmes pouvant intervenir (MTU/Fragmentation)
| |
| − |
| |
| − | == Architecture d'un déploiement NAT64/DNS64 ==
| |
| − |
| |
| − | Positionnement des 2 dispositifs dans l'architecture réseau
| |
| − |
| |
| − | Routage et adressage nécessaire
| |
| − |
| |
| − | == Exemples de fonctionnement ==
| |
| − |
| |
| − | Reprise du réseau mobile.
| |
| − |
| |
| − | [[Image:NAT64_1.png]]
| |
| − |
| |
| − | [[Image:NAT64_2.png]]
| |
| − |
| |
| − | [[Image:NAT64_3.png]]
| |
| − |
| |
| − | [[Image:NAT64_4.png]]
| |
| − |
| |
| − | [[Image:NAT64_5.png]]
| |
| − |
| |
| − | [[Image:NAT64_6.png]]
| |
| − |
| |
| − | [[Image:NAT64_7.png]]
| |
