Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Pourquoi vos considérations opérationnelles pour IPv6 Les en-têtes d'extension ne fonctionnent jamais comme vous le prévoyez

Publié le
Print Friendly, PDF & Email

 

IPv6 En-têtes d'extensionIPv6 En-têtes d'extension

IPv6 Les en-têtes d'extension ont fait partie du noyau IPv6 spécification comme détaillé dans RFC8200. Ils offrent des informations supplémentaires sur IPv6 paquets sur la façon dont ils sont traités ou acheminés, comme les options saut par saut. L'en-tête Options saut par saut n'est ni inséré ni supprimé.

Néanmoins, il peut être examiné ou traité par n'importe quel nœud le long du chemin de livraison d'un paquet jusqu'à ce que le paquet atteigne le nœud (ou chacun de l'ensemble de nœuds, dans le cas de la multidiffusion) identifié dans le champ Adresse de destination. IPv6 en-tête.

L'en-tête Options saut par saut, lorsqu'il est présent, doit suivre immédiatement le IPv6 entête. Sa présence est indiquée par la valeur zéro dans le champ En-tête suivant du IPv6 en-tête (extrait de RFC 8200).

Leurs implémentations dans plusieurs IPv6 les déploiements ont conduit à de nombreux problèmes de sécurité tels que le 'Logiciel Cisco IOS IPv6 Vulnérabilité de déni de service du réassemblage de la fragmentation virtuelle' ou alors IPv6 Options hop-by-hop utilisation-après-libre.

 

L'IETF travaille sur IPv6 En-têtes d'extension

Plusieurs IPv6 les ingénieurs se sont réunis pour écrire le 'Implications opérationnelles de IPv6 Paquets avec en-têtes d'extension

Le document met en évidence les problèmes concernant IPv6 En-têtes d'extension et pourquoi ils sont supprimés intentionnellement sur l'Internet public.

 

Contraintes de transfert de paquets

De nombreux routeurs grand public ont des limitations concernant la longueur de l'en-tête IP qu'ils peuvent traiter. Avec IPv6 En-têtes d'extension, cela peut conduire à une réduction du débit ou simplement à la suppression de paquets.

 

Partage de charge ECMP et basé sur le hachage

De nombreux routeurs doivent déduire plus d'informations sur la façon de faire le partage de charge. le IPv6 L'en-tête d'étiquette de flux serait utile à cette fin car il éviterait d'avoir à traiter plusieurs IPv6 En-têtes d'extension avant de prendre une décision.

Malheureusement, de nombreux routeurs (environ 20 à 30%) déployés ne pas utiliser le IPv6 en-tête d'étiquette de flux correctement, et donc, IPv6 Les en-têtes d'extension sont souvent supprimés dans ces cas.

 

Problèmes de sécurité avec IPv6 En-têtes d'extension

De nombreux routeurs ont une politique de refus par défaut dans les opérations de sécurité. Cela signifie que IPv6 Les en-têtes d'extension sont souvent supprimés par défaut. De plus, lorsque des listes de contrôle d'accès sont définies, elles le sont souvent d'une manière où IPv6 Les en-têtes d'extension peuvent provoquer un contournement de sécurité. Par conséquent, pour des raisons de sécurité, ils sont généralement supprimés. De plus, en raison des exigences de traitement de ces en-têtes supplémentaires, de nombreux pare-feu préfèrent les supprimer car ils peuvent être utilisés comme vecteur de déni de service.

 

Conclusion

Le IETF draft sur les `` Implications opérationnelles de IPv6 Packets with Extension Headers 'offre une excellente discussion approfondie aux ingénieurs réseau sur les implications de IPv6 extensions côté opération.

Dans ce blog, nous avons donné un aperçu aux ingénieurs réseaux et systèmes. Nous encourageons les lecteurs à parcourir Internet-Draft et, si possible, proposer des suggestions au Groupe de travail IETF v6ops

 

 

 


 

blog de Logan A propos Auteur

Logan Velvindron
Ingénieur Sécurité Infrastructure 

Il expérimente de nouvelles technologies de sécurité qui ont une valeur commerciale. De plus, il contribue au groupe de travail sur l'ingénierie Internet à la fois en tant que développeur de spécifications, membre de la Direction de la zone de sécurité / Internet des objets et président du groupe de travail. Il a géré et dirigé plusieurs hackathons de l'IETF lors des deux Sommet de l'Internet africain et des réunions de l'IETF. 

 

 

 

 

Dernière modification le -
Date et heure à Maurice -