Difference between revisions of "MOOC:Archive4"
From Livre IPv6
(→Conclusion) |
|||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | === 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 | ||
+ | |} |
Latest revision as of 06:50, 23 April 2019
Contents
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 | Coeur de réseau | ISP | Entreprises | Particuliers |
---|---|---|---|---|
Double pile | X | X | X | X |
6PE (MPLS) | X | X | X | |
6to4 | X | X | X | |
Tunnel Broker | X | X | X | |
Tunnels configurés | ? | X | X | X |
TSP | X | X | X | |
ISATAP | X | |||
TEREDO | X | X | X | |
Relais applicatifs | X | X | X | |
NAT-PT | X | X | X | |
DSTM | X | X | X | |
SOCKS | X | X | ||
VPN | X | X | X | |
L2TP | X | X | X |