Résumé

  • RFC 3378 documentait EtherIP, mécanisme minimal qui plaçait une trame Ethernet derrière un en-tête de seize bits puis la transportait dans IPv4 avec le numéro de protocole 97.
  • Le format ne fournissait ni authentification du pair, ni contrôle d’intégrité de la trame interne, ni séquence, ni commande de tunnel, ni prévention des boucles. Décapsuler ne prouvait pas qu’un LAN sûr s’étendait désormais à distance.

Une trame Ethernet porte des adresses et une charge utile, mais une grande partie de la sécurité d’un LAN n’est pas écrite dans cette trame. Elle vient du câble, des commutateurs, du périmètre, de la topologie et de l’idée que certains protocoles ne parlent qu’à des voisins. EtherIP conservait l’enveloppe tout en déplaçant ces présupposés.

Publié en septembre 2002 avec le statut Informational, RFC 3378 consignait un protocole conçu en 1991 et 1992. Il expliquait l’attribution du numéro IP 97 et fournissait un contexte historique. Les auteurs recommandaient les futurs travaux normalisés sur les tunnels de couche 2 et les pseudowires plutôt qu’EtherIP pour de nouvelles architectures.

Le format tenait presque dans une note de bas de page. L’en-tête IPv4 annonçait le protocole 97. Ensuite venaient quatre bits de version valant trois et douze bits réservés valant zéro. La trame Ethernet ou IEEE 802.3 suivait, sans sa séquence FCS. Le récepteur rejetait les autres valeurs, extrayait la trame, calculait un nouveau FCS et l’émettait sur le LAN distant.

Cette validation portait sur la syntaxe. Les seize bits n’identifiaient pas l’émetteur et n’autorisaient pas l’adresse MAC. Ils ne contenaient ni identifiant de session, ni numéro de séquence, ni négociation, ni protection contre la répétition, ni contrôle propre à la charge interne.

Le FCS révélait une rupture de preuve. Celui du LAN d’origine n’entrait pas dans le tunnel. RFC 3378 précisait que la somme de contrôle IPv4 ne protégeait pas la trame encapsulée et comptait sur un protocole supérieur pour l’intégrité. Le nouveau FCS calculé à la sortie pouvait être exact même après une altération antérieure : il attestait seulement la nouvelle transmission locale.

Une station terminale pouvait sélectionner ses propres trames. Une station ressemblant à un pont pouvait écouter tout le segment puis appliquer des règles sur les adresses source et destination, l’EtherType ou le VLAN. Elle devait éviter d’encapsuler ce qui pouvait rester local ou passer par un routeur normal. Ces décisions dépendaient de l’environnement ; le petit en-tête ne les décrivait pas.

Il fallait aussi déterminer l’adresse IP de la station EtherIP distante, souvent à partir de la destination MAC. Aucun service universel de découverte ou de correspondance n’était défini. La validité du paquet reposait donc sur une configuration antérieure : quelles trames traversent, et quelle passerelle représente leur destination.

Le mode pont introduisait le risque le plus spectaculaire. Plusieurs passerelles pouvaient capturer puis réinjecter la même trame jusqu’à la faire circuler sans fin. Diffusion et multidiffusion aggravaient ce risque. La RFC imposait une topologie en arbre, mais confiait sa construction à la personne configurant les stations. Aucun compteur de sauts ni protocole d’arbre couvrant n’interrompait automatiquement une erreur.

Une boucle pouvait ainsi résulter de règles localement correctes. Chaque passerelle faisait exactement ce qu’on lui demandait ; l’ensemble renvoyait pourtant la trame vers un segment déjà traversé. Les compteurs confirmaient l’activité sans démontrer un progrès utile.

Le périmètre de sécurité s’allongeait également. Autoriser EtherIP à travers un pare-feu pouvait ouvrir des communications arbitraires. Un mécanisme faible, acceptable entre voisins supposés proches, devenait plus dangereux entre segments distants. RFC 3378 citait VRRP comme exemple et proposait IPsec pour protéger les datagrammes extérieurs.

RFC 2401 décrit l’architecture IPsec de l’époque ; RFC 4301 l’a remplacée. IPsec pouvait authentifier des pairs et protéger le transport. Il ne décidait pas si la règle de capture était juste, si la topologie était sans boucle, si l’injection distante était autorisée ni si l’application avait accepté la donnée.

RFC 2003 sur IP-dans-IP et RFC 2784 sur GRE donnent d’autres points de comparaison. RFC 3931 a ensuite donné à L2TPv3 une connexion de contrôle et des sessions ; RFC 3985 a posé l’architecture pseudowire, et RFC 4448 a décrit l’émulation Ethernet. Cette chronologie montre ce que les travaux ultérieurs ont explicité, sans ajouter ces propriétés à EtherIP après coup.

RFC 2119 précise enfin la portée de MUST : les bons bits de version devaient être envoyés et les mauvais rejetés. Cela ne prouvait ni permission du pare-feu, ni confiance, ni déploiement. Le registre IANA rendait le numéro reconnaissable ; il n’en faisait pas une preuve d’usage ou de sécurité.

La spécification initiale minimale de Lu Heng éclaire l’utilité d’un tel format : quelques bits communs peuvent débloquer une fonction avant que l’architecture complète existe. Ses couches de réalité en montrent le prix analytique. Sélection, encapsulation, confiance du pair, route, intégrité, décapsulation, nouveau FCS, injection et réception sont liées, mais ne constituent jamais un reçu unique.

EtherIP déplaçait donc une enveloppe familière, pas son monde local. Le LAN restait une combinaison de topologie, d’administration, de sécurité et de conséquences physiques. Seize bits suffisaient pour le transport ; tout le reste devait être reconstruit et vérifié.

Sources