Revision as of 12:13, 20 September 2009 (view source) Ltoutain (Talk | contribs) (→‎Routage) ← Older edit		Revision as of 12:13, 20 September 2009 (view source) Ltoutain (Talk | contribs) (→‎Routage) Newer edit →
Line 436:		Line 436:
	*Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.		*Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
−	*Le champ type indique la nature du routage. Le routage par la source, de type 0 est spécifié a été déprécié (cf rfc5095). La suite de l'en-tête correspond à ce type.	+	*Le champ type indique la nature du routage. Le routage par la source, de type 0 est spécifié a été déprécié (cf RFC5095). La suite de l'en-tête correspond à ce type.
	*Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.		*Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.
	*Les 32 bits suivants sont inutilisés pour préserver l'alignement.		*Les 32 bits suivants sont inutilisés pour préserver l'alignement.

---

Revision as of 12:13, 20 September 2009

Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double de l'en-tête IPv4 sans les options), le protocole IP a subi un toilettage reprenant l'expérience acquise au fil des ans avec IPv4. Le format des en-têtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements :

• L'en-tête ne contient plus le champ checksum, qui devait être ajusté par chaque routeur en raison de la décrémentation du champ durée de vie. Par contre, pour éviter qu'un paquet dont le contenu est erroné -- en particulier sur l'adresse de destination -- ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de checksum de bout en bout incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le checksum d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum intègre le pseudo-en-tête, alors que pour ICMPv4, il ne portait que sur le message ICMP.
• La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone de données utiles.
• Les options ont été retirées de l'en-tête et remplacées par de nouveaux en-têtes appelés extensions qui peuvent être facilement ignorées par les routeurs intermédiaires.
• Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement, surtout avec les nouvelles architectures à 64 bits.
• La taille minimale des MTU : Maximum Transmission Unit est de 1 280 octets. Le choix de 1 280 comme MTU minimal en IPv6 permet le tunnelage de paquets IPv6. En effet, la taille de 1 500 octets est généralement admise car elle correspond à la valeur imposée par Ethernet. La majorité des autres réseaux offrent une taille supérieure. La valeur de 576 octets retenue pour IPv4 permettait de prendre en compte des réseaux comme Appletalk. Pour ces réseaux, une couche d'adaptation (comme avec les couches d'adaptation AAL d'ATM) devra être mise en oeuvre pour pouvoir transporter les paquets IPv6.
• La fonction de fragmentation a été retirée des routeurs. Les champs qui s'y reportent (identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes de découverte du PMTU(Path MTU) évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue (voir Fragmentation).

Le format d'en-tête d'un paquet IPv6 est donné par le RFC 2460 (cf. Format d'un datagramme IPv6).

Figure : Format d'un datagramme IPv6

Version 

Le champ version est le seul champ qui occupe la même place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6.

Classe de trafic 

Le premier mot de 32 bits étant exclu du calcul du checksum avec les pseudo-en-têtes, il est plus facile de le faire évoluer. Dans la version standardisée par le RFC 2460 un champ classe de trafic sur 8 bits permet la différenciation de services conformément aux spécifications du RFC 2474.

Le champ classe de trafic est aussi appelé dans les paquets IPv4 octet DiffServ (DS), il prend la place du champ ToS, initialement défini dans la spécification d'IPv4 (cf. figure Format de l'octet classe de trafic). Le champ DS est découpé en deux parties. Le sous-champ DSCP (DiffServ Code Point) contient les valeurs des différents comportements. Les deux derniers bits du champ sont actuellement non utilisés, mais devraient servir aux routeurs pour indiquer un risque de congestion en combinaison avec l'algorithme RED (Random Early Detection).

L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic seront définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu pour que l'introduction de telles classes de service soit efficace, il faut offrir des tarifications différentes pour chacune des classes et des mécanismes de contrôle pour vérifier qu'un utilisateur n'utilise pas que les classes les plus élevées ou qu'il dépasse son contrat.

