3. The IPv4 ID Field (Le champ ID d'IPv4)
IP prend en charge la fragmentation des datagrammes, où les grands datagrammes sont découpés en composants plus petits pour traverser des liens dont l'unité de transmission maximale (MTU) est limitée. Les fragments sont indiqués de différentes manières en IPv4 et en IPv6 :
- En IPv4, les fragments sont indiqués à l'aide de quatre champs de l'en-tête de base : Identification (ID), décalage de fragment (Fragment Offset), un indicateur « Don't Fragment » (DF) et un indicateur « More Fragments » (MF) [RFC791].
- En IPv6, les fragments sont indiqués dans un en-tête d'extension qui comprend un ID, un décalage de fragment et un indicateur M (more fragments) similaires à leurs homologues en IPv4 [RFC2460].
La fragmentation IPv6 diffère de la fragmentation IPv4 sur quelques points importants. La fragmentation IPv6 se produit uniquement à la source, de sorte qu'un bit DF n'est pas nécessaire pour empêcher les dispositifs en aval de déclencher une fragmentation (autrement dit, IPv6 se comporte toujours comme si DF=1). L'en-tête de fragment IPv6 n'est présent que lorsqu'un datagramme a été fragmenté, ou lorsque la source a reçu un message d'erreur ICMPv6 « packet too big » indiquant que le chemin ne peut pas prendre en charge la MTU IPv6 minimale requise de 1280 octets et est donc sujet à traduction [RFC2460] [RFC4443]. Ce dernier cas n'est pertinent que pour les datagrammes IPv6 envoyés vers des destinations IPv4 afin de permettre une fragmentation ultérieure après la traduction en IPv4.
À l'exception de ces deux cas, le champ ID n'est pas présent pour les datagrammes non fragmentés ; ainsi, il n'a de sens que pour les datagrammes déjà fragmentés ou les datagrammes destinés à être fragmentés dans le cadre d'une traduction IPv4. Enfin, le champ ID d'IPv6 est de 32 bits et doit être unique par paire adresse source/adresse de destination pour IPv6, alors que pour IPv4 il n'est que de 16 bits et doit être unique par triplet adresse source/adresse de destination/protocole.
Ce document se concentre sur les problèmes du champ ID d'IPv4, car en IPv6 ce champ est plus grand et n'est présent que dans les fragments.
3.1. Uses of the IPv4 ID Field (Utilisations du champ ID d'IPv4)
Le champ ID d'IPv4 était à l'origine destiné à la fragmentation et au réassemblage [RFC791]. Pour une adresse source, une adresse de destination et un protocole donnés, les fragments d'un datagramme d'origine sont mis en correspondance en fonction de leur ID IPv4. Cela exige que les ID soient uniques au sein du triplet adresse source/adresse de destination/protocole lorsque la fragmentation est possible (par exemple, DF=0) ou lorsqu'elle s'est déjà produite (par exemple, frag_offset>0 ou MF=1).
D'autres utilisations ont été envisagées pour le champ ID d'IPv4. Ce champ a été proposé comme moyen de détecter et de supprimer les datagrammes en double, par exemple sur des routeurs congestionnés (mentionné à la section 3.2.1.5 de [RFC1122]) ou dans des accélérateurs réseau. Il a également été proposé de l'utiliser sur les hôtes d'extrémité pour réduire l'impact de la duplication sur les protocoles de couche supérieure (par exemple, un traitement supplémentaire dans TCP ou la nécessité d'une suppression des doublons au niveau applicatif dans UDP). Ce point est examiné plus en détail à la section 5.1.
Le champ ID d'IPv4 est utilisé dans certains outils de diagnostic pour corréler des datagrammes mesurés à divers endroits le long d'un chemin réseau. Cela est déjà insuffisant en IPv6, car les datagrammes non fragmentés sont dépourvus d'ID ; ces outils sont donc déjà mis à jour pour éviter une telle dépendance au champ ID. Ce point est également examiné plus en détail à la section 5.1.
L'ID doit clairement être unique (au sein de la MDL, au sein du triplet adresse source/adresse de destination/protocole) pour prendre en charge la fragmentation et le réassemblage, mais tous les datagrammes ne sont pas fragmentés ni ne permettent la fragmentation. Ce document déprécie les utilisations autres que la fragmentation, ce qui permet à l'ID d'être répété (au sein de la MDL, au sein du triplet adresse source/adresse de destination/protocole) dans ces cas.
3.2. Background on IPv4 ID Reassembly Issues (Contexte des problèmes de réassemblage de l'ID IPv4)
Ce qui suit est un résumé des problèmes liés au réassemblage des fragments IPv4 dans les environnements à haut débit, soulevés précédemment [RFC4963]. Les lecteurs sont encouragés à consulter le RFC 4963 pour une discussion plus détaillée de ces problèmes.
Avec la taille maximale de datagramme IPv4 de 64 Ko, un champ ID de 16 bits qui ne se répète pas dans les 120 secondes signifie que l'agrégat de toutes les connexions TCP d'un protocole donné entre deux points d'extrémité IP est limité à environ 286 Mbps ; à une MTU plus typique de 1500 octets, cette vitesse tombe à 6,4 Mbps [RFC791] [RFC1122] [RFC4963]. Cette limite s'applique actuellement à tous les datagrammes IPv4 d'un même protocole (c'est-à-dire du champ protocole IPv4) entre deux adresses IP, que la fragmentation soit activée ou inhibée et qu'un datagramme soit fragmenté ou non.
IPv6, même à des MTU typiques, est capable de 18,7 Tbps avec fragmentation entre deux points d'extrémité IP en tant qu'agrégat sur tous les protocoles, en raison du champ ID de 32 bits plus grand (et du fait que le champ next-header d'IPv6, l'équivalent du champ protocole d'IPv4, n'est pas pris en compte pour différencier les fragments). Lorsque la fragmentation n'est pas utilisée, le champ est absent, et dans ce cas les vitesses d'IPv6 ne sont pas limitées par l'unicité du champ ID.
Notez également que 120 secondes n'est qu'une estimation de la MDL. Elle est liée au délai de réassemblage comme borne inférieure et à la durée de vie maximale d'un segment TCP (Maximum Segment Lifetime) comme borne supérieure (toutes deux comme indiqué dans [RFC1122]). Des délais réseau sont introduits d'autres manières, par exemple par les liaisons satellite, qui peuvent ajouter des secondes de délai même si le Time to Live (TTL) n'est pas décrémenté d'une quantité correspondante. Il n'existe donc aucun mécanisme d'application pour garantir que les datagrammes de plus de 120 secondes soient écartés.
Les dispositifs Internet sans fil sont fréquemment connectés à des débits supérieurs à 54 Mbps, et les liaisons filaires de 1 Gbps sont la configuration par défaut depuis plusieurs années. Bien que de nombreux chemins de transport de bout en bout soient limités par la congestion, ces dispositifs atteignent facilement un débit applicatif de plus de 100 Mbps sur les réseaux locaux (par exemple, des débits de transfert de fichiers de disque à disque), et de nombreuses démonstrations de débit avec des systèmes commerciaux sur étagère (COTS) sur des chemins longue distance affichent ces vitesses depuis plus d'une décennie. Cela suggère fortement que l'unicité de l'ID IPv4 est sans objet depuis longtemps.