Aller au contenu principal

RFC 1812 - Requirements for IP Version 4 Routers

Statut de ce Mémo

Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet et demande des discussions et des suggestions d'amélioration. Veuillez consulter l'édition actuelle des « Internet Official Protocol Standards » (STD 1) pour connaître l'état de normalisation de ce protocole. La distribution de ce mémo n'est pas limitée.

Préface​

Ce document est une mise à jour du RFC 1716 (document historique sur les exigences des routeurs). Ce RFC conserve les travaux importants du groupe de travail, mais l'IESG a estimé qu'il ne décrivait pas suffisamment les technologies actuelles pour être considéré comme une norme actuelle.

L'éditeur actuel a été chargé de mettre à jour ce document afin qu'il puisse être utilisé comme spécification d'approvisionnement et guide pour les implémenteurs. Dans ce processus, il s'est entièrement appuyé sur les travaux de ses prédécesseurs et s'est largement inspiré des textes fournis par des contributeurs experts. Tout le mérite leur revient ; les erreurs lui incombent.

Le contenu et la forme de ce document doivent beaucoup au président du groupe de travail, ainsi qu'à Philip Almquist, éditeur et auteur original du document. Ils doivent également beaucoup à Frank Kastenholz, éditeur précédent. Sans leurs efforts, ce document n'aurait pas existé.

Table des matières​

1. Introduction​

Ce mémo remplace le RFC 1716 « Requirements for Internet Gateways » ([INTRO:1]).

Ce mémo définit et discute les exigences applicables aux dispositifs qui assurent les fonctions de transfert au niveau de la couche réseau de la famille de protocoles Internet. La communauté Internet désigne généralement ces dispositifs par le terme routeurs IP (IP routers) ou simplement routeurs (routers). La communauté OSI les appelle systèmes intermédiaires (intermediate systems). De nombreux anciens documents Internet les appelaient passerelles (gateways), terme qui est aujourd'hui peu utilisé afin d'éviter toute confusion avec les passerelles applicatives (application gateways).

La différence entre un routeur IP et d'autres types de dispositifs de commutation de paquets réside dans le fait que le routeur examine l'en-tête du protocole IP lors du processus de commutation. Il supprime généralement l'en-tête de couche liaison utilisé lors de la réception du message, modifie l'en-tête IP et remplace l'en-tête de couche liaison pour la retransmission.

Les auteurs et lecteurs de ce mémo doivent reconnaître que de nombreux routeurs prennent en charge plusieurs protocoles. À l'avenir, des portions de plus en plus importantes d'Internet nécessiteront la prise en charge de familles de protocoles multiples. Cependant, ce mémo ne cherche pas à définir les exigences Internet pour des familles de protocoles autres que TCP/IP.

Ce document énumère les protocoles standard que les routeurs connectés à Internet DOIVENT utiliser, et incorpore par référence les RFC et autres documents décrivant les spécifications actuelles de ces protocoles. Il corrige les erreurs dans les documents référencés et ajoute des discussions et des conseils supplémentaires pour les implémenteurs.

Pour chaque protocole, ce mémo contient également un ensemble explicite d'exigences, de recommandations et d'options. Le lecteur doit comprendre que la liste des exigences de ce mémo est elle-même incomplète. L'ensemble complet des exigences pour un routeur Internet est principalement défini dans les documents de spécification des protocoles standard, combinés aux modifications, révisions et compléments contenus dans ce mémo.

Ce mémo doit être lu conjointement avec les RFC sur les exigences pour les hôtes Internet ([INTRO:2] et [INTRO:3]). Les hôtes et les routeurs Internet doivent tous deux être capables d'initier des datagrammes IP et de recevoir des datagrammes IP qui leur sont destinés. La principale différence entre un hôte Internet et un routeur est que le routeur implémente un algorithme de transfert, alors que l'hôte Internet n'a pas besoin de cette fonctionnalité. Un hôte Internet fonctionnant comme routeur DOIT se conformer aux exigences contenues dans ce mémo.

L'objectif d'interopérabilité des systèmes ouverts exige que les routeurs fonctionnent correctement en tant qu'hôtes Internet lorsque cela est nécessaire. Pour atteindre cet objectif, ce mémo fournit des orientations pour de telles situations. Par souci de simplification et de facilité de mise à jour, ce mémo évite de dupliquer les discussions sur les exigences des hôtes présentes dans [INTRO:2] et [INTRO:3], et incorpore par référence les exigences pertinentes de ces documents. Dans certains cas, ce document remplace les exigences énoncées dans [INTRO:2] et [INTRO:3].

