5. Impact of Proposed Changes (Impact des changements proposés)
Cette section examine l'impact des changements proposés sur les dispositifs hérités, la génération de datagrammes dans les dispositifs mis à jour, les boîtiers intermédiaires (middleboxes) et la compression d'en-tête.
5.1. Impact on Legacy Internet Devices (Impact sur les dispositifs Internet hérités)
Les utilisations héritées du champ ID d'IPv4 comprennent la génération de fragments, le réassemblage de fragments, la détection des datagrammes en double et des utilisations « autres ».
Les dispositifs actuels génèrent déjà des valeurs d'ID qui sont réutilisées au sein du triplet adresse source/adresse de destination/protocole en moins de deux minutes, la MDL Internet actuellement estimée. Ils supposent que la MDL sur leur chemin de bout en bout est bien plus faible.
Certains dispositifs existants sont connus pour générer des ID invariables pour les datagrammes atomiques depuis près d'une décennie, notamment certains téléphones cellulaires. Ces valeurs d'ID constantes sont la raison de leur prise en charge comme optimisation de ROHC [RFC5225]. Ce point est examiné plus en détail à la section 5.4. La génération de datagrammes IPv4 avec des ID constants (nuls) est également décrite dans le cadre de la norme de traduction IP/ICMP [RFC6145].
De nombreux dispositifs actuels prennent en charge une fragmentation qui ignore le bit « Don't Fragment » (DF) d'IPv4. De tels dispositifs font déjà transiter du trafic provenant de sources qui réutilisent l'ID. Si des fragments de datagrammes différents réutilisant le même ID (au sein du triplet adresse source/adresse de destination/protocole) arrivent entrelacés à la destination, la fragmentation échouerait et le trafic serait abandonné. Soit cet entrelacement est rare, soit le trafic de ces dispositifs ne traverse pas largement ces dispositifs ignorant DF, car aucune occurrence significative d'erreurs de réassemblage n'a été signalée. Les dispositifs ignorant DF ne sont pas conformes aux normes existantes, et il n'est pas réalisable de mettre à jour les normes pour les considérer comme conformes.
Le champ ID a été envisagé pour une utilisation dans la détection des doublons, comme discuté à la section 4.1. Bien que ce document autorise désormais la réutilisation de l'ID IPv4 pour les datagrammes atomiques, une telle réutilisation est déjà courante (comme indiqué ci-dessus). Les accélérateurs de protocole sont connus pour implémenter la détection des doublons IPv4, mais ces dispositifs sont également connus pour violer d'autres normes Internet afin d'obtenir de meilleures performances de bout en bout. Ces dispositifs présenteraient déjà des abandons erronés pour ce trafic actuel, et cela n'a pas été signalé.
Il existe d'autres utilisations potentielles du champ ID, notamment à des fins de diagnostic. De telles utilisations doivent déjà composer avec des datagrammes atomiques dont le champ ID est réutilisé. Aucun rapport ne fait état de problèmes rencontrés par ces utilisations avec les datagrammes actuels qui réutilisent les ID.
Ainsi, en raison des exigences précédentes, ce document recommande que les mécanismes de détection des doublons et de diagnostic IPv4 appliquent des méthodes compatibles avec IPv6, c'est-à-dire des méthodes qui ne reposent pas sur le champ ID (par exemple, comme suggéré dans [RFC6621]). Cela découle de l'utilisation du champ ID uniquement pour le réassemblage, ainsi que du danger connu que représentent les dispositifs existants qui réutilisent déjà le champ ID.
5.2. Impact on Datagram Generation (Impact sur la génération de datagrammes)
Ce qui suit est un résumé des recommandations résultant des changements précédents apportés à la spécification du champ ID d'IPv4.
Comme les datagrammes atomiques peuvent utiliser des valeurs d'ID IPv4 arbitraires, le champ ID n'impose plus d'impact sur les performances dans ces cas. Toutefois, l'impact sur les performances subsiste pour les datagrammes non atomiques. En conséquence :
Les sources de datagrammes IPv4 non atomiques DOIVENT (MUST) limiter leur débit pour se conformer aux exigences d'unicité de l'ID. Ces sources incluent, en particulier, DNS sur UDP [RFC2671].
Comme il n'existe pas de définition stricte de la MDL, des dangers de réassemblage existent indépendamment de l'intervalle de réutilisation de l'ID IPv4 ou du délai de réassemblage. En conséquence :
Les protocoles de couche supérieure DEVRAIENT (SHOULD) vérifier l'intégrité des datagrammes IPv4, par exemple à l'aide d'une somme de contrôle ou d'un hachage capable de détecter les erreurs de réassemblage (les sommes de contrôle UDP et TCP sont faibles à cet égard, mais c'est mieux que rien).
Des contrôles d'intégrité supplémentaires peuvent être employés à l'aide de tunnels, comme le prend en charge la couche Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], IPsec [RFC4301] ou le Stream Control Transmission Protocol (SCTP) [RFC4960]. De tels contrôles peuvent éviter les dangers de réassemblage qui peuvent survenir lors de l'utilisation des sommes de contrôle UDP et TCP [RFC4963] ou lors de l'utilisation de sommes de contrôle partielles comme dans UDP-Lite [RFC3828]. Comme ces contrôles d'intégrité peuvent éviter l'impact des erreurs de réassemblage :
Les sources de datagrammes IPv4 non atomiques utilisant des contrôles d'intégrité forts PEUVENT (MAY) réutiliser l'ID dans des intervalles plus courts que les valeurs de MDL typiques.
Notez toutefois qu'une telle réutilisation fréquente peut encore entraîner un réassemblage corrompu et un faible débit, bien qu'elle ne propage pas les erreurs de réassemblage aux protocoles de couche supérieure.
5.3. Impact on Middleboxes (Impact sur les boîtiers intermédiaires)
Les boîtiers intermédiaires comprennent les dispositifs de réécriture tels que les traducteurs d'adresses réseau (NAT), les traducteurs d'adresses/ports réseau (NAPT) et d'autres mécanismes de partage d'adresses (ASM). Ils comprennent également les dispositifs qui inspectent et filtrent les datagrammes mais qui ne sont pas des routeurs, tels que les accélérateurs et les pare-feu.
Les changements proposés dans ce document peuvent ne pas être implémentés par les boîtiers intermédiaires ; toutefois, ces changements sont plus susceptibles de rendre le comportement actuel des boîtiers intermédiaires conforme que d'affecter le service fourni par ces dispositifs.
5.3.1. Rewriting Middleboxes (Boîtiers intermédiaires de réécriture)
Les NAT et les NAPT réécrivent des champs IP, et les entrées de tunnel (utilisant l'encapsulation IPv4) copient et modifient certains champs IPv4 ; tous sont donc considérés comme des sources de datagrammes, tout comme les dispositifs qui réécrivent une partie quelconque du quadruplet adresse source/adresse de destination/protocole/ID pour des datagrammes [RFC3022]. Il en va de même pour d'autres ASM, notamment IPv4 Residual Deployment (4rd) [De11], IVI [RFC6219] et d'autres de la famille « A+P » (adresse plus port) [Bo11]. Cela vaut également pour tout autre mécanisme de réécriture de datagrammes. En conséquence, ils sont soumis à toutes les exigences de toute source de datagrammes, comme cela a été noté.
Les NAT/ASM/réécrivains présentent une situation particulièrement difficile pour la fragmentation. Comme ils écrasent des parties du quadruplet de réassemblage dans les deux sens, ils peuvent détruire l'unicité du quadruplet et entraîner un danger de réassemblage. Chaque fois que les champs d'adresse source, d'adresse de destination ou de protocole IPv4 sont modifiés, un NAT/ASM/réécrivain doit s'assurer que le champ ID est généré de manière appropriée, plutôt que simplement copié depuis le datagramme entrant.
Plus précisément :
Les dispositifs de partage d'adresses ou de réécriture DOIVENT (MUST) s'assurer que le champ ID d'IPv4 des datagrammes dont les adresses ou les protocoles sont traduits est conforme à ces exigences, comme si le datagramme provenait de ce dispositif.
Cette conformité signifie que le champ ID d'IPv4 des datagrammes non atomiques traduits au niveau d'un NAT/ASM/réécrivain doit obéir aux exigences d'unicité de toute source de datagrammes IPv4. Malheureusement, les fragments traduits violent déjà cette exigence, car ils répètent un ID IPv4 au sein de la MDL pour un triplet adresse source/adresse de destination/protocole donné.
De tels problèmes liés à la transmission de fragments à travers des NAT/ASM/réécrivains sont déjà connus ; la traduction est généralement fondée sur le numéro de port de transport, qui n'est de toute façon présent que dans le premier fragment [RFC3022]. Ce document souligne que non seulement le réassemblage (et éventuellement la fragmentation ultérieure) est nécessaire à la traduction, mais qu'il peut être utilisé pour éviter les problèmes d'unicité de l'ID IPv4.
Notez que les NAT/ASM doivent déjà faire preuve d'une prudence particulière lorsqu'ils émettent des datagrammes du côté public, car la fusion de datagrammes provenant de nombreuses sources sur une seule adresse source sortante peut entraîner des collisions d'ID IPv4. Cette situation est antérieure à ce document et n'est pas affectée par celui-ci. Elle est exacerbée dans les NAT à grande échelle, dits « carrier grade » [Pe11].
Les entrées de tunnel agissent comme des sources pour l'en-tête le plus externe, mais les tunnels agissent comme des routeurs pour les en-têtes internes (c'est-à-dire le datagramme tel qu'il arrive à l'entrée du tunnel). Les entrées peuvent toujours fragmenter en tant que sources d'origine de l'en-tête externe, car elles contrôlent l'unicité de ce champ ID IPv4 et la valeur de DF sur l'en-tête externe indépendamment de ces valeurs sur l'en-tête interne (du datagramme entrant).
5.3.2. Filtering Middleboxes (Boîtiers intermédiaires de filtrage)
Les boîtiers intermédiaires comprennent également des dispositifs qui filtrent les datagrammes, tels que les accélérateurs réseau et les pare-feu. Certains de ces dispositifs seraient dotés d'une déduplication des datagrammes qui repose sur l'unicité de l'ID IP pour identifier les doublons, ce qui a été discuté à la section 5.1.
5.4. Impact on Header Compression (Impact sur la compression d'en-tête)
Les algorithmes de compression d'en-tête prennent déjà en compte les diverses manières dont l'ID IPv4 change entre des datagrammes successifs [RFC1144] [RFC2508] [RFC3545] [RFC5225]. Ces algorithmes supposent actuellement que l'ID IPv4 est préservé de bout en bout. Certains algorithmes autorisent déjà l'hypothèse que l'ID ne change pas (par exemple, ROHC [RFC5225]), tandis que d'autres incluent des ID invariables au moyen de deltas nuls (par exemple, Enhanced Compressed RTP (ECRTP) [RFC3545]).
Lorsque la compression suppose par défaut un ID changeant, le fait d'avoir un ID invariable peut rendre la compression moins efficace. De tels ID invariables ont été décrits dans divers RFC (par exemple, la note de bas de page 21 de [RFC1144] et cRTP [RFC2508]). Lorsque la compression peut supposer un ID IPv4 invariable -- comme avec ROHC et ECRTP -- l'efficacité peut être accrue.
5.5. Impact of Network Reordering and Loss (Impact du réordonnancement et des pertes réseau)
La tolérance au réordonnancement et aux pertes dans le réseau est une caractéristique essentielle de l'architecture Internet. Bien que la plupart des réseaux IP actuels évitent de tels événements gratuits, le réordonnancement et les pertes peuvent se produire et se produisent effectivement. Les datagrammes sont déjà censés pouvoir être réordonnés ou perdus, et la récupération de ces erreurs (lorsqu'elle est prise en charge) se produit déjà aux couches de transport ou supérieures.
Le réordonnancement est généralement associé à des transitoires de routage ou au fractionnement des flux sur plusieurs chemins. Les pertes sont généralement associées à la congestion du chemin ou à une défaillance de liaison (partielle ou totale). L'impact de ces événements est différent pour les datagrammes atomiques et non atomiques et est examiné ci-dessous. En résumé, les recommandations de ce document rendent Internet plus robuste au réordonnancement et aux pertes en mettant l'accent sur les exigences d'unicité de l'ID pour les datagrammes non atomiques et en indiquant plus clairement l'impact de ces exigences sur les deux extrémités et sur les dispositifs de transit de datagrammes.
5.5.1. Atomic Datagrams Experiencing Reordering or Loss (Datagrammes atomiques subissant un réordonnancement ou des pertes)
La réutilisation des valeurs d'ID n'affecte pas les datagrammes atomiques lorsque le bit DF est correctement respecté, car la restauration de l'ordre ne dépend pas de l'en-tête du datagramme. TCP utilise un numéro de séquence dans l'en-tête de transport ; dans certains autres protocoles, la séquence est indiquée et restaurée au niveau de la couche applicative.
Lorsque DF=1 est ignoré, un réordonnancement ou une perte peut amener des fragments de datagrammes différents à s'entrelacer et donc à être réassemblés de manière incorrecte puis abandonnés. La réutilisation des valeurs d'ID dans les datagrammes atomiques, telle que permise par ce document, peut entraîner une perte de datagrammes plus élevée dans de tels cas. De telles situations peuvent déjà exister, car certains dispositifs connus utilisent un ID constant pour les datagrammes atomiques (certains téléphones cellulaires) et certains dispositifs connus ignorent DF=1, mais des niveaux élevés de pertes correspondantes n'ont pas été signalés. L'absence de tels rapports indique soit une absence de réordonnancement ou de perte dans ces cas, soit une tolérance aux pertes qui en résultent. Si de tels problèmes étaient signalés, il serait plus productif de traiter les dispositifs non conformes (qui ignorent DF=1), car il n'est pas pratique de définir des spécifications Internet pour tolérer des dispositifs qui ignorent ces spécifications. C'est pourquoi ce document souligne la nécessité de respecter DF=1, ainsi que la nécessité pour les dispositifs de transit de datagrammes de conserver le bit DF tel que reçu (c'est-à-dire plutôt que de l'effacer).
5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss (Datagrammes non atomiques subissant un réordonnancement ou des pertes)
Les datagrammes non atomiques reposent sur l'unicité de la valeur d'ID pour tolérer le réordonnancement des fragments, notamment lorsque des fragments de datagrammes différents s'entrelacent à la suite d'un tel réordonnancement. La perte de fragments peut entraîner le réassemblage de fragments provenant de datagrammes d'origine différents, ce qui explique pourquoi la réutilisation de l'ID dans les datagrammes non atomiques est fondée sur la durée de vie maximale du datagramme (fragment), et non simplement sur l'entrelacement attendu dû au réordonnancement.
Ce document ne modifie pas les exigences d'unicité des ID dans les datagrammes non atomiques et n'affecte donc pas leur tolérance à un tel réordonnancement ou à de telles pertes. Ce document souligne la nécessité de l'unicité de l'ID pour toutes les sources de datagrammes, y compris les boîtiers intermédiaires de réécriture ; la nécessité de limiter le débit des sources pour garantir l'unicité de l'ID ; la nécessité de ne pas réutiliser l'ID pour les datagrammes retransmis ; et la nécessité d'utiliser des contrôles d'intégrité de couche supérieure pour éviter les erreurs de réassemblage -- tout cela se traduit par une meilleure tolérance aux événements de réordonnancement ou de perte.