|
|
| (8 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | > [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]] >[[MOOC:Sequence_4|Séquence 4]] > Document compagnon
| |
| − | ----
| |
| − | = Intégration d'IPv6 à l'Internet actuel =
| |
| | | | |
| − |
| |
| − | <!-- ----------------------------------------- -->
| |
| − | == <div id="why">I/ Pourquoi utiliser IPv6 ? </div> ==
| |
| − | <!-- ----------------------------------------- -->
| |
| − | [[MOOC:Compagnon_Act41]]
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − | == <div id="scenario"> II/ Quel scénario pour le déploiement ? </div> ==
| |
| − | <!-- ----------------------------------------- -->
| |
| − | [[MOOC:Compagnon_Act42]]
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − | ==<div id="DeployerIPv6">III/ Activer IPV6 dans son infrastructure </div>==
| |
| − | <!-- ----------------------------------------- -->
| |
| − | [[MOOC:Compagnon_Act43]]
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − | == <div id="connectivité">IV/ Etablir la connectivité IPv6 </div> ==
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − | [[MOOC:Compagnon_Act44]]
| |
| − |
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − | == <div id="interopéré">V/ Interopérabilité avec les services de l'Internet IPv4 </div>==
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − |
| |
| − | ===<div id="ALG">Relais applicatifs</div>===
| |
| − |
| |
| − | Les relais applicatifs ou ALG (''Application Level Gateway'') représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.
| |
| − |
| |
| − | Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.
| |
| − |
| |
| − | L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
| |
| − |
| |
| − | [[image:CS186.gif]]
| |
| − |
| |
| − | Les relais applicatifs regroupent :
| |
| − |
| |
| − | * les proxies et les caches web,
| |
| − | * les spoolers d'impression,
| |
| − | * les serveurs de courrier électronique,
| |
| − | * les serveurs DNS,
| |
| − | * ...
| |
| − |
| |
| − | ====Configuration d'un relais applicatif pour le Web====
| |
| − |
| |
| − | Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.
| |
| − |
| |
| − | #cat /usr/local/etc/apache/httpd.conf
| |
| − | #
| |
| − | # Proxy Server directives. Uncomment the following lines to
| |
| − | # enable the proxy server:
| |
| − | #
| |
| − | <IfModule mod_proxy.c>
| |
| − | ProxyRequests On
| |
| − | <Directory proxy:*>
| |
| − | Order deny,allow
| |
| − | Allow from all
| |
| − | </Directory>
| |
| − | #
| |
| − | # Enable/disable the handling of HTTP/1.1 "Via:" headers.
| |
| − | # ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
| |
| − | # Set to one of: Off | On | Full | Block
| |
| − | #
| |
| − | ProxyVia On
| |
| − | </IfModule>
| |
| − | # End of proxy directives.
| |
| − |
| |
| − |
| |
| − | ===<div id="NAT64">NAT64/DNS64</div>===
| |
| − | RFC 6146
| |
| − |
| |
| − | Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-64 permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-64 sont des routeurs réalisant la traduction des paquets IPv6 émis par des clients en paquets IPv4 pour des serveurs.
| |
| − |
| |
| − |
| |
| − | Le principe de fonctionnement de NAT64 pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses sous forme de données. Par contre, ce mécanisme offre une certaine transparence au niveau des clients IPv6.
| |
| − |
| |
| − |
| |
| − | <!-- ----------------------------------------- -->
| |
| − | == <div id="conlusion4">Conclusion </div>==
| |
| − | <!-- ----------------------------------------- -->
| |
| − |
| |
| − | === Etat de la standardisation à l'IETF ===
| |
| − |
| |
| − |
| |
| − | ====Working Group ngtrans : approche "boite à outils"====
| |
| − |
| |
| − | D'une façon générale, l'une des clés de l'adoption d'une nouvelle technologie repose sur la facilité avec laquelle il est possible d'abandonner l'ancienne au profit de la nouvelle. Aussi, le groupe de travail IETF ngtrans a été créé, dès l'origine et en parallèle du groupe de travail IETF ipng, pour traiter des aspects liés à la transition des réseaux et applications d'IPv4 vers IPv6. La principale contrainte à respecter étant qu'il ne doit pas y avoir de jour J pour le basculement de l'ensemble de l'Internet vers IPv6 (à l'image du passage à l'an 2000 par exemple), et qu'au contraire il doit être possible de passer graduellement et progressivement d'IPv4 à IPv6, à tout moment et indépendamment de l'infrastructure réseau considérée.
| |
| − |
| |
| − | Ngtrans a donné le jour à nombre de mécanismes de transition, permettant chacun de résoudre une problématique de transition particulière (interconnexion de réseaux IPv6 isolés, communication entre applications IPv4 et IPv6, transport de flux IPv6 dans les réseaux IPv4, etc...). Finalement une boîte à outils très complète a été définie, apportant des solutions a un vaste ensemble problèmes liés à la transition, soit localement à un terminal, soit plus globalement à l'échelle d'un réseau ou même de l'Internet dans son ensemble.
| |
| − |
| |
| − | Cette mission remplie pour sa majeure partie, le groupe de travail ngtrans a finalement été clos pour laisser la place à IPv6ops traitant plus globalement de l'ensemble des aspects opérationnels liés au déploiement d'IPv6. En outre, il a souvent été reproché à ngtrans d'avoir spécifié une large boîte à outils sans en avoir décrit le mode d'emploi, et sans discernement des cas de transition concrets ou théoriques. Ainsi l'adoption d'IPv6 aurait été rendue en apparence plus complexe, contrairement au but initialement recherché.
| |
| − |
| |
| − | ====Working Group IPv6ops : de la transition à la coexistence (déploiement opérationnel)====
| |
| − |
| |
| − | Au-delà de la critique faite à ngtrans et qui est encore aujourd'hui matière à débats, le groupe de travail IPv6ops (IPv6 operations), créé en septembre 2002, s'inscrit dans une dynamique nouvelle visant à traiter de l'ensemble des problèmes opérationnels liés au déploiement d'IPv6. Fort du principe selon lequel le passage d'IPv4 à IPv6 ne peut se réaliser que progressivement selon les infrastructures concernées et graduellement dans le temps, et sur la base du constat de l'absence d'imminence véritable d'une pénurie d'adresses IPv4, la transition IPv4/IPv6 devient essentiellement une question de coexistence des deux versions du protocole IP. Entre autres, l'approche en scénarios d'intégration d'IPv6 à l'existant, initialisée par ngtrans, est reprise par IPv6ops et se trouve déclinée selon quatre grandes familles : les réseaux de "mobiles" (UMTS, 3G), les réseaux d'ISP, les réseaux d'entreprise et les réseaux SOHO/domestiques. Cette approche en scénarios, a été achevée fin 2004, selon les objectifs fixés actuellement par le groupe IPv6ops.
| |
| − |
| |
| − | === Utilisation des mécanismes d'intégration d'IPv6===
| |
| − |
| |
| − | Les principaux mécanismes d'intégration d'IPv6 -aussi dénommés mécanismes de transition- spécifiés par l'IETF sont regroupés dans le tableau ci-dessous. Leur utilisation possible dans différents segments du réseau est mentionnée. La difficulté est de pouvoir distinguer les différents usages de ces mécanismes, par exemple la fonction de serveur du tunnel broker, installée dans le réseau de l'ISP, et la fonction client de ce service installée chez un usager -entreprise ou particulier. Cette distinction est détaillée dans le paragraphe où le mécanisme est décrit (cf. tableau Mécanismes de transition).
| |
| − |
| |
| − | {|
| |
| − | |+ '''''Mécanismes de transition'''''
| |
| − | |-style="background:silver"
| |
| − | !Mécanismes de transition !! Coeur de réseau !! ISP !! Entreprises !! Particuliers
| |
| − | |-
| |
| − | |[[Déploiement d'IPv6 et mécanismes d'intégration#Double Pile|Double pile]] || X || X || X || X
| |
| − | |-style="background:silver"
| |
| − | |[[Déploiement d'IPv6 et mécanismes d'intégration#6PE (MPLS)|6PE (MPLS)]] || X || X || X ||
| |
| − | |-
| |
| − | |[[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]] || || X || X || X
| |
| − | |-style="background:silver"
| |
| − | |[[Déploiement IPv6 des fournisseurs d'accès (ISP)#Tunnel Broker|Tunnel Broker]] || || X || X || X
| |
| − | |-
| |
| − | |[[Tunnels configurés]] || ? || X || X || X
| |
| − | |-style="background:silver"
| |
| − | |[[Déploiement IPv6 des fournisseurs d'accès (ISP)#TSP : tunnel setup protocol|TSP]] || || X || X || X
| |
| − | |-
| |
| − | |[[Accès des entreprises et des particuliers à l'Internet IPv6#ISATAP|ISATAP]] || || || X ||
| |
| − | |-style="background:silver"
| |
| − | |[[Accès des entreprises et des particuliers à l'Internet IPv6#TOREDO|TEREDO]] || || X || X || X
| |
| − | |-
| |
| − | |[[Mécanismes d'interopérabilité#relais|Relais applicatifs]] || || X || X || X
| |
| − | |-style="background:silver"
| |
| − | |[[Mécanismes d'interopérabilité#NAT-PT|NAT-PT]] || || X || X || X
| |
| − | |-
| |
| − | |[[Mécanismes d'interopérabilité#DSTM|DSTM]] || || X || X || X
| |
| − | |-style="background:silver"
| |
| − | |[[Mécanismes d'interopérabilité#SOCKS|SOCKS]] || || || X || X
| |
| − | |-
| |
| − | |[[VPN]] || || X || X || X
| |
| − | |-style="background:silver"
| |
| − | |[[L2TP]] || || X || X || X
| |
| − | |}
| |
