Objectifs de certification

CCNA 200-301

• 1.7 Décrire la nécessité d’un adressage IPv4 privé

• 1.6 Configurer et vérifier l’adressage et le sous-réseautage (subnetting) IPv4

• 1.8 Configurer et vérifier l’adressage et les préfixes IPv6

• 1.9 Comparer les types d’adresses IPv6

  • 1.9.a Global unicast
  • 1.9.b Unique local
  • 1.9.c Link local
  • 1.9.d Anycast
  • 1.9.e Multicast
  • 1.9.f Modified EUI 64

En-têtes IPv4 et IPv6

Même si la certification Cisco CCNA n’exige pas la connaissance des en-têtes IPv4 ou IPv6 (ni d’aucun autre protocole), il est utile de distinguer les différences entre ces en-têtes et de les comparer d’un protocole à l’autre.

1. En-tête IPv4

On retiendra qu’un en-tête IPv4 dispose d’une taille variable de minimum 20 octets et de maximum 60 octets. La taille d’un paquet entier peut aller jusque 65536 octets. Mais certaines technologies L2 (de couche 2) comme Ethernet ne supportent que des paquets d’une taille de 64 à 1500 octets (a contrario, FDDI suporte des paquets de maximum 4478 octets, Frame-Relay supporte des paquets d’une taille variant entre 46 et 4470 octets).

En IPv4, quand le paquet doit passer par un chemin qui connait une liaison dont le MTU (Maximum Transfer Unit) est inférieur à la taille du paquet, le routeur qui connecte cette liaison réalise une fragmentation du paquet original, divisant la charge dans la taille adaptée en répétant l’en-tête. Des champs de fragmentation identifient les paquets qui sont reconstruits uniquement à l’endroit de la destination finale. Autrement dit, la fragmentation ne peut s’opérer qu’une seule fois dans la communication.

On reconnaîtra aussi le champ “Time To Live”, qui est codé sur 8 bits (de 0 à 255) dont la valeur démarre au maximum. La valeur de ce champ est dés-incrémentée de 1 au passage de chaque routeur. Quand cette valeur atteint 1, le paquet ne peut plus être transféré et l’interface du routeur qui a reçu le paquet retourne à la source un message ICMP “Time Excedeed”.

Le champ “Protocol” annonce un protocole de couche supérieure (L4, Transport) embarqué dans la charge du paquet. Les valeurs les plus courantes sont les suivantes.

2. En-tête IPv6 de base

Par rapport à un en-tête IPv4, IPv6 vise à minimiser la surcharge à son niveau et à simplifier le processus de traitement des paquets sur les routeurs.

A première vue, un en-tête IPv6 a été simplifié pour laisser principalement quelques champs de taille fixe comme les adresses source et destination codées sur 128 bits, un champ de durée de vie (Hop Limit) et celui qui annonce une charge supérieure (Next Header).

Comparativement à IPv4, un en-tête IPv6 dispose des caractéristiques suivantes.

• Un en-tête IPv6 de taille fixe de 40 octets.
• Disparition du champ “Header Checksum”, IHL.
• La fonction de fragmentation a été retirée des routeurs et disparaissent de l’en-tête de base pour être reportées dans des en-têtes d’extension.
• Les champs “Options” remplacées par des en-têtes d’“Extensions”.
• Les champs d’adresses sont des mots de 128 bits.
• Le champ IPv6 “Next Header” correspond au champ “Protocol” IPv4.
• Le champ IPv6 “Hop Limit” correspond au champ “Time to Live” IPv4.
• Le champ IPv6 “Flow Label” est nouveau

En téléchargeant les livres du Guide CCNA 200-301 vous encouragez son auteur !

3. En-têtes IPv6 d’extension

IPv6 encapsule tout le trafic dans un en-tête fixe de base constitué de huit champs.

Les extensions d’IPv6 peuvent être vues comme un prolongement de l’encapsulation d’IPv6 dans IPv6.

À part l’extension de “proche-en-proche” traitée par tous les routeurs intermédiaires, les autres extensions ne sont prises en compte que par les équipements destinataires du paquet.

Une extension a une longueur multiple de 8 octets. Elle commence par un champ “Next Header” d’un octet qui définit le type de données qui suit l’extension : une autre extension ou un protocole de couche 4 (voir tableau Valeurs du champ “Next Header”).

Pour les extensions à longueur variable, l’octet suivant contient la longueur de l’extension en mots de 8 octets, le premier n’étant pas compté (une extension de 16 octets a un champ longueur de 1).

Les extensions peuvent s’enchaîner en suivant l’ordre défini par le RFC 8200 Extension Header Order. Cette possibilité rend les politiques de filtrage plus lourdes, nécessitant une bonne connaissance du protocole et générant de la charge sur le matériel filtrant.

4. Découverte du MTU dans le chemin

La procédure “Path MTU” est définie dans le RFC 8201. Son implémentation n’est pas obligatoire sur les noeuds IPv6 et peut être absente.

Initialement, l’équipement émetteur fait l’hypothèse que le PMTU (Path MTU) d’un certain chemin est égal au MTU du lien auquel il est directement attaché (40+ 1460 = 1500 octets).

S’il s’avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d’erreur ICMPv6 de type “Packet too Big”, en y indiquant le MTU accepté (soit par exemple 1480). Fort de ces informations, l’équipement émetteur réduit le PMTU supposé pour ce chemin (40 + 1440 = 1480 octets).

Plusieurs itérations peuvent être nécessaires avant d’obtenir un PMTU permettant à tout paquet d’arriver à l’équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Le protocole reposant sur l’hypothèse de la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire.

Source : Mécanisme de découverte du PMTU

A cet égard, les pare-feu pourraient bloquer ce trafic utile car il serait considéré comme une connexion directe venant d’un Internet de moindre confiance, en dehors de tout état ou session.

Aussi, ce trafic reste vulnérable à des attaques de déni de service (DoS) provoquant des ruptures de connexion ou l’impossibilité de transférer des données en envoyant des messages “Packet Too Big” à un noeud.

Le RFC4890 propose des recommandations en matière de filtrage IPv6 sur les pare-feu / firewalls.