L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en "Best Effort" même si certains sont plus "Best" que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe de service haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de service vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer le paquets en fonction de paramètres locaux (trafic du directeur de la société, flux multimédia interactif,...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs, il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi.

Dans le cœur de son réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur.

Pour l'instant deux types de comportement sont standardisés :

• Assured Forwarding : Ce comportement définit quatre classes de services et trois priorités suivant que l'utilisateur respecte son contrat, le dépasse légèrement ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats.
• Explicit Forwarding : Ce comportement est comparable à un circuit à débit constant établi dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat.

En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. En particulier, la valeur 0xE0 correspond à la classe de contrôle du réseau (Network Control). Elle est utilisée dans des mises en oeuvre d'IPv6 pour l'émission de certains paquets ICMPv6.

Identificateur de flux 

Ce champ contient un numéro unique choisi par la source, qui a pour but de faciliter le travail des routeurs et la mise en oeuvre des fonctions de qualité de service comme RSVP. Cet indicateur peut être considéré comme une marque à un contexte dans le routeur. Le routeur peut alors faire un traitement particulier : choix d'une route, traitement en "temps-réel" de l'information.

Avec IPv4, certains routeurs, pour optimiser le traitement, se basent sur les valeurs des champs adresses de la source et de destination, numéros de port de la source et de destination et protocole pour construire un contexte. Ce contexte sert à router plus rapidement les paquets puisqu'il évite de consulter les tables de routage pour chaque paquet. Ce contexte est détruit après une période d'inactivité.

Avec IPv6, cette technique est officialisée. Le champ identificateur de flux peut être rempli avec une valeur aléatoire qui servira à référencer le contexte. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est optimisé puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet. De plus si une extension de confidentialité est utilisée, les informations concernant les numéros de port sont masquées aux routeurs intermédiaires.

L'utilisation de ce champ a été rendue confuse car Cisco dans le cadre du Tag Switching a proposé de l'utiliser pour augmenter la vitesse de commutation des paquets. Cette proposition consiste à ne garantir l'unicité de l'identificateur de flux que sur un lien. Le routeur possède dans sa mémoire une table de correspondance qui permet, en fonction du lien d'arrivée et du numéro d'identificateur de flux, de déterminer le lien de sortie et la nouvelle valeur de l'identificateur. Cette proposition se rapproche énormément des techniques utilisées dans les circuits virtuels (ATM, Frame Relay, X.25,...).

Le groupe de travail MPLS (Multi Protocol Label Switching) a intégré les travaux sur le Tag Switching et a précisé la manière dont la commutation des paquets pourra être faite. L'identificateur de flux d'IPv6 n'est plus utilisé, mais un en-tête spécifique est introduit entre l'encapsulation de niveau 2 et celle de niveau 3. L'identificateur de flux n'a plus à être modifié en cours de transmission. Cette évolution clarifie l'utilisation du protocole RSVP (Reservation Protocol) qui peut se baser sur cette valeur, identique tout au long du chemin, pour identifier un flux.

En fait, l'utilisation de l'étiquette de flux est très floue, les micro-flux, c'est-à-dire de flux applicatifs, ne sont pas vus dans le coeur du réseau pour des raisons de scalabilité, de plus MPLS a repris la notion de routage spécifique en fonction d'une étiquette. Pour l'instant ce champ peut être vu comme réservé et son utilisation pourra être mieux spécifiée dans le futur.

Longueur des données utiles (payload) 

Contrairement à IPv4, ce champ, sur deux octets, ne contient que la taille des données utiles, sans prendre en compte la longueur de l'en-tête. Pour des paquets dont la taille des données serait supérieure à 65 535 ce champ vaut 0 et l'option jumbogramme de l'extension de "proche-en-proche" est utilisée (cf. Jumbogramme) (type 194 ou 0xc2, RFC 2675 ). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.).

En-tête suivant 

Ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-tête. Il peut s'agir d'un protocole (de niveau supérieur ICMP, UDP, TCP...) ou de la désignation d'extensions (cf. tableau Valeurs du champ en-tête suivant).

Valeurs du champ en-tête suivant

valeur	Extension		valeur	Protocole
0	Proche-en-proche		4	IPv4
43	Routage		6	TCP
44	Fragmentation		17	UDP
50	Confidentialité		41	IPv6
51	Authentification		58	ICMPv6
59	Fin des en-têtes		132	SCTP
60	Destination		136	UDP-lite
135	Mobilité
140	Shim6

Les extensions contiennent aussi ce champ pour permettre un chaînage.

Nombre de sauts 

Il est décrémenté à chaque nœud traversé. Un datagramme retransmis par un routeur est rejeté avec l'émission d'un message d'erreur ICMPv6 vers la source si la valeur après décrémentation atteint 0.
Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est d'indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s'agit d'un nombre de sauts, la décrémentation est toujours de 1.
La valeur initiale de ce champ devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée, mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64.
La valeur par défaut peut être dynamiquement attribuée aux équipements du réseau par les annonce des routeurs (cf. Configuration automatique), une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation, puisque ce champ codé sur 8 bits n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.

Exemples

Le paquet IPv6 suivant a été capturé au cours d'une connexion FTP :

0000: 60 00 00 00 00 28 06 40 3f fe 03 02 00 12 00 02
0010: 00 00 00 00 00 00 00 13 3f fe 03 05 10 02 00 01
0020: 02 00 c0 ff fe 11 cb a0|ff b3 00 15 55 4d fd d1
0030: 00 00 00 00 a0 02 40 00 7d 76 00 00 02 04 05 a0
0040: 01 03 03 00 01 01 08 0a 00 9a 17 44 00 00 00 00

Le paquet commence par 6 qui indique la version du protocole. Le second champ 00 donne la classe de trafic DiffServ. L'identificateur de flux n'a pas été défini par la source (0 00 00). La longueur du paquet est de 0x0028 octets. Le paquet ne contient pas d'extension puisque la valeur de l'en-tête suivant, 0x06, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le paquet pourra traverser est de 64 (0x40). Les adresses source et destination sont des adresses de test appartenant au plan d'adressage agrégé.

Justification des extentions

Figure : Enchaînement d'extentions La figure "Enchaînement d'extentions" montre la souplesse avec laquelles plusieurs extentions peuvent être chaînées. Chaque extention contient dans son en-tête un champ en-tête suivant et longueur. Le premier paquet ne contient pas d'extention, le champ en-tête suivant pointe sur TCP. Le second paquet contient une extention de routage qui pointe sur TCP. Dans le dernier paquet, une extention de fragmentation est ajoutée après celle de routage.

Si cet enchaînement d'extention offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port, il faut en effet lire tout l'enchaînement d'extention pour arriver au protocole de niveau 4. Ceci a seri de justification au l'identificateur de flux qui permettait de refleter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront aux numéros de ports.

Les extentions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extention de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extentions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).

