Format d'en-tête IPv6 : Structure, champs et en-têtes d'extension

Pourquoi IPv6 a modifié l'en-tête#

L'en-tête IPv4 a grandi organiquement sur plusieurs décennies. Des options ont été ajoutées, des champs ont été réutilisés, et à la fin vous aviez un en-tête de longueur variable avec 14 champs différents (certains optionnels) et une structure complexe que les routeurs devaient analyser soigneusement à chaque saut.

IPv6 a adopté une approche différente : longueur fixe, simplifié et optimisé pour le transfert rapide. L'en-tête de base fait toujours exactement 40 octets, avec 8 champs bien définis. Pas d'options de longueur variable, pas de somme de contrôle d'en-tête, pas de champs de fragmentation dans l'en-tête principal.

Le résultat est un en-tête que les routeurs peuvent traiter plus rapidement, qui est plus facile à implémenter en matériel et qui supporte l'extension sans rompre la rétrocompatibilité. Comprendre l'en-tête IPv6 signifie comprendre pourquoi il est construit ainsi et quels compromis les concepteurs ont faits.

L'en-tête de base de 40 octets#

Chaque paquet IPv6 commence par exactement 40 octets dans ce format :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Taille fixe. Pas d'options dans l'en-tête de base. Chaque routeur sait exactement où se trouve chaque champ sans analyse.

Les huit champs#

Examinons chaque champ dans l'ordre où les routeurs les traitent généralement.

1. Version (4 bits)#

Toujours 6 pour les paquets IPv6. Toujours 4 pour les paquets IPv4. C'est ainsi que les appareils distinguent IPv6 d'IPv4 sur le fil.

Implication pratique : Les systèmes dual-stack regardent ces 4 bits en premier pour déterminer comment analyser le reste du paquet.

Version = 6 (binaire: 0110)

Simple, immuable et critique pour l'identification du protocole.

2. Traffic Class (8 bits)#

Auparavant appelé « Priorité » dans les premières spécifications IPv6, ce champ marque les paquets pour le traitement de la qualité de service (QoS). Il remplit le même objectif que le Type de Service (ToS) ou le Differentiated Services Code Point (DSCP) d'IPv4.

Structure :

• Bits 0-5 : DSCP (Differentiated Services Code Point)
• Bits 6-7 : ECN (Explicit Congestion Notification)

Valeurs DSCP courantes :

ECN permet aux routeurs de signaler la congestion sans abandonner les paquets. Il est utilisé par les implémentations TCP modernes pour un meilleur contrôle de la congestion.

Exemple :

Traffic Class = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (Non capable ECN)

Les routeurs qui prennent en charge QoS examinent ce champ pour prioriser les paquets. La VoIP obtient une priorité plus élevée que les téléchargements de fichiers. La vidéo en temps réel reçoit un meilleur traitement que l'email.

3. Flow Label (20 bits)#

L'une des fonctionnalités les plus intéressantes mais sous-utilisées d'IPv6. Le Flow Label identifie les paquets qui appartiennent au même flux et doivent recevoir un traitement de routage identique.

Objectif :

• Permettre aux routeurs d'identifier les paquets liés sans examiner les en-têtes de couche supérieure
• Prendre en charge le transfert rapide pour les flux connus
• Fournir un handle pour QoS par flux

Spécification (RFC 6437) :

• Valeur 0 : Paquet ne fait pas partie d'un flux
• Valeur 1-0xFFFFF : Identifiant de flux (choisi aléatoirement par la source)
• Doit être cohérent pour tous les paquets d'un flux
• Devrait être pseudo-aléatoire pour permettre le hachage du routeur

Ce qui constitue un flux :

• Source + Destination + Flow Label l'identifie de manière unique
• Tous les paquets dans une connexion TCP pourraient utiliser le même Flow Label
• Ou chaque flux vidéo pourrait obtenir une étiquette unique

Utilisation pratique :

