Mon blog

À une époque, il semblait encore possible de résumer dans un RFC tout ce que devait savoir le développeur de services réseaux. Ce n'est évidemment plus le cas, néanmoins, ce RFC, qui synthétise les règles que doivent respecter les machines non-routeuses reste utile, certaines des règles qu'il pose étant toujours d'actualité.

Un problème classique de l'implémenteur est le nombre de RFC à lire, et le risque de ne plus pouvoir distinguer les choses importantes des détails, au milieu de toutes ces normes. D'où l'idée de résumer les « choses importantes » dans des RFC de synthèse comme le RFC 1812 pour les routeurs ou comme deux RFC, le RFC 1122 et le nôtre, qui couvrent les machines non-routeuses (host en anglais, parfois traduit par terminal, qui est un terme que je trouve trop marqué par l'époque des mainframes et du Minitel). Le RFC 1122 couvre les couches basses et le 1123 les couches hautes. C'est un des plus vieux RFC encore en service. À l'époque (1989), les médias et les experts officiels n'avaient pas encore découvert l'Internet mais celui-ci était déjà suffisamment complexe pour que la section 1.2.1 s'inquiète de l'« énorme croissance de l'Internet » et des problèmes qu'elle pose.

Comme le note la section 1, de tels RFC de synthèse sont normalement inutiles. « Une mise en œuvre de bonne foi, faite en lisant soigneusement les RFC, ainsi qu'en suivant les activités de la communauté technique et des bons principes d'ingéniérie, ne devrait se différencier des demandes de ce RFC que de manière mineure. » Mais la pratique ne suivant pas toujours la théorie, et des mises en œuvre des protocoles Internet s'étant avérées très boguées, la réalisation d'un RFC de rappel a semblé une bonne idée. En revanche, la mise à jour régulière de ce RFC, promise en section 1, ne s'est jamais concrétisée, même s'il y a eu des mises à jour partielles, comme les RFC 1349 ou RFC 2181.

La partie la plus souvent citée de notre RFC est certainement la section 2.1 Host names and numbers, qui normalise la syntaxe pour les noms de machines sur Internet. Cette syntaxe est limitée à LDH (Letters - Digits - Hyphen) c'est-à-dire un sous-ensemble d'ASCII limité aux lettres de A à Z, aux chiffres et au tiret. Contrairement à ce qu'on lit souvent sous la plume d'ignorants, cette limite n'a rien à voir avec le DNS, qui était une invention récente à l'époque de notre RFC. Cette limite plonge au contraire ses racines dans des normes plus anciennes, comme le RFC 952 qui était même encore plus strict (le nom ne pouvait pas commencer par un chiffre). Ainsi, les règles pour les noms de machines ne sont pas les mêmes que pour un nom de domaine. C'est pour cela qu'il a fallu développer IDN (RFC 3490), pas à cause d'une soi-disant limite du DNS.

La section 1.2.2 rappelle un de ces « bons principes d'ingéniérie », la fameuse phrase « Soyez prudents dans ce que vous envoyez et ouverts dans ce que vous recevez » (« Be liberal in what you accept, and conservative in what you send », déjà présente dans le RFC 791).

Voyons maintenant les autres parties, moins célèbres, de ce RFC.

Sur certains points, les changements dans l'Internet ont été positifs. C'est ainsi que la section 1.2.4 déplorait que l'auto-configuration des machines connectés était toujours aussi utopique, alors que depuis, notamment grâce à DHCP (RFC 2131), elle est devenue une réalité.

Par contre, d'autres fonctions, sur lesquelles on fondait beaucoup d'espoirs, n'ont jamais vraiment pris. Ainsi, la section 2.4 mentionne les TOS d'IPv4, que peu d'applications utilisent et que beaucoup de routeurs ou de coupe-feux bloquent. (Petite publicité personnelle : echoping permet de définir ces valeurs TOS, avec l'option -P.)

La section 3 est consacrée au protocole telnet, qui devrait logiquement être abandonné aujourd'hui, remplacé par SSH.

La section 4 concerne le transfert de fichiers, qui à l'époque se faisait uniquement avec FTP. Il est toujours utilisé aujourd'hui, mais HTTP (RFC 2616) et SCP ont diminué son importance.

La section 5 parle du courrier électronique mais on ne recommande pas sa lecture, les normes et, encore plus, la réalité ayant beaucoup évolué depuis (les textes à jour sont les RFC 2821 et RFC 2822).

La section 6.1 détaille les interactions avec les systèmes de résolution de noms. Elle n'est pas limitée au DNS, loin de là, la section 6.1.3.8 expliquant la possibilité d'utiliser également un fichier local (/etc/hosts sur Unix) et de configurer quel mécanisme de résolution est utilisé (/etc/host.conf sur Unix).

La 6.1.4, elle, mentionne les listes de domaines dans lesquels chercher un nom (fonction mise en œuvre avec la directive search dans le /etc/resolv.conf des machines Unix). La publication du RFC en 1989 n'a pas empêché Verisign de déposer un brevet en 2003 (6,560,634) sur cette fonction. Et l'office états-unien des brevets l'a accepté (les offices des brevets acceptent tout et n'importe quoi ; ils n'ont ni la compétence, ni l'envie de chercher des précédents, puisque leurs revenus dépendent des dépôts).

La section 6.2 concerne la gestion des machines, à une époque où le protocole SNMP était très récent.