Déploiement résiduel IPv4 – Wikipedia wiki

Déploiement résiduel IPv4 ( 4e ) est un mécanisme de transition IPv6 pour les fournisseurs de services Internet pour le déploiement de la version 6 du protocole Internet (IPv6), tout en conservant le service IPv4 aux clients. Le protocole et les applications d’échantillons sont spécifiés dans RFC 7600.

Caractéristiques [ modifier ]]

Le déploiement résiduel IPv4 a trois fonctionnalités principales:

• Topologie en maillage: entre deux points de terminaison, les paquets IPv4 prennent la même chose routes directes comme paquets IPv6. ^[d’abord]
• Adresses IPv4 partagées: Pour gérer la pénurie d’adresse IPv4 inévitable, plusieurs clients peuvent se voir attribuer une adresse IPv4 courante, avec des ensembles de ports TCP / UDP disjoints affectés à chacun (une application du modèle général A + P de RFC 6346).
• Fonctionnement sans état: les conversions des paquets IPv4 en paquets IPv6 à l’entrée du domaine et l’inverse à la sortie du domaine sont apatrides (c’est-à-dire où un où un où vous pas d’état par client est nécessaire dans les nœuds de bord de domaine).

Par rapport à d’autres mécanismes spécifiés par l’IETF ayant les mêmes caractéristiques principales, c’est-à-dire MAP-E (RFC 7597, RFC 7598, RFC 2473) et MAP-T (RFC 7599, RFC 7598, RFC 6145), sa propriété distinctive est qu’il est qu’il est simultanément les soutiens:

• Transparence complète de la fragmentation IPv4: avec cette fonctionnalité, la prise en charge du chemin MTU découverte de RFC 4821, recommandée dans RFC 6349, est préservée. Sans cela, partout où les pare-feu filtrent les paquets ICMP, les systèmes finaux qui prennent en charge RFC 4821 ^[2] perdre leur capacité à Profitez des chemins qui prennent en charge les gros paquets .
• Applicabilité des inspections de paquets IPv6 à IPv4: Lors de la traversée des domaines IPv6 uniquement, les paquets IPv4 convertis sont des paquets IPv6 ordinaires, avec leur contenu inchangé et valide dans IPv6. ^[3] Ainsi, les filtres IPv6 qui sont effectués dans le domaine IPv6 uniquement, par ex. pour Listes de contrôle d’accès, caches Web, inspections de paquets profonds sont, implicitement et automatiquement, efficaces sur les paquets IPv4 de transfert de domaine.

MAP-E ne prend en charge que le premier, et MAP-T ne prend en charge que le second.

Si un FAI souhaite offrir un service IPv4 résiduel sur un domaine IPv6 uniquement et fournit des équipements de prémisse client à tous ses clients de ce domaine, il peut choisir n’importe lequel de MAP-E, MAP-T ou 4e, avec une conscience dûment que MAP-E et MAP-T sont spécifiés dans les RFC de track standards, tandis que le 4RD est, au moins jusqu’à présent, spécifié dans un RFC de piste expérimentale (voir la section historique ci-dessous): le mécanisme choisi reste purement interne à chaque domaine.

Des principes [ modifier ]]

La clé qui permet de combiner la transparence iPv4-fragmentation avec l’inspection de paquets profonds IPv6 dans une seule conception est l’utilisation d’un traduction de paquets réversible Aux entrées et sorties de domaine. ^[3] Cela est possible car les en-têtes de paquets IPv6, dûment complétés par leurs en-têtes de fragment chaque fois que nécessaire, sont suffisamment grands pour y coder, d’une manière ad hoc détaillée dans RFC 7600, toutes les informations utiles de tête IPv4. (Ce n’était pas possible en 6e, le mécanisme de tunneling pour IPv6 dans les domaines IPv4 uniquement, car les en-têtes IPv4 sont trop petits pour contenir toutes les informations IPv6-Header).

Les options de couches IP de l’IPv4 ne sont pas prises en charge dans le 4e, mais sans conséquence pratique car les systèmes finaux sont déjà adaptés au fait que, pour des raisons de sécurité, les options IP-couche IP sont filtrées par de nombreux routeurs. ^[4]