De nombreuses implémentations définissent Flow Label à 0 car :

• Le matériel nécessaire pour hacher/transférer basé sur Flow Label n'est pas universel
• Le support applicatif est limité
• C'est optionnel et zéro fonctionne bien

Mais lorsqu'il est utilisé correctement, Flow Label permet :

• L'équilibrage de charge sur les routes ECMP (Equal Cost Multi-Path)
• L'ingénierie de trafic par flux
• Le transfert rapide matériel

Exemple de configuration de Flow Label (Linux) :

# Activer les labels de flux automatiques
sysctl -w net.ipv6.auto_flowlabels=1
 
# Les labels de flux seront définis en fonction du hachage 5-tuple

Linux génère automatiquement des labels de flux pour les connexions TCP lorsqu'activé, en utilisant un hachage de l'adresse source/destination et des ports.

4. Payload Length (16 bits)#

Longueur de la charge utile du paquet en octets, excluant l'en-tête de base de 40 octets.

Plage : 0 à 65 535 octets

Détails importants :

• Inclut les en-têtes d'extension (le cas échéant) plus les données de couche supérieure
• N'inclut PAS l'en-tête IPv6 de base de 40 octets
• La valeur maximale 65 535 signifie que la taille maximale du paquet est de 65 575 octets (65 535 + 40)

Cas spécial : Jumbograms

