Aller au contenu principal

1. Introduction

Ce document fait partie d'une paire qui définit et discute les exigences pour les implémentations de systèmes hôtes de la suite de protocoles Internet. Ce RFC couvre les couches de protocole de communication (communication protocol layers) : couche de liaison (link layer), couche IP (IP layer) et couche de transport (transport layer). Son RFC compagnon, « Requirements for Internet Hosts -- Application and Support » [INTRO:1], couvre les protocoles de la couche application. Ce document devrait également être lu en conjonction avec « Requirements for Internet Gateways » [INTRO:2].

Ces documents sont destinés à fournir des conseils aux fournisseurs, implémenteurs et utilisateurs de logiciels de communication Internet. Ils représentent le consensus d'un grand corpus d'expérience technique et de sagesse, contribué par les membres des communautés de recherche et de fournisseurs Internet.

Ce RFC énumère les protocoles standard qu'un hôte connecté à Internet doit (MUST) utiliser, et il incorpore par référence les RFC et autres documents décrivant les spécifications actuelles pour ces protocoles. Il corrige les erreurs dans les documents référencés et ajoute des discussions et des conseils supplémentaires pour un implémenteur.

Pour chaque protocole, ce document contient également un ensemble explicite d'exigences, de recommandations et d'options. Le lecteur doit comprendre que la liste des exigences dans ce document est incomplète en elle-même ; l'ensemble complet des exigences pour un hôte Internet est principalement défini dans les documents de spécification de protocole standard, avec les corrections, modifications et suppléments contenus dans ce RFC.

Une implémentation de bonne foi des protocoles qui a été produite après lecture attentive des RFC et avec une certaine interaction avec la communauté technique Internet, et qui a suivi de bonnes pratiques d'ingénierie logicielle de communication, devrait différer des exigences de ce document que de manière mineure. Ainsi, dans de nombreux cas, les « exigences » dans ce RFC sont déjà énoncées ou impliquées dans les documents de protocole standard, de sorte que leur inclusion ici est, dans un certain sens, redondante. Cependant, elles ont été incluses parce que certaines implémentations passées ont fait le mauvais choix, causant des problèmes d'interopérabilité, de performance et/ou de robustesse.

Ce document comprend une discussion et une explication de nombreuses exigences et recommandations. Une simple liste d'exigences serait dangereuse, car :

  • Certaines fonctionnalités requises sont plus importantes que d'autres, et certaines fonctionnalités sont optionnelles (optional).
  • Il peut y avoir des raisons valables pour lesquelles des produits de fournisseurs particuliers conçus pour des contextes restreints pourraient choisir d'utiliser des spécifications différentes.

Cependant, les spécifications de ce document doivent (MUST) être suivies pour atteindre l'objectif général d'interopération arbitraire d'hôtes à travers la diversité et la complexité du système Internet. Bien que la plupart des implémentations actuelles ne respectent pas ces exigences de diverses manières, certaines mineures et certaines majeures, cette spécification est l'idéal vers lequel nous devons avancer.

Ces exigences sont basées sur le niveau actuel de l'architecture Internet. Ce document sera mis à jour selon les besoins pour fournir des clarifications supplémentaires ou pour inclure des informations supplémentaires dans les domaines où les spécifications évoluent encore.

Cette section d'introduction commence par un bref aperçu de l'architecture Internet en ce qui concerne les hôtes, puis donne quelques conseils généraux aux fournisseurs de logiciels hôtes. Enfin, il y a quelques conseils sur la lecture du reste du document et une certaine terminologie.

1.1 L'architecture Internet (The Internet Architecture)

Les informations générales et la discussion sur l'architecture Internet et la suite de protocoles de support peuvent être trouvées dans le DDN Protocol Handbook [INTRO:3] ; pour le contexte, voir par exemple [INTRO:9], [INTRO:10] et [INTRO:11]. La référence [INTRO:5] décrit la procédure pour obtenir des documents de protocole Internet, tandis que [INTRO:6] contient une liste des numéros attribués dans les protocoles Internet.

1.1.1 Hôtes Internet (Internet Hosts)

Un ordinateur hôte, ou simplement « hôte (host) », est le consommateur ultime des services de communication. Un hôte exécute généralement des programmes d'application au nom d'utilisateur(s), employant des services de communication réseau et/ou Internet pour soutenir cette fonction. Un hôte Internet correspond au concept de « système terminal (End-System) » utilisé dans la suite de protocoles OSI [INTRO:13].

1.1.2 Hypothèses architecturales (Architectural Assumptions)

L'architecture Internet est basée sur un ensemble spécifique d'hypothèses concernant le système de communication, et les implémentations doivent (MUST) refléter ces hypothèses. Les principales hypothèses architecturales sont les suivantes :

  • Internet est un système distribué à grande échelle : Il n'y a pas de contrôle central ; au lieu de cela, il y a des domaines administratifs autonomes, ou « systèmes autonomes (Autonomous Systems, AS) ».
  • Hétérogénéité : Internet est construit à partir de nombreux systèmes de communication différents, y compris différentes technologies de liaison de données et différentes implémentations de routeur.
  • Robustesse : Le système doit continuer à fonctionner face aux défaillances de composants.

