4. Internet Layer - Protocols (Couche Internet - Protocoles)

4.1 Introduction (Introduction)

Ce chapitre et le chapitre 5 traitent des protocoles utilisés par la couche Internet: IP, ICMP et IGMP. Puisque le routage est évidemment un sujet central dans un document sur les routeurs, le chapitre 5 se limite aux aspects des protocoles directement liés au routage. Ce chapitre contient le reste de la discussion sur les protocoles de la couche Internet.

4.2 Internet Protocol - IP (Protocole Internet)

4.2.1 Introduction (Introduction)

Les routeurs DOIVENT implémenter le protocole IP défini par [INTERNET:1]. Ils DOIVENT également implémenter ses extensions obligatoires: les sous-réseaux (définis dans [INTERNET:2]), la diffusion IP (définie dans [INTERNET:3]) ainsi que le routage inter-domaine sans classe (CIDR, défini dans [INTERNET:15]).

Les implémenteurs de routeurs n'ont pas besoin de considérer la conformité avec le chapitre intitulé "Internet Protocol -- IP" dans [INTRO:2], car ce chapitre est entièrement répété ou remplacé dans ce document. Les routeurs DOIVENT être conformes et DEVRAIENT être inconditionnellement conformes aux exigences relatives à IP dans la section intitulée "SPECIFIC ISSUES" de [INTRO:2].

Dans ce qui suit, dans certains cas, l'opération spécifiée est de rejeter silencieusement les datagrammes reçus. Cela signifie que le datagramme sera rejeté sans traitement ultérieur et que le routeur n'enverra pas de message d'erreur ICMP en conséquence (voir section [4.3]). Cependant, pour diagnostiquer les problèmes, le routeur DEVRAIT fournir la capacité d'enregistrer les erreurs (voir section [1.3.3]), y compris le contenu des datagrammes rejetés silencieusement, et DEVRAIT compter les datagrammes rejetés.

4.2.2 Protocol Walk-Through (Parcours du protocole)

RFC 791 [INTERNET:1] est la spécification du protocole Internet.

4.2.2.1 Options: RFC 791 Section 3.2 (Options)

Dans les datagrammes reçus par le routeur lui-même, la couche IP DOIT interpréter les options IP qu'elle comprend et laisser le reste inchangé pour les protocoles de couche supérieure.

Les protocoles de couche supérieure peuvent avoir besoin de la capacité de définir des options IP dans les datagrammes qu'ils envoient ou d'examiner les options IP dans les datagrammes qu'ils reçoivent. Les sections ultérieures de ce document discutent du support spécifique des options IP requis par les protocoles de couche supérieure.

DISCUSSION (Discussion)

Ni ce mémo ni [INTRO:2] ne définissent l'ordre dans lequel un récepteur doit traiter plusieurs options dans le même en-tête IP. Les hôtes et les routeurs qui initient des datagrammes contenant plusieurs options doivent être conscients que cela introduit certaines ambiguïtés dans la signification des options lorsqu'elles sont combinées avec des options de routage source.

Voici les exigences pour les options IP spécifiques:

(a) Security Option (Option de sécurité)

Certains environnements exigent l'option Security dans chaque paquet initié ou reçu. Les routeurs DEVRAIENT implémenter l'option de sécurité révisée décrite dans [INTERNET:5].

DISCUSSION (Discussion)

Notez que l'option de sécurité décrite dans [INTERNET:1] et RFC 1038 ([INTERNET:16]) est obsolète.