Pour les paquets supérieurs à 65 535 octets, Payload Length est défini à 0 et un en-tête d'extension Hop-by-Hop avec l'option Jumbogram porte la longueur réelle (jusqu'à 4 294 967 295 octets).

Les Jumbograms sont rares. Ils sont utilisés sur des réseaux haute performance spécialisés avec support de trame jumbo, typiquement sur des liens 10 Gbps+.

Exemple :

Payload Length = 1440 octets
  En-tête IPv6 de 40 octets (non compté)
  Charge utile de 1440 octets (en-tête TCP + données)
  Paquet total = 1480 octets

5. Next Header (8 bits)#

Identifie le type d'en-tête suivant immédiatement l'en-tête IPv6. C'est ainsi que les en-têtes d'extension et les protocoles de couche supérieure sont spécifiés.

Valeurs courantes :

Comment fonctionne le chaînage :

Chaque en-tête d'extension contient son propre champ Next Header, formant une chaîne :

En-tête IPv6 (Next Header = 0)
  -> Hop-by-Hop Options (Next Header = 43)
    -> Routing Header (Next Header = 6)
      -> En-tête TCP
        -> Données

L'hôte récepteur traite les en-têtes dans l'ordre jusqu'à ce qu'il atteigne le protocole de transport (TCP/UDP) ou les données.

Exemple sans en-têtes d'extension :

Next Header = 6 (TCP)
  En-tête IPv6 directement suivi de l'en-tête TCP

Exemple avec en-têtes d'extension :

Next Header = 44 (Fragment)
  En-tête IPv6 suivi de l'en-tête Fragment (Next Header = 6)
    En-tête Fragment suivi de l'en-tête TCP

6. Hop Limit (8 bits)#

Le nombre de sauts de routeur restants avant que le paquet ne soit abandonné. Chaque routeur le décrémente de 1. Quand il atteint 0, le routeur abandonne le paquet et envoie un message ICMPv6 Time Exceeded.

Plage : 0-255

C'est l'équivalent IPv6 du champ TTL (Time To Live) d'IPv4, mais le nom est plus précis — il compte les sauts, pas le temps.

Valeurs initiales courantes :

Pourquoi les valeurs différentes comptent pour l'empreinte digitale :

Vous pouvez deviner l'OS source en regardant le Hop Limit dans les paquets reçus :

Hop Limit reçu: 56
  56 + 8 sauts = 64 (probablement Linux/BSD)
 
Hop Limit reçu: 117
  117 + 11 sauts = 128 (probablement Windows)

Traceroute utilise Hop Limit :

Traceroute fonctionne en envoyant des paquets avec des valeurs de Hop Limit incrémentales :

• Hop Limit 1 : Le premier routeur répond avec Time Exceeded
• Hop Limit 2 : Le deuxième routeur répond avec Time Exceeded
• Hop Limit 3 : Le troisième routeur répond avec Time Exceeded
• ...jusqu'à ce que la destination soit atteinte

Considération de sécurité :

Certaines attaques utilisent de faibles Hop Limits pour faire expirer les paquets avant d'atteindre les systèmes IDS/IPS. Les pare-feu appliquent parfois des valeurs minimales de Hop Limit pour le trafic entrant.

Exemple :

Hop Limit = 64
  Le routeur 1 reçoit, décrémente à 63, transfère
  Le routeur 2 reçoit, décrémente à 62, transfère
  ...
  Le routeur 64 reçoit, décrémente à 0, abandonne et envoie ICMPv6 Type 3

7. Source Address (128 bits)#

L'adresse IPv6 de l'expéditeur du paquet. Toujours 128 bits, sans exceptions.

Format : Notation d'adresse IPv6 standard

2001:db8:1234:5678:9abc:def0:1234:5678

Considérations spéciales :

L'adresse non spécifiée (::) n'est valide que dans des cas spécifiques :

• Duplicate Address Detection (DAD)
• Requêtes DHCP avant l'attribution d'adresse
• Certains messages ICMPv6

Les adresses link-local (fe80::/10) sont des adresses source valides mais uniquement sur le lien local. Les routeurs ne transfèrent pas les paquets avec des sources link-local.

Les adresses multicast ne sont jamais des adresses source valides. Un paquet avec une source multicast devrait être abandonné immédiatement.

Problème pratique : sélection d'adresse source

Lorsqu'un hôte a plusieurs adresses IPv6 (courant avec SLAAC, DHCPv6 et extensions de confidentialité), il doit choisir laquelle utiliser comme source. La RFC 6724 définit l'algorithme de sélection, préférant :

1. Même portée d'adresse que la destination
2. Adresses avec un préfixe correspondant plus long
3. Adresses non dépréciées
4. Adresses avec une préférence plus élevée

8. Destination Address (128 bits)#

L'adresse IPv6 du destinataire prévu du paquet. Comme Source Address, toujours 128 bits.

Format : Notation d'adresse IPv6 standard

2001:4860:4860::8888

Décision de routage :

Les routeurs examinent ce champ pour déterminer où transférer le paquet. Contrairement à IPv4 où NAT pourrait réécrire les adresses, les adresses de destination IPv6 restent généralement inchangées de bout en bout.

Adresses spéciales :

Loopback (::1) ne doit jamais apparaître dans un paquet sur le fil. Les paquets vers ::1 sont gérés en interne.

Les adresses multicast (ff00::/8) indiquent que le paquet doit être livré à plusieurs destinataires :

• ff02::1 - Tous les nœuds sur le lien local
• ff02::2 - Tous les routeurs sur le lien local
• ff02::1:ff00:0/104 - Multicast de nœud sollicité (pour Neighbor Discovery)

Modification de l'en-tête de routage :

Lorsqu'un en-tête d'extension Routing est présent, les nœuds intermédiaires peuvent traiter l'adresse de destination différemment, mais c'est peu commun dans les réseaux modernes en raison de préoccupations de sécurité.

Comparaison des en-têtes IPv6 vs IPv4#

Comprendre ce qui a changé aide à apprécier les décisions de conception.

Ce qui a été supprimé et pourquoi#

Somme de contrôle d'en-tête : Les routeurs IPv4 recalculent la somme de contrôle à chaque saut car TTL change. Cela ajoute une surcharge de traitement. IPv6 l'élimine car :

• La couche liaison (Ethernet) a sa propre somme de contrôle
• La couche transport (TCP/UDP) a sa propre somme de contrôle
• Les routeurs n'ont pas besoin de vérifier l'intégrité du paquet — les points terminaux le font

Champ Header Length : IPv4 en a besoin car les options rendent l'en-tête de longueur variable. L'en-tête fixe de 40 octets d'IPv6 rend ce champ inutile.

Champs de fragmentation : IPv4 permet à n'importe quel routeur de fragmenter les paquets. IPv6 exige que la source effectue la fragmentation en utilisant Path MTU Discovery. Cela déplace la complexité vers les points terminaux et améliore les performances du routeur.

Options : Les options IPv4 sont rarement utilisées mais forcent les routeurs à analyser des en-têtes de longueur variable. IPv6 déplace les options vers les en-têtes d'extension, gardant l'en-tête de base simple.

En-têtes d'extension expliqués#

Les en-têtes d'extension sont la façon dont IPv6 ajoute des fonctionnalités sans compliquer l'en-tête de base. Ils apparaissent entre l'en-tête IPv6 et la couche transport (TCP/UDP), formant une chaîne.

Comment fonctionnent les en-têtes d'extension#

Chaque en-tête d'extension contient un champ Next Header qui pointe vers le prochain en-tête de la chaîne :

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

Les hôtes traitent les en-têtes d'extension dans l'ordre. Les routeurs ne traitent généralement que les Hop-by-Hop Options ; les autres en-têtes ne sont examinés que par la destination.

En-têtes d'extension standard#

RFC 8200 définit l'ordre recommandé lorsque plusieurs en-têtes d'extension sont présents :

1. Hop-by-Hop Options (0)
2. Destination Options (pour les destinations intermédiaires lorsque l'en-tête Routing est présent)
3. Routing (43)
4. Fragment (44)
5. Authentication Header (51)
6. Encapsulating Security Payload (50)
7. Destination Options (60) (pour la destination finale)
8. Upper Layer (TCP=6, UDP=17, ICMPv6=58)

En-tête Hop-by-Hop Options (Type 0)#

Porte des options qui doivent être examinées par chaque routeur le long du chemin.

Format :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Options courantes :

Pad1 et PadN : Remplissage pour l'alignement

Router Alert (Type 5) : Indique aux routeurs d'examiner le paquet de plus près. Utilisé par des protocoles comme MLD (Multicast Listener Discovery).

Jumbogram (Type 194) : Pour les paquets supérieurs à 65 535 octets.

Doit être en premier : Si présent, Hop-by-Hop Options doit suivre immédiatement l'en-tête IPv6. La RFC 8200 exige cet ordre strict.

Problème de sécurité : De nombreux routeurs abandonnent les paquets avec des en-têtes Hop-by-Hop qu'ils ne reconnaissent pas, ou les limitent fortement. En pratique, cet en-tête d'extension est peu commun en dehors de protocoles spécifiques (MLD, jumbograms).

En-tête Routing (Type 43)#

Spécifie les nœuds intermédiaires que le paquet doit visiter avant d'atteindre sa destination finale.

Format :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     Type-specific data                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Types de routage :

Type 0 (Déprécié) : Routage source libre original. Déprécié par RFC 5095 en raison de problèmes de sécurité (attaques d'amplification).

Type 2 : Utilisé par Mobile IPv6 pour le routage vers les nœuds mobiles. Cas d'usage limité.

Type 3 : Segment Routing Header (SRH) pour SRv6. Cas d'usage moderne pour l'ingénierie de trafic et le chaînage de services dans les réseaux d'opérateurs.

Sécurité : Les en-têtes de routage Type 0 permettaient aux attaquants de router les paquets à travers des nœuds arbitraires, créant des attaques d'amplification. La plupart des réseaux abandonnent le Type 0. Le Type 3 (SRv6) est conçu plus soigneusement mais soulève toujours des problèmes de sécurité sur Internet public.

En-tête Fragment (Type 44)#

Utilisé lorsque la source fragmente un paquet trop grand pour le MTU du chemin.

Format :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champs :

• Next Header : Protocole des données fragmentées (TCP, UDP, etc.)
• Fragment Offset : Décalage de ce fragment dans le paquet original (en unités de 8 octets)
• Drapeau M : More Fragments (1 = plus à venir, 0 = dernier fragment)
• Identification : ID unique pour le réassemblage (identique pour tous les fragments d'un paquet)

Comment fonctionne la fragmentation :

1. La source essaie d'envoyer un grand paquet
2. Reçoit un message ICMPv6 Packet Too Big
3. Fragmente le paquet en morceaux plus petits
4. Ajoute un en-tête Fragment à chaque morceau
5. La destination réassemble basé sur le champ Identification

Exemple :

Paquet original de 2000 octets, MTU 1280 :

Fragment 1:
  En-tête IPv6 (40 octets)
  En-tête Fragment (8 octets) [M=1, Offset=0, ID=12345]
  Données (1232 octets)
  Total: 1280 octets
 
Fragment 2:
  En-tête IPv6 (40 octets)
  En-tête Fragment (8 octets) [M=0, Offset=154, ID=12345]
  Données (768 octets)
  Total: 816 octets

MTU minimal : IPv6 exige que tous les liens supportent au moins 1280 octets. Les sources peuvent envoyer des paquets de 1280 octets sans fragmentation sur n'importe quel réseau IPv6 conforme.

Problèmes de sécurité : La fragmentation permet des attaques :

• Fragments chevauchants (masquer la charge utile des IDS)
• Inondations de fragments (épuiser les ressources de réassemblage)
• Fragments minuscules (gaspiller le temps de traitement)

De nombreux pare-feu abandonnent les paquets fragmentés ou les réassemblent avant l'inspection.

En-tête Destination Options (Type 60)#

Porte des options uniquement pour le nœud de destination. Les routeurs intermédiaires ne le traitent pas.

Format : Identique à Hop-by-Hop Options, mais examiné uniquement à la destination.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cas d'usage :

• Remplissage pour l'alignement
• Options spécifiques aux applications
• Extensions futures sans changer l'en-tête de base

Peut apparaître deux fois dans la chaîne d'en-têtes :

1. Avant l'en-tête Routing (traité par les destinations intermédiaires)
2. Après les en-têtes ESP/AH (traité par la destination finale)

Authentication Header (Type 51) et ESP (Type 50)#

En-têtes IPsec fournissant authentification et chiffrement.

AH (51) : Fournit authentification et intégrité mais pas de confidentialité. Rarement utilisé car ESP peut faire la même chose plus le chiffrement.

ESP (50) : Fournit confidentialité, authentification et intégrité. Standard pour les VPN et la communication chiffrée.

IPsec est un large sujet au-delà de la structure des en-têtes. Point clé : ces en-têtes font partie de la conception d'IPv6 dès le début, contrairement à IPv4 où IPsec a été ajouté plus tard.

Traitement des en-têtes d'extension#

Les hôtes doivent :

• Traiter tous les en-têtes d'extension dans l'ordre
• Supporter tous les en-têtes d'extension standard
• Gérer les en-têtes inconnus selon la valeur Next Header

Les routeurs généralement :

• N'examinent que les Hop-by-Hop Options
• Transfèrent les autres en-têtes d'extension sans traitement
• Peuvent limiter le débit ou abandonner les paquets avec certains en-têtes pour la sécurité

Considérations de pare-feu :

Les en-têtes d'extension compliquent les pare-feu car :

• L'en-tête de transport (TCP/UDP) peut être profond dans le paquet
• Doit analyser toute la chaîne pour trouver les ports pour le filtrage
• Les attaquants peuvent masquer les charges utiles avec des chaînes d'en-têtes complexes

Meilleures pratiques :

• Limiter la longueur de la chaîne d'en-têtes d'extension
• Abandonner les paquets avec des en-têtes dépréciés (Type 0 Routing)
• Réassembler les fragments avant l'inspection
• Limiter le débit des paquets avec options Hop-by-Hop

Pourquoi pas de somme de contrôle ?#

IPv4 inclut une somme de contrôle d'en-tête que les routeurs doivent recalculer à chaque saut (car TTL change). IPv6 l'omet délibérément.

Raisonnement :

1. La couche liaison a déjà des sommes de contrôle : Ethernet a CRC32. Wi-Fi a des sommes de contrôle. Les couches liaison modernes sont fiables.

2. Sommes de contrôle de couche transport : TCP et UDP incluent des sommes de contrôle couvrant les données et les en-têtes. La vérification de bout en bout se produit de toute façon.

3. Performance du routeur : Recalculer les sommes de contrôle à chaque saut gaspille des cycles CPU. Les routeurs haute vitesse transfèrent des milliards de paquets par seconde — éliminer le calcul de la somme de contrôle aide.

4. Les erreurs sont rares : Les réseaux modernes ont de faibles taux d'erreur de bits. Les sommes de contrôle détectent moins d'erreurs que dans les années 1980 lorsque IPv4 a été conçu.

Qu'en est-il de la corruption ?

Si un bit se retourne dans un en-tête IPv6 :

• Mauvaise adresse de destination : Le paquet va au mauvais endroit ou est abandonné, TCP retransmet
• Mauvais hop limit : Le paquet peut mourir tôt ou tard, impact marginal
• Mauvais next header : La destination ne peut pas l'analyser, TCP détecte les données manquantes et retransmet

Le principe de bout en bout dit que les points terminaux doivent détecter et gérer les erreurs. Les routeurs intermédiaires transfèrent simplement les paquets rapidement.

Implications pratiques#

Pour les ingénieurs réseau#

Configuration de pare-feu :

• Doit analyser les chaînes d'en-têtes d'extension pour trouver les en-têtes de transport
• Devrait limiter la profondeur de chaîne pour empêcher les abus
• Abandonner les en-têtes dépréciés (Type 0 Routing)

Optimisation des performances :

• Pas de somme de contrôle d'en-tête signifie un transfert plus rapide en matériel
• La taille d'en-tête fixe permet un meilleur pipeline dans les routeurs
• Les en-têtes d'extension peuvent déclencher un traitement en chemin lent

Dépannage :

• tcpdump montre tous les en-têtes : tcpdump -i eth0 -vv ip6
• Wireshark analyse clairement les en-têtes d'extension
• Vérifier les en-têtes d'extension inattendus causant des abandons

Pour les développeurs#

Programmation socket :

• Les sockets IPv6 peuvent recevoir des en-têtes d'extension via des données auxiliaires
• Les applications ont rarement besoin de construire manuellement des en-têtes d'extension
• L'OS gère automatiquement la fragmentation

Construction de paquets :

• Définir Traffic Class pour les applications sensibles à QoS (VoIP, vidéo)
• Activer la génération automatique de Flow Label pour un meilleur équilibrage de charge ECMP
• Ne supposez pas que vous pouvez fragmenter — utilisez PMTUD correctement

Sécurité :

• Valider les adresses source (rejeter les sources multicast, etc.)
• Gérer soigneusement les paquets fragmentés ou les rejeter
• Sachez que les équipements intermédiaires peuvent abandonner les en-têtes d'extension

Pour les administrateurs système#

Configuration MTU :

• Assurez-vous que le MTU est au moins de 1280 octets sur tous les liens
• Les MTU plus grands améliorent les performances (1500 standard, 9000 pour les trames jumbo)
• Autoriser ICMPv6 Packet Too Big à travers les pare-feu

Configuration QoS :

• Configurer les routeurs pour honorer les marquages Traffic Class
• Mapper le trafic applicatif aux valeurs DSCP appropriées
• Surveiller que les politiques QoS fonctionnent correctement

IPsec/VPN :

• AH et ESP sont des en-têtes d'extension — les pare-feu doivent les autoriser
• IPsec ajoute de la surcharge — tenir compte de cela dans les calculs MTU
• Considérer l'impact du mode transport vs mode tunnel sur les en-têtes

Examiner les en-têtes avec des outils#

tcpdump#

Capturer et afficher les en-têtes IPv6 :

# Capture de paquets IPv6 de base
sudo tcpdump -i eth0 -n ip6
 
# Sortie verbeuse montrant tous les champs d'en-tête
sudo tcpdump -i eth0 -vv ip6
 
# Montrer uniquement les paquets avec en-têtes d'extension
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# Capturer les paquets fragmentés
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

Exemple de sortie :

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
Analyse:
- Source: 2001:db8::10, port 54321
- Destination: 2001:db8::20, port 80
- En-tête d'extension: Destination Options (DSTOPT)
- Transport: TCP SYN

Wireshark#

Wireshark fournit une analyse détaillée des en-têtes :

Filtres :

# Tout le trafic IPv6
ipv6
 
# Paquets avec en-têtes d'extension spécifiques
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# Paquets fragmentés
ipv6.fragment
 
# Traffic Class spécifique
ipv6.tclass == 46  # Expedited Forwarding

Inspection d'en-tête :

1. Développer « Internet Protocol Version 6 » dans les détails du paquet
2. Voir tous les 8 champs clairement étiquetés
3. Les en-têtes d'extension apparaissent comme des couches séparées
4. Clic droit sur les champs pour le filtrage

Scapy (Python)#

Construire et analyser les paquets IPv6 programmatiquement :

from scapy.all import *
 
# Créer un paquet IPv6
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# Montrer la structure du paquet
pkt.show()
 
# Sortie:
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# Ajouter un en-tête d'extension
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

Erreurs de configuration courantes#

Bloquer complètement les en-têtes d'extension#

Problème : Le pare-feu abandonne tous les paquets avec des en-têtes d'extension.

Impact :

• La fragmentation ne fonctionne pas (type 44 bloqué)
• Les VPN IPsec échouent (types 50/51 bloqués)
• Certains trafics légitimes sont abandonnés

Solution : Autoriser les en-têtes nécessaires (Fragment, AH, ESP), bloquer ceux dépréciés (Type 0 Routing).

# iptables: Autoriser les fragments, abandonner le routage Type 0
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Ignorer Traffic Class#

Problème : Routeurs configurés sans QoS, tous les paquets reçoivent un traitement best-effort.

Impact :

• La qualité VoIP souffre
• Les flux vidéo mettent en mémoire tampon
• Le trafic sensible au temps concurrence les transferts en masse

Solution : Configurer les politiques QoS basées sur Traffic Class/DSCP.

! Exemple Cisco IOS
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

Incompatibilités MTU#

Problème : Liens avec MTU < 1280 ou pare-feu bloquant ICMPv6 Packet Too Big.

Impact :

• Les connexions se bloquent
• Les grands transferts échouent
• PMTUD ne fonctionne pas

Solution : Assurer un MTU minimal de 1280 partout, autoriser ICMPv6 type 2.

# Définir le MTU
ip link set dev eth0 mtu 1500
 
# Vérifier
ip -6 link show eth0
 
# Autoriser Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Articles connexes#

• Fondamentaux IPv6 - Comprendre l'adressage IPv6 de base et les concepts avant de plonger dans les en-têtes.
• ICMPv6 expliqué - En savoir plus sur ICMPv6, qui utilise la valeur Next Header 58 et est critique pour IPv6.
• Configuration de pare-feu IPv6 - Configurer les pare-feu pour gérer correctement les en-têtes IPv6 et les en-têtes d'extension.

Questions fréquemment posées#