Une implémentation sincère générée après une lecture attentive des RFC ne devrait différer des exigences de ce mémo que sur des points mineurs. La production d'une telle implémentation nécessite généralement une certaine interaction avec la communauté technique Internet et le respect de bonnes pratiques d'ingénierie logicielle de communication. Dans de nombreux cas, les exigences de ce document sont en quelque sorte redondantes car elles sont déjà énoncées explicitement ou implicitement dans les documents de protocoles standard. Elles ont été incluses parce que certaines implémentations passées ont fait de mauvais choix, entraînant des problèmes d'interopérabilité, de performance et/ou de robustesse.

Ce mémo contient des discussions et des explications sur de nombreuses exigences et recommandations. Une simple liste d'exigences est dangereuse car :

  • Certaines fonctionnalités obligatoires sont plus importantes que d'autres, et certaines sont optionnelles.

  • Certaines fonctionnalités sont importantes pour des applications particulières des routeurs, mais sans rapport avec d'autres applications.

  • Certains produits de fournisseurs conçus pour des environnements restreints peuvent avoir des raisons légitimes d'utiliser des spécifications différentes.

Cependant, pour atteindre l'objectif global d'interopérabilité arbitraire des routeurs dans la diversité et la complexité d'Internet, il est nécessaire de se conformer aux spécifications de ce mémo. Bien que la plupart des implémentations actuelles ne satisfassent pas à ces exigences sur divers aspects (certains mineurs, d'autres majeurs), cette spécification est l'idéal vers lequel nous devons tendre.

Ces exigences sont basées sur le niveau actuel de l'architecture Internet. Ce mémo sera mis à jour si nécessaire pour inclure des informations supplémentaires ou fournir des clarifications supplémentaires dans les domaines où les spécifications sont encore en évolution.

1.1 Reading this Document​

1.1.1 Organisation​

Ce mémo imite l'organisation hiérarchique utilisée dans [INTRO:2] et [INTRO:3]. Ainsi, le chapitre 2 décrit les couches de l'architecture Internet. Le chapitre 3 couvre la couche liaison. Les chapitres 4 et 5 se concentrent sur les protocoles de la couche réseau et les algorithmes de transfert. Le chapitre 6 couvre la couche transport. Les protocoles de couche supérieure sont répartis dans les chapitres 7, 8 et 9. Le chapitre 7 décrit les protocoles utilisés par les routeurs pour échanger des informations de routage entre eux. Le chapitre 8 traite de la gestion de réseau. Le chapitre 9 traite d'autres protocoles de couche supérieure. Le dernier chapitre couvre les fonctions d'exploitation et de maintenance. Cette organisation a été choisie pour sa simplicité, sa clarté et sa cohérence avec les RFC sur les exigences des hôtes. Les annexes de ce mémo contiennent des références, un glossaire et quelques spéculations sur les orientations futures des normes pour les routeurs.

Lors de la description des exigences, on suppose que les implémentations reflètent fidèlement la hiérarchie des protocoles. Cependant, une hiérarchisation stricte est un modèle imparfait tant pour la famille de protocoles que pour les méthodes d'implémentation recommandées. Les protocoles de différentes couches interagissent de manière complexe et parfois subtile, et certaines fonctionnalités impliquent souvent plusieurs couches. Il existe de nombreux choix de conception dans les implémentations, dont beaucoup impliquent de rompre de manière créative avec une hiérarchisation stricte. Il est fortement recommandé à chaque implémenteur de lire [INTRO:4] et [INTRO:5].

Chaque section principale de ce mémo est organisée en sous-sections suivantes :

(1) Introduction

(2) Revue du protocole (Protocol Walk-Through) — examine le document de spécification du protocole section par section, corrige les erreurs, énonce les exigences qui pourraient être ambiguës ou peu claires, et fournit des clarifications ou des explications supplémentaires.

(3) Questions spécifiques (Specific Issues) — discute des questions de conception et d'implémentation du protocole non couvertes dans la revue.

