1. Introduction (INTRODUCTION)

Ce document, avec un autre document, définit et discute les exigences de l'implémentation des systèmes hôtes du jeu de protocoles Internet. Ce RFC traite des couches de protocole de communication : la couche de liaison, la couche Internet et la couche de transport ; son document compagnon RFC « Exigences pour les hôtes Internet -- Application et support » [INTRO:1] traite des protocoles de la couche applicative. Ce document doit également être lu avec « Exigences pour les passerelles Internet » [INTRO:2].

Ces documents visent à fournir des directives aux fournisseurs, aux implémenteurs et aux utilisateurs de logiciels de communication Internet. Ils représentent un consensus d'expérience technique et de sagesse considérable, contribuée par les membres de la communauté de recherche et des fournisseurs Internet.

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

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

Après avoir lu attentivement le RFC et avoir eu un certain échange avec la communauté technique Internet, en implémentant les protocoles de bonne foi et en suivant les bonnes pratiques de génie logiciel de communication, l'implémentation qui en résulte ne devrait différer des exigences de ce document que de façon mineure. Par conséquent, dans de nombreux cas, les « exigences » de ce RFC ont déjà été énoncées ou impliquées dans les documents de protocole standard, de sorte que les inclure est en un sens redondant. Cependant, elles ont été incluses parce que certaines implémentations passées ont fait de mauvais choix, entraînant des problèmes d'interopérabilité, de performance et/ou de robustesse.

Ce document contient des discussions et des explications de nombreuses exigences et recommandations. Une simple liste d'exigences est dangereuse, car :

• Certaines caractéristiques requises sont plus importantes que d'autres, et certaines caractéristiques sont optionnelles.
• Il peut y avoir de bonnes raisons pour qu'un produit vendeur particulier, conçu pour un environnement contraint, choisisse une spécification différente.

Cependant, pour atteindre l'objectif global d'interopérabilité de n'importe quel hôte sur la diversité et la complexité des systèmes Internet, les normes de ce document doivent être suivies. Bien que la plupart des implémentations actuelles échouent à divers degrés (parfois mineurs, parfois majeurs) à répondre à ces exigences, cette spécification est l'idéal vers lequel nous devrions tendre.

Ces exigences sont basées sur le niveau actuel de l'architecture Internet. Ce fichier sera mis à jour selon les besoins pour fournir des clarifications supplémentaires ou intégrer des informations supplémentaires dans les domaines où les normes sont encore en évolution.

Cette section d'introduction donne d'abord un bref aperçu de l'architecture Internet pertinente pour les hôtes, puis donne quelques conseils généraux aux fournisseurs de logiciels hôtes. Enfin, elle fournit des directives pour la lecture du reste du document et quelques termes.

1.1 L'architecture Internet (The Internet Architecture)

Pour un arrière-plan général et des discussions sur l'architecture Internet et la famille de protocoles sous-jacente, voir le DDN Protocol Handbook [INTRO:3] ; des documents d'arrière-plan incluent par exemple [INTRO:9], [INTRO:10] et [INTRO:11]. La référence [INTRO:5] décrit la procédure d'obtention des documents de protocole Internet, et [INTRO:6] contient la liste des numéros assigné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 final des services de communication. Les hôtes exécutent généralement des applications pour le compte des utilisateurs et utilisent les services de communication réseau et/ou Internet pour prendre en charge cette fonction. Un hôte Internet correspond au concept de « système final (End-System) » utilisé dans la famille de protocoles OSI [INTRO:13].

Un système de communication Internet se compose de réseaux de paquets interconnectés, utilisant les protocoles Internet pour prendre en charge la communication entre les ordinateurs hôtes. Ces réseaux sont interconnectés à l'aide d'ordinateurs à commutation de paquets appelés « passerelles (gateways) » ou « routeurs IP (IP routers) » (terme de la communauté Internet), « systèmes intermédiaires (Intermediate Systems) » (monde OSI) [INTRO:13]. Le RFC « Exigences pour les passerelles Internet » [INTRO:2] contient la spécification officielle des passerelles Internet. Ce RFC, avec ce document et son document compagnon [INTRO:1], définit les règles pour l'implémentation de l'architecture Internet actuelle.