1.1.3 Suite de protocoles Internet (Internet Protocol Suite)

Pour communiquer en utilisant le système Internet, un hôte doit (MUST) implémenter l'ensemble de protocoles en couches comprenant la suite de protocoles Internet. Un hôte doit généralement implémenter au moins un protocole de chaque couche.

Les couches de protocole utilisées dans l'architecture Internet sont :

  • Couche application (Application Layer)
  • Couche transport (Transport Layer)
  • Couche Internet (Internet Layer)
  • Couche de liaison (Link Layer)

1.1.4 Code de passerelle embarqué (Embedded Gateway Code)

Certains hôtes Internet seront connectés à des réseaux qui ont été désignés comme réseaux stub. Un réseau stub est défini comme un réseau qui ne transporte du trafic que pour les hôtes directement connectés à lui. Des exemples courants de réseaux stub sont les LAN départementaux.

1.2 Considérations générales (General Considerations)

1.2.1 Évolution continue d'Internet (Continuing Internet Evolution)

Le système Internet a grandi et évolué continuellement depuis ses débuts dans l'ARPANET il y a plus de 20 ans. Les exigences et spécifications d'implémentation doivent donc être flexibles pour s'adapter au changement continu.

1.2.2 Principe de robustesse (Robustness Principle)

À chaque couche des protocoles, il existe une règle générale dont l'application peut conduire à d'énormes avantages en robustesse et interopérabilité :

« Soyez libéral dans ce que vous acceptez, et conservateur dans ce que vous envoyez »

Le logiciel devrait être écrit pour gérer toutes les erreurs concevables, peu importe leur improbabilité ; tôt ou tard, un paquet arrivera avec cette combinaison particulière d'erreurs et d'attributs, et à moins que le logiciel ne soit préparé, le chaos peut s'ensuivre. En général, il est préférable de supposer que le réseau est rempli d'entités malveillantes qui enverront des paquets conçus pour avoir le pire effet possible. Cette hypothèse conduira à une conception de protection appropriée.

1.2.3 Journalisation des erreurs (Error Logging)

La suite de protocoles Internet comprend plusieurs mécanismes pour signaler les erreurs à l'hôte source. Cependant, toutes les erreurs ne sont pas signalées par des mécanismes de protocole ; certaines sont simplement enregistrées localement dans le système hôte. La sophistication de la facilité de journalisation des erreurs et les détails de son utilisation peuvent varier d'un système à l'autre.

1.2.4 Configuration

La configuration d'un système hôte n'est généralement pas spécifiée par les documents de protocole Internet. Cependant, il existe certains paramètres de configuration qui doivent être configurables dans n'importe quel hôte Internet.

1.3 Lecture de ce document (Reading this Document)

1.3.1 Organisation

Ce document couvre les domaines principaux suivants :

  • Couche de liaison (Link Layer) (Section 2)
  • Protocoles de couche Internet (Internet Layer protocols) (Section 3)
  • Protocoles de couche transport (Transport Layer protocols) (Section 4)

1.3.2 Exigences (Requirements)

Dans ce document, les mots utilisés pour définir l'importance de chaque exigence particulière sont en majuscules. Ces mots sont :

  • MUST : Ce mot ou l'adjectif « REQUIRED » signifie que l'élément est une exigence absolue de la spécification.
  • SHOULD : Ce mot ou l'adjectif « RECOMMENDED » signifie qu'il peut exister des raisons valables dans des circonstances particulières pour ignorer cet élément, mais les implications complètes doivent être comprises et le cas soigneusement pesé avant de choisir un cours différent.
  • MAY : Ce mot ou l'adjectif « OPTIONAL » signifie que cet élément est vraiment optionnel.

1.3.3 Terminologie (Terminology)

Ce document utilise les termes techniques suivants :

  • Segment : Un segment est l'unité de transmission de bout en bout dans le protocole TCP.
  • Message : Dans cette description des protocoles de couche inférieure, un message est l'unité de transmission dans un protocole de couche transport.
  • Datagramme (Datagram) : Un datagramme est un paquet IP.
  • Paquet (Packet) : Un paquet est tout bloc formaté de données.
  • Trame (Frame) : Une trame est un paquet de couche de liaison.
  • Réseau connecté (Connected Network) : Un réseau connecté est tout réseau auquel un hôte est interfacé, que ce soit physiquement, virtuellement ou logiquement.
  • Multihomed : Un hôte est dit multihomed s'il a plusieurs adresses IP.

1.4 Remerciements (Acknowledgments)

Ce document incorpore des contributions et des commentaires de nombreux membres de la communauté Internet.