Mon blog

Un RFC de synthèse, qui rassemble tout ce que le fabricant d'un routeur IP doit savoir, parmi tous les RFC dispersés. L'idée était bonne mais, n'ayant jamais été mis à jour, ce RFC contient également pas mal de choses dépassées.

Créer un nouveau routeur IP est un gros travail, en partie parce qu'il faut lire des dizaines de RFC différents, sans avoir de vision d'ensemble et sans toujours pouvoir déterminer facilement ce qu'on doit faire et ce qui est facultatif. D'où l'idée de RFC de synthèse, comme celui-ci pour les routeurs (il succède au RFC 1716) ou comme le RFC 1123 pour les machines « terminales ». Mais, si le principe est bon, l'actualisation d'un tel document s'est révélée difficile. L'IETF travaillant sur la base du volontariat et la mise à jour de grosses synthèses étant moins intéressante que la création de nouveaux protocoles, le RFC a pris sérieusement la poussière. Officiellement, seul le RFC 2644 le modifie mais, en pratique, d'autres points de notre RFC semblent bien dépassés aujourd'hui. Par exemple, rares sont encore les équipements qui utilisent les paquets ICMP de répression de la source (Source Quench, section 4.3.3.3) car ces paquets facilitent trop les DoS (le RFC 6633 a officialisé l'abandon de ces paquets). Même chose pour le routage dirigé par la source (source routing).

Ce RFC fait 175 pages et est donc un gros morceau à lire (mais on ne crée pas un nouveau routeur tous les jours). C'est néanmoins une excellente source d'information pour quiconque s'intéresse au fonctionnement réel des réseaux informatiques.

Il commence par rappeler quelques principes généraux (sections 1 et 2), notamment le fait que ce RFC ne remplace pas les RFC standardisant tel ou tel protocole ou comme le principe de robustesse, Be conservative in what you do, be liberal in what you accept from others ou, dit autrement, « Ne faites pas le malin, essayez de coopérer avec les autres, pas de leur prouver qu'ils ont tort ». La section 2, sur l'architecture de l'Internet, est une bonne source sur ce sujet, recommandée à ceux qui apprennent comment fonctionne Internet. Puis chaque section est consacrée à une couche particulière, la section 3 à la couche 2, deux sections, 4 et 5, à la couche 3 (la section 5 s'occupant spécifiquement des cas où le paquet est transmis - forwarding), etc. La section 7, qui concerne la couche application s'occupe notamment des protocoles de routage.

Ainsi, pour citer quelques exemples des règles que pose ce RFC :

• La section 3 sur la couche de liaison précise que le routeur IPv4 qui met en œuvre ARP (RFC 826) ne devrait pas abandonner les paquets tout de suite s'il manque provisoirement une entrée dans la table ARP (ce conseil n'est plus du tout suivi aujourd'hui où, pour éviter l'encombrement des files d'attentes et les DoS, les routeurs du cœur de l'Internet jettent immédiatement les paquets qui ne peuvent pas être transmis pour cette raison).
• La section 4 n'impose pas de respecter les options IP comme Timestamp ou Record route qui n'ont jamais été réellement déployées (et ont disparu en IPv6).
• La section 4 rappelle que le routeur doit être capable de fragmenter les paquets trop gros (cela a disparu en IPv6 et, même en IPv4, c'est peu utilisé, au profit des techniques décrites dans les RFC 1191 et RFC 4821).
• La section 4 parle aussi d'ICMP et note que, pour éviter les avalanches, un paquet ICMP d'erreur ne doit jamais être envoyé en réponse à un autre paquet ICMP d'erreur.

Comme noté au début, le RFC n'a jamais été mis à jour donc il ne faut pas espérer y trouver d'informations sur les techniques apparues depuis, comme le NAT ou IPv6.