Les hôtes Internet varient considérablement en taille, vitesse et fonction. Leur taille va du microprocesseur à la station de travail, au mainframe et au superordinateur. Sur le plan fonctionnel, ils vont de l'hôte à usage unique (tel qu'un serveur de terminaux) à l'hôte à service complet prenant en charge de nombreux services réseau en ligne, incluant généralement la connexion à distance, le transfert de fichiers et le courrier électronique.

Si un hôte possède plusieurs interfaces vers le même réseau ou des réseaux différents, on l'appelle généralement multihébergé (multihomed). Voir la section 3.3.4 sur le multihébergement.

1.1.2 Hypothèses architecturales (Architectural Assumptions)

L'architecture Internet actuelle repose sur un ensemble d'hypothèses sur les systèmes de communication. Les hypothèses les plus pertinentes pour les hôtes sont les suivantes :

(a) L'Internet est un réseau de réseaux.

Chaque hôte est connecté directement à un réseau particulier ; sa connexion à l'Internet n'est que conceptuelle. Deux hôtes sur le même réseau communiquent en utilisant le même ensemble de protocoles que lorsqu'ils communiquent avec un hôte sur un réseau distant.

(b) Les passerelles ne conservent pas d'informations d'état de connexion.

Pour améliorer la robustesse du système de communication, les passerelles sont conçues pour être sans état, en transférant chaque datagramme IP indépendamment de tout autre datagramme. Par conséquent, des chemins redondants peuvent être utilisés pour fournir un service robuste en cas de défaillance des passerelles et des réseaux intermédiaires.

Toutes les informations d'état nécessaires au contrôle de flux et à la fiabilité de bout en bout sont implémentées dans les hôtes, dans la couche de transport ou l'application. Par conséquent, toutes les informations de contrôle de connexion résident avec les extrémités de communication, de sorte qu'elles ne sont perdues que si une extrémité échoue.

(c) La complexité du routage doit être placée dans les passerelles.

Le routage est un problème complexe et difficile qui doit être exécuté par les passerelles plutôt que par les hôtes. Un objectif important est d'isoler les logiciels hôtes de l'évolution inévitable de l'architecture de routage Internet.

(d) Les systèmes doivent tolérer de grandes différences de réseau.

Un objectif fondamental de la conception Internet est de tolérer une large gamme de caractéristiques de réseau — par exemple la bande passante, la latence, la perte de paquets, le réordonnancement et la taille maximale des paquets. Un autre objectif est la robustesse contre les défaillances individuelles des réseaux, passerelles et hôtes, en exploitant toute la bande passante encore disponible. L'objectif final est l'« interconnexion de systèmes ouverts » complète : un hôte Internet doit pouvoir interopérer de manière robuste et efficace avec tout autre hôte Internet sur des chemins Internet divers.

Parfois, les implémenteurs de hôtes conçoivent pour un objectif moins ambitieux. Par exemple, l'environnement LAN est généralement beaucoup plus doux que l'Internet entier ; les LAN ont une faible perte de paquets, une faible latence et ne réordonnent pas. Certains fournisseurs ont commercialisé des implémentations hôtes uniquement adaptées aux environnements LAN simples, mais qui fonctionnent mal pour l'interopérabilité générale. Les fournisseurs justifient ces produits par l'économie dans les marchés LAN restreints. Cependant, les LAN isolés restent rarement isolés longtemps ; ils sont bientôt connectés les uns aux autres, aux intranets organisationnels, et enfin au système Internet mondial. En fin de compte, les logiciels hôtes Internet incomplets ou non conformes nuisent autant au client qu'au fournisseur.

Les exigences détaillées dans ce document sont conçues pour des hôtes Internet entièrement fonctionnels, capables d'une interopérabilité complète sur n'importe quel chemin Internet.