(b) Stream Identifier Option (Option d'identificateur de flux)

Cette option est obsolète; les routeurs NE DEVRAIENT PAS placer cette option dans les datagrammes qu'ils initient. Cette option dans les datagrammes reçus par les routeurs DOIT être ignorée.

(c) Source Route Options (Options de routage source)

Les routeurs DOIVENT être capables d'agir en tant que destination finale d'un routage source. Si un routeur reçoit un paquet contenant un routage source terminé, ce paquet a atteint sa destination finale. Dans une telle option, le pointeur pointe au-delà du dernier champ et l'adresse de destination dans l'en-tête IP est l'adresse du routeur. L'option reçue (route enregistrée) DOIT être transmise à la couche transport (ou au traitement des messages ICMP).

Dans le cas général, la réponse correcte à un datagramme à routage source traversera la même route. Les routeurs DOIVENT fournir un moyen par lequel les protocoles de transport et les applications peuvent inverser le routage source dans le datagramme reçu. Lorsque le routeur ne connaît pas de contraintes de politique, ce routage source inversé DOIT être inséré dans les datagrammes qu'ils initient (voir [INTRO:2] pour plus de détails). Cependant, si le routeur est conscient de la politique, il PEUT choisir un autre chemin.

Certaines applications dans les routeurs PEUVENT exiger que l'utilisateur puisse entrer un routage source.

Les routeurs NE DOIVENT PAS initier de datagrammes contenant plusieurs options de routage source. Comment un routeur doit procéder lors du transfert d'un paquet contenant plusieurs options de routage source est décrit dans la section [5.2.4.1].

Lorsqu'une option de routage source est créée (ce qui se produit lorsque le routeur initie un datagramme à routage source ou lorsqu'une option de routage source est insérée en raison d'un filtre spécial), elle DOIT être correctement formée (voir le cas (B) dans la discussion ci-dessous), même si elle est créée en inversant une route enregistrée qui inclut incorrectement l'hôte source.

DISCUSSION (Discussion)

Supposons qu'un datagramme à routage source doive être routé de la source S via les routeurs G1, G2, Gn vers la destination D. La source S construit un datagramme dont l'adresse de destination est l'adresse IP de G1 et une option de routage source pour transmettre le datagramme au reste de sa destination. Cependant, il existe une ambiguïté dans la spécification quant à savoir si l'option de routage source dans le datagramme émis par S devrait être (A) ou (B):

(A): {>>G2, G3, ... Gn, D} &lt;--- correct

(B): {S, >>G2, G3, ... Gn, D} &lt;---- incorrect

(où >> indique le pointeur). Si (A) est envoyé, le datagramme reçu à D contiendra l'option: {G1, G2, ... Gn >>}, avec S et D comme adresses IP source et destination. Si (B) est envoyé, le datagramme reçu à D contiendra à nouveau S et D comme mêmes adresses IP source et destination, mais l'option sera: {S, G1, ...Gn >>}; c'est-à-dire que l'hôte d'origine serait le premier saut dans la route.

(d) Record Route Option (Option d'enregistrement de route)

Les routeurs PEUVENT prendre en charge l'option Record Route dans les datagrammes qu'ils initient.

(e) Timestamp Option (Option d'horodatage)

Les routeurs PEUVENT prendre en charge l'option timestamp dans les datagrammes qu'ils initient. Les règles suivantes s'appliquent:

Lors de l'initiation d'un datagramme contenant une option Timestamp, le routeur DOIT enregistrer un horodatage dans l'option si
- son champ d'adresse Internet n'est pas préspécifié, ou
- sa première adresse préspécifiée est l'adresse IP de l'interface logique envoyant le datagramme (ou le router-id du routeur si le datagramme est envoyé via une interface non numérotée).
Si le routeur lui-même reçoit un datagramme contenant une option Timestamp, le routeur DOIT insérer l'heure actuelle dans l'option Timestamp (s'il y a de l'espace dans l'option pour le faire) avant de transmettre l'option à la couche transport ou ICMP pour traitement. S'il n'y a pas d'espace, le routeur DOIT incrémenter le compteur de débordement dans l'option.
Les valeurs d'horodatage DOIVENT suivre les règles définies dans [INTRO:2].

IMPLEMENTATION (Implémentation)

Pour maximiser l'utilité des horodatages inclus dans l'option timestamp, les horodatages insérés devraient être aussi proches que possible du moment où le paquet arrive au routeur. Pour les datagrammes initiés par le routeur, les horodatages insérés devraient être aussi proches que possible du moment où le datagramme est transmis à la couche liaison pour transmission.

L'option timestamp permet l'utilisation d'horloges temporelles non standard, mais l'utilisation d'horloges non synchronisées limite l'utilité de l'horodatage. Par conséquent, il est recommandé que les routeurs implémentent le protocole Network Time Protocol pour synchroniser leurs horloges.

4.2.2.2 Addresses in Options: RFC 791 Section 3.1 (Adresses dans les options)

Il est demandé aux routeurs d'insérer leur adresse dans les options Record Route, Strict Source and Record Route, Loose Source and Record Route ou Timestamp. Lorsqu'un routeur insère son adresse dans de telles options, il DOIT utiliser l'adresse IP de l'interface logique envoyant le paquet. Si cette règle ne peut pas être respectée car l'interface de sortie n'a pas d'adresse IP (c'est-à-dire une interface non numérotée), le routeur DOIT plutôt insérer son router-id. Le router-id d'un routeur est l'une des adresses IP du routeur. Le Router ID PEUT être spécifié sur une base système ou par liaison. L'adresse du routeur utilisée comme router-id NE DOIT PAS changer (même après un redémarrage), sauf si elle est modifiée par un administrateur réseau. Les modifications administratives pertinentes incluent la reconfiguration du routeur de sorte que l'adresse IP utilisée comme router-id ne soit plus l'une des adresses IP du routeur. Les routeurs avec plusieurs interfaces non numérotées PEUVENT avoir plusieurs router-ids. Chaque interface non numérotée DOIT être associée à un router-id spécifique. Cette association NE DOIT PAS changer (même après un redémarrage) sans reconfiguration du routeur.

DISCUSSION (Discussion)

Cette spécification n'autorise pas de routeur sans au moins une adresse IP. Nous ne considérons pas cela comme une limitation sérieuse, car un routeur a besoin d'une adresse IP pour satisfaire aux exigences de gestion du chapitre [8], même si le routeur n'est connecté qu'à des liens point à point.

IMPLEMENTATION (Implémentation)

Une méthode possible pour choisir un router-id satisfaisant à cette exigence est d'utiliser l'adresse IP numériquement la plus petite (ou la plus grande) attribuée au routeur (en traitant l'adresse comme un entier 32 bits).

4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1 (Bits d'en-tête IP inutilisés)

L'en-tête IP contient deux bits réservés: un dans l'octet Type of Service et un dans le champ Flags. Les routeurs NE DOIVENT PAS définir l'un de ces bits à 1 dans les datagrammes qu'ils initient. Les routeurs NE DOIVENT PAS rejeter des paquets (refuser de recevoir ou de transférer) uniquement parce qu'un ou plusieurs de ces bits réservés ont une valeur non nulle; c'est-à-dire que les routeurs NE DOIVENT PAS examiner les valeurs de ces bits.

DISCUSSION (Discussion)

Les futures révisions du protocole IP pourraient utiliser ces bits inutilisés. Ces règles visent à garantir que ces révisions puissent être déployées sans avoir à mettre à jour simultanément tous les routeurs sur Internet.

4.2.2.4 Type of Service: RFC 791 Section 3.1 (Type de service)

L'octet Type-of-Service dans l'en-tête IP est divisé en trois parties: le champ Precedence (les 3 bits de poids fort), le champ généralement appelé Type of Service ou TOS (les 4 bits suivants) et le bit réservé (le bit de poids faible).

Les règles pour le bit réservé sont décrites dans la section [4.2.2.3].

Une discussion plus large sur le champ TOS et son utilisation se trouve dans [ROUTE:11].

La description du champ IP Precedence est remplacée par la section [5.3.3]. RFC 795, Service Mappings, est obsolète et NE DEVRAIT PAS être implémenté.

4.2.2.5 Header Checksum: RFC 791 Section 3.1 (Somme de contrôle d'en-tête)

Comme décrit dans la section [5.2.2], les routeurs DOIVENT vérifier la somme de contrôle IP de tout paquet reçu et DOIVENT rejeter les messages contenant une somme de contrôle invalide. Les routeurs NE DOIVENT PAS fournir de moyen de désactiver cette vérification de somme de contrôle.

Les routeurs PEUVENT utiliser une mise à jour incrémentale de la somme de contrôle de l'en-tête IP lorsque le seul changement à l'en-tête IP est la durée de vie. Cela réduira la probabilité que le routeur ait une corruption non détectée de l'en-tête IP. Pour une discussion sur la mise à jour incrémentale des sommes de contrôle, voir [INTERNET:6].

IMPLEMENTATION (Implémentation)

Une description plus complète de la somme de contrôle IP (y compris de nombreux conseils d'implémentation) se trouve dans [INTERNET:6] et [INTERNET:7].

4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1 (Options d'en-tête non reconnues)

Les routeurs DOIVENT ignorer les options IP qu'ils ne reconnaissent pas. Un corollaire de cette exigence est que les routeurs DOIVENT implémenter l'option End of Option List et l'option No Operation, car aucune des deux ne contient de longueur explicite.

DISCUSSION (Discussion)

Toutes les futures options IP contiendront une longueur explicite.

4.2.2.7 Fragmentation: RFC 791 Section 3.2 (Fragmentation)

Les routeurs DOIVENT prendre en charge la fragmentation décrite dans [INTERNET:1].

Lorsqu'un routeur fragmente un datagramme IP, il DEVRAIT minimiser le nombre de fragments. Lorsqu'un routeur fragmente un datagramme IP, il DEVRAIT envoyer les fragments dans l'ordre. Les méthodes de fragmentation qui peuvent produire un fragment IP sensiblement plus petit qu'un autre PEUVENT faire du premier fragment IP le plus petit.

DISCUSSION (Discussion)

Il existe plusieurs techniques de fragmentation couramment utilisées sur Internet. Une technique implique de diviser le datagramme IP en fragments IP, le premier étant de taille MTU et les autres à peu près de la même taille et plus petits que la MTU. Cela se fait pour deux raisons. Le premier fragment IP de la séquence sera la MTU effective du chemin actuel entre les hôtes, et la taille des fragments IP suivants est conçue pour minimiser la fragmentation ultérieure du datagramme IP. Une autre technique consiste à diviser le datagramme IP en fragments IP de taille MTU, le dernier fragment étant le seul plus petit, comme décrit dans [INTERNET:1].

Une astuce courante utilisée par certaines implémentations TCP/IP consiste à fragmenter un datagramme IP qui doit passer par un routeur en fragments IP ne dépassant pas 576 octets. Cela vise à permettre aux fragments IP résultants de traverser le reste du chemin sans fragmentation supplémentaire. Cependant, cela impose une charge plus importante sur l'hôte de destination car il aura plus de fragments IP à réassembler en un datagramme IP. Il n'est pas non plus efficace sur les réseaux où la MTU ne change qu'une seule fois et reste bien au-dessus de 576 octets. Les exemples incluent les réseaux LAN tels que les réseaux IEEE 802.5 avec une MTU de 2048 ou Ethernet avec une MTU de 1500.

Une autre technique de fragmentation discutée consiste à diviser le datagramme IP en fragments IP à peu près de taille égale, de taille inférieure ou égale à la MTU du réseau du prochain saut. Cela vise à minimiser le nombre de fragments qu'une fragmentation supplémentaire en aval du chemin entraînerait et à garantir que chaque fragment a un délai égal.

Les routeurs DEVRAIENT produire aussi peu de fragments IP que possible.

Le travail avec des machines lentes nous amène à croire que l'envoi du petit fragment IP en premier, s'il est nécessaire de fragmenter un message, maximise les chances qu'un hôte avec des interfaces lentes reçoive tous les fragments.

4.2.2.8 Reassembly: RFC 791 Section 3.2 (Réassemblage)

Comme spécifié dans la section correspondante de [INTRO:2], les routeurs DOIVENT prendre en charge le réassemblage des datagrammes qu'ils transmettent à eux-mêmes.

4.2.2.9 Time to Live: RFC 791 Section 3.2 (Durée de vie)

Le traitement du Time to Live (TTL) pour les paquets initiés ou reçus par le routeur est régi par [INTRO:2]; cette section ne modifie aucune de ses dispositions. Cependant, comme le reste de la section du protocole IP de [INTRO:2] est réécrit, cette section est également réécrite.

En particulier, les routeurs NE DOIVENT PAS examiner le TTL d'un paquet à tout moment autre que lors du transfert du paquet.

Les routeurs NE DOIVENT PAS initier ou transférer des datagrammes avec une valeur Time-to-Live (TTL) de zéro.

Les routeurs NE DOIVENT PAS rejeter des datagrammes uniquement parce que le TTL est égal à zéro ou un à la réception; s'il est adressé au routeur et qu'il est par ailleurs valide, le routeur DOIT tenter de le recevoir.

Pour les messages initiés par le routeur, la couche IP DOIT fournir à la couche transport un moyen de définir le champ TTL de chaque datagramme envoyé. Lorsqu'une valeur TTL fixe est utilisée, elle DOIT être configurable. Ce nombre DEVRAIT dépasser le diamètre typique d'Internet; la sagesse actuelle suggère qu'il devrait dépasser le double du diamètre d'Internet pour permettre la croissance. Les valeurs actuellement recommandées sont normalement publiées dans le RFC Assigned Numbers. Le champ TTL a deux fonctions: limiter la durée de vie des segments TCP (voir RFC 793 [TCP:1], p. 28) et terminer les boucles de routage Internet. Bien que le TTL soit un temps en secondes, il a également certaines propriétés du nombre de sauts, car chaque routeur doit réduire le champ TTL d'au moins 1.

L'expiration du TTL vise à entraîner le rejet d'un datagramme par un routeur, mais pas par l'hôte de destination. Par conséquent, les hôtes qui agissent comme routeurs en transférant des datagrammes DOIVENT suivre les règles TTL pour les routeurs.

Les protocoles de couche supérieure peuvent vouloir définir le TTL pour implémenter une recherche de "portée étendue" de certaines ressources Internet. Cela est utilisé par certains outils de diagnostic et devrait être utile pour localiser le serveur "le plus proche" d'une classe donnée en utilisant la multidiffusion IP. Des protocoles de transport spécifiques peuvent également vouloir spécifier leur propre limite TTL pour la durée de vie maximale des datagrammes.

La valeur par défaut fixe doit être suffisamment grande pour s'adapter au "diamètre" d'Internet, c'est-à-dire le chemin le plus long possible. Une valeur raisonnable est environ le double du diamètre pour permettre la croissance continue d'Internet. Au moment de la rédaction, les messages traversant les États-Unis parcourent fréquemment 15 à 20 routeurs; cela suggère que la valeur TTL par défaut devrait dépasser 40, et 64 est une valeur courante.

4.2.2.10 Multi-subnet Broadcasts: RFC 922 (Diffusions multi-sous-réseaux)

Les diffusions all-subnets (appelées diffusions multi-sous-réseaux dans [INTERNET:3]) sont obsolètes. Voir la section [5.3.5.3].

4.2.2.11 Addressing: RFC 791 Section 3.2 (Adressage)

Comme décrit en 2.2.5.1, il existe maintenant cinq classes d'adresses IP: Classe A à Classe E. Les adresses de classe D sont utilisées pour la multidiffusion IP [INTERNET:4], tandis que les adresses de classe E sont réservées à un usage expérimental. La distinction entre les adresses de classe A, B et C n'est plus importante; elles sont utilisées comme préfixes réseau unicast génériques, n'ayant qu'une signification historique quant à leur classe.

Les adresses de multidiffusion IP sont des adresses logiques de 28 bits représentant un groupe d'hôtes et peuvent être permanentes ou temporaires. Les adresses de multidiffusion permanentes sont attribuées par l'Internet Assigned Number Authority [INTRO:7], tandis que les adresses temporaires peuvent être attribuées dynamiquement à des groupes temporaires. L'appartenance au groupe est déterminée dynamiquement à l'aide d'IGMP [INTERNET:4].

Nous résumons maintenant les cas spéciaux importants des adresses IP unicast génériques, en utilisant la notation d'adresse IP suivante:

{ &lt;Network-prefix>, &lt;Host-number> }

et la notation -1 pour représenter un champ contenant tous les bits à 1 et 0 pour représenter un champ contenant tous les bits à 0.

(a) { 0, 0 }

Cet hôte sur ce réseau. Les routeurs NE DOIVENT PAS l'utiliser comme adresse source, sauf qu'un routeur PEUT l'utiliser comme adresse source pendant l'initialisation (par exemple, si le routeur utilise BOOTP pour charger ses informations de configuration).

Pour les datagrammes entrants livrés localement (voir section [5.2.3]) avec une adresse source de { 0, 0 }, ils DOIVENT être acceptés si le routeur implémente le protocole pertinent et que ce protocole définit clairement l'action appropriée à prendre. Sinon, le routeur DOIT rejeter silencieusement tout datagramme livré localement avec une adresse source de { 0, 0 }.

DISCUSSION (Discussion)

Certains protocoles définissent des actions spécifiques à prendre lors de la réception d'un datagramme avec une adresse source de { 0, 0 }. Deux exemples sont BOOTP et ICMP Mask Request. Le fonctionnement normal de ces protocoles dépend généralement de la capacité à recevoir des datagrammes avec une adresse source de { 0, 0 }. Cependant, pour la plupart des protocoles, il est préférable d'ignorer les datagrammes avec une adresse source de { 0, 0 } car ils peuvent être générés par des hôtes ou des routeurs mal configurés. Par conséquent, si le routeur sait comment gérer un datagramme donné avec une adresse source { 0, 0 }, le routeur DOIT l'accepter. Sinon, le routeur DOIT le rejeter.

Voir également la section [4.2.3.1] pour les utilisations non standard de { 0, 0 }.

(b) { 0, <Host-number> }

Hôte spécifié sur ce réseau. Les routeurs NE DOIVENT PAS l'envoyer, sauf qu'un routeur PEUT l'utiliser comme adresse source pendant l'initialisation, par laquelle il apprend sa propre adresse IP.

(c) { -1, -1 }

Diffusion limitée. Elle NE DOIT PAS être utilisée comme adresse source.

Un datagramme avec cette adresse de destination sera reçu par chaque hôte et routeur sur le réseau physique connecté, mais ne sera pas transféré au-delà de ce réseau.

(d) { <Network-prefix>, -1 }

Diffusion dirigée - diffusion dirigée vers le préfixe réseau spécifié. Elle NE DOIT PAS être utilisée comme adresse source. Les routeurs PEUVENT initier des paquets de diffusion dirigée réseau. Les routeurs DOIVENT recevoir des paquets de diffusion dirigée réseau; cependant, les routeurs PEUVENT avoir une option de configuration pour empêcher la réception de ces paquets. Une telle option DOIT par défaut autoriser la réception.

(e) { 127, <any> }

Adresse de bouclage d'hôte interne. Les adresses de cette forme NE DOIVENT PAS apparaître en dehors d'un hôte.

Le <Network-prefix> est attribué administrativement, de sorte que sa valeur sera unique dans le domaine de routage auquel l'appareil est connecté.

Les adresses IP ne permettent pas que les champs <Host-number> ou <Network-prefix> aient les valeurs 0 ou -1, sauf dans les cas spéciaux énumérés ci-dessus. Cela signifie que chacun de ces champs a une longueur d'au moins deux bits.

DISCUSSION (Discussion)

Les versions antérieures de ce document indiquaient également que le numéro de sous-réseau ne devait être ni 0 ni -1 et devait avoir une longueur d'au moins deux bits. Dans un monde CIDR, le numéro de sous-réseau est évidemment une extension du préfixe réseau et ne peut pas être interprété sans le reste du préfixe. Par conséquent, compte tenu du CIDR, cette restriction de numéro de sous-réseau n'a aucun sens et peut être ignorée en toute sécurité.

Pour plus de discussion sur les adresses de diffusion, voir la section [4.2.3.1].

Lorsqu'un routeur initie un datagramme, l'adresse IP source DOIT être l'une de ses propres adresses IP (mais pas une adresse de diffusion ou de multidiffusion). La seule exception est pendant l'initialisation.

Dans la plupart des cas, le traitement des datagrammes adressés à une destination de diffusion ou de multidiffusion est traité comme s'ils étaient adressés à l'une des adresses IP du routeur; c'est-à-dire:

Les routeurs DOIVENT recevoir et traiter normalement tout paquet avec une adresse de destination de diffusion.
Les routeurs DOIVENT recevoir et traiter normalement tout paquet envoyé à une adresse de destination de multidiffusion pour laquelle le routeur a demandé la réception.

Le terme specific-destination address désigne l'équivalent local de l'adresse IP d'un hôte. L'adresse de destination spécifique est définie comme l'adresse de destination dans l'en-tête IP, sauf si l'en-tête contient une adresse de diffusion ou de multidiffusion, auquel cas la destination spécifique est l'adresse IP attribuée à l'interface physique sur laquelle le datagramme est arrivé.

Les routeurs DOIVENT rejeter silencieusement tout datagramme reçu contenant une adresse IP source invalide selon les règles de cette section. Cette validation PEUT être effectuée par la couche IP ou (le cas échéant) par chaque protocole dans la couche transport. Comme pour tous les datagrammes rejetés par le routeur, le rejet de datagrammes DEVRAIT être compté.

DISCUSSION (Discussion)

Les datagrammes mal adressés peuvent être causés par des diffusions de couche liaison de datagrammes unicast ou par un autre routeur ou hôte confus ou mal configuré.

4.2.3 Specific Issues (Questions spécifiques)

4.2.3.1 IP Broadcast Addresses (Adresses de diffusion IP)

Pour des raisons historiques, il existe de nombreuses adresses IP (certaines standard et certaines non standard) utilisées pour indiquer qu'un paquet IP est une diffusion IP. Les routeurs

(1) DOIVENT traiter les paquets adressés à 255.255.255.255 ou { <Network-prefix>, -1 } comme une diffusion IP.

(2) DEVRAIENT rejeter silencieusement à la réception (c'est-à-dire ne même pas transmettre aux applications du routeur) tous les paquets adressés à 0.0.0.0 ou { <Network-prefix>, 0 }. Si ces paquets ne sont pas rejetés silencieusement, ils DOIVENT être traités comme une diffusion IP (voir section [5.3.5]). Il PEUT y avoir une option de configuration pour permettre la réception de ces paquets. Cette option DEVRAIT par défaut les rejeter.

(3) DEVRAIENT (par défaut) utiliser l'adresse de diffusion limitée (255.255.255.255) lors de l'initiation d'une diffusion IP vers un (sous-)réseau connecté (sauf lors de l'envoi d'une réponse de masque d'adresse ICMP, comme décrit dans la section [4.3.3.9]). Les routeurs DOIVENT recevoir la diffusion limitée.

(4) NE DEVRAIENT PAS initier de datagrammes adressés à 0.0.0.0 ou { <Network-prefix>, 0 }. Il PEUT y avoir une option de configuration pour permettre la génération de ces datagrammes (au lieu d'utiliser les diffusions au format 1s associées). Cette option DEVRAIT par défaut ne pas les générer.

DISCUSSION (Discussion)

Dans le deuxième point, le routeur ne peut évidemment pas reconnaître une adresse de la forme { <Network-prefix>, 0 } si le routeur n'a pas d'interface vers ce préfixe réseau. Dans ce cas, les règles du deuxième point ne s'appliquent pas car du point de vue du routeur, le paquet n'est pas un paquet de diffusion IP.

4.2.3.2 IP Multicasting (Multidiffusion IP)

Les routeurs IP DEVRAIENT satisfaire aux exigences d'hôte spécifiées dans [INTRO:2] concernant la multidiffusion IP. Les routeurs IP DEVRAIENT prendre en charge la multidiffusion IP locale sur tous les réseaux connectés. Lorsqu'un mappage de l'adresse de multidiffusion IP à l'adresse de couche liaison est spécifié (voir les diverses spécifications IP-over-xxx), il DEVRAIT utiliser ce mappage et PEUT être configuré pour utiliser la diffusion de couche liaison à la place. Sur les liaisons point à point et toutes les autres interfaces, la multidiffusion est encapsulée en diffusion de couche liaison. La prise en charge de la multidiffusion IP locale comprend l'initiation de datagrammes de multidiffusion, l'adhésion à des groupes de multidiffusion et la réception de datagrammes de multidiffusion ainsi que le départ de groupes de multidiffusion. Cela signifie la prise en charge de tout [INTERNET:4], y compris IGMP (voir section [4.4]).

DISCUSSION (Discussion)

Bien que le titre de [INTERNET:4] soit Host Extensions for IP Multicasting, il s'applique à tous les systèmes IP, y compris les hôtes et les routeurs. En particulier, comme les routeurs peuvent rejoindre des groupes de multidiffusion, il est correct qu'ils exécutent la partie hôte d'IGMP, signalant leur appartenance au groupe à tous les routeurs de multidiffusion qui peuvent être présents sur leurs réseaux connectés (qu'ils soient eux-mêmes des routeurs de multidiffusion ou non).

Certains protocoles de routeur peuvent spécifiquement nécessiter la prise en charge de la multidiffusion IP (par exemple, OSPF [ROUTE:1]) ou peuvent la recommander (par exemple, ICMP Router Discovery [INTERNET:13]).

4.2.3.3 Path MTU Discovery (Découverte de MTU de chemin)

Pour éliminer ou minimiser la fragmentation, il est souhaitable de connaître la MTU de chemin de la source à la destination. La MTU de chemin est le minimum de la MTU de chaque saut dans le chemin. [INTERNET:14] décrit une technique pour découvrir dynamiquement l'unité de transmission maximale (MTU) de tout chemin Internet. Pour les chemins qui traversent des routeurs qui ne prennent pas en charge [INTERNET:14], cette technique peut ne pas découvrir la MTU de chemin correcte, mais elle choisira toujours une MTU de chemin aussi précise que celle choisie par les anciennes techniques ou les pratiques actuelles, souvent plus précise.

Lorsqu'un routeur initie des datagrammes IP, il DEVRAIT utiliser le schéma décrit dans [INTERNET:14] pour limiter la taille du datagramme. Si la route du routeur vers la destination du datagramme est apprise d'un protocole de routage qui fournit des informations de MTU de chemin, le schéma décrit dans [INTERNET:14] est toujours utilisé, mais les informations de MTU de chemin du protocole de routage DEVRAIENT être utilisées comme estimation initiale de la MTU de chemin et comme limite supérieure pour la MTU de chemin.

4.2.3.4 Subnetting (Sous-réseautage)

Dans certains cas, il peut être souhaitable de prendre en charge les sous-réseaux d'un réseau particulier qui ne sont interconnectés que via des chemins qui ne font pas partie du réseau sous-réseauté. Cela s'appelle la prise en charge de sous-réseaux discontinus.

Les routeurs DOIVENT prendre en charge les sous-réseaux discontinus.

IMPLEMENTATION (Implémentation)

Dans les réseaux IP classiques, cela est difficile à implémenter; dans les réseaux CIDR, c'est un sous-produit naturel. Par conséquent, les routeurs NE DEVRAIENT PAS faire d'hypothèses sur l'architecture de sous-réseau, mais DEVRAIENT traiter chaque route comme un préfixe réseau générique.

DISCUSSION (Discussion)

Internet a récemment connu une croissance à un rythme étonnant. Cela a causé des tensions sérieuses sur les techniques d'adressage IP. Un facteur majeur de cette tension est les limites de classe d'adresse IP rigides. Cela rend difficile l'ajustement efficace de la taille du préfixe réseau pour leurs réseaux et l'agrégation de plusieurs préfixes réseau en une seule annonce de routage. En éliminant les limites de classe strictes des adresses IP et en traitant chaque route comme un préfixe réseau générique, ces tensions peuvent être considérablement réduites.

La technique qui fait actuellement cela est le routage inter-domaine sans classe (CIDR) [INTERNET:15].

Pour des raisons similaires, le bloc d'adresses associé à un préfixe réseau donné peut être subdivisé en sous-blocs de tailles différentes, de sorte que les préfixes réseau associés aux sous-blocs auront des longueurs différentes. Par exemple, dans un bloc où le préfixe réseau a une longueur de 8 bits, un sous-bloc pourrait avoir un préfixe réseau de 16 bits, un autre pourrait avoir un préfixe réseau de 18 bits et un troisième un préfixe réseau de 14 bits.

Les routeurs DOIVENT prendre en charge les préfixes réseau de longueur variable dans leur configuration d'interface et leur base de données de routage.

4.3 Internet Control Message Protocol - ICMP (Protocole de message de contrôle Internet)

4.3.1 Introduction (Introduction)

ICMP est un protocole auxiliaire qui fournit des fonctions de routage, de diagnostic et d'erreur pour IP. Il est décrit dans [INTERNET:8]. Les routeurs DOIVENT prendre en charge ICMP.

Les messages ICMP entrent dans deux catégories, qui seront discutées dans les sections suivantes:

Messages d'erreur ICMP:

Destination Unreachable (Destination inaccessible) Section 4.3.3.1
Redirect (Redirection) Section 4.3.3.2
Source Quench (Limitation de source) Section 4.3.3.3
Time Exceeded (Temps dépassé) Section 4.3.3.4
Parameter Problem (Problème de paramètre) Section 4.3.3.5

Messages de requête ICMP:

Echo (Écho) Section 4.3.3.6
Information (Information) Section 4.3.3.7
Timestamp (Horodatage) Section 4.3.3.8
Address Mask (Masque d'adresse) Section 4.3.3.9
Router Discovery (Découverte de routeur) Section 4.3.3.10

Les exigences générales ICMP et les discussions se trouvent dans la section suivante.

4.3.2 General Issues (Questions générales)

4.3.2.1 Unknown Message Types (Types de messages inconnus)

Si un message ICMP de type inconnu est reçu, il DOIT être transmis à l'interface utilisateur ICMP (si le routeur en a une) ou rejeté silencieusement (si le routeur n'en a pas).

4.3.2.2 ICMP Message TTL (TTL de message ICMP)

Lors de l'initiation d'un message ICMP, le routeur DOIT initialiser le TTL. Le TTL d'une réponse ICMP NE DOIT PAS être tiré du paquet qui a déclenché la réponse.

4.3.2.3 Original Message Header (En-tête de message original)

Historiquement, chaque message d'erreur ICMP contient l'en-tête Internet et au moins les 8 premiers mots de données du datagramme qui a déclenché l'erreur. En raison de l'utilisation du tunneling IP-in-IP et d'autres techniques, cela n'est plus suffisant. Par conséquent, les datagrammes ICMP DEVRAIENT contenir autant du datagramme original que possible sans que le datagramme ICMP ne dépasse 576 octets de longueur. L'en-tête IP retourné (et les données utilisateur) DOIT être identique à celui reçu, sauf que le routeur n'a pas besoin d'annuler les modifications apportées à l'en-tête IP qui sont normalement effectuées lors du transfert avant la détection de l'erreur (par exemple, décrémenter le TTL ou mettre à jour les options). Notez que les exigences de la section [4.3.3.5] remplacent cette exigence dans certains cas (c'est-à-dire pour les messages Parameter Problem, si le problème se trouve dans un champ modifié, le routeur doit annuler la modification). Voir section [4.3.3.5]).

4.3.2.4 ICMP Message Source Address (Adresse source de message ICMP)

Sauf indication contraire dans ce document, l'adresse IP source dans un message ICMP initié par le routeur DOIT être l'une des adresses IP associées à l'interface physique transmettant le message ICMP. Si l'interface n'a pas d'adresse IP qui lui est associée, le router-id du routeur est utilisé à la place (voir section [5.2.5]).

4.3.2.5 TOS and Precedence (TOS et priorité)

Les messages d'erreur ICMP DEVRAIENT définir leurs bits TOS à la même valeur que les bits TOS dans le paquet qui a provoqué l'envoi du message d'erreur ICMP, sauf si les définir à cette valeur entraînerait le rejet immédiat du message d'erreur ICMP car il ne pourrait pas être routé vers sa destination. Sinon, les messages d'erreur ICMP DOIVENT être envoyés avec un TOS normal (c'est-à-dire zéro). Les messages de réponse ICMP DEVRAIENT définir leurs bits TOS à la même valeur que les bits TOS dans la requête ICMP qui a provoqué la réponse.

Les messages d'erreur ICMP Source Quench (s'ils sont envoyés) DOIVENT définir leur champ IP Precedence à la même valeur que le champ IP Precedence dans le paquet qui a provoqué l'envoi du message ICMP Source Quench. Tous les autres messages d'erreur ICMP (Destination Unreachable, Redirect, Time Exceeded et Parameter Problem) DEVRAIENT définir leur valeur de priorité à 6 (INTERNETWORK CONTROL) ou 7 (NETWORK CONTROL). La valeur IP Precedence de ces messages d'erreur PEUT être configurable.

Les messages de réponse ICMP DOIVENT définir leur champ IP Precedence à la même valeur que le champ IP Precedence dans la requête ICMP qui a provoqué la réponse.

4.3.2.6 Source Route (Route source)

Si le paquet qui a provoqué l'envoi d'un message d'erreur ICMP contient une option de route source, le message d'erreur ICMP DEVRAIT également contenir une option de route source du même type (strict ou loose), créée en inversant la partie enregistrée de la route avant le pointeur dans l'option de route source du paquet original, sauf si le message d'erreur ICMP est un message ICMP Parameter Problem se plaignant de l'option de route source dans le paquet original, ou sauf si le routeur connaît une politique qui empêcherait la livraison du message d'erreur ICMP.

DISCUSSION (Discussion)

Dans les environnements qui utilisent l'option de sécurité du département de la Défense des États-Unis (définie dans [INTERNET:5]), les messages ICMP peuvent avoir besoin d'inclure une option de sécurité. Des détails sur ce sujet devraient être disponibles auprès de la Defense Communications Agency.

4.3.2.7 When Not to Send ICMP Errors (Quand ne pas envoyer d'erreurs ICMP)

Les messages d'erreur ICMP NE DOIVENT PAS être envoyés à la suite de la réception de:

un message d'erreur ICMP, ou
un paquet qui n'a pas réussi les tests de validation d'en-tête IP décrits dans la section [5.2.2] (sauf si cette section autorise spécifiquement l'envoi d'un message d'erreur ICMP), ou
un paquet adressé à une adresse de diffusion IP ou de multidiffusion IP, ou
un paquet envoyé en diffusion ou multidiffusion de couche liaison, ou
un paquet dont l'adresse source a un préfixe réseau de zéro ou est une adresse source invalide (comme défini dans la section [5.3.7]), ou
tout fragment d'un datagramme autre que le premier fragment (c'est-à-dire un paquet avec un décalage de fragment non nul dans l'en-tête IP).

De plus, les messages d'erreur ICMP NE DOIVENT PAS être envoyés dans tous les cas où ce mémo indique qu'un paquet doit être rejeté silencieusement.

Remarque: Ces limitations ont la priorité sur toute exigence d'envoi de messages d'erreur ICMP ailleurs dans ce document.

DISCUSSION (Discussion)

Ces règles visent à empêcher les tempêtes de diffusion qui se produisent parce que les routeurs ou les hôtes répondent aux paquets de diffusion par des messages d'erreur ICMP. Par exemple, un paquet UDP de diffusion vers un port inexistant pourrait déclencher un déluge de datagrammes ICMP Destination Unreachable de tous les appareils qui n'ont pas ce port de destination. Sur un grand Ethernet, les collisions résultantes pourraient rendre le réseau inutilisable pendant une seconde ou plus.

Chaque datagramme diffusé sur un réseau connecté devrait avoir une adresse de diffusion IP valide comme destination IP (voir section [5.3.4] et [INTRO:2]). Cependant, certains appareils violent cette règle. Par conséquent, pour détecter de manière fiable les paquets de diffusion, le routeur doit vérifier les diffusions de couche liaison ainsi que les adresses de couche IP.

IMPLEMENTATION+ (Implémentation)

Cela nécessite que la couche liaison notifie la couche IP lorsqu'un paquet de diffusion de couche liaison est reçu; voir section [3.1].

4.3.2.8 Rate Limiting (Limitation de débit)

Les routeurs qui envoient des messages ICMP Source Quench DOIVENT être capables de limiter le taux de génération de messages. Les routeurs DEVRAIENT également être capables de limiter le taux auquel ils envoient d'autres types de messages d'erreur ICMP (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem). Les paramètres de limitation de débit DEVRAIENT être configurables dans la configuration du routeur. La manière dont la limitation est appliquée (par exemple, par routeur ou par interface) est laissée à la discrétion de l'implémenteur.

DISCUSSION (Discussion)

Deux problèmes liés à l'envoi de messages d'erreur ICMP par les routeurs sont: (1) la consommation de bande passante sur le chemin inverse, et (2) l'utilisation des ressources du routeur (par exemple, mémoire, temps CPU)

Pour aider à résoudre ces problèmes, les routeurs peuvent limiter la fréquence à laquelle ils génèrent des messages d'erreur ICMP. Pour des raisons similaires, les routeurs peuvent limiter la fréquence à laquelle certains autres types de messages sont générés (par exemple, les réponses ICMP Echo).

IMPLEMENTATION (Implémentation)

Divers mécanismes ont été utilisés ou proposés pour limiter le taux d'envoi de messages ICMP:

(1) Basé sur le comptage - par exemple, envoyer un message d'erreur ICMP pour chaque N-ième paquet rejeté ou pour chaque hôte source donné. Ce mécanisme peut convenir pour ICMP Source Quench (s'il est utilisé), mais peut ne pas convenir pour d'autres types de messages ICMP.

(2) Basé sur une minuterie - par exemple, envoyer au plus un message d'erreur ICMP à un hôte source donné ou au total tous les T millisecondes.

(3) Basé sur la bande passante - par exemple, limiter le taux d'envoi de messages ICMP via une interface particulière à une certaine fraction de la bande passante du réseau connecté.

4.3.3 Specific Issues (Questions spécifiques)

4.3.3.1 Destination Unreachable (Destination inaccessible)

Si un routeur ne peut pas transférer un paquet car il n'a aucune route vers la destination dans le paquet (y compris aucune route par défaut), le routeur DOIT générer un message ICMP Destination Unreachable, Code 0 (Network Unreachable). Si le routeur a effectivement une route vers le réseau de destination spécifié dans le paquet, mais la route que le routeur a spécifie un TOS qui n'est ni le TOS par défaut (0000) ni le TOS du paquet que le routeur essaie de router, le routeur DOIT générer un message ICMP Destination Unreachable, Code 11 (Network Unreachable for TOS).

Si un paquet doit être transféré vers un hôte directement connecté à un réseau directement connecté au routeur (c'est-à-dire que le routeur est le dernier routeur de saut) et que le routeur a déterminé qu'il n'y a pas de chemin vers l'hôte de destination, le routeur DOIT générer un message ICMP Destination Unreachable, Code 1 (Host Unreachable). Si un paquet doit être transféré vers un hôte directement connecté à un réseau directement connecté au routeur et que le routeur ne peut pas transférer le paquet car aucune route vers la destination n'a un TOS égal au TOS demandé dans le paquet ou au TOS par défaut (0000), le routeur DOIT générer un message ICMP Destination Unreachable, Code 12 (Host Unreachable for TOS).

DISCUSSION (Discussion)

L'intention est que le routeur génère un "générique" Host/Network Unreachable si le routeur n'a absolument aucun chemin vers la destination (y compris une route par défaut). Si le routeur a un ou plusieurs chemins vers la destination, mais qu'aucun de ces chemins n'a un TOS acceptable, le routeur génère des messages "for TOS unreachable".

4.3.3.2 Redirect (Redirection)

Les messages ICMP Redirect sont générés pour informer les hôtes locaux qu'ils devraient utiliser un routeur de prochain saut différent pour un certain trafic.

Contrairement à [INTRO:2], un routeur PEUT ignorer les redirections ICMP lors de la sélection d'un chemin pour les paquets initiés par le routeur si le routeur exécute un protocole de routage ou si le transfert est activé sur le routeur et sur l'interface envoyant le paquet.

4.3.3.3 Source Quench (Limitation de source)

Les routeurs NE DEVRAIENT PAS initier de messages ICMP Source Quench. Comme spécifié dans la section [4.3.2], les routeurs qui initient des messages Source Quench DOIVENT être capables de limiter leur taux de génération.

DISCUSSION (Discussion)

La recherche semble indiquer que Source Quench consomme de la bande passante réseau mais est un remède inefficace (et injuste) contre la congestion. Voir par exemple [INTERNET:9] et [INTERNET:10]. La section [5.3.6] discute de la réflexion actuelle sur la façon dont les routeurs devraient gérer la surcharge et la congestion du réseau.

Les routeurs PEUVENT ignorer tous les messages ICMP Source Quench qu'ils reçoivent.

DISCUSSION (Discussion)

Les routeurs eux-mêmes peuvent recevoir Source Quench en raison de l'initiation de paquets envoyés à un autre routeur ou hôte. De tels datagrammes peuvent être par exemple des mises à jour EGP vers un autre routeur ou un flux telnet vers un hôte. Un mécanisme a été proposé ([INTERNET:11], [INTERNET:12]) pour que la couche IP réponde directement à Source Quench en contrôlant le taux d'envoi de paquets, mais cette proposition est actuellement expérimentale et n'est actuellement pas recommandée.

4.3.3.4 Time Exceeded (Temps dépassé)

Lorsqu'un routeur transfère un paquet et que le champ TTL du paquet est décrémenté à zéro, les exigences de la section [5.2.3.8] s'appliquent.

Lorsqu'un routeur réassemble un paquet adressé au routeur, il agit comme un hôte Internet. Par conséquent, les exigences de réassemblage de [INTRO:2] s'appliquent.

Lorsqu'un routeur reçoit (c'est-à-dire adressé au routeur) un message Time Exceeded, il DOIT se conformer à [INTRO:2].

4.3.3.5 Parameter Problem (Problème de paramètre)

Pour toute erreur non spécifiquement couverte par d'autres messages ICMP, le routeur DOIT générer un message Parameter Problem. Le champ d'en-tête IP ou l'option IP qui contient l'octet indiqué par le champ de pointeur DOIT rester inchangé dans l'en-tête IP retourné dans ce message ICMP. La section [4.3.2] définit des exceptions à cette exigence.

Une nouvelle variante du message Parameter Problem est définie dans [INTRO:2]:

Code 1 = Option requise manquante.

DISCUSSION (Discussion)

Cette variante est actuellement utilisée dans la communauté militaire pour une option de sécurité manquante.

4.3.3.6 Echo Request/Reply (Requête/Réponse d'écho)

Les routeurs DOIVENT implémenter la fonction de serveur ICMP Echo, qui reçoit les requêtes Echo envoyées au routeur et envoie les réponses Echo correspondantes. Les routeurs DOIVENT être prêts à recevoir, réassembler et répondre aux datagrammes de requête ICMP Echo d'au moins la taille de 576 et le maximum des MTU de tous les réseaux connectés.

La fonction de serveur Echo PEUT choisir de ne pas répondre aux requêtes d'écho ICMP adressées à une adresse de diffusion IP ou de multidiffusion IP.

Les routeurs DEVRAIENT avoir une option de configuration qui, si elle est activée, amène le routeur à ignorer silencieusement toutes les requêtes d'écho ICMP; si elle est fournie, cette option DOIT par défaut autoriser les réponses.

DISCUSSION (Discussion)

La règle neutre sur la réponse aux requêtes Echo de diffusion et de multidiffusion provient de la section "Echo Request/Reply" de [INTRO:2].

Comme décrit dans la section [10.3.3], les routeurs DOIVENT également implémenter une interface de couche utilisateur/application pour envoyer des requêtes Echo et recevoir des réponses Echo à des fins de diagnostic. Tous les messages ICMP Echo Reply DOIVENT être transmis à cette interface.

L'adresse IP source dans une réponse ICMP Echo DOIT être la même que l'adresse de destination spécifique du message de requête ICMP Echo correspondant.

Les données reçues dans une requête ICMP Echo DOIVENT être entièrement contenues dans la réponse Echo générée.

Si une option Record Route et/ou Timestamp est reçue dans une requête ICMP Echo, cette option (ces options) DEVRAIT être mise à jour pour inclure le routeur actuel et incluse dans l'en-tête IP du message Echo Reply, non tronquée. Par conséquent, la route enregistrée sera utilisée pour l'ensemble de l'aller-retour.

Si une option Source Route est reçue dans une requête ICMP Echo, la route de retour DOIT être inversée et utilisée comme option Source Route du message Echo Reply, sauf si le routeur connaît une politique qui empêcherait la livraison du message.

4.3.3.7 Information Request/Reply (Requête/Réponse d'information)

Les routeurs NE DEVRAIENT PAS initier ou répondre à ces messages.

DISCUSSION (Discussion)

Les paires Information Request/Reply étaient destinées à prendre en charge les systèmes d'auto-configuration (comme les stations de travail sans disque) pour leur permettre de découvrir leur préfixe réseau IP lors du démarrage. Cependant, ces messages sont maintenant obsolètes. Les protocoles RARP et BOOTP fournissent de meilleurs mécanismes pour que les hôtes découvrent leur propre adresse IP.

4.3.3.8 Timestamp and Timestamp Reply (Horodatage et réponse d'horodatage)

Les routeurs PEUVENT implémenter Timestamp et Timestamp Reply. S'ils sont implémentés, alors:

La fonction de serveur ICMP Timestamp DOIT retourner une réponse Timestamp pour chaque message Timestamp reçu. Elle DEVRAIT être conçue pour que la variance du délai soit minimisée.
Les messages de requête ICMP Timestamp adressés à une adresse de diffusion IP ou de multidiffusion IP PEUVENT être rejetés silencieusement.
L'adresse IP source dans une réponse ICMP Timestamp DOIT être la même que l'adresse de destination spécifique du message de requête Timestamp correspondant.
Si une option Source Route est reçue dans une requête ICMP Timestamp, la route de retour DOIT être inversée et utilisée comme option Source Route du message Timestamp Reply, sauf si le routeur connaît une politique qui empêcherait la livraison du message.
Si une option Record Route et/ou Timestamp est reçue dans une requête Timestamp, cette (ces) option(s) DEVRAIT être mise à jour pour inclure le routeur actuel et incluse dans l'en-tête IP du message Timestamp Reply.
Si le routeur fournit une interface de couche application pour envoyer des messages de requête Timestamp, les messages de réponse Timestamp entrants DOIVENT être transmis vers le haut à l'interface utilisateur ICMP.

La forme préférée (valeur standard) des valeurs d'horodatage est les millisecondes depuis minuit, temps universel. Cependant, il peut être difficile de fournir cette valeur avec une résolution en millisecondes. Par exemple, de nombreux systèmes utilisent une horloge qui ne se met à jour qu'à la fréquence de ligne, 50 ou 60 fois par seconde. Par conséquent, la valeur standard permet une certaine marge de manœuvre:

(a) La valeur standard DOIT être mise à jour au moins 16 fois par seconde (c'est-à-dire que les six bits de poids faible de la valeur peuvent être non définis au maximum).

(b) La précision de la valeur standard DOIT s'approcher de la précision de l'horloge CPU définie par l'opérateur, c'est-à-dire correcte à quelques minutes près.

IMPLEMENTATION (Implémentation)

Pour satisfaire la deuxième condition, un routeur peut avoir besoin d'interroger un serveur de temps lors du démarrage ou du redémarrage du routeur. L'utilisation du protocole UDP Time Server est recommandée à cette fin. Les implémentations plus avancées utiliseront le protocole Network Time Protocol (NTP) pour obtenir une synchronisation d'horloge proche de la milliseconde; cependant, cela n'est pas requis.

4.3.3.9 Address Mask Request/Reply (Requête/Réponse de masque d'adresse)

Les routeurs DOIVENT implémenter la prise en charge de la réception de messages de requête ICMP Address Mask et de la réponse avec des messages de réponse ICMP Address Mask. Ces messages sont définis dans [INTERNET:2].

Les routeurs DEVRAIENT avoir une option de configuration pour chaque interface logique spécifiant si le routeur est autorisé à répondre aux requêtes Address Mask pour cette interface; cette option DOIT par défaut autoriser les réponses. Les routeurs NE DOIVENT PAS répondre aux requêtes Address Mask avant que le routeur ne connaisse le masque d'adresse correct.

Les routeurs NE DOIVENT PAS répondre aux requêtes Address Mask dont l'adresse source est 0.0.0.0 et qui arrivent sur une interface physique associée à plusieurs interfaces logiques dont les masques d'adresse ne sont pas tous identiques.

Les routeurs DEVRAIENT vérifier toutes les réponses ICMP Address Mask reçues pour déterminer si les informations qu'elles contiennent correspondent à la connaissance du routeur du masque d'adresse. Si une réponse ICMP Address Mask semble être erronée, le routeur DEVRAIT enregistrer le masque d'adresse et l'adresse IP de l'expéditeur. Les routeurs NE DOIVENT PAS utiliser le contenu d'une réponse ICMP Address Mask pour déterminer le masque d'adresse correct.

Parce que les hôtes peuvent ne pas être en mesure de connaître le masque d'adresse si le routeur est en panne au démarrage de l'hôte, le routeur PEUT envoyer des réponses ICMP Address Mask non sollicitées sur chacune de ses interfaces logiques après avoir configuré son propre masque d'adresse. Cependant, cette fonctionnalité peut être dangereuse dans les environnements qui utilisent des masques d'adresse de longueur variable. Par conséquent, les réponses Address Mask non sollicitées NE DOIVENT PAS être diffusées sur l'une des interfaces logiques suivantes:

qui n'est pas configurée pour envoyer des réponses Address Mask non sollicitées. Chaque interface logique DOIT avoir un paramètre de configuration contrôlant cela, et ce paramètre DOIT par défaut ne pas envoyer de réponses Address Mask non sollicitées.
qui partage un préfixe réseau contenant (mais non identique) et une interface physique.

La forme { <Network-prefix>, -1 } de l'adresse de diffusion IP DOIT être utilisée pour diffuser les réponses Address Mask.

DISCUSSION (Discussion)

La capacité pour les routeurs de désactiver l'envoi de réponses Address Mask est requise dans un petit nombre de sites qui mentent délibérément à leurs hôtes sur le masque d'adresse. On s'attend à ce que ce besoin disparaisse à mesure que de plus en plus d'hôtes se conforment à la norme des exigences d'hôte.

La raison du deuxième point ci-dessus et l'exigence concernant l'adresse de diffusion IP à utiliser est de prévenir les problèmes lorsque plusieurs préfixes réseau IP sont utilisés sur le même réseau physique.

4.3.3.10 Router Advertisement and Solicitations (Annonces et sollicitations de routeur)

Les routeurs IP DOIVENT prendre en charge la partie routeur du protocole de découverte de routeur ICMP [INTERNET:13] sur tous les réseaux connectés sur lesquels le routeur prend en charge l'adressage de multidiffusion IP ou de diffusion IP. L'implémentation DOIT inclure toutes les variables de configuration spécifiées pour le routeur, avec les valeurs par défaut spécifiées.

DISCUSSION (Discussion)

Les routeurs n'ont pas besoin d'implémenter la partie hôte du protocole de découverte de routeur ICMP, mais peuvent la trouver utile pour le fonctionnement lorsque le transfert IP est désactivé (c'est-à-dire lorsqu'ils fonctionnent comme hôte).

DISCUSSION (Discussion)

Nous notons qu'il est courant que les hôtes utilisent RIP Version 1 comme protocole de découverte de routeur. Ces hôtes écoutent le trafic RIP et utilisent les informations extraites de ce trafic pour découvrir les routeurs et décider quel routeur utiliser comme routeur de premier saut pour une destination donnée. Bien que ce comportement soit découragé, il reste courant et les implémenteurs devraient en être conscients.

4.4 Internet Group Management Protocol - IGMP (Protocole de gestion de groupe Internet)

IGMP [INTERNET:4] est un protocole utilisé entre les hôtes et les routeurs de multidiffusion sur un seul réseau physique pour établir l'appartenance des hôtes à des groupes de multidiffusion particuliers. Les routeurs de multidiffusion utilisent ces informations en combinaison avec un protocole de routage de multidiffusion pour prendre en charge le transfert de multidiffusion IP à travers Internet.

Les routeurs DEVRAIENT implémenter la partie hôte d'IGMP.