Aller au contenu principal

4. Updates to the IPv4 ID Specification (Mises à jour de la spécification IPv4 ID)

Ce document met à jour la spécification du champ ID d'IPv4 de trois manières distinctes, examinées dans les sous-sections suivantes :

  • Utiliser le champ ID d'IPv4 uniquement pour la fragmentation
  • Encourager un fonctionnement sûr lorsque le champ ID d'IPv4 est utilisé
  • Éviter un impact sur les performances lorsque le champ ID d'IPv4 est utilisé

Il existe deux types de datagrammes, définis ci-dessous et utilisés dans la discussion qui suit :

  • Les datagrammes atomiques sont des datagrammes qui ne sont pas encore fragmentés et pour lesquels toute fragmentation ultérieure a été inhibée.
  • Les datagrammes non atomiques sont des datagrammes qui ont déjà été fragmentés ou pour lesquels la fragmentation reste possible.

Cette même définition peut être exprimée en pseudo-code, à l'aide des opérateurs logiques courants (l'égalité est ==, le « et » logique est &&, le « ou » logique est ||, le supérieur à est >, et la fonction parenthèse est utilisée de manière habituelle) comme suit :

  • Datagrammes atomiques : (DF==1)&&(MF==0)&&(frag_offset==0)
  • Datagrammes non atomiques : (DF==0)||(MF==1)||(frag_offset>0)

Le test des datagrammes non atomiques est le négatif logique du test des datagrammes atomiques ; ainsi, toutes les possibilités sont prises en compte.

4.1. IPv4 ID Used Only for Fragmentation (IPv4 ID utilisé uniquement pour la fragmentation)​

Bien que le RFC 1122 suggère que le champ ID d'IPv4 ait d'autres utilisations, notamment la déduplication des datagrammes, ces utilisations ne sont déjà pas interopérables avec les implémentations connues de sources qui ne font pas varier leur ID. Ce document ne définit donc la valeur de ce champ que pour la fragmentation et le réassemblage :

Le champ ID d'IPv4 NE DOIT PAS (MUST NOT) être utilisé à des fins autres que la fragmentation et le réassemblage.

La déduplication des datagrammes peut toujours être réalisée à l'aide d'une détection des doublons fondée sur un hachage dans les cas où le champ ID est absent (datagrammes IPv6 non fragmentés), laquelle peut également être appliquée aux datagrammes atomiques IPv4 sans utiliser le champ ID [RFC6621].

Dans les datagrammes atomiques, le champ ID d'IPv4 n'a aucune signification ; il peut donc être mis à une valeur arbitraire, c'est-à-dire que l'exigence d'ID non répétitifs au sein du triplet adresse source/adresse de destination/protocole n'est plus requise pour les datagrammes atomiques :

Les sources d'origine PEUVENT (MAY) mettre le champ ID d'IPv4 des datagrammes atomiques à n'importe quelle valeur.