1.1.3 La suite de protocoles Internet (Internet Protocol Suite)

Pour communiquer à l'aide du système Internet, les hôtes doivent implémenter l'ensemble de protocoles en couches qui composent la suite de protocoles Internet. Les hôtes doivent généralement implémenter au moins un protocole de chaque couche.

Les couches de protocole utilisées dans l'architecture Internet sont les suivantes [INTRO:4] :

Couche applicative (Application Layer)

La couche applicative est le niveau le plus élevé de la suite de protocoles Internet. La suite de protocoles Internet ne subdivise pas davantage la couche applicative, bien que certains protocoles de couche applicative Internet contiennent en effet quelques sous-couches internes. La couche applicative de la suite de protocoles Internet combinaison essentiellement les fonctions des deux couches supérieures du modèle de référence OSI — la couche de présentation et la couche applicative.

Nous distinguons deux classes de protocoles de couche applicative : les protocoles utilisateurs qui fournissent un service direct aux utilisateurs, et les protocoles de support qui fournissent des fonctions système générales. Les exigences pour les protocoles utilisateurs et de support se trouvent dans le RFC compagnon [INTRO:1].

Les protocoles utilisateurs Internet les plus courants sont :

• Telnet (connexion à distance)
• FTP (transfert de fichiers)
• SMTP (livraison de courrier électronique)

Il existe de nombreux autres protocoles utilisateurs standardisés [INTRO:4] ainsi que de nombreux protocoles utilisateurs privés.

Les protocoles de support pour le mappage des noms d'hôtes, le démarrage et la gestion incluent SNMP, BOOTP, RARP et le système de noms de domaine (DNS).

Couche de transport (Transport Layer)

La couche de transport fournit des services de communication de bout en bout aux applications. Il y a actuellement deux protocoles de transport principaux :

• Le protocole de contrôle de transmission (TCP)
• Le protocole de datagramme utilisateur (UDP)

TCP est un service de transport fiable orienté connexion, fournissant la fiabilité de bout en bout, le réordonnancement et le contrôle de flux. UDP est un service de transport sans connexion (« datagramme »).

D'autres protocoles de transport ont été développés par la communauté de recherche, et la collection officielle des protocoles de transport Internet pourrait s'étendre à l'avenir.

Les protocoles de la couche de transport sont discutés au chapitre 4.

Couche Internet (Internet Layer)

Tous les protocoles de transport Internet utilisent le protocole Internet (IP) pour transmettre des données du hôte source au hôte de destination. IP est un service internetwork sans connexion ou datagramme qui ne fournit pas de garantie de livraison de bout en bout. Par conséquent, les datagrammes IP peuvent arriver au hôte de destination corrompus, dupliqués, dans le désordre, ou ne pas arriver du tout. Lorsqu'une fiabilité est requise, les couches au-dessus d'IP sont responsables de fournir un service de livraison fiable. Le protocole IP contient des dispositions pour l'adressage, la spécification du type de service, la fragmentation et le réassemblage, ainsi que des informations de sécurité.

La caractéristique de datagramme ou sans connexion du protocole IP est une caractéristique fondamentale et distinctive de l'architecture Internet. L'IP Internet est le modèle du protocole de réseau sans connexion OSI [INTRO:12].

ICMP est un protocole de contrôle considéré comme faisant partie d'IP, bien qu'il soit architecturale au-dessus d'IP, c'est-à-dire qu'il utilise IP comme les protocoles de transport tels que TCP ou UDP pour transporter ses données de bout en bout. ICMP fournit des rapports d'erreur, des rapports de congestion et une redirection de passerelle de premier saut.

IGMP est un protocole de couche Internet utilisé pour établir des groupes d'hôtes dynamiques pour le multicast IP.

Les protocoles de couche Internet IP, ICMP et IGMP sont discutés au chapitre 3.

Couche de liaison (Link Layer)

Pour communiquer sur le réseau auquel il est directement connecté, un hôte doit implémenter les protocoles de communication utilisés pour se connecter à ce réseau. Nous appelons ces protocoles de couche de liaison ou de couche d'accès au support.

