Aller au contenu principal

6. Updates to Existing Standards (Mises à jour des normes existantes)

Les sections suivantes traitent des changements spécifiques apportés aux protocoles existants, indiqués par ce document.

6.1. Updates to RFC 791 (Mises à jour du RFC 791)​

Le RFC 791 indique que :

Le module de protocole d'origine d'un datagramme Internet fixe le champ identification à une valeur qui doit être unique pour cette paire source-destination et ce protocole pendant la durée où le datagramme sera actif dans le système Internet.

Il indique ensuite que :

Ainsi, l'émetteur doit choisir l'identificateur de manière qu'il soit unique pour cette paire source-destination et ce protocole pendant la durée où le datagramme (ou l'un de ses fragments) pourrait être vivant dans Internet.

Il semble donc qu'un module de protocole émetteur doive tenir une table d'identificateurs, avec une entrée pour chaque destination avec laquelle il a communiqué au cours de la dernière durée de vie maximale d'un datagramme pour Internet.

Toutefois, comme le champ identificateur autorise 65 536 valeurs différentes, certains hôtes peuvent peut-être simplement utiliser des identificateurs uniques indépendamment de la destination.

Il est approprié que certains protocoles de niveau supérieur choisissent l'identificateur. Par exemple, les modules de protocole TCP peuvent retransmettre un segment TCP identique, et la probabilité d'une réception correcte serait améliorée si la retransmission portait le même identificateur que la transmission d'origine, puisque les fragments de l'un ou l'autre datagramme pourraient être utilisés pour construire un segment TCP correct.

Ce document modifie le RFC 791 comme suit :

  • L'unicité de l'ID IPv4 ne s'applique qu'aux datagrammes non atomiques.
  • Les datagrammes IPv4 non atomiques retransmis ne sont plus autorisés à réutiliser la valeur d'ID.

6.2. Updates to RFC 1122 (Mises à jour du RFC 1122)​

Le RFC 1122 indique, à la section 3.2.1.5 (« Identification : RFC 791 Section 3.2 »), que :

Lors de l'envoi d'une copie identique d'un datagramme antérieur, un hôte PEUT (MAY) éventuellement conserver le même champ Identification dans la copie.

DISCUSSION:

Certains experts des protocoles Internet ont soutenu que, lorsqu'un hôte envoie une copie identique d'un datagramme antérieur, la nouvelle copie devrait contenir la même valeur d'Identification que l'original. Deux avantages ont été suggérés : (1) si les datagrammes sont fragmentés et que certains fragments sont perdus, le récepteur peut être en mesure de reconstruire un datagramme complet à partir des fragments de l'original et des copies ; (2) une passerelle congestionnée pourrait utiliser le champ IP Identification (et le décalage de fragment) pour écarter de la file d'attente les datagrammes en double.

Ce document modifie le RFC 1122 comme suit :

  • Le champ ID d'IPv4 n'est plus autorisé à être utilisé pour la détection des doublons. Cela s'applique à la fois aux datagrammes atomiques et non atomiques.
  • Les datagrammes IPv4 non atomiques retransmis ne sont plus autorisés à réutiliser la valeur d'ID.

6.3. Updates to RFC 2003 (Mises à jour du RFC 2003)​

Ce document met à jour la manière dont les tunnels IPv4-in-IPv4 créent les valeurs d'ID IPv4 pour l'en-tête externe IPv4 [RFC2003], mais uniquement de la même manière que pour toute autre source de datagrammes IPv4. Plus précisément, le RFC 2003 indique ce qui suit, où [10] désigne le RFC 791 :

Identification, indicateurs (Flags), décalage de fragment (Fragment Offset)

Ces trois champs sont définis comme spécifié dans [10]...

Ce document modifie le RFC 2003 comme suit :

  • Le champ ID d'IPv4 est défini comme le permet le RFC 6864.