3. Protocoles de la couche Internet (INTERNET LAYER PROTOCOLS)
3.1 Introduction (INTRODUCTION)
Tous les hôtes Internet doivent implémenter IP, ICMP et (au moins sous une forme restreinte) IGMP.
DISCUSSION :
Pour IP et ICMP, ce mémorandum corrige et complète les spécifications des hôtes de RFC-791, RFC-792 et RFC-950, et réaffirme certains points clés. Pour IGMP, ce mémorandum spécifie ses exigences côté hôte, le protocole IGMP lui-même étant défini dans RFC-1112 [IP:4].
Les hôtes qui hébergent plusieurs hôtes (voir section 3.3.4) doivent traiter correctement les datagrammes entrants arrivant de plusieurs interfaces, et doivent pouvoir utiliser n'importe quelle adresse comme adresse source de datagrammes sortants.
L'interface entre la couche IP et la couche de transport doit fournir un accès complet à tous les mécanismes de la couche IP. Voir section 3.4.
Les protocoles de la couche Internet IP, ICMP et IGMP sont discutés au chapitre 3.
3.2 Analyse du protocole (PROTOCOL WALK-THROUGH)
Cette section examine les documents de spécification des protocoles IP, ICMP et IGMP section par section, corrige les erreurs et énonce les exigences qui pourraient être ambiguës ou mal définies.
3.2.1 Protocole Internet -- IP (Internet Protocol -- IP)
3.2.1.1 Version
L'hôte DOIT (MUST) vérifier que le champ VERSION de l'en-tête IP est égal à 4. Si la version n'est pas 4, le datagramme DOIT (MUST) être ignoré silencieusement ; un message ICMP Parameter Problem peut également être généré.
3.2.1.2 Checksum d'en-tête (Header Checksum)
L'hôte DOIT (MUST) vérifier le checksum d'en-tête (HEADER CHECKSUM) des datagrammes IP entrants ; si le checksum est erroné, le datagramme DOIT (MUST) être ignoré silencieusement.
DISCUSSION :
Le checksum est utilisé pour détecter les erreurs survenant dans l'en-tête pendant la transmission. Notez qu'il diffère des checksums de bout en bout dans les protocoles de couche supérieure comme TCP ou UDP.
3.2.1.3 Adresses (Addresses)
(1) Adresse source (Source Address)
L'hôte DOIT (MUST) vérifier que l'adresse source (SOURCE ADDRESS) d'un datagramme entrant n'est pas une adresse de diffusion ou de multicast (voir ci-dessous) ; sinon, le datagramme DOIT (MUST) être ignoré silencieusement.
(2) Adresse de destination (Destination Address)
Un datagramme peut être adressé à un réseau Internet, un sous-réseau ou un hôte. Une adresse IP adressée à un hôte est appelée une « adresse de destination spécifique (specific-destination address) ». L'adresse de destination spécifique est soit l'adresse IP de l'hôte, soit une adresse de diffusion ou de multicast (voir sections 3.3.6 et 3.3.7).
L'adresse de destination d'un datagramme IP PEUT (MAY) être l'une des quatre formes standard d'adresses de diffusion IP :
(a) {numéro de réseau, -1} Diffusion dirigée (Directed Broadcast)
(b) {numéro de réseau, numéro de sous-réseau, -1} Diffusion dirigée de sous-réseau (Subnet Directed Broadcast)
(c) {numéro de réseau, -1, -1} Diffusion dirigée de tous les sous-réseaux (All-Subnets Directed Broadcast)
(d) {-1, -1} Diffusion limitée (Limited Broadcast)
Ici "-1" signifie que tous les bits du champ correspondant sont à 1 ; une telle adresse est appelée « adresse de diffusion (broadcast address) ». L'interprétation des champs numéro de réseau et numéro de sous-réseau est détaillée dans RFC-950 [IP:3].
L'hôte DOIT (MUST) reconnaître l'une des formes de diffusion ci-dessus dans l'adresse de destination d'un datagramme entrant. De plus, pour les hôtes d'une classe* utilisant des formes non standard d'adresses de diffusion utilisant 0 au lieu de -1 (par exemple 4.2BSD Unix et ses dérivés, mais pas 4.3BSD), l'hôte DEVRAIT (SHOULD) reconnaître et accepter ces adresses de diffusion non standard.
L'hôte DOIT (MUST) ignorer silencieusement un datagramme entrant dont l'adresse de destination n'est ni l'adresse IP propre de l'hôte, ni une adresse de diffusion ou de multicast valide. Cependant, si l'hôte transfère des datagrammes en tant que passerelle (voir section 3.3.5), son traitement diffère de ce qui est prescrit ici (voir [INTRO:2]).
Si un hôte reçoit un datagramme adressé à une adresse de diffusion de la couche de liaison (voir section 2.4) mais dont l'adresse IP de destination n'est pas une adresse de diffusion ou de multicast IP valide, il DEVRAIT (SHOULD) l'ignorer silencieusement.
DISCUSSION :
Les règles (1) et (2) ci-dessus empêchent collectivement un hôte d'accepter tout datagramme dont l'adresse de destination est invalide, dont l'adresse source est invalide, ou dont l'adresse source est une adresse de diffusion/multicast. En particulier, cela empêche les attaques de type « Land » (datagrammes dont l'adresse source est égale à l'adresse de destination).
Le concept d'adresse de destination spécifique est utilisé pour distinguer la véritable adresse de destination d'un datagramme (même si elle est une diffusion ou un multicast) de la différence d'interprétation du champ d'adresse de destination IP au niveau du réseau local.
(3) Adressage par sous-réseau (Subnet Addressing)
L'hôte DOIT (MUST) implémenter l'adressage par sous-réseau (tel que défini dans RFC-950 [IP:3]). Cela signifie que le masque d'adresse (ADDRESS MASK) est utilisé pour déterminer quels bits de l'adresse IP de destination identifient le réseau/sous-réseau et quels bits identifient l'hôte.
(4) Adresse source invalide (Invalid Source Address)
La couche IP DOIT (MUST) vérifier le champ d'adresse source avant de passer un datagramme entrant vers la couche de transport ; si l'adresse source est 0, une adresse de diffusion ou une adresse de multicast, le datagramme DOIT (MUST) être ignoré silencieusement.
3.2.1.4 Réassemblage (Reassembly)
La couche IP DOIT (MUST) implémenter le réassemblage des datagrammes IP entrants (voir section 3.3.2).
3.2.1.5 Identificateur (Identification)
Si l'hôte n'utilise pas le champ d'identification (IDENTIFICATION), il PEUT (MAY) le mettre à zéro dans les datagrammes sortants, ou à une valeur localement unique. Il DEVRAIT (SHOULD) éviter de conserver la même valeur de champ d'identification dans plusieurs copies d'un même datagramme.
DISCUSSION :
Le champ d'identification est utilisé pour distinguer différentes copies d'un datagramme (par exemple envoyées plusieurs fois via un routage de source). Si un datagramme identique est envoyé plusieurs fois avec le même champ d'identification, le récepteur peut le rejeter à tort comme fragment en double.
3.2.1.6 Type de service (Type-Of-Service)
L'en-tête IP contient un champ Type de service (TOS) comme décrit précédemment. La couche de transport DOIT (MUST) pouvoir définir la valeur TOS des datagrammes sortants ; cette valeur DOIT (MUST) être transmise de manière transparente à la couche IP. La valeur TOS reçue DEVRAIT (SHOULD) être transmise vers la couche de transport.
Si la couche IP implémente les mappages de couche de liaison définis dans RFC-795 [IP:13], elle PEUT (MAY) les utiliser pour sélectionner la priorité ou la classe de service de la couche de liaison pour l'envoi de datagrammes.
DISCUSSION :
L'implémentation actuelle du champ TOS n'est pas encore largement utilisée dans l'Internet global, mais les hôtes devraient prendre en charge la définition de ce champ afin qu'il puisse être immédiatement opérationnel lorsque ces mécanismes entrent en vigueur.
3.2.1.7 Durée de vie (Time-To-Live)
Le champ TTL (Time-To-Live) des datagrammes sortants DOIT (MUST) être défini par l'émetteur. Les datagrammes avec TTL de 0 NE DOIVENT PAS (MUST NOT) être envoyés. Les datagrammes reçus avec un TTL inférieur à 2 NE DOIVENT PAS (MUST NOT) être ignorés (seules les passerelles ignorent un datagramme lorsque le TTL atteint 0 après décrément).
La durée de vie DOIT (MUST) pouvoir être définie par la couche de transport, et cette valeur DOIT (MUST) être transmise de manière transparente à la couche IP. Une valeur TTL fixe DOIT (MUST) être configurable.
3.2.1.8 Options IP (IP Options)
(1) Traitement général des options (General Option Processing)
La couche IP DOIT (MUST) permettre à la couche de transport de spécifier les options IP à envoyer dans les datagrammes sortants, et DOIT (MUST) transmettre de manière transparente toutes les options IP reçues vers la couche supérieure. La couche IP DOIT (MUST) ignorer silencieusement les options qu'elle ne comprend pas.
Si la couche IP reçoit une option IP qu'elle ne comprend pas mais qui comporte un champ de longueur, elle DOIT (MUST) sauter l'option et continuer le traitement de l'en-tête. Si le champ de longueur d'option est zéro ou hors limites, cela DOIT (MUST) être traité comme une erreur (par exemple en envoyant un message ICMP Parameter Problem).
(2) Format d'option (Option Format)
Les formats de chaque option IP sont détaillés dans RFC-791. Ils ne sont pas répétés ici.
(3) Option de routage de source (Source Route Option)
L'hôte DOIT (MUST) être capable d'initier et de terminer des options de routage de source (SOURCE ROUTE) ; c'est-à-dire que l'hôte doit pouvoir insérer une option de routage de source dans les datagrammes sortants et doit pouvoir traiter les options de routage de source dans les datagrammes entrants.
Si un datagramme entrant porte une option de routage de source non encore complétée, l'hôte DOIT (MUST) le passer vers la couche de transport (car le routage de source complété est géré par la couche de transport). Si le routage de source est complété, le datagramme avec la marque de complétion DOIT (MUST) être passé à la couche de transport.
Lorsqu'un hôte transfère un datagramme de routage de source en tant que passerelle (voir section 3.3.5), il DOIT (MUST) mettre à jour l'option de routage de source conformément à la spécification de passerelle, et construire un itinéraire de retour correct (non redondant).
Un en-tête IP PEUT (MAY) contenir plusieurs options de routage de source.
(4) Option d'enregistrement de route (Record Route Option)
L'hôte PEUT (MAY) insérer une option d'enregistrement de route (RECORD ROUTE) dans les datagrammes sortants, et PEUT (MAY) traiter cette option dans les datagrammes entrants. Pour les hôtes exigeant la prise en charge de cette option, leur couche IP DOIT (MUST) mettre à jour l'option correctement selon RFC-791.
(5) Option d'horodatage (Time Stamp Option)
L'hôte PEUT (MAY) insérer une option d'horodatage (TIME STAMP) dans les datagrammes sortants, et traiter correctement cette option dans les datagrammes entrants.
(6) Option d'identificateur de flux (Stream Identifier Option)
L'hôte PEUT (MAY) envoyer l'option d'identificateur de flux (STREAM IDENTIFIER), et DOIT (MUST) ignorer silencieusement l'option reçue (car cette option est obsolète).
(7) Option de sécurité (Security Option)
L'hôte PEUT (MAY) implémenter l'option de sécurité IP (SECURITY) [IP:8]. Si elle est implémentée, son traitement doit conforme à RFC-791 et RFC-1108.
3.2.2 Protocole de messages de contrôle Internet -- ICMP (Internet Control Message Protocol -- ICMP)
Le format et le traitement des messages ICMP sont spécifiés dans RFC-792. Seuls les points pertinents pour l'implémentation des hôtes sont discutés ici.
(1) Traitement général des messages (General Message Processing)
L'hôte DOIT (MUST) ignorer silencieusement un message ICMP de type inconnu. Pour les messages d'erreur ICMP, au moins 8 octets du datagramme d'origine (c'est-à-dire l'en-tête IP d'origine plus 8 octets) DOIT (MUST) être inclus, et les octets du datagramme d'origine inclus DOIVENT (MUST) être identiques à ceux reçus.
Les messages d'erreur ICMP DOIVENT (MUST) être démultiplexés vers le protocole de transport correct (basé sur le champ de protocole dans l'en-tête IP d'origine inclus).
(2) Destination inaccessible (Destination Unreachable)
Lorsque la couche IP ne peut pas livrer un datagramme, elle DOIT (MUST) pouvoir générer un message Destination inaccessible (DESTINATION UNREACHABLE), et prendre en charge les codes suivants :
- Code 2 (protocole inaccessible)
- Code 3 (port inaccessible)
Le message ICMP Destination inaccessible DOIT (MUST) être transmis vers la couche supérieure. La couche supérieure DEVRAIT (SHOULD) agir de manière appropriée sur le message (par exemple en terminant la connexion concernée).
L'hôte DOIT (MUST) interpréter le message Destination inaccessible uniquement comme un indice (c'est-à-dire qu'il n'impose pas d'action immédiate, sauf si le protocole/application de transport concerné l'exige).
(3) Source Quench
Si les tampons de l'hôte dépassent la limite, il PEUT (MAY) (et DEVRAIT (SHOULD)) envoyer un message Source Quench (SOURCE QUENCH). Le message Source Quench reçu DOIT (MUST) être transmis vers la couche supérieure, qui DEVRAIT (SHOULD) réduire le taux d'envoi en conséquence.
(4) Délai dépassé (Time Exceeded)
Le message Délai dépassé (TIME EXCEEDED) reçu DOIT (MUST) être transmis vers la couche supérieure.
(5) Problème de paramètre (Parameter Problem)
L'hôte DEVRAIT (SHOULD) envoyer un message Problème de paramètre (PARAMETER PROBLEM) lorsqu'il détecte un paramètre erroné dans l'en-tête IP ; le message reçu DOIT (MUST) être transmis vers la couche supérieure, et PEUT (MAY) (et DEVRAIT (SHOULD)) être rapporté à l'utilisateur.
(6) Echo Request/Reply
L'hôte DOIT (MUST) implémenter le serveur Echo (ECHO SERVER, répond aux demandes Echo) et le client Echo (ECHO CLIENT, envoie des demandes Echo). La demande Echo DEVRAIT (SHOULD) être envoyée.
Les demandes Echo adressées à une adresse de diffusion DEVRAIENT (SHOULD) être ignorées silencieusement ; les demandes Echo adressées à une adresse de multicast DEVRAIENT (SHOULD) être ignorées silencieusement. L'adresse source d'une réponse Echo DOIT (MUST) utiliser l'adresse de destination spécifique de la demande d'origine. La réponse Echo DOIT (MUST) renvoyer les mêmes octets de données que la demande. La réponse Echo DOIT (MUST) être transmise vers la couche supérieure. La réponse Echo DEVRAIT (SHOULD) réfléchir les options d'enregistrement de route et d'horodatage de la demande ; DOIT (MUST) inverser et réfléchir l'option de routage de source.
(7) Information Request/Reply
L'hôte PEUT (MAY) implémenter les messages Information Request et Information Reply.
(8) Timestamp et Timestamp Reply
L'hôte PEUT (MAY) implémenter les messages Timestamp et Timestamp Reply. S'il est implémenté, il DEVRAIT (SHOULD) minimiser la variabilité du délai, DEVRAIT (SHOULD) ignorer silencieusement les timestamps de diffusion et de multicast, l'adresse source de la réponse DOIT (MUST) utiliser l'adresse de destination spécifique, et DOIT (MUST) respecter les règles de « valeur standard » de RFC-792, et DOIT (MUST) transmettre la réponse vers la couche supérieure.
(9) Address Mask Request/Reply
L'hôte DOIT (MUST) que le masque d'adresse (ADDRESS MASK) puisse être spécifié par configuration, et DOIT (MUST) prendre en charge la configuration statique du masque d'adresse. L'hôte PEUT (MAY) obtenir dynamiquement le masque d'adresse pendant le démarrage (via un protocole de bootstrap), PEUT (MAY) l'obtenir via les messages ICMP Address Mask Request/Reply. S'il ne reçoit pas de réponse dans un délai raisonnable, il DOIT (MUST) rétransmettre la demande ; s'il n'y a toujours pas de réponse, il DEVRAIT (SHOULD) supposer un masque par défaut. Le masque d'adresse DEVRAIT (SHOULD) être vérifié pour sa plausibilité. L'hôte NE DOIT PAS (MUST NOT) envoyer de réponses Address Mask non autorisées ; il DOIT (MUST) envoyer une réponse Address Mask (avec l'indicateur d'autorité défini) uniquement s'il est explicitement configuré comme agent de masque d'adresse. Lors de l'initialisation, la demande DOIT (MUST) être envoyée en diffusion.
3.2.3 Protocole de gestion de groupe Internet -- IGMP (Internet Group Management Protocol -- IGMP)
IGMP est défini dans RFC-1112 [IP:4] ; les exigences d'implémentation côté hôte sont dans la section 3.3.7. IGMP lui-même est optionnel pour les hôtes non connectés à des passerelles prenant en charge le routage multicast.
3.3 Problèmes spécifiques (SPECIFIC ISSUES)
3.3.1 Routage des datagrammes sortants (Routing Outbound Datagrams)
3.3.1.1 Introduction
Lorsqu'un hôte envoie un datagramme IP, il doit décider quelle interface physique utiliser et quelle passerelle de premier saut (si l'hôte de destination n'est pas sur le réseau connecté). Ce processus décisionnel est appelé « routage (routing) ».
L'hôte DOIT (MUST) utiliser le masque d'adresse lorsqu'il décide « local (réseau connecté) » contre « distant (non connecté) ».
L'hôte DOIT (MUST) être capable de fonctionner normalement sur un réseau connecté sans qu'aucune passerelle y soit configurée.
DISCUSSION :
Le routage est l'un des domaines les plus complexes et encore en évolution de l'architecture Internet. Les hôtes ne doivent pas implémenter le protocole de routage complet des passerelles, mais s'appuyer sur des mécanismes simples : passerelle par défaut, messages de redirection et cache de routage.
3.3.1.2 Cache de routage et routes statiques (Route Cache and Static Routes)
L'hôte DOIT (MUST) maintenir un « cache de routage (route cache) » enregistrant la passerelle de saut suivant pour chaque réseau/hôte de destination. L'hôte DOIT (MUST) utiliser la passerelle par défaut lorsqu'aucune entrée n'est trouvée dans le cache. L'hôte DOIT (MUST) prendre en charge plusieurs passerelles par défaut.
L'hôte PEUT (MAY) fournir une table de routes statiques (static routes) ; ces routes statiques PEUVENT (MAY) être marquées comme remplaçables ou non par les redirections.
DISCUSSION :
Le message Redirect est envoyé par une passerelle pour informer un hôte d'une meilleure passerelle de premier saut pour une destination donnée. Lorsqu'un hôte reçoit un message Redirect, il DOIT (MUST) mettre à jour son cache de routage. L'hôte DOIT (MUST) traiter à la fois les redirections Host et Net de manière équivalente.
Un message Redirect illégal (par exemple pointant vers une passerelle non sur un réseau directement connecté) DEVRAIT (SHOULD) être ignoré.
3.3.1.3 Clé du cache de routage (Route Cache Keying)
Le cache de routage DEVRAIT (SHOULD) être indexé par l'adresse de l'hôte de destination (plutôt que l'adresse de réseau), et DEVRAIT (SHOULD) inclure la valeur TOS dans le cache.
DISCUSSION :
L'indexation par hôte évite les problèmes où différents hôtes sur le même réseau empruntent des chemins différents, et permet un routage plus fin par hôte de destination.
3.3.1.4 Détection de passerelle morte (Dead Gateway Detection)
L'hôte DOIT (MUST) être capable de détecter la défaillance de la passerelle de saut suivant. L'hôte NE DOIT PAS (MUST NOT) supposer qu'une route reste valide pour toujours.
DISCUSSION :
Plusieurs techniques peuvent détecter une passerelle morte. Une méthode consiste à pinger continuellement la passerelle, mais cela génère trop de trafic, donc on DEVRAIT (SHOULD) pinger uniquement lorsqu'il y a du trafic à envoyer, et DEVRAIT (SHOULD) uniquement en l'absence d'indication positive. Les couches supérieure et inférieure peuvent fournir des conseils de réussite/échec de livraison (advice).
Une autre technique courante (écouter passivement les protocoles de routage des passerelles) n'est pas recommandée (voir ci-dessous).
3.3.1.5 Sélection d'une nouvelle passerelle (New Gateway Selection)
Si la passerelle défaillante n'est pas la passerelle par défaut actuelle, la couche IP peut basculer immédiatement vers une passerelle par défaut. Si la passerelle défaillante est la passerelle par défaut actuelle, la couche IP DOIT (MUST) en sélectionner une différente (en supposant que plusieurs sont connues), pour la route défaillante et pour établir de nouvelles routes.
DISCUSSION :
Lorsqu'une passerelle tombe en panne, les autres passerelles du réseau connecté en seront informées via un protocole de routage inter-passerelles, mais cela n'est pas immédiat (le temps de stabilisation est généralement de 30 à 60 secondes). Si l'hôte bascule vers une passerelle de remplacement avant que les passerelles ne soient d'accord, la nouvelle passerelle cible transférera probablement les datagrammes vers la passerelle défaillante et renverra une redirection vers celle-ci. Il en résulte une oscillation rapide du contenu du cache de routage de l'hôte pendant la stabilisation. On a suggéré que la logique de passerelle morte inclue une certaine hystérésis pour éviter cette oscillation, mais l'expérience montre qu'elle est inoffensive.
IMPLEMENTATION :
Une technique d'implémentation pour choisir une nouvelle passerelle par défaut consiste à simplement parcourir en round-robin la liste des passerelles par défaut ; une autre consiste à classer les passerelles par priorité et à « pinger » les passerelles de priorité plus élevée lorsqu'elles ne sont pas la passerelle par défaut actuelle.
3.3.1.6 Initialisation (Initialization)
Les informations suivantes DOIVENT (MUST) être configurables :
(1) Adresse(s) IP (une ou plusieurs). (2) Masque(s) d'adresse (un ou plusieurs). (3) Liste de passerelles par défaut, avec priorité.
Une méthode de saisie manuelle de ces données de configuration DOIT (MUST) être fournie. De plus, diverses méthodes permettant de déterminer dynamiquement ces informations peuvent être utilisées (voir chapitre « Host Initialization » de [INTRO:1]).
DISCUSSION :
Certaines implémentations d'hôtes découvrent quelles passerelles existent en écoutant les protocoles de passerelle sur le réseau de diffusion. Une méthode standard de découverte de passerelle par défaut est en cours d'élaboration.
3.3.2 Réassemblage (Reassembly)
La fonction de réassemblage IP DOIT (MUST) satisfaire aux exigences suivantes :
- Un hôte DOIT (MUST) être capable de réassembler des datagrammes fragmentés d'au moins 576 octets.
- Le délai d'attente de réassemblage (reassembly timeout) DOIT (MUST) être d'au moins 60 secondes, mais ne DOIT PAS (MUST NOT) dépasser 120 secondes.
- Lorsqu'un datagramme est abandonné pour cause de dépassement du délai de réassemblage, l'hôte DOIT (MUST) envoyer un message ICMP « Time Exceeded » (Temps dépassé) au groupe de codes 1, à la source du datagramme.
- Le hôte DOIT (MUST) fournir un mécanisme permettant à la couche de transport d'apprendre la taille maximale du message de transport pouvant être reçu (MMS_R), bien que cette information soit normalement dérivée de la taille de datagramme maximale effective (EMTU_R). La valeur EMTU_R DEVRAIT (SHOULD) être configurable par l'opérateur, ou DEVRAIT (SHOULD) être considérée comme illimitée.
DISCUSSION :
La valeur de 576 octets pour la taille minimale de datagramme garantie est historiquement liée aux limites de la technologie des réseaux locaux initiale ; elle devrait être suffisante pour la plupart des en-têtes de protocoles au-dessus d'IP. Notez que l'exigence de réassembler au moins 576 octets est distincte de l'exigence de transmettre des datagrammes de cette taille.
3.3.3 Fragmentation
Un hôte DOIT (MUST) prendre en charge la fragmentation IP locale. Lorsqu'il fragmente un datagramme, un hôte DOIT (MUST) copier les champs d'en-tête IP appropriés dans chaque en-tête de fragment. L'hôte DOIT (MUST) fournir la taille maximale du message de transport pouvant être envoyé (MMS_S) à la couche de transport. Si l'hôte ne fragmente pas ses datagrammes sortants, il NE DOIT PAS (MUST NOT) envoyer de datagramme plus grand que le MMS_S fourni à la couche de transport.
DISCUSSION :
La fragmentation est une fonctionnalité importante pour l'interopérabilité. Cependant, elle introduit une surcharge et une perte de fiabilité (si un fragment est perdu, tout le datagramme doit être retransmis). Dès que possible, les hôtes DEVRAIENT (SHOULD) éviter la fragmentation en utilisant le MMS_S correct pour la destination.
Un hôte DEVRAIT (SHOULD) envoyer des datagrammes d'au plus 576 octets aux destinations hors réseau (off-net), sauf indication contraire fournie par la découverte de MTU de chemin.
Un indicateur de configuration « All-Subnets-MTU » PEUT (MAY) être fourni.
3.3.4 Multihoming local (Local Multihoming)
Un hôte multihomed possède plusieurs adresses IP, qui peuvent résider sur les mêmes réseaux ou sur des réseaux différents. Un hôte possédant plusieurs adresses IP DOIT (MUST) être capable d'envoyer et de recevoir des datagrammes en utilisant n'importe laquelle de ses adresses IP.
Un hôte multihomed DOIT (MUST) être capable de répondre à un datagramme entrant avec la même adresse que l'adresse de destination spécifique (specific-destination) du datagramme d'origine. L'hôte DOIT (MUST) permettre à une application de choisir l'adresse IP locale source pour les datagrammes qu'elle envoie.
DISCUSSION :
Le multihoming est complexe. Lorsqu'un datagramme arrive sur une interface qui ne correspond pas à l'adresse de destination, l'hôte DEVRAIT (SHOULD) ignoré silencieusement le datagramme, sauf s'il s'agit d'une adresse de diffusion ou de multicast valide sur cette interface. Inversement, l'hôte NE DEVRAIT PAS (SHOULD NOT) envoyer de datagramme via une interface « incorrecte » pour l'adresse source choisie, à moins d'être configuré pour le faire.
3.3.5 Transfert de routage de source (Source Route Forwarding)
Sous les restrictions suivantes, un hôte PEUT (MAY) agir comme saut intermédiaire dans un routage de source en transférant un datagramme à route source vers le saut spécifié suivant.
Cependant, dans l'exécution de cette fonction de type passerelle, l'hôte DOIT (MUST) respecter toutes les règles applicables de transfert des datagrammes à route source par une passerelle [INTRO:2]. Cela inclut ce qui suit (ces clauses particulières remplacent les clauses d'hôte correspondantes données plus haut dans ce document) :
(A) TTL (voir section 3.2.1.7)
Le champ TTL **DOIT (MUST)** être décrémenté comme spécifié pour les passerelles dans [INTRO:2], et le datagramme peut par conséquent être abandonné.
(B) ICMP Destination Unreachable (voir section 3.2.2.1)
L'hôte **DOIT (MUST)** être capable de générer des messages « Destination Unreachable » avec les codes suivants :
4 (Fragmentation Needed but DF Set — Fragmentation nécessaire mais DF positionné) — lorsqu'un datagramme à route source ne peut être fragmenté pour s'adapter au réseau cible ;
5 (Source Route Failed — Échec du routage de source) — lorsqu'un datagramme à route source ne peut être transféré, par exemple en raison d'un problème de routage ou si le saut suivant d'une route source stricte n'est pas sur le réseau connecté.
(C) Adresse source IP (voir section 3.2.1.3)
Le datagramme à route source transféré **PEUT (MAY)** (et le fera généralement) avoir une adresse source qui n'est pas l'une des adresses IP de l'hôte de transfert.
(D) Option Record Route (voir section 3.2.1.8d)
Un hôte transférant un datagramme à route source contenant une option Record Route **DOIT (MUST)** mettre à jour cette option (si elle dispose encore d'espace).
(E) Option Timestamp (voir section 3.2.1.8e)
Un hôte transférant un datagramme à route source contenant une option Timestamp **DOIT (MUST)** ajouter l'horodatage actuel à l'option, conformément aux règles de cette option.
Pour définir les restrictions selon lesquelles un hôte transfère des datagrammes à route source, nous utilisons les termes « routage de source local (local source-routing) » pour désigner le cas où le saut suivant sera atteint via la même interface physique que celle par laquelle le datagramme est arrivé ; sinon, il s'agit d'un « routage de source non local (non-local source-routing) ».
- Un hôte est autorisé à effectuer un routage de source local sans restriction.
- Un hôte prenant en charge le routage de source non local DOIT (MUST) disposer d'un commutateur configurable pour désactiver le transfert, et ce commutateur DOIT (MUST) être désactivé par défaut.
- Un hôte DOIT (MUST) satisfaire toutes les exigences de passerelle des filtres de politique configurables de [INTRO:2] qui restreignent le transfert non local.
Si un hôte reçoit un datagramme à route source incomplète mais ne le transfère pas pour une raison quelconque, l'hôte DEVRAIT (SHOULD) renvoyer un message ICMP « Destination Unreachable (code 5, Source Route Failed) », à moins que le datagramme ne soit lui-même un message d'erreur ICMP.
3.3.6 Diffusions (Broadcasts)
La section 3.2.1.3 définit quatre formes standard d'adresses de diffusion IP :
Diffusion limitée (Limited Broadcast) : {-1, -1}
Diffusion dirigée (Directed Broadcast) : {<numéro de réseau>, -1}
Diffusion dirigée sous-réseau (Subnet Directed Broadcast) : {<numéro de réseau>, <numéro de sous-réseau>, -1}
Diffusion dirigée toutes-sous-réseaux (All-Subnets Directed Broadcast) : {<numéro de réseau>, -1, -1}
Un hôte DOIT (MUST) reconnaître l'une quelconque des formes ci-dessus dans le champ d'adresse de destination d'un datagramme entrant.
Il existe une classe d'hôtes* utilisant des formes d'adresse de diffusion non standard, remplaçant -1 par 0. Tous les hôtes DEVRAIENT (SHOULD) reconnaître et accepter chacune de ces adresses de diffusion non standard comme adresse de destination d'un datagramme entrant. Un hôte PEUT (MAY) fournir facultativement une option de configuration pour chaque interface physique afin de choisir la forme 0 ou la forme -1 de l'adresse de diffusion, mais cette option DEVRAIT (SHOULD) être par défaut la forme standard (-1).
*Systèmes dérivés d'Unix 4.2BSD et suivants, à l'exception de 4.3BSD.
Lorsqu'un hôte envoie un datagramme à une adresse de diffusion de la couche de liaison (link-layer), l'adresse de destination IP DOIT (MUST) être une adresse de diffusion IP ou de multicast IP valide.
Un hôte DEVRAIT (SHOULD) ignorer silencieusement les datagrammes reçus via une diffusion de couche de liaison (voir section 2.4) mais qui ne spécifient pas d'adresse de destination de multicast ou de diffusion IP.
Un hôte DEVRAIT (SHOULD) utiliser l'adresse de diffusion limitée pour diffuser sur le réseau connecté.
DISCUSSION :
L'utilisation de l'adresse de diffusion limitée plutôt que de l'adresse de diffusion dirigée peut améliorer la robustesse du système. Les problèmes sont souvent causés par des machines qui ne comprennent pas la grande variété d'adresses de diffusion (voir section 3.2.1.3), ou qui ont une opinion différente des adresses de diffusion utilisées. Un exemple typique de ce dernier cas est une machine qui ne comprend pas le sous-réseau mais est connectée à un réseau qui a été subdivisé. L'envoi d'une diffusion de sous-réseau pour le réseau connecté déroutera ces machines, qui la verront comme un message destiné à un autre hôte.
La question de savoir si les datagrammes adressés à l'adresse de diffusion limitée doivent être émis depuis toutes les interfaces d'un hôte multihomed a fait l'objet de discussions. La présente spécification ne prend pas position sur cette question.
3.3.7 Multidiffusion IP (IP Multicasting)
Un hôte DEVRAIT (SHOULD) prendre en charge la multidiffusion IP locale sur tous les réseaux connectés pour lesquels un mappage d'adresses IP de classe D vers des adresses de couche de liaison a été défini (voir ci-dessous). La prise en charge de la multidiffusion IP locale comprend l'envoi de datagrammes multicast, l'adhésion à des groupes multicast et la réception de datagrammes multicast, ainsi que le départ de groupes multicast. Cela implique la prise en charge de l'intégralité de [IP:4] (à l'exception du protocole IGMP lui-même, qui est OPTIONNEL (OPTIONAL)).
DISCUSSION :
IGMP fournit aux passerelles capables de routage multicast les informations nécessaires pour prendre en charge la multidiffusion IP à travers plusieurs réseaux. Actuellement, les passerelles de routage multicast en sont encore au stade expérimental et ne sont pas largement disponibles. Pour les hôtes non connectés à un réseau disposant de passerelles de routage multicast, ou qui n'ont pas besoin de recevoir des datagrammes multicast en provenance d'autres réseaux, IGMP est inutile et reste donc optionnel pour l'instant. Cependant, le reste de [IP:4] est actuellement recommandé, afin de fournir un accès au niveau IP à l'adressage multicast local du réseau, comme alternative souhaitable à l'adressage par diffusion locale. On s'attend à ce qu'à l'avenir, à mesure que les passerelles de routage multicast deviendront plus répandues, IGMP devienne recommandé.
Si IGMP n'est pas implémenté, l'hôte DEVRAIT (SHOULD) néanmoins adhérer au groupe « all-hosts » (tous-hôtes) (224.0.0.1) lors de l'initialisation de sa couche IP, et maintenir cette adhésion tant que la couche IP est active.
DISCUSSION :
L'adhésion au groupe « all-hosts » prend en charge l'usage strictement local de la multidiffusion, par exemple les protocoles de découverte de passerelle, même sans implémentation d'IGMP.
Le mappage des adresses IP de classe D vers des adresses locales est actuellement spécifié pour les types de réseaux suivants :
-
Ethernet/IEEE 802.3, tel que défini dans [IP:4].
-
Tout réseau prenant en charge la diffusion mais non la multidiffusion : toutes les adresses IP de classe D sont mappées vers l'adresse de diffusion locale.
-
Tout type de liaison point à point (par exemple liaison SLIP ou HDLC) : aucun mappage n'est nécessaire. Tous les datagrammes multicast IP sont envoyés tels quels dans la trame locale.
Les mappages pour d'autres types de réseaux seront spécifiés ultérieurement.
Un hôte DEVRAIT (SHOULD) fournir un moyen permettant aux protocoles ou applications de couche supérieure de déterminer lesquels de ses réseaux connectés prennent en charge l'adressage multicast IP.
3.3.8 Signalement d'erreurs (Error Reporting)
Dans la mesure du possible, un hôte DOIT (MUST) renvoyer un datagramme d'erreur ICMP lorsqu'une erreur est détectée, sauf dans les cas où le renvoi de messages d'erreur ICMP est explicitement interdit.
DISCUSSION :
Un phénomène courant dans les réseaux de datagrammes est la « maladie du trou noir (black hole disease) » : des datagrammes sont envoyés, mais rien ne revient. Sans aucun message d'erreur, l'utilisateur a du mal à comprendre où se situe le problème.
3.4 Interface couche Internet / couche de transport (INTERNET/TRANSPORT LAYER INTERFACE)
L'interface entre la couche IP et la couche de transport DOIT (MUST) fournir un accès complet à tous les mécanismes de la couche IP, y compris les options, le type de service et la durée de vie. La couche de transport DOIT (MUST) disposer d'un mécanisme pour définir ces paramètres d'interface, ou d'un chemin pour les transmettre de manière transparente depuis la couche application, ou les deux.
DISCUSSION :
On exhorte les applications à tirer parti de ces mécanismes là où ils sont applicables, même s'ils ne sont pas encore effectifs dans l'Internet actuel (par exemple le TOS). Cela permettra à ces mécanismes d'être immédiatement disponibles lorsqu'ils le deviendront, sans nécessiter de restructuration massive des logiciels d'hôte.
Nous décrivons maintenant l'interface conceptuelle entre la couche de transport et la couche IP comme un ensemble d'appels de procédure. Il s'agit d'une extension des informations de la section 3.3 de RFC-791 [IP:1].
-
Envoyer un datagramme (Send Datagram)
SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result )
Les paramètres sont définis dans RFC-791. Le passage du paramètre Id est facultatif ; voir section 3.2.1.5.
-
Recevoir un datagramme (Receive Datagram)
RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)
Tous les paramètres sont définis dans RFC-791, à l'exception de :
SpecDest = l'adresse de destination spécifique du datagramme (définie dans la section 3.2.1.3)
Le paramètre result dst contient l'adresse de destination du datagramme. Comme celle-ci peut être une adresse de diffusion ou de multicast, le paramètre SpecDest DOIT (MUST) être transmis (non montré dans RFC-791). Le paramètre opt contient toutes les options IP reçues dans le datagramme ; ces options DOIT (MUST) également être transmises à la couche de transport.
-
Sélectionner l'adresse source (Select Source Address)
GET_SRCADDR(remote, TOS) -> local
remote = adresse IP distante TOS = type de service local = adresse IP locale
Voir section 3.3.4.3.
-
Trouver les tailles maximales de datagramme (Find Maximum Datagram Sizes)
GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
MMS_R = taille maximale du message de transport receivable. MMS_S = taille maximale du message de transport envoyable. (local, remote, TOS sont définis comme ci-dessus)
Voir sections 3.3.2 et 3.3.3.
-
Avis de réussite de livraison (Advice on Delivery Success)
ADVISE_DELIVPROB(sense, local, remote, TOS)
Ici, le paramètre sense est un drapeau d'un bit indiquant si l'avis est positif ou négatif ; voir la discussion de la section 3.3.1.4. Les autres paramètres sont définis précédemment.
-
Envoyer un message ICMP (Send ICMP Message)
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result
(les paramètres sont définis dans RFC-791).
Le passage du paramètre Id est facultatif ; voir section 3.2.1.5. La couche de transport DOIT (MUST) être capable d'envoyer certains messages ICMP : port inaccessible ou tout message de type requête. Bien sûr, cette fonction peut être considérée comme un cas particulier de l'appel SEND() ; nous la décrivons séparément pour plus de clarté.
-
Recevoir un message ICMP (Receive ICMP Message)
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
(les paramètres sont définis dans RFC-791).
La couche IP DOIT (MUST) transmettre certains messages ICMP vers les routines de couche de transport correspondantes. Bien sûr, cette fonction peut être considérée comme un cas particulier de l'appel RECV() ; nous la décrivons séparément pour plus de clarté.
Pour les messages d'erreur ICMP, les données transmises vers le haut DOIVENT (MUST) inclure l'en-tête Internet d'origine plus tous les octets du message d'origine contenus dans le message ICMP. La couche de transport utilisera ces données pour localiser les informations d'état de connexion (le cas échéant).
En particulier, les messages ICMP suivants DEVRAIENT (SHOULD) être transmis vers le haut :
- Destination Unreachable (Destination inaccessible)
- Source Quench (Source épuisée)
- Echo Reply (Réponse d'écho) (vers l'interface utilisateur ICMP, sauf si la requête d'écho provient de la couche IP)
- Timestamp Reply (Réponse d'horodatage) (vers l'interface utilisateur ICMP)
- Time Exceeded (Temps dépassé)
DISCUSSION :
À l'avenir, il peut y avoir des ajouts à cette interface pour transmettre des données de chemin entre la couche IP et la couche de transport (voir section 3.3.1.3).
3.5 Résumé des exigences de la couche Internet (INTERNET LAYER REQUIREMENTS SUMMARY)
| Fonctionnalité (Feature) | Section | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Implémenter IP et ICMP (Implement IP and ICMP) | 3.1 | x | ||||
| Gérer le multihoming distant dans la couche application (Handle remote multihoming in application layer) | 3.1 | x | ||||
| Prendre en charge le multihoming local (Support local multihoming) | 3.1 | x | ||||
| Respecter les spécifications de passerelle si transfert de datagrammes (Meet gateway specs if forward datagrams) | 3.1 | x | ||||
| Commutateur de configuration pour passerelle embarquée (Configuration switch for embedded gateway) | 3.1 | x | 1 | |||
| - Le commutateur de config par défaut non-passerelle (- Config switch default to non-gateway) | 3.1 | x | 1 | |||
| - Auto-config selon le nombre d'interfaces (- Auto-config based on number of interfaces) | 3.1 | x | ||||
| Être capable de journaliser les datagrammes abandonnés (Able to log discarded datagrams) | 3.1 | x | ||||
| - Enregistrer dans un compteur (- Record in counter) | 3.1 | x | ||||
| Rejeter silencieusement Version != 4 (Silently discard Version != 4) | 3.2.1.1 | x | ||||
| Vérifier la somme de contrôle IP, rejeter silencieusement le datagramme erroné (Verify IP checksum, silently discard bad dgram) | 3.2.1.2 | x | ||||
| Adressage (Addressing) : | ||||||
| - Adressage par sous-réseau (RFC-950) (- Subnet addressing (RFC-950)) | 3.2.1.3 | x | ||||
| - L'adresse source doit être l'adresse IP propre de l'hôte (- Src address must be host's own IP address) | 3.2.1.3 | x | ||||
| - Rejeter silencieusement le datagramme à mauvaise adresse de destination (- Silently discard datagram with bad dest addr) | 3.2.1.3 | x | ||||
| - Rejeter silencieusement le datagramme à mauvaise adresse source (- Silently discard datagram with bad src addr) | 3.2.1.3 | x | ||||
| Prendre en charge le réassemblage (Support reassembly) | 3.2.1.4 | x | ||||
| Conserver le même champ Id dans un datagramme identique (Retain same Id field in identical datagram) | 3.2.1.5 | x | ||||
| TOS : | ||||||
| - Permettre à la couche transport de définir le TOS (- Allow transport layer to set TOS) | 3.2.1.6 | x | ||||
| - Transmettre le TOS reçu vers la couche transport (- Pass received TOS up to transport layer) | 3.2.1.6 | x | ||||
| - Utiliser les mappages de couche liaison RFC-795 pour le TOS (- Use RFC-795 link-layer mappings for TOS) | 3.2.1.6 | x | ||||
| TTL : | ||||||
| - Envoyer un paquet avec TTL de 0 (- Send packet with TTL of 0) | 3.2.1.7 | x | ||||
| - Abandonner les paquets reçus avec TTL < 2 (- Discard received packets with TTL < 2) | 3.2.1.7 | x | ||||
| - Permettre à la couche transport de définir le TTL (- Allow transport layer to set TTL) | 3.2.1.7 | x | ||||
| - TTL fixe configurable (- Fixed TTL is configurable) | 3.2.1.7 | x | ||||
| Options IP (IP Options) : | ||||||
| - Permettre à la couche transport d'envoyer des options IP (- Allow transport layer to send IP options) | 3.2.1.8 | x | ||||
| - Transmettre toutes les options IP reçues vers la couche supérieure (- Pass all IP options rcvd to higher layer) | 3.2.1.8 | x | ||||
| - La couche IP ignore silencieusement les options inconnues (- IP layer silently ignore unknown options) | 3.2.1.8 | x | ||||
| - Option de sécurité (- Security option) | 3.2.1.8a | x | ||||
| - Envoyer l'option Stream Identifier (- Send Stream Identifier option) | 3.2.1.8b | x | ||||
| - Ignorer silencieusement l'option Stream Identifer (- Silently ignore Stream Identifer option) | 3.2.1.8b | x | ||||
| - Option Record Route (- Record Route option) | 3.2.1.8d | x | ||||
| - Option Timestamp (- Timestamp option) | 3.2.1.8e | x | ||||
| Option Source Route (Source Route Option) : | ||||||
| - Originer et terminer les options Source Route (- Originate & terminate Source Route options) | 3.2.1.8c | x | ||||
| - Datagramme avec SR terminé transmis vers TL (- Datagram with completed SR passed up to TL) | 3.2.1.8c | x | ||||
| - Construire un retour de route correct (non redondant) (- Build correct (non-redundant) return route) | 3.2.1.8c | x | ||||
| - Envoyer plusieurs options SR dans un en-tête (- Send multiple SR options in one header) | 3.2.1.8c | x | ||||
| ICMP : | ||||||
| - Rejeter silencieusement un msg ICMP de type inconnu (- Silently discard ICMP msg with unknown type) | 3.2.2 | x | ||||
| - Inclure plus de 8 octets du datagramme d'origine (- Include more than 8 octets of orig datagram) | 3.2.2 | x | ||||
| - Les octets inclus identiques à ceux reçus (- Included octets same as received) | 3.2.2 | x | ||||
| - Démultiplexer l'erreur ICMP vers le protocole transport (- Demux ICMP Error to transport protocol) | 3.2.2 | x | ||||
| - Envoyer un message d'erreur ICMP avec TOS=0 (- Send ICMP error message with TOS=0) | 3.2.2 | x | ||||
| - Envoyer un message d'erreur ICMP pour : (- Send ICMP error message for: ) | ||||||
| - msg d'erreur ICMP (- ICMP error msg) | 3.2.2 | x | ||||
| - diffusion IP ou multicast IP (- IP b'cast or IP m'cast) | 3.2.2 | x | ||||
| - diffusion de couche liaison (- Link-layer b'cast) | 3.2.2 | x | ||||
| - fragment non initial (- Non-initial fragment) | 3.2.2 | x | ||||
| - datagramme à adresse source non unique (- Datagram with non-unique src address) | 3.2.2 | x | ||||
| - Renvoyer les messages d'erreur ICMP (sauf interdiction) (- Return ICMP error msgs (when not prohibited)) | 3.3.8 | x | ||||
| - Destination Unreachable : | ||||||
| Générer Destination Unreachable (code 2/3) (Generate Dest Unreachable (code 2/3)) | 3.2.2.1 | x | ||||
| Transmettre ICMP Dest Unreachable vers la couche supérieure (Pass ICMP Dest Unreachable to higher layer) | 3.2.2.1 | x | ||||
| La couche supérieure agit sur Dest Unreach (Higher layer act on Dest Unreach) | 3.2.2.1 | x | ||||
| Interpréter Dest Unreach comme simple indice (Interpret Dest Unreach as only hint) | 3.2.2.1 | x | ||||
| - Redirect : | ||||||
| Hôte envoie Redirect (Host send Redirect) | 3.2.2.2 | x | ||||
| Mettre à jour le cache de routage à la réception de Redirect (Update route cache when recv Redirect) | 3.2.2.2 | x | ||||
| Gérer à la fois Host et Net Redirects (Handle both Host and Net Redirects) | 3.2.2.2 | x | ||||
| Rejeter un Redirect illégal (Discard illegal Redirect) | 3.2.2.2 | x | ||||
| - Source Quench : | ||||||
| Envoyer Source Quench si tampon dépassé (Send Source Quench if buffering exceeded) | 3.2.2.3 | x | ||||
| Transmettre Source Quench vers la couche supérieure (Pass Source Quench to higher layer) | 3.2.2.3 | x | ||||
| La couche supérieure agit sur Source Quench (Higher layer act on Source Quench) | 3.2.2.3 | x | ||||
| - Time Exceeded : transmettre vers la couche supérieure (Time Exceeded: pass to higher layer) | 3.2.2.4 | x | ||||
| - Parameter Problem : | ||||||
| Envoyer des messages Parameter Problem (Send Parameter Problem messages) | 3.2.2.5 | x | ||||
| Transmettre Parameter Problem vers la couche supérieure (Pass Parameter Problem to higher layer) | 3.2.2.5 | x | ||||
| Signaler Parameter Problem à l'utilisateur (Report Parameter Problem to user) | 3.2.2.5 | x | ||||
| - Requête/Réponse ICMP Echo (ICMP Echo Request or Reply) : | ||||||
| Serveur Echo et client Echo (Echo server and Echo client) | 3.2.2.6 | x | ||||
| Client Echo (Echo client) | 3.2.2.6 | x | ||||
| Rejeter la requête Echo adressée à une diffusion (Discard Echo Request to broadcast address) | 3.2.2.6 | x | ||||
| Rejeter la requête Echo adressée à un multicast (Discard Echo Request to multicast address) | 3.2.2.6 | x | ||||
| Utiliser l'adresse dest spécifique comme source Echo Reply (Use specific-dest addr as Echo Reply src) | 3.2.2.6 | x | ||||
| Envoyer les mêmes données dans Echo Reply (Send same data in Echo Reply) | 3.2.2.6 | x | ||||
| Transmettre Echo Reply vers la couche supérieure (Pass Echo Reply to higher layer) | 3.2.2.6 | x | ||||
| Réfléchir les options Record Route, Timestamp (Reflect Record Route, Time Stamp options) | 3.2.2.6 | x | ||||
| Inverser et réfléchir l'option Source Route (Reverse and reflect Source Route option) | 3.2.2.6 | x | ||||
| - Requête/Réponse masque d'adresse ICMP (ICMP Address Mask Request and Reply) : | ||||||
| Source du masque d'adresse configurable (Addr Mask source configurable) | 3.2.2.9 | x | ||||
| Prendre en charge la configuration statique du masque d'adresse (Support static configuration of addr mask) | 3.2.2.9 | x | ||||
| Obtenir dynamiquement le masque d'adresse pendant le démarrage (Get addr mask dynamically during booting) | 3.2.2.9 | x | ||||
| Obtenir l'adresse via Requête/Réponse masque ICMP (Get addr via ICMP Addr Mask Request/Reply) | 3.2.2.9 | x | ||||
| Retransmettre la requête masque si pas de réponse (Retransmit Addr Mask Req if no Reply) | 3.2.2.9 | x | 3 | |||
| Supposer le masque par défaut si pas de réponse (Assume default mask if no Reply) | 3.2.2.9 | x | 3 | |||
| Mettre à jour le masque d'adresse uniquement depuis la 1re réponse (Update address mask from first Reply only) | 3.2.2.9 | x | 3 | |||
| Vérification de plausibilité du masque d'adresse (Reasonableness check on Addr Mask) | 3.2.2.9 | x | ||||
| Envoyer des messages de réponse masque non autorisés (Send unauthorized Addr Mask Reply msgs) | 3.2.2.9 | x | ||||
| Explicitement configuré comme agent (Explicitly configured to be agent) | 3.2.2.9 | x | ||||
| Config statique => drapeau Addr-Mask-Authoritative (Static config=> Addr-Mask-Authoritative flag) | 3.2.2.9 | x | ||||
| Diffuser la réponse masque d'adresse à l'initialisation (Broadcast Addr Mask Reply when init.) | 3.2.2.9 | x | 3 | |||
| Routage des datagrammes sortants (ROUTING OUTBOUND DATAGRAMS) : | ||||||
| - Utiliser le masque d'adresse dans la décision local/distant (Use address mask in local/remote decision) | 3.3.1.1 | x | ||||
| - Fonctionner sans passerelle sur le réseau connecté (Operate with no gateways on conn network) | 3.3.1.1 | x | ||||
| - Maintenir un « cache de routage » des passerelles de saut suivant (Maintain "route cache" of next-hop gateways) | 3.3.1.2 | x | ||||
| - Traiter Host et Net Redirect de la même manière (Treat Host and Net Redirect the same) | 3.3.1.2 | x | ||||
| - En l'absence d'entrée de cache, utiliser la passerelle par défaut (If no cache entry, use default gateway) | 3.3.1.2 | x | ||||
| Prendre en charge plusieurs passerelles par défaut (Support multiple default gateways) | 3.3.1.2 | x | ||||
| - Fournir une table de routes statiques (Provide table of static routes) | 3.3.1.2 | x | ||||
| Drapeau : route remplaçable par Redirects (Flag: route overridable by Redirects) | 3.3.1.2 | x | ||||
| - Indexer le cache de routage sur l'hôte, pas sur le réseau (Key route cache on host, not net address) | 3.3.1.3 | x | ||||
| - Inclure le TOS dans le cache de routage (Include TOS in route cache) | 3.3.1.3 | x | ||||
| - Être capable de détecter la défaillance de la passerelle de saut suivant (Able to detect failure of next-hop gateway) | 3.3.1.4 | x | ||||
| - Supposer que la route est valide pour toujours (Assume route is good forever) | 3.3.1.4 | x | ||||
| - Pinger continuellement les passerelles (Ping gateways continuously) | 3.3.1.4 | x | ||||
| - Pinger uniquement quand du trafic est envoyé (Ping only when traffic being sent) | 3.3.1.4 | x | ||||
| - Pinger uniquement sans indication positive (Ping only when no positive indication) | 3.3.1.4 | x | ||||
| - Les couches supérieure et inférieure donnent des conseils (Higher and lower layers give advice) | 3.3.1.4 | x | ||||
| - Basculer de la passerelle par défaut défaillante vers une autre (Switch from failed default g'way to another) | 3.3.1.5 | x | ||||
| - Méthode de saisie manuelle des infos de config (Manual method of entering config info) | 3.3.1.6 | x | ||||
| Réassemblage et fragmentation (REASSEMBLY and FRAGMENTATION) : | ||||||
| - Être capable de réassembler les datagrammes entrants (Able to reassemble incoming datagrams) | 3.3.2 | x | ||||
| Datagrammes d'au moins 576 octets (At least 576 byte datagrams) | 3.3.2 | x | ||||
| EMTU_R configurable ou indéfini (EMTU_R configurable or indefinite) | 3.3.2 | x | ||||
| - La couche transport peut apprendre MMS_R (Transport layer able to learn MMS_R) | 3.3.2 | x | ||||
| - Envoyer ICMP Time Exceeded en cas de dépassement de réassemblage (Send ICMP Time Exceeded on reassembly timeout) | 3.3.2 | x | ||||
| Valeur de délai de réassemblage fixe (Fixed reassembly timeout value) | 3.3.2 | x | ||||
| - Transmettre MMS_S vers les couches supérieures (Pass MMS_S to higher layers) | 3.3.3 | x | ||||
| - Fragmentation locale des paquets sortants (Local fragmentation of outgoing packets) | 3.3.3 | x | ||||
| Sinon ne pas envoyer plus grand que MMS_S (Else don't send bigger than MMS_S) | 3.3.3 | x | ||||
| - Envoyer max 576 vers destination hors réseau (Send max 576 to off-net destination) | 3.3.3 | x | ||||
| - Drapeau de configuration All-Subnets-MTU (All-Subnets-MTU configuration flag) | 3.3.3 | x | ||||
| Multihoming : | ||||||
| - Répondre avec la même adresse que l'adresse dest spécifique (Reply with same addr as spec-dest addr) | 3.3.4.2 | x | ||||
| - Permettre à l'application de choisir l'adresse IP locale (Allow application to choose local IP addr) | 3.3.4.2 | x | ||||
| - Rejeter silencieusement le datagramme sur interface « erronée » (Silently discard d'gram in "wrong" interface) | 3.3.4.2 | x | ||||
| - N'envoyer le datagramme que via l'interface « correcte » (Only send d'gram through "right" interface) | 3.3.4.2 | x | 4 | |||
| Transfert de routage de source (SOURCE-ROUTE FORWARDING) : | ||||||
| - Transférer le datagramme avec option Source Route (Forward datagram with Source Route option) | 3.3.5 | x | 1 | |||
| Respecter les règles de passerelle correspondantes (Obey corresponding gateway rules) | 3.3.5 | x | 1 | |||
| Mettre à jour TTL selon les règles de passerelle (Update TTL by gateway rules) | 3.3.5 | x | 1 | |||
| Être capable de générer les codes d'erreur ICMP 4, 5 (Able to generate ICMP err code 4, 5) | 3.3.5 | x | 1 | |||
| Adresse source IP non hôte local (IP src addr not local host) | 3.3.5 | x | 1 | |||
| Mettre à jour les options Timestamp, Record Route (Update Timestamp, Record Route options) | 3.3.5 | x | 1 | |||
| Commutateur configurable pour SR non local (Configurable switch for non-local SRing) | 3.3.5 | x | 1 | |||
| Désactivé par défaut (Defaults to OFF) | 3.3.5 | x | 1 | |||
| Satisfaire les règles d'accès passerelle pour SR non local (Satisfy gwy access rules for non-local SRing) | 3.3.5 | x | 1 | |||
| Si pas de transfert, envoyer Dest Unreach (cd 5) (If not forward, send Dest Unreach (cd 5)) | 3.3.5 | x | 2 | |||
| Diffusion (BROADCAST) : | ||||||
| - Adresse de diffusion comme adresse source IP (Broadcast addr as IP source addr) | 3.2.1.3 | x | ||||
| - Recevoir formats de diffusion 0 ou -1 OK (Receive 0 or -1 broadcast formats OK) | 3.3.6 | x | ||||
| - Option configurable pour envoyer diffusion 0 ou -1 (Config'ble option to send 0 or -1 b'cast) | 3.3.6 | x | ||||
| Par défaut diffusion -1 (Default to -1 broadcast) | 3.3.6 | x | ||||
| - Reconnaître tous les formats d'adresse de diffusion (Recognize all broadcast address formats) | 3.3.6 | x | ||||
| - Utiliser adresse b'cast/m'cast IP dans b'cast liaison (Use IP b'cast/m'cast addr in link-layer b'cast) | 3.3.6 | x | ||||
| - Rejeter silencieusement les datagrammes b'cast liaison seule (Silently discard link-layer-only b'cast dg's) | 3.3.6 | x | ||||
| - Utiliser l'adresse de diffusion limitée pour le réseau connecté (Use Limited Broadcast addr for connected net) | 3.3.6 | x | ||||
| Multicast (MULTICAST) : | ||||||
| - Prendre en charge la multidiffusion IP locale (RFC-1112) (Support local IP multicasting (RFC-1112)) | 3.3.7 | x | ||||
| - Prendre en charge IGMP (RFC-1112) (Support IGMP (RFC-1112)) | 3.3.7 | x | ||||
| - Rejoindre le groupe all-hosts au démarrage (Join all-hosts group at startup) | 3.3.7 | x | ||||
| - Les couches supérieures apprennent la capacité m'cast de l'iface (Higher layers learn i'face m'cast capability) | 3.3.7 | x | ||||
| Interface (INTERFACE) : | ||||||
| - Permettre à la couche transport d'utiliser tous les mécanismes IP (Allow transport layer to use all IP mechanisms) | 3.4 | x | ||||
| - Transmettre l'identifiant d'interface vers la couche transport (Pass interface ident up to transport layer) | 3.4 | x | ||||
| - Transmettre toutes les options IP vers la couche transport (Pass all IP options up to transport layer) | 3.4 | x | ||||
| - La couche transport peut envoyer certains messages ICMP (Transport layer can send certain ICMP messages) | 3.4 | x | ||||
| - Transmettre les messages ICMP spécifiés vers la couche transport (Pass spec'd ICMP messages up to transp. layer) | 3.4 | x | ||||
| Inclure en-tête IP + au moins 8 octets de l'orig. (Include IP hdr+8 octets or more from orig.) | 3.4 | x |
Notes de bas de page (Footnotes) :
(1) Uniquement si la fonctionnalité est implémentée. (2) Cette exigence est annulée si le datagramme est un message d'erreur ICMP. (3) Uniquement si la fonctionnalité est implémentée et configurée sur « activé ». (4) Sauf s'il dispose de la fonctionnalité de passerelle embarquée ou est soumis à un routage de source.