Il existe de nombreux protocoles de couche de liaison différents, correspondant à de nombreux types de réseaux différents. Voir le chapitre 2.

1.1.4 Code de passerelle intégré (Embedded Gateway Code)

Certains logiciels de hôtes Internet incluent des fonctionnalités de passerelle intégrées, permettant à ces hôtes de transférer des paquets comme des passerelles tout en exécutant toujours les fonctions de la couche applicative du hôte.

Ces systèmes à double usage doivent suivre le RFC des exigences de passerelle [INTRO:2] dans leurs fonctionnalités de passerelle, et ce document dans leurs fonctionnalités de hôte. Dans tous les cas de chevauchement, les deux spécifications doivent être cohérentes.

La communauté Internet est divisée sur les fonctionnalités de passerelle intégrée. Les principaux arguments sont les suivants :

Pour (Pro) : Dans les environnements LAN non officiels ou les internets isolés, il peut être pratique et économique d'utiliser des systèmes hôtes existants comme passerelles.

Il y a également un argument architectural en faveur des fonctionnalités de passerelle intégrée : le multihébergement est beaucoup plus courant que prévu à l'origine, et le multihébergement oblige les hôtes à prendre des décisions de routage comme les passerelles. Si un hôte multihébergé inclut une passerelle intégrée, il possédera une connaissance complète du routage, lui permettant de prendre de meilleures décisions de routage.

Contre (Con) : Les algorithmes et protocoles de passerelle sont encore en évolution et continueront de changer à mesure que le système Internet grandit. Essayer d'inclure une fonctionnalité de passerelle générique dans la couche IP d'un hôte obligera les responsables de maintenance des systèmes hôtes à suivre ces changements (plus fréquents). De plus, un plus grand pool d'implémentations de passerelles rendra la coordination des changements plus difficile. Enfin, la complexité de la couche IP d'une passerelle est légèrement supérieure à celle d'un hôte, rendant les tâches d'implémentation et d'exploitation plus complexes.

De plus, certains styles d'exploitation des hôtes ne conviennent pas à la fourniture d'un service de passerelle stable et robuste.

Les deux points de vue ont une part considérable de raison. Une conclusion qui peut en être tirée est que les administrateurs de hôtes doivent avoir un contrôle conscient de savoir si un hôte donné agit en tant que passerelle. Les exigences détaillées figurent à la section 3.1.

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

Les fournisseurs de logiciels de hôtes Internet ont tiré deux leçons importantes que les nouveaux fournisseurs devraient prendre au sérieux.

1.2.1 L'évolution continue d'Internet (Continuing Internet Evolution)

La croissance massive d'Internet a révélé des problèmes de gestion et de mise à l'échelle d'un grand système de communication de paquets basé sur les datagrammes. Ces problèmes sont en cours de résolution, et par conséquent les normes décrites dans ce document continueront d'évoluer. Ces changements seront planifiés et contrôlés avec soin, car les fournisseurs et les organisations responsables de l'exploitation des réseaux y participent largement.

Le développement, l'évolution et la révision sont des caractéristiques des protocoles de réseau informatique d'aujourd'hui, et continueront pendant plusieurs années. Un fournisseur qui développe un logiciel de communication informatique pour la suite de protocoles Internet (ou toute autre suite de protocoles !) puis ne maintient et ne met pas à jour ce logiciel face aux spécifications changeantes laissera une traînée de clients mécontents. Internet est un grand réseau de communication où les utilisateurs restent en contact continu. L'expérience montre que la connaissance des défauts des logiciels des fournisseurs se propage rapidement dans la communauté technique Internet.

1.2.2 Principe de robustesse (Robustness Principle)

À chaque couche de protocole, il y a une règle générale dont l'application apporte d'énormes avantages en robustesse et en interopérabilité [IP:1] :

« Soyez libéral dans ce que vous acceptez, et conservateur dans ce que vous envoyez (Be liberal in what you accept, and conservative in what you send) »

