Résumé

  • La RFC 3069 permettait à des VLAN clients distincts de partager un sous-réseau IPv4 et une passerelle, sans fusionner leurs domaines de diffusion de couche 2.
  • Comme un hôte du même préfixe tente d’abord une résolution ARP, le routeur du super-VLAN doit assurer la médiation : le masque ne prouve ni l’adjacence ni l’autorisation.

Moins d’adresses, davantage de médiation

Le calcul d’adresses était convaincant. Dans l’exemple de la RFC, trois clients prévoyaient chacun seize hôtes. Des sous-réseaux distincts consommaient 28 adresses après prise en compte des adresses réseau, de diffusion dirigée et de passerelle, ainsi que de l’arrondi en puissances de deux. Le modèle de la RFC 3069 en utilisait dix-neuf : les trois sous-VLAN clients partageaient 1.1.1.0/24 et la passerelle 1.1.1.1, tout en conservant des plages d’hôtes disjointes. Une adresse inutilisée pouvait être attribuée ailleurs sans renuméroter le client.

Cette économie ne rendait pas les clients voisins en couche 2. Chaque sous-VLAN restait son propre domaine de diffusion. Pourtant, chaque hôte utilisait la longueur de préfixe du super-VLAN. La logique IP ordinaire considérait donc une adresse de 1.1.1.0/24 comme directement joignable et tentait une résolution d’adresse au lieu d’envoyer le paquet à la passerelle par défaut. ARP trouve une adresse de couche liaison sur le réseau local ; il ne réunit pas deux domaines de diffusion isolés.

Le routeur du super-VLAN fournissait le relais manquant. La RFC 3069 indique qu’il peut remplir une fonction similaire à Proxy ARP : répondre à un hôte qui demande l’adresse d’un hôte situé dans un autre sous-VLAN, puis recevoir la trame et acheminer le paquet. Pour l’hôte, la destination semblait voisine. Dans le système de transfert, le routeur intervenait. Le préfixe exprimait une relation d’adressage, pas un fait physique ou de couche 2.

Cette distinction place un état opérationnel derrière la simplicité apparente. Le routeur doit connaître l’appartenance des adresses aux sous-VLAN, décider si le demandeur peut utiliser l’adresse source annoncée, répondre à ARP de façon cohérente et ne transférer que sur le chemin prévu. Un masque plausible ou une réponse ARP réussie ne prouve pas que l’association adresse-VLAN est actuelle ou autorisée. La RFC recommande des plages d’adresses « collantes » : rejeter les paquets IP ou ARP reçus sur un sous-VLAN lorsque leur adresse source ne lui est pas attribuée, et éventuellement consigner l’événement.

L’efficacité de cette règle dépend des données d’allocation et d’association locales.

Certains comportements familiers d’un sous-réseau ne correspondent plus à un seul domaine de diffusion. La RFC ne prend pas en charge la diffusion dirigée, car l’adresse tout-à-un ne peut pas désigner simultanément plusieurs domaines de couche 2 isolés. Le multicast demande aussi une attention particulière : un routeur multicast peut avoir besoin d’un état de type route d’hôte pour que les contrôles RPF fonctionnent entre domaines séparés. Plus tard, la RFC 4562 a décrit les difficultés de réplication multicast et la limite de 4096 VLAN dans les réseaux d’accès haut débit.

L’économie d’adresses ne supprimait pas les coûts opérationnels ; elle les déplaçait vers l’état du routeur et l’exploitation du réseau.

La limite des preuves compte. La RFC 3069 est informative et ne définit pas une norme Internet ; elle omet délibérément les détails d’implémentation. Elle rapporte qu’Extreme Networks avait une implémentation fonctionnelle en service dans des centres de données de fournisseurs depuis plus d’un an : il s’agit du témoignage des auteurs, pas d’une étude indépendante d’adoption. Les travaux d’autres fournisseurs n’étaient que des rumeurs. Le document ne fournit aucune mesure générale d’interopérabilité, de taux d’échec ou de résultat client.

Lire le paquet, pas seulement le masque

Quand un flux du même sous-réseau échoue, le masque n’est qu’un indice. Il faut examiner la requête et la réponse sur le sous-VLAN concerné, l’adresse source, l’allocation adresse-VLAN du routeur, la décision proxy/ARP et le résultat du transfert. En multicast, l’état RPF et les éléments propres à l’émetteur comptent aussi. Ces traces montrent ce que le routeur a fait à un point d’observation ; elles ne prouvent pas automatiquement le succès applicatif ni l’isolation de tous les chemins d’accès.

Sources