Sous de nombreux sujets individuels de ce mémo, il existe des éléments entre crochets étiquetés DISCUSSION ou IMPLEMENTATION. Ces éléments visent à fournir une justification, une clarification ou une explication du texte d'exigences précédent. Les éléments d'implémentation contiennent des approches suggérées que les implémenteurs pourraient souhaiter envisager. Les sections DISCUSSION et IMPLEMENTATION ne font pas partie de la norme.

1.1.2 Exigences​

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

  • DOIT (MUST) Ce mot signifie que l'élément est une exigence absolue de la spécification. Toute violation d'une telle exigence constitue une erreur fondamentale. Aucune circonstance ne peut la justifier.

  • DOIT IMPLÉMENTER (MUST IMPLEMENT) Cette expression signifie que cette spécification exige l'implémentation de l'élément, mais n'exige pas qu'il soit activé par défaut.

  • NE DOIT PAS (MUST NOT) Cette expression signifie que l'élément est une interdiction absolue de la spécification.

  • DEVRAIT (SHOULD) Ce mot signifie qu'il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être pleinement comprises et soigneusement pesées avant de choisir une autre voie.

  • DEVRAIT IMPLÉMENTER (SHOULD IMPLEMENT) La signification de cette expression est similaire à DEVRAIT, mais est utilisée lorsqu'il est recommandé de fournir une fonctionnalité particulière sans nécessairement l'activer par défaut.

  • NE DEVRAIT PAS (SHOULD NOT) Cette expression signifie qu'il peut exister des raisons valables et utiles dans des circonstances particulières d'accepter le comportement décrit. Néanmoins, toutes les implications doivent être pleinement comprises et soigneusement pesées avant d'implémenter un comportement portant ce label.

  • PEUT (MAY) Ce mot signifie que l'élément est véritablement optionnel. Un fournisseur peut choisir d'inclure l'élément parce qu'un marché particulier l'exige ou parce qu'il améliore le produit. Un autre fournisseur peut omettre le même élément.

1.1.3 Conformité​

Certaines exigences s'appliquent à tous les routeurs. D'autres ne s'appliquent qu'aux routeurs qui implémentent certaines fonctionnalités ou protocoles. Dans les paragraphes suivants, « pertinent » désigne l'union de l'ensemble des exigences applicables à tous les routeurs et de l'ensemble des exigences applicables à un routeur particulier en raison des fonctionnalités et protocoles qu'il implémente.

Notez que toutes les exigences pertinentes ne sont pas directement énoncées dans ce mémo. Diverses sections de ce mémo incorporent par référence des sections des spécifications des exigences des hôtes [INTRO:2] et [INTRO:3]. Pour déterminer la conformité à ce mémo, il importe peu qu'une exigence pertinente soit directement énoncée dans ce mémo ou incorporée uniquement par référence à l'un de ces documents.

Une implémentation est dite conditionnellement conforme (conditionally compliant) si elle satisfait à toutes les exigences DOIT, DOIT IMPLÉMENTER et NE DOIT PAS pertinentes. Une implémentation est dite inconditionnellement conforme (unconditionally compliant) si elle est conditionnellement conforme et satisfait en outre à toutes les exigences DEVRAIT, DEVRAIT IMPLÉMENTER et NE DEVRAIT PAS pertinentes. Une implémentation qui n'est pas conditionnellement conforme (c'est-à-dire qui ne satisfait pas à une ou plusieurs exigences DOIT, DOIT IMPLÉMENTER ou NE DOIT PAS pertinentes) est non conforme.

Cette spécification indique parfois qu'une implémentation DEVRAIT implémenter une variable de gestion et DEVRAIT avoir une valeur par défaut particulière. Une implémentation inconditionnellement conforme implémente le comportement par défaut et, s'il existe d'autres comportements implémentés, la variable correspondante. Une implémentation conditionnellement conforme documente clairement quelle est la valeur par défaut de la variable, ou ce qui peut être interprété si la variable n'est pas implémentée. Une implémentation qui n'implémente pas la variable et choisit un comportement différent est non conforme.

Pour les exigences DEVRAIT et NE DEVRAIT PAS, un routeur PEUT fournir une option de configuration qui lui fait adopter un comportement différent de celui prescrit par l'exigence. Si l'option a un paramètre par défaut qui fait fonctionner le routeur de la manière requise, la présence d'une telle option de configuration n'invalide pas la déclaration de conformité inconditionnelle du routeur.