Les logiciels doivent être écrits pour gérer toute erreur concevable, aussi improbable soit-elle ; tôt ou tard, un paquet arrivant avec cette combinaison particulière d'erreur et d'attributs arrivera, et à moins que le logiciel n'y soit préparé, le chaos peut s'ensuivre. En général, il est bon de supposer que le réseau regorge d'entités malveillantes qui enverront des paquets conçus pour produire le pire effet. Cette hypothèse guidera vers une conception de protection appropriée, bien que les problèmes les plus graves de l'Internet soient causés par des mécanismes inattendus déclenchés par des événements de faible probabilité ; la simple malveillance humaine n'emprunterait jamais un chemin aussi détourné !

Les logiciels de hôtes Internet à tous les niveaux doivent être conçus pour l'adaptabilité au changement. Prenons un exemple simple : considérons une spécification de protocole contenant une énumération des valeurs pour un champ d'en-tête particulier — par exemple un champ de type, un numéro de port ou un code d'erreur ; il faut supposer que cette énumération est incomplète. Par conséquent, si la spécification définit quatre codes d'erreur possibles, le logiciel ne doit jamais planter lorsqu'un cinquième code apparaît. Les codes non définis peuvent être enregistrés (voir ci-dessous), mais ne doivent pas provoquer de défaillance.

La seconde partie de ce principe est presque tout aussi importante : les logiciels sur d'autres hôtes peuvent contenir des défauts qui rendent l'exploitation de caractéristiques de protocole légales mais obscures imprudente. S'écarter du manifeste et du simple est dangereux, de peur de causer des effets néfastes ailleurs. La corollaire est « méfiez-vous des hôtes au comportement aberrant » ; les logiciels de hôtes doivent non seulement être préparés à survivre en présence d'autres hôtes au comportement aberrant, mais aussi coopérer pour limiter l'étendue des dommages que de tels hôtes peuvent infliger à l'installation de communication partagée.

1.2.3 Journalisation des erreurs (Error Logging)

L'Internet contient une grande variété de systèmes hôtes et passerelles, chacun implémentant de nombreux protocoles et couches de protocole, dont certains contiennent des erreurs et des caractéristiques défectueuses dans leurs logiciels de protocole Internet. En raison de la complexité, de la diversité et de la distribution des fonctionnalités, le diagnostic des problèmes Internet est souvent très difficile.

Si l'implémentation d'un hôte comprend un mécanisme bien conçu pour enregistrer les erreurs ou les événements de protocole « étranges », cela aidera au diagnostic des problèmes. Lors de l'enregistrement des erreurs, il est important d'inclure autant d'informations de diagnostic que possible. En particulier, il est souvent utile d'enregistrer l'en-tête du paquet qui a provoqué l'erreur. Cependant, il faut veiller à ce que le journal des erreurs ne consomme pas de ressources excessives ou n'interfère pas avec le fonctionnement de l'hôte.

Les événements de protocole anormaux mais inoffensifs peuvent faire déborder le fichier journal des erreurs ; cela peut être évité en utilisant un journal « circulaire », ou en activant le journal uniquement lors du diagnostic de pannes connues. Il peut être utile de filtrer et de compter les messages consécutifs en double. Une stratégie qui semble fonctionner est : (1) compter toujours les conditions anormales et permettre l'accès à ces compteurs via un protocole de gestion (voir [INTRO:1]) ; et (2) permettre d'activer sélectivement l'enregistrement d'événements importants. Par exemple, il peut être utile de pouvoir « tout enregistrer » ou « enregistrer tout de l'hôte X ».

Notez que différents gestionnaires peuvent avoir des stratégies différentes sur la quantité de journalisation des erreurs qu'ils souhaitent généralement activer. Certains disent « tant que cela ne me nuit pas, je ne veux pas le savoir », tandis que d'autres préfèrent une attitude plus vigilante et proactive pour détecter et éliminer les anomalies de protocole.

1.2.4 Configuration