Un autre problème sur lequel la spécification 4e va au-delà de celles de Map-E et MAP-T concerne des datagrammes IPv4 fragmentés. Dans les spécifications MAP-E et MAP-T, les seuls comportements entièrement décrits impliquent le réassemblage de Datagram à l’entrée du domaine avant le transfert. ^{[5] [6]} Afin d’améliorer les performances perçues par l’utilisateur, de réduire le traitement de l’entrée du domaine et de réduire les opportunités d’attaque, la spécification 4e comprend un algorithme par lequel les fragments de grandes datagrammes sont transmis un par un. ^[7]

Histoire [ modifier ]]

La première spécification “4rd”, contrairement à la courante de RFC 7600, a utilisé l’encapsulation IPv4 dans les paquets IPv6, la seule approche de tunnelisation connue à l’époque pour assurer une conservation IPv4 complète dans les domaines IPv6 uniquement.
C’était la première proposition qui combinait la cartographie d’adresse sans état, la topologie en maillage et A + P. ^{[8] [9]}

Une autre approche sans état Mesh-A + P a ensuite été proposée, appelée Divi. ^[dix] Au lieu de l’encapsulation, il a utilisé deux traductions successives (de l’IPv4 à IPv6 puis à l’inverse), sur la base des traductions unidirectionnelles SIIT existantes de RFC 2765.
Par rapport à l’encapsulation, il avait l’avantage de rendre les inspections de paquets IPv6 applicables aux paquets UDP et TCP IPv4 traduits, mais, en raison des limites de Siit, manquait de compatibilité complète avec la fragmentation IPv4 (et par conséquent, comme mentionné ci-dessus, la compatibilité avec le chemin MTU Discover dans RFC 6349).

Dans ce contexte, l’approbation de l’une des deux conceptions en tant que seule norme semblait hors de portée, malgré le souhait général de l’UNICITy standard.
Deux directions différentes ont ensuite été prises.

• Un proposé pour renommer la 4e solution d’encapsulation comme Map-e , pour renommer la double traduction SIIT comme Map-t et pour les associer à une spécification combinée nommée CARTE . ^[11] L’idée était que, pour satisfaire l’objectif standard de l’UNICIT, une spécification ayant deux variantes (parmi lesquelles un choix reste nécessaire pour chaque domaine IPv6 uniquement), pourrait être considéré comme équivalent à une seule norme. Mais aucun consensus n’a été atteint sur cette interprétation. ^[douzième]
• L’autre était basée sur la découverte que, comme mentionné ci-dessus, un algorithme de double traduction IPv4-IPV6 mis à niveau était possible qui a combiné l’applicabilité des inspections de paquets IPv6 à IPv4, comme MAP-T et une compatibilité complète avec la fragmentation IPv4 comme MAP-E. Comme l’acronyme “4rd” n’était plus utilisé pour la solution d’encapsulation, cette solution a été nommée 4e . Une proposition pour adopter cette approche pour une norme unique a été faite. ^[13] Mais, malgré une validation de son principe sur une mise en œuvre, ^[14] n’a pas suscité l’intérêt des partisans de MAP-E ou MAP-T. ^[douzième]

Après un long débat, le groupe de travail des softwire ^[15] a décidé, en août 2012, que la carte-E serait standardisée, et ce travail pourrait se poursuivre sur le 4e et le MAP-T, mais uniquement comme expérimental. ^[douzième]

Enfin, en décembre 2014, le groupe de travail Softwire ^[15] a changé sa décision précédente et a décidé de placer MAP-T sur les normes en parallèle avec MAP-E, a fourni une note dans le MAP-T RFC signalerait son incompatibilité avec la découverte MTU du chemin de RFC 4821. ^[16]

Ce reste 4e Seul dans la catégorie expérimentale (pourtant avec la possibilité des FAI de le déployer, pour ses avantages fonctionnels, dans des domaines où ils fournissent un équipement de locaux clients à tous leurs clients).

Déploiement du monde réel [ modifier ]]

L’ISP français libre est réputé avoir déployé 4e pour son expérience de FTTH dans des “zones moins denses”, à partir de décembre 2015. L’implémentation du modèle A + P implique l’attribution de quatre gammes de ports contiguës à différents clients pour chaque IPV4 adresse. Free était également connu pour être le premier implémentateur du 6e. ^[17]

Les références [ modifier ]]