Deuxièmement, tous les nœuds réseau, qu'il s'agisse de routeurs intermédiaires, d'hôtes de destination ou d'autres dispositifs (par exemple, les NAT et autres mécanismes de partage d'adresses, les pare-feu, les sorties de tunnel), ne peuvent pas se fier au champ des datagrammes atomiques :

Tous les dispositifs qui examinent les en-têtes IPv4 DOIVENT (MUST) ignorer le champ ID d'IPv4 des datagrammes atomiques.

Le champ ID d'IPv4 n'a donc de sens que pour les datagrammes non atomiques -- soit les datagrammes qui ont déjà été fragmentés, soit ceux pour lesquels la fragmentation reste autorisée. Les datagrammes atomiques sont détectés par leurs champs DF, MF et décalage de fragmentation comme expliqué à la section 4, car un tel test est entièrement rétrocompatible ; ainsi, ce document ne réserve aucune valeur d'ID IPv4, y compris 0, comme distinguée.

Déprécier l'utilisation du champ ID d'IPv4 pour des usages autres que le réassemblage ne devrait avoir que peu -- voire aucun -- impact. Les ID IPv4 sont déjà fréquemment répétés, par exemple sur des connexions même modérément rapides et depuis certaines sources qui ne font pas varier l'ID du tout, et aucun impact négatif n'a été observé. La suppression des doublons a été suggérée [RFC1122] et a été implémentée dans certains accélérateurs de protocole, mais aucun impact de la réutilisation de l'ID IPv4 n'a été signalé à ce jour. Les routeurs ne sont pas tenus d'émettre des ICMP selon une échelle de temps particulière, et la répétition de l'ID IPv4 n'aurait donc pas dû être utilisée à des fins de validation ; ce scénario n'a pas été observé. En outre, la répétition se produit déjà et aurait été remarquée [RFC1812]. Le relais ICMP aux entrées de tunnel est spécifié pour utiliser un état temporaire (soft state) plutôt qu'un cache de datagrammes ; pour des raisons similaires, si ce dernier est utilisé, cela aurait dû être remarqué [RFC2003]. Ces problèmes et d'autres problèmes hérités sont examinés plus en détail à la section 5.1.

4.2. Encouraging Safe IPv4 ID Use (Encourager un usage sûr de l'ID IPv4)​

Ce document modifie également la spécification du champ ID d'IPv4 afin d'encourager son usage sûr.

Comme indiqué dans le RFC 1122, si TCP retransmet un segment, il peut être possible de réutiliser l'ID IPv4 (voir la section 6.2). Cela peut rendre difficile pour une source d'éviter la répétition de l'ID IPv4 pour les fragments reçus. Le RFC 1122 conclut que ce comportement « n'est pas utile » ; ce document formalise cette conclusion comme suit :

L'ID IPv4 des datagrammes non atomiques NE DOIT PAS (MUST NOT) être réutilisé lors de l'envoi d'une copie d'un datagramme non atomique antérieur.

Le RFC 1122 suggère également que les fragments peuvent se chevaucher. Un tel chevauchement peut se produire si des retransmissions successives sont fragmentées de manières différentes mais avec le même ID IPv4 de réassemblage. Ce chevauchement est signalé comme le résultat de la réutilisation des ID IPv4 lors de la retransmission de datagrammes, ce que ce document déprécie. Toutefois, il résulte également de la duplication de datagrammes dans le réseau, qui peut encore se produire. En conséquence, ce document ne modifie pas la nécessité pour les récepteurs de prendre en charge les fragments qui se chevauchent.

4.3. IPv4 ID Requirements That Persist (Exigences relatives à l'ID IPv4 qui subsistent)​

Ce document n'assouplit pas les exigences d'unicité du champ ID d'IPv4 de la [RFC791] pour les datagrammes non atomiques, à savoir :

Les sources émettant des datagrammes non atomiques NE DOIVENT PAS (MUST NOT) répéter les valeurs d'ID IPv4 au sein d'une même MDL pour un triplet adresse source/adresse de destination/protocole donné.

Ces sources comprennent les hôtes d'origine, les entrées de tunnel et les NAT (y compris les autres mécanismes de partage d'adresses) (voir la section 5.3).

Ce document n'assouplit pas l'exigence selon laquelle tous les dispositifs réseau doivent respecter le bit DF, à savoir :

Les datagrammes IPv4 dont DF=1 NE DOIVENT PAS (MUST NOT) être fragmentés.

Les dispositifs de transit de datagrammes IPv4 NE DOIVENT PAS (MUST NOT) effacer le bit DF.

Plus précisément, DF=1 empêche la fragmentation des datagrammes atomiques. DF=1 empêche également la fragmentation ultérieure des fragments reçus. La fragmentation dans le réseau n'est autorisée que lorsque DF=0 ; ce document ne modifie pas cette exigence.