Résumé

  • CONNECT-ETHERNET établit, selon la révision 15, un lien Ethernet émulé sur HTTP ; il ne définit pas l’autorité associée à chaque adresse MAC ou étiquette 802.1Q transportée.
  • Le 101 ou le 2xx atteste l’ouverture du tunnel. Le filtrage des sources, l’accord VLAN, la prévention des boucles, la sortie physique et l’effet au destinataire exigent leurs propres reçus.

La révision 15 de draft-ietf-masque-connect-ethernet, publiée le 30 septembre 2026, décrit le transport de trames Ethernet complètes entre un client HTTP et un proxy relié à un segment physique ou virtuel. Le document du groupe MASQUE vise le niveau Proposed Standard. Il demeure un Internet-Draft en évaluation par l’IESG, sous-état AD Followup ; la nouvelle révision a replacé l’examen IANA dans l’état « Version Changed - Review Needed ». Ce n’est pas un RFC, ni une preuve de déploiement, d’adoption ou de conformité.

Sous HTTP/1.1, le client envoie une requête GET avec Upgrade: connect-ethernet et le serveur réussit par 101 Switching Protocols. Sous HTTP/2 ou HTTP/3, Extended CONNECT emploie :protocol = connect-ethernet et une réponse 2xx conforme lance le Capsule Protocol. Ce succès signifie que le proxy a établi le tunnel et accepte de relayer des trames. Il ne parle pas encore d’une trame précise.

Trois autorités dans une seule vue réseau

L’enveloppe HTTP peut être protégée par TLS ou QUIC, comme l’exige le projet. Le proxy peut authentifier Alice et lui accorder l’URI /ethernet/lab. À l’intérieur, Alice peut toutefois émettre une trame dont l’adresse source est celle d’un automate, d’une passerelle ou d’un autre utilisateur. Le projet avertit expressément que des trames arbitraires et des adresses MAC sources arbitraires peuvent servir à l’usurpation, à l’empoisonnement ARP, NDP ou CAM et au déni de service.

L’identité du principal HTTP, l’identité prétendue dans l’en-tête Ethernet et l’autorité de produire un effet sur le segment sont donc trois objets. Les réunir dans une colonne « tunnel authentifié » facilite le tableau de bord, mais détruit la preuve.

Le contexte 0 ne résout pas ce problème. Il indique seulement que la charge utile est une trame Ethernet, de l’adresse de destination jusqu’à l’octet précédant le FCS. Le FCS d’origine est omis, les interfaces le retirant à l’entrée et le régénérant à la sortie. Une protection de transport intègre et un nouveau contrôle de lien ne prouvent pas que l’adresse source appartenait au principal HTTP.

Le VLAN transparent n’est pas une politique partagée

Par défaut, une étiquette IEEE 802.1Q traverse le tunnel sans transformation. Si une extrémité l’interprète, les deux côtés doivent s’accorder, par signalisation ou configuration, sur un traitement cohérent. Or cette procédure n’est pas définie dans le projet.

Le proxy peut associer chaque VLAN à un URI distinct, supprimer l’étiquette à l’entrée puis la réappliquer à la sortie. Cette souplesse transforme la table URI–VLAN en actif de sécurité. Il faut conserver la version de la règle, son propriétaire, le principal, l’étiquette reçue, la traduction appliquée, la priorité finale et l’interface de sortie. Une réponse 200 atteste l’acceptation de la requête ; elle ne signe aucune de ces correspondances.

Le cas limite révèle l’enjeu. Une configuration est modifiée sur un seul côté. Les deux extrémités restent conformes à HTTP, le tunnel demeure actif, les trames sont bien formées ; pourtant, elles entrent dans un domaine administratif différent. La conformité mécanique ne crée pas l’accord sémantique manquant.

Un lien émulé ne gère pas tout le pont

CONNECT-ETHERNET présente un lien point à point. Lorsqu'on le branche sur un réseau externe, l’extrémité peut devoir assumer des fonctions de commutateur : diffusion, multidiffusion, traitement des trames PAUSE, apprentissage et prévention des boucles. Le projet place ces responsabilités hors de son mécanisme.

Deux liens valides peuvent donc former une boucle invalide. Une tempête de diffusion épuise la capacité, fait perdre des trames et perturbe les protocoles de contrôle transportés. STP ou RSTP, une délégation au noyau, une topologie démontrée sans boucle, ainsi que des limites de débit sont les contrôles pertinents. Aucun n’est contenu dans le succès HTTP.

Un contrôle opérationnel sérieux juxtapose état du flux HTTP, rôle spanning-tree, mouvements d’adresses apprises, débit broadcast, rejets de sources et pertes. Le lien peut être sain tandis que le service de pont est dangereux.

La livraison se mesure trame par trame

Avec QUIC DATAGRAM, une trame trop grande pour la charge disponible doit être abandonnée ; elle ne doit pas être transférée opportunément dans une capsule. Les capsules DATAGRAM fiables peuvent franchir plusieurs paquets, mais l’ordre n’est pas garanti dans toutes les architectures, notamment lorsqu’un intermédiaire réencode le mode. Une trame décapsulée trop grande pour l’interface ou le réseau de sortie doit elle aussi être abandonnée, avec un compteur recommandé.

Les contextes inconnus ou reçus avant leur requête peuvent être perdus silencieusement ou brièvement tamponnés. Si l’extrémité ne peut remettre une trame au segment, elle la supprime. Tous ces résultats sont compatibles avec un tunnel encore ouvert.

Il faut donc un reçu en chaîne : principal et politique HTTP ; URI ; résultat 101/2xx ; contexte et mode ; décision sur la source MAC ; traitement VLAN ; état du pont ; admission dans la file ; résultat de l’interface ; observation du destinataire. Les premières étapes ne doivent pas être présentées comme la preuve des dernières.

Les textes de Heng Lu sur la primauté du code en fonctionnement, la spécification initiale minimale et le problème d’agence servent ici de grille éditoriale déclarée. Un standard commun gagne à rester précis et étroit ; les systèmes locaux doivent prouver les décisions supplémentaires qu’ils prennent. L’agence porte sur le pouvoir d’introduire des effets dans un domaine de diffusion, pas seulement sur le droit d’ouvrir une session. Il s’agit d’une lecture, non d’une intention attribuée à l’IETF.

Sources