De même, sauf interdiction explicite dans ce mémo, un routeur PEUT fournir des options qui lui font violer les exigences DOIT ou NE DOIT PAS. Un routeur fournissant de telles options est (pleinement ou conditionnellement) conforme uniquement si chaque option de ce type a un paramètre par défaut qui fait fonctionner le routeur conformément aux exigences de ce mémo. Les auteurs de ce mémo reconnaissent les réalités du marché, mais recommandent vivement de ne pas fournir de telles options. Les exigences marquées DOIT ou NE DOIT PAS le sont parce que les experts du domaine les considèrent comme particulièrement importantes pour l'interopérabilité ou le bon fonctionnement sur Internet. Les fournisseurs doivent soigneusement peser les coûts de support client liés à la fourniture d'options violant ces règles.

Bien sûr, ce mémo n'est pas une spécification complète d'un routeur IP — il se rapproche davantage de ce que la communauté OSI appelle un profil (profile). Par exemple, ce mémo exige l'implémentation de nombreux protocoles. La plupart des spécifications de ces protocoles ne sont pas répétées dans ce mémo, mais les implémenteurs doivent implémenter les protocoles conformément à ces spécifications.

1.2 Relationships to Other Standards​

Lors de l'examen des spécifications et de l'état de normalisation des protocoles, plusieurs documents de référence pertinents existent :

  • INTERNET OFFICIAL PROTOCOL STANDARDS (Normes officielles des protocoles Internet)

    Ce document décrit le processus de normalisation Internet et liste l'état de normalisation des protocoles. Au moment de la rédaction, la version actuelle de ce document est STD 1, RFC 1780, [ARCH:7]. Ce document est réédité périodiquement. Il convient de toujours consulter le dépôt RFC et d'utiliser la version la plus récente de ce document.

  • Assigned Numbers (Numéros attribués)

    Ce document liste les valeurs attribuées aux paramètres utilisés dans divers protocoles, par exemple les codes de protocole IP, les numéros de port TCP, les codes d'options Telnet, les types de matériel ARP et les noms de types de terminaux. Au moment de la rédaction, la version actuelle de ce document est STD 2, RFC 1700, [INTRO:7]. Ce document est réédité périodiquement. Il convient de toujours consulter le dépôt RFC et d'utiliser la version la plus récente de ce document.

  • Host Requirements (Exigences pour les hôtes)

    Cette paire de documents passe en revue les spécifications applicables aux hôtes et fournit des orientations et des clarifications sur les ambiguïtés. Notez que ces exigences s'appliquent également aux routeurs, sauf indication contraire dans ce mémo. Au moment de la rédaction, les versions actuelles de ces documents sont RFC 1122 et RFC 1123 (STD 3), [INTRO:2] et [INTRO:3].

  • Router Requirements (Exigences pour les routeurs, anciennement appelées exigences pour les passerelles)

    Le présent mémo.

Notez que ces documents sont révisés et mis à jour à des moments différents. En cas de divergence entre ces documents, le plus récent prévaut.

Ces documents et d'autres documents de protocoles Internet sont disponibles à l'adresse suivante :

The InterNIC
DS.INTERNIC.NET
InterNIC Directory and Database Service
[email protected]
+1-908-668-6587
URL: http://ds.internic.net/

1.3 General Considerations​

Les fournisseurs de logiciels Internet ont appris plusieurs leçons importantes que les nouveaux fournisseurs devraient sérieusement prendre en compte.

1.3.1 Évolution continue d'Internet​

La croissance massive d'Internet a mis en évidence des problèmes de gestion et de mise à l'échelle des grands systèmes de communication par paquets de datagrammes. Ces problèmes étant en cours de résolution, les spécifications décrites dans ce mémo continueront d'évoluer. De nouveaux protocoles, algorithmes et architectures de routage sont continuellement développés. De nouveaux protocoles de couche réseau et des modifications aux protocoles existants sont également continuellement conçus. Les routeurs jouent un rôle crucial dans Internet, et le nombre de routeurs déployés sur Internet est bien inférieur au nombre d'hôtes. Par conséquent, les fournisseurs doivent s'attendre à ce que les normes pour les routeurs continuent d'évoluer plus rapidement que les normes pour les hôtes. Ces changements sont soigneusement planifiés et contrôlés, car les fournisseurs et les organisations responsables des opérations réseau participent largement à la planification.