Traitement optimisé des extentions

Figure : Traitement de l'option LSR en IPv4

L'exemple suivant permet de souligner les problèmes d'utilisation des options dans IPv4, d'illustrer la notion de tunnel et le concept de transmission multicast.

La solution (cf. figure Traitement de l'option LSR en IPv4) consiste à émettre le paquet avec l'option de routage libéral par la source (loose source routing). Le paquet est destiné au routeur R1, qui permute l'adresse de destination avec celle contenue dans le champ option. Le paquet franchissant les routeurs entre A et R1 puis R1 et B sera retardé à cause de la présence du champ option. Avec IPv4, les options sont obligatoirement prises en compte par tous les routeurs intermédiaires. Ceux-ci, pour des raisons de performance, privilégient les paquets sans option. De plus, par construction, la longueur du champ option est limitée à 40 octets, ce qui limite l'emploi simultané de plusieurs options.

Figure : Traitement avec l'extention de routage IPv6

Avec IPv6 la philosophie est différente comme le montre la figure "Traitement avec l'extention de routage IPv6". Un paquet normal à destination de R1 est envoyé dans le réseau et est traité normalement par les routeurs intermédiaires. R1 reconnait son adresse et le passe à la couche supérieur qui traite l'extention de routage. Cette couche inverse les adresses et réémet le paquet vers la nouvelle destination.

Ordre des extentions

Figure : Importance de l'ordre des extentions

Le RFC 2460 recommande l'ordre suivant :

• Proche-en-proche (doit toujours être en première position)
• Destination (sera aussi traité par les routeurs listés dans l'extension de routage par la source)
• Routage par la source
• Fragmentation
• Authentification
• Destination (traité uniquement par l'équipement terminal)

En fait, il y a actuellement très peu de chance de trouver des extentions dans les paquets IPv6, encore moins plusieurs extentions enchaînées. Par ontre l'exemple précédent est instructif car il montre que la place d'une extention dans la chaîne est importante.

On peut remarquer que ce paquet contient deux extentions destination. La première étant placée avant l'extention de routage serait traitée par tous les routeurs intermédiaire listés dans l'option de routage. La second située après, ne serait traitée que par le destinataire final. De plus cette option étant également placée après l'extention de chiffrement, ses données ne circuleraient pas en clair sur le réseau.

De même l'extention fragmentation est située après celle de routage. Seul le destinataire final fera le réassemblage du paquet.

Options dans les extentions

Proche-en-proche

Cette extension (en anglais : hop-by-hop) se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d'en-tête en-tête suivant de l'en-tête précédent) est 0 et le champ longueur de l'extension contient le nombre de mots de 64 bits moins 1.

L'extension est composée d'options. Pour l'instant, seules quatre options, dont deux de bourrage, sont définies (cf. Format des options IPv6). Chaque option est une suite d'octets. Le premier octet est un type, le deuxième (sauf pour l'option 0) contient la longueur de l'option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :

• 00 : le routeur ignore l'option ;
• 01 : le routeur rejette le paquet ;
• 10 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité ;
• 11 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité si l'adresse de destination n'est pas multicast.

Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).

Les quatre options de proche-en-proche sont :

• Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage.
• Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le champ longueur indique le nombre d'octets qui suivent.

Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.

• Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0.
  Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.

• L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (Multicast Listener Discovery) ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données.
  L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux.
  Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :
  • 0 : pour les messages du protocole MLD de gestion des groupes multicast ;
  • 1 : pour les messages RSVP ;
  • 2 : pour les réseaux actifs ;

les autres valeurs sont réservées.

Destination

Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Pour l'instant, à part les options de bourrage (voir Pad1 et Padn) et de mobilité (cf. Mobilité dans IPv6), la seule autre option concerne le tunnelage dans des paquets IPv6 (RFC 2473). Cette option permet de limiter le niveau d'encapsulation dans des tunnels des paquets IPv6.

Routage

Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau. La mobilité IPv6 a également introduit une extension de routage (type = 2) (cf. Optimisation dans le cas du mobile dans un réseau étranger).

Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (loose) (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau.

Le principe du routage par la source ou Source Routing dans IPv4 est rappelé en introduction de ce chapitre sur les extensions. Le principe est le même pour IPv6. L'émetteur met dans le champ destination du paquet IPv6, l'adresse du premier routeur servant de relais, l'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.

La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :

• Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
• Le champ type indique la nature du routage. Le routage par la source, de type 0 est spécifié a été déprécié (cf RFC5095). La suite de l'en-tête correspond à ce type.
• Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.
• Les 32 bits suivants sont inutilisés pour préserver l'alignement.

La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.

Fragmentation

La fragmentation telle qu'elle est pratiquée dans IPv4 n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4 quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille et si le bit DF (don't fragment) est à 0, il découpe l'information à transmettre en fragments. Or le réseau IP étant un réseau à datagramme, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et par conséquent seul le destinataire peut effectuer le réassemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir Mécanisme de découverte du PMTU (RFC 1981)). En pratique une taille de paquets de 1 500 octets est presque universelle.

Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de grande taille. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera chez l'émetteur et le réassemblage chez le récepteur.

Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :

• Le champ place du fragment indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
• Le bit M s'il vaut 1 indique qu'il y aura d'autres fragments émis.
• Le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.
• Le bit DF (don't fragment) n'est plus nécessaire puisque, si un paquet est trop grand, il y aura rejet du paquet par le routeur.

Dans IPv4, la valeur d'une option était codée de manière à indiquer au routeur effectuant la fragmentation si elle devait être copiée dans les fragments. Dans IPv6, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant proche-en-proche, routage par la source) sont recopiées dans chaque fragment.

Sécurité

Deux extensions de sécurité -- les extensions d'authentification AH (Authentication Header) et de confidentialité ESP (Encapsulating Security Payload) -- sont définies par l'IETF. Elles permettent de protéger les communications passées sur les réseaux IPv6 mais aussi IPv4 en assurant les services de confidentialité, authentification, intégrité et détection de rejeux. Le chapite Sécurité, RFC 2402 donne une description détaillée de ces extensions, et présente les modes de protection existants.