Il serait idéal que l'implémentation des hôtes de la suite de protocoles Internet soit entièrement auto-configurable. Cela permettrait d'implémenter l'ensemble du protocole en ROM ou de le graver dans le silicium, de simplifier les stations de travail sans disque, et serait une aubaine pour les administrateurs LAN affairés et les fournisseurs de systèmes. Nous n'avons pas encore atteint cet idéal ; en fait, nous en sommes encore loin.

À de nombreux endroits de ce document, vous trouverez une exigence selon laquelle un paramètre donné doit être une option configurable. Il y a plusieurs raisons différentes derrière de telles exigences. Dans quelques cas, il y a une incertitude ou un désaccord actuel sur la meilleure valeur, et il peut être nécessaire de mettre à jour la valeur recommandée à l'avenir. Dans d'autres cas, la valeur dépend en effet de facteurs externes — par exemple la taille de l'hôte et la distribution de sa charge de communication, ou la vitesse et la topologie des réseaux voisins — et les algorithmes d'auto-réglage ne sont pas disponibles et peuvent être insuffisants. Dans certains cas, la configurabilité est requise pour des exigences de gestion.

Enfin, certaines options de configuration sont nécessaires pour communiquer avec des implémentations de protocole obsolètes ou erronées, toujours présentes dans de nombreux endroits de l'Internet, qui distribuent sans code source. Pour qu'un système correct coexiste avec ces systèmes défectueux, les administrateurs doivent souvent « mal configurer » le système correct. Ce problème se corrigera progressivement à mesure que les systèmes défectueux seront mis hors service, mais les fournisseurs ne peuvent l'ignorer.

Lorsque nous disons qu'un paramètre doit être configurable, nous n'exigeons pas qu'il soit lu explicitement à partir d'un fichier de configuration à chaque démarrage. Nous recommandons aux implémenteurs de fournir une valeur par défaut pour chaque paramètre, de sorte que le fichier de configuration ne soit utilisé que pour remplacer les valeurs par défaut inappropriées dans une installation particulière. Par conséquent, l'exigence de configurabilité est une garantie qu'il est possible de remplacer la valeur par défaut si nécessaire, même dans un produit binaire ou basé sur ROM.

Ce document exige dans certains cas que ces valeurs par défaut soient des valeurs spécifiques. Lorsqu'un élément de configuration contrôle la compatibilité avec des systèmes défectueux existants, le choix de la valeur par défaut est une question sensible. Pour que l'Internet converge vers une interopérabilité complète, les valeurs par défaut intégrées dans les implémentations doivent implémenter le protocole officiel, et non une « mauvaise configuration » pour accommoder les implémentations défectueuses. Bien que des considérations de marché aient conduit certains fournisseurs à choisir des valeurs par défaut mal configurées, nous exhortons les fournisseurs à choisir des valeurs par défaut conformes aux normes.

Enfin, nous notons que les fournisseurs doivent fournir une documentation adéquate pour tous les paramètres de configuration, leurs limites et leurs effets.

1.3 Lecture de ce document (Reading this Document)

1.3.1 Organisation (Organization)

La hiérarchie des protocoles est généralement utilisée comme principe d'organisation pour implémenter les logiciels de réseau, et pour organiser ce document. En décrivant les règles, nous supposons que les implémentations mappent en effet strictement la hiérarchie des protocoles. Par conséquent, les trois chapitres principaux suivants spécifient respectivement les exigences pour la couche de liaison, la couche Internet et la couche de transport. Le RFC compagnon [INTRO:1] couvre les logiciels de la couche applicative. Cette organisation hiérarchique a été choisie pour la simplicité et la clarté.

Cependant, la hiérarchisation stricte est un modèle imparfait à la fois pour la famille de protocoles et pour la méthode d'implémentation recommandée. Les protocoles de différentes couches interagissent de manière complexe et parfois subtile, et des fonctionnalités particulières impliquent souvent plusieurs couches. Il existe de nombreux choix de conception dans les implémentations, dont beaucoup impliquent de « briser » de manière créative la hiérarchisation stricte. Nous exhortons chaque implémenteur à lire les références [INTRO:7] et [INTRO:8].