Le développement, l'évolution et la révision sont des caractéristiques des protocoles de réseaux informatiques d'aujourd'hui, et cette situation perdurera pendant plusieurs années. Les fournisseurs qui développent des logiciels de communication informatique pour la famille de protocoles Internet (ou toute autre famille de protocoles !) et qui ne maintiennent et ne mettent pas ensuite à jour ce logiciel pour s'adapter aux spécifications changeantes laisseront derrière eux une longue file de clients mécontents. Internet est un grand réseau de communication, et les utilisateurs sont constamment en contact. L'expérience montre que la connaissance des défauts des logiciels des fournisseurs se répand très rapidement dans toute la communauté technique Internet.

1.3.2 Principe de robustesse​

À toutes les couches du protocole, une règle générale de Jon Postel dans [TRANS:2], dont l'application peut apporter de grands bénéfices en termes de robustesse et d'interopérabilité :

Soyez conservateur dans ce que vous faites,
soyez libéral dans ce que vous acceptez des autres.

Les logiciels doivent être écrits pour gérer toutes les erreurs imaginables, aussi improbables soient-elles. Finalement, un paquet avec cette combinaison particulière d'erreurs et d'attributs arrivera, et si le logiciel n'est pas préparé, il tombera dans la confusion. Il est préférable de supposer que le réseau est rempli d'entités malveillantes qui envoient des paquets conçus pour produire les pires effets. Cette hypothèse conduit à une conception de protection appropriée. Les problèmes les plus graves sur Internet sont causés par des mécanismes inattendus déclenchés par des événements à faible probabilité. La simple malveillance humaine ne suit jamais un chemin aussi tortueux !

La capacité d'adaptation au changement doit être intégrée dans toutes les couches du logiciel de routeur. Prenons un exemple simple : une spécification de protocole qui contient une énumération des valeurs d'un champ d'en-tête particulier — par exemple, un champ de type, un numéro de port ou un code d'erreur. Il faut supposer que cette énumération est incomplète. Si une spécification de protocole définit quatre codes d'erreur possibles, le logiciel NE DOIT PAS planter lorsqu'un cinquième code est défini. Les codes non définis peuvent être enregistrés, mais ne doivent jamais provoquer d'échec.

La deuxième partie du principe est presque aussi importante : les logiciels sur les hôtes ou d'autres routeurs peuvent contenir des défauts, ce qui rend imprudent l'exploitation de fonctionnalités de protocole légitimes mais ambiguës. Il est imprudent de s'écarter des pratiques évidentes et simples, car cela peut avoir des effets néfastes ailleurs. Le corollaire de ce point est : méfiez-vous des hôtes défaillants. Le logiciel de routeur doit être prêt à survivre en présence d'hôtes défaillants. L'une des fonctions importantes d'un routeur sur Internet est de limiter les dommages que de tels hôtes peuvent causer aux équipements de communication partagés.

1.3.3 Journalisation des erreurs​

Internet contient une grande variété de systèmes, chacun implémentant de nombreux protocoles et couches de protocoles. Certains d'entre eux contiennent des erreurs ou des fonctionnalités trompeuses dans leurs logiciels de protocoles Internet. En raison de la complexité, de la diversité et de la distribution des fonctions, le diagnostic des problèmes peut être très difficile.

Si un routeur contient une installation soigneusement conçue pour enregistrer les erreurs ou les événements anormaux, cela aidera au diagnostic des problèmes. Lors de l'enregistrement d'une erreur, il est important d'inclure autant d'informations de diagnostic que possible. En particulier, il est souvent utile d'enregistrer les en-têtes du paquet qui a causé l'erreur. Cependant, il faut veiller à ce que la journalisation des erreurs ne consomme pas de ressources excessives ou n'interfère pas autrement avec le fonctionnement du routeur.

Les événements de protocole anormaux mais inoffensifs ont tendance à inonder les fichiers journaux d'erreurs. Cela peut être évité en utilisant des journaux circulaires ou en n'activant la journalisation que lors du diagnostic de pannes connues. Il peut être utile de filtrer et de compter les messages successifs en double. Une stratégie qui semble très efficace consiste à simultanément :

  • Toujours compter les situations anormales et rendre ces compteurs accessibles via des protocoles de gestion (voir chapitre 8) ; et
  • Permettre l'activation sélective de la journalisation de divers événements — par exemple, il peut être utile de pouvoir tout enregistrer, ou tout enregistrer pour l'hôte X.

Ce sujet est discuté plus en détail dans [MGT:5].

1.3.4 Configuration​

Dans un monde idéal, les routeurs seraient faciles à configurer, voire entièrement auto-configurables. Cependant, l'expérience pratique du monde réel montre que c'est un objectif impossible, et de nombreuses tentatives des fournisseurs pour faciliter la configuration ont en réalité causé plus de problèmes aux clients qu'elles n'en ont évités. À titre d'exemple extrême, un routeur conçu pour démarrer sans informations de configuration et commencer à router des paquets choisira presque certainement certains paramètres incorrects et pourrait causer de graves problèmes sur les réseaux connectés malheureux.

Ce mémo exige fréquemment que les paramètres soient des options configurables. Il y a plusieurs raisons à cela. Dans un petit nombre de cas, il existe actuellement une certaine incertitude ou un désaccord sur la valeur optimale, et la valeur recommandée pourrait devoir être mise à jour à l'avenir. Dans d'autres cas, la valeur dépend de facteurs externes — par exemple, la distribution de la charge de communication, ou la vitesse et la topologie des réseaux voisins — et des algorithmes d'auto-ajustement ne sont pas disponibles ou insuffisants. Dans certains cas, la configurabilité est nécessaire pour des raisons de gestion.

Enfin, certaines options de configuration sont nécessaires pour communiquer avec des implémentations anciennes ou incorrectes de protocoles, qui existent dans de nombreuses parties d'Internet sans distribution du code source. Pour que les systèmes corrects coexistent avec ces systèmes défectueux, les administrateurs doivent parfois mal configurer les systèmes corrects. Ce problème se corrigera progressivement avec la mise hors service des systèmes défectueux, mais les fournisseurs ne peuvent pas l'ignorer.

Lorsque nous disons qu'un paramètre doit être configurable, nous n'entendons pas exiger que sa valeur soit explicitement lue à partir d'un fichier de configuration à chaque démarrage. De nombreux paramètres ont des valeurs appropriées dans toutes les situations sauf les plus inhabituelles. Dans ce cas, il est tout à fait raisonnable que le paramètre prenne cette valeur par défaut si elle n'est pas explicitement définie.

Dans certains cas, ce mémo exige des valeurs spécifiques pour de telles valeurs par défaut. Lorsqu'un élément de configuration contrôle l'adaptation aux systèmes défectueux existants, le choix de la valeur par défaut est une question délicate. Pour qu'Internet converge avec succès vers une interopérabilité complète, les valeurs par défaut intégrées dans les implémentations doivent implémenter le protocole officiel, et non une mauvaise configuration pour s'adapter aux implémentations défectueuses. Les réalités du marché amèneront certains fournisseurs à choisir des valeurs par défaut incorrectement configurées, mais nous exhortons vivement les fournisseurs à choisir des valeurs par défaut conformes aux normes.

Enfin, nous notons que les fournisseurs doivent fournir une documentation suffisante sur tous les paramètres de configuration, leurs limites et leurs effets.

1.4 Algorithms​

À plusieurs endroits dans ce mémo, des algorithmes spécifiques que les routeurs doivent suivre sont spécifiés. Ces algorithmes eux-mêmes ne sont pas des exigences pour les routeurs. Un routeur n'est pas tenu d'implémenter chaque algorithme exactement tel qu'il est écrit dans ce document. Au lieu de cela, l'implémentation doit présenter au monde extérieur le même comportement qu'une implémentation stricte et littérale de l'algorithme spécifié.

La façon dont les algorithmes sont décrits diffère de la façon dont un bon implémenteur les implémenterait. Pour les besoins de l'explication, un style mettant l'accent sur la concision, la clarté et l'indépendance vis-à-vis des détails d'implémentation a été choisi. Un bon implémenteur choisira des algorithmes et des méthodes d'implémentation qui produisent les mêmes résultats que ces algorithmes, mais qui peuvent être plus efficaces ou moins généraux.

Notez que la technique d'implémentation efficace des routeurs dépasse le cadre de ce mémo.

Dernière mise à jour le