Résumé
- La RFC 9898 est un document IETF Informational. Elle examine des problèmes connus de Neighbor Discovery IPv6 et leurs mesures d’atténuation ; elle précise qu’elle n’introduit aucune nouvelle solution ni aucun nouveau protocole d’isolation des hôtes.
- Elle regroupe les causes profondes en trois familles : multicast, confiance envers tous les nœuds présents sur le lien et entrées de cache des voisins du routeur créées à la demande.
- L’isolation L3+L2 est l’option la plus forte de la hiérarchie : elle peut traiter tous les problèmes inventoriés, mais exige une isolation L2, un préfixe unique par hôte et un support du routeur ou des interfaces adaptées.
- L’isolation L3 traite la plupart des problèmes sur un support partagé ; l’isolation L2 partielle réduit surtout les domaines multicast et ne supprime pas automatiquement la confiance sur le lien ni la création à la demande des entrées du routeur.
Lire la hiérarchie
Avec l’isolation L3+L2, chaque hôte se trouve dans son propre sous-réseau et sur son propre lien. La portée multicast et la frontière de confiance isolées éliminent les trois causes inventoriées, y compris les entrées du routeur créées à la demande. Cette force a un prix opérationnel : préfixes par hôte, séparation L2, support du routeur ou nombre suffisant d’interfaces logiques, et capacité à faire transiter le trafic par le routeur. Le trafic hôte-à-hôte peut alors se concentrer sur ce routeur, tandis que des applications multicast d’hôte à hôte comme mDNS peuvent être perturbées.
L’isolation L3 attribue à chaque hôte un sous-réseau distinct tout en conservant un support partagé. Elle atténue la plupart des problèmes inventoriés, mais le multicast link-local du DAD reste lié aux performances et à la fiabilité de ce support. Le contexte de sécurité sur le lien dépend également du support et du modèle de confiance. Les RFC 8273 et RFC 9663 apportent des éléments sur les préfixes par hôte et leur attribution ; elles ne transforment pas chaque déploiement en modèle universel.
L’isolation L2 partielle maintient les hôtes dans un même sous-réseau, tout en séparant les domaines multicast au moyen de fonctions de proxy ou d’optimisation. Son bénéfice déclaré est de réduire le trafic multicast, notamment pour la résolution d’adresses. Il ne faut pas la présenter comme supprimant automatiquement la confiance sur le lien ou les entrées du routeur créées à la demande.
La RFC 9898 propose de considérer les méthodes de la plus forte à la plus faible comme une orientation opérationnelle contextuelle, et non comme une exigence normative universelle. Les méthodes fortes préviennent davantage de problèmes mais imposent plus de conditions ; les méthodes faibles laissent des problèmes résiduels à compléter. Le document ne fournit ni prévalence de déploiement, ni coûts universels, ni mesures de débit, ni réduction mesurée des incidents, ni seuil de topologie, de nombre d’interfaces, de cache ou de multicast, ni délai de migration.
Sources
- RFC 9898 — Neighbor Discovery Considerations in IPv6 Deployments
- RFC 4861 — Neighbor Discovery for IP version 6 (IPv6)
- RFC 4862 — IPv6 Stateless Address Autoconfiguration
- RFC 8273 — Unique IPv6 Prefix per Host
- RFC 9663 — Using DHCPv6 Prefix Delegation to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