Ce document utilise une notation fonctionnelle (« appel de procédure ») pour décrire les interfaces de service conceptuelles entre les couches, similaire à celle utilisée dans la spécification TCP [TCP:1]. Les implémentations de hôtes doivent prendre en charge le flux d'informations logiques impliqué par ces appels, mais ne doivent pas nécessairement implémenter littéralement les appels eux-mêmes. Par exemple, de nombreuses implémentations reflètent le couplage entre la couche de transport et la couche IP en partageant des structures de données communes. Ainsi, ces structures de données, plutôt que des appels de procédure explicites, deviennent le véhicule de transmission de nombreuses informations requises.

En général, chaque chapitre principal de ce document est organisé par les sous-sections suivantes :

1. Introduction
2. Analyse du protocole (Protocol Walk-Through) — examine la documentation de spécification de protocole section par section, corrige les erreurs, énonce les exigences qui pourraient être ambiguës ou mal définies, et fournit des clarifications ou des explications supplémentaires.
3. Problèmes spécifiques (Specific Issues) — discute des problèmes de conception et d'implémentation de protocole non inclus dans l'analyse.
4. Interfaces — discute de l'interface de service vers la couche supérieure suivante.
5. Résumé (Summary) — contient un résumé des exigences de cette section.

Sous de nombreux sujets individuels de ce document, il y a des matériaux annotés « DISCUSSION » ou « IMPLEMENTATION ». L'objectif de ces matériaux est de clarifier et d'expliquer le texte d'exigence précédent. Ils incluent également des suggestions sur de possibles directions ou développements futurs. Les matériaux d'implémentation contiennent des approches suggérées que les implémenteurs pourraient vouloir envisager.

La sous-section Résumé est destinée à servir de guide et d'index vers le corps du texte, mais est inévitablement brève et incomplète. Le résumé ne doit jamais être utilisé seul ou cité séparément du RFC complet.

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 » (DOIT)

Ce mot, ou l'adjectif « REQUIRED », indique que l'élément est une exigence absolue de la norme.

« SHOULD » (DEVRAIT)

Ce mot, ou l'adjectif « RECOMMENDED », indique qu'il peut y avoir des raisons valables d'ignorer cet élément dans des circonstances particulières, mais que toutes les implications doivent être comprises et soigneusement pondérées avant de choisir une approche différente.

« MAY » (PEUT)

Ce mot, ou l'adjectif « OPTIONAL », indique que l'élément est en effet optionnel. Par exemple, un fournisseur peut choisir d'inclure l'élément en raison d'un besoin du marché ou pour améliorer le produit ; un autre fournisseur peut omettre le même élément.

Si une implémentation ne satisfait pas à une ou plusieurs exigences MUST du protocole qu'elle implémente, l'implémentation n'est pas conforme à la spécification. Une implémentation qui satisfait à toutes les exigences MUST et SHOULD de son protocole est dite « inconditionnellement conforme (unconditionally compliant) » ; une implémentation qui satisfait à toutes les exigences MUST mais pas à toutes les exigences SHOULD est dite « conditionnellement conforme (conditionally compliant) ».

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. Un segment se compose d'un en-tête TCP suivi de données d'application. Un segment est transporté en étant encapsulé dans un datagramme IP.

Message

Dans la description des protocoles de couche inférieure, un message est l'unité de transmission dans le protocole de transport. En particulier, un segment TCP est un message. Un message se compose d'un en-tête de protocole de transport suivi de données de protocole d'application. Pour être transporté de bout en bout sur l'Internet, un message doit être encapsulé dans un datagramme.

Datagramme IP (IP Datagram)

Un datagramme IP est l'unité de transmission de bout en bout dans le protocole IP. Un datagramme IP se compose d'un en-tête IP suivi de données de couche de transport, c'est-à-dire un en-tête IP suivi d'un message.

Dans la description de la couche Internet (section 3), le terme non qualifié « datagramme (datagram) » doit être compris comme désignant un datagramme IP.

Paquet (Packet)

Un paquet est l'unité de données transférée à travers l'interface entre la couche Internet et la couche de liaison. Il contient un en-tête IP et des données. Un paquet peut être un datagramme IP complet, ou un fragment d'un datagramme IP.

Trame (Frame)

Une trame est l'unité de transmission dans le protocole de couche de liaison, composée d'un en-tête de couche de liaison suivi d'un paquet.

Réseau connecté (Connected Network)

Le réseau auquel un hôte est interfacé est généralement appelé « réseau local (local network) » ou « sous-réseau (subnetwork) » par rapport à cet hôte. Cependant, ces termes peuvent prêter à confusion, nous utilisons donc le terme « réseau connecté (connected network) » dans ce document.

Multihébergé (Multihomed)

Si un hôte possède plusieurs adresses IP, il est dit multihébergé. Pour une discussion sur le multihébergement, voir la section 3.3.4.

Interface réseau physique (Physical network interface)

Il s'agit de l'interface physique vers le réseau connecté, possédant une adresse de couche de liaison (possiblement unique). Plusieurs interfaces réseau physiques sur un seul hôte peuvent partager la même adresse de couche de liaison, mais cette adresse doit être unique pour les différents hôtes sur le même réseau physique.

Interface [réseau] logique (Logical [network] interface)

Nous définissons l'interface [réseau] logique comme un chemin logique vers le réseau connecté, distingué par une adresse IP unique. Voir la section 3.3.4.

Adresse de destination spécifique (Specific-destination address)

Il s'agit de l'adresse de destination valide du datagramme, même s'il s'agit d'une diffusion ou d'un multicast ; voir la section 3.2.1.3.

Chemin (Path)

À un moment donné, tous les datagrammes IP d'un hôte source particulier à un hôte de destination particulier traverseront généralement la même séquence de passerelles. Nous appelons cette séquence le « chemin (Path) ». Notez que le chemin est unidirectionnel ; il n'est pas rare d'avoir des chemins différents dans les deux directions entre une paire donnée de hôtes.

MTU

Unité de transmission maximale (Maximum Transfer Unit), c'est-à-dire la taille maximale du paquet qui peut être transmise.

Les termes trame, paquet, datagramme, message et segment sont illustrés par le schéma suivant :

A. Transmission sur un réseau connecté :

_______________________________________________
| LL hdr | IP hdr |         (data)              |
|________|________|_____________________________|

<---------- Frame ----------------------------->
         <----------Packet -------------------->

B. Avant la fragmentation IP ou après le réassemblage IP :

______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|

<--------  Datagram ------------------>
          <-------- Message ----------->

Ou, pour TCP :

______________________________________
| IP hdr |  TCP hdr | Application Data |
|________|__________|__________________|

<--------  Datagram ------------------>
          <-------- Segment ----------->

1.4 Remerciements (Acknowledgments)

Ce document incorpore des contributions et des commentaires d'un grand nombre d'experts en protocoles Internet (y compris des représentants d'universités et de laboratoires de recherche, de fournisseurs et d'agences gouvernementales). Il a été principalement compilé par le groupe de travail sur les exigences des hôtes (Host Requirements Working Group) de l'IETF (Internet Engineering Task Force).

L'éditeur tient à remercier tout particulièrement les personnes suivantes pour leur dévouement, qui ont assisté à de nombreuses réunions prolongées au cours des 18 derniers mois et ont produit 3 millions d'octets de courrier électronique pour réaliser ce document : Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU) et James Van Bokkelen (FTP Software).

De plus, les personnes suivantes ont apporté des contributions significatives à ce travail : Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology) et Mike StJohns (DCA). Les personnes suivantes ont également apporté des contributions importantes dans des domaines spécifiques : Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco) et Rayan Zachariassen (Toronto).

Nous exprimons notre gratitude à tous, y compris à tout contributeur qui pourrait avoir été omis par inadvertance de la liste.