Résumé
- RFC 9818 impose au routeur de bordure client de servir IA_PD côté LAN, d’associer chaque bail à une route et à un prochain saut, puis de retirer cette route et de rendre le préfixe au pool lors de la libération ou de l’expiration.
- Le filtrage doit admettre par défaut les sources appartenant aux préfixes délégués, tandis que la durée de vie donnée en aval ne peut dépasser le temps restant de la délégation reçue en amont.
- Un reçu local de garde du préfixe doit relier délégation parente, bail enfant, route, filtre, horloges et fin de garde. Il s’agit d’une proposition éditoriale de Daniel Kade, pas d’un champ RFC ni d’une exigence IETF.
Le compteur d’adresses libres peut être exact et la capacité réellement disponible égale à zéro. Ce paradoxe apparaît lorsque l’outil d’inventaire voit un bloc reçu du fournisseur, mais que le routeur de bordure ne transforme pas le reste de ce bloc en délégations utilisables sur son LAN.
RFC 9818 s’intéresse précisément à cette transformation. Le fournisseur remet un préfixe au routeur CE. Celui-ci en consomme une partie pour ses liens, conserve le reliquat pour d’autres routeurs, répond aux demandes DHCPv6, installe les routes correspondantes et adapte son filtrage. Chaque étape produit une vérité partielle. Aucune, prise seule, ne prouve que les paquets du routeur enfant peuvent aller et revenir.
Le sujet n’est donc pas une nouvelle façon de compter les adresses. C’est une chaîne de garde temporaire. Le pouvoir d’utiliser une portion du préfixe passe d’un serveur amont au routeur CE, puis à un client IA_PD, mais il reste borné par le temps et par les décisions d’exécution du détenteur intermédiaire.
Une délégation en amont ne remplit pas le LAN
De nombreux fournisseurs remettent aux clients des blocs plus grands qu’un /64. Sans prise en charge d’IA_PD sur les interfaces LAN, le routeur CE ne peut pas distribuer les portions inutilisées aux routeurs placés derrière lui selon le mécanisme visé par RFC 9818. Il peut configurer ses hôtes locaux et, malgré cela, bloquer l’extension du réseau.
LPD-1 rend donc la délégation de préfixe obligatoire côté LAN. LPD-2 exige que l’allocation enfant provienne du préfixe délégué et qu’une erreur de gestion soit consignée lorsque le nombre de préfixes disponibles ne suffit pas. Le succès amont et l’échec aval ne se contredisent pas : ils décrivent deux frontières de décision différentes.
Le modèle par défaut est plat. Après avoir attribué les préfixes nécessaires aux liens locaux, le CE met les autres à disposition des routeurs du LAN. Une hiérarchie peut être configurée, notamment avec des préfixes plus courts que /64, mais une suite de délégations hiérarchiques sans connaissance topologique peut déséquilibrer l’arbre et épuiser une branche. La norme ne transforme pas cette option en choix universel.
LPD-3 protège la continuité : le préfixe d’un lien ne doit pas changer sans politique locale ni changement de topologie. Cette phrase ne garantit pas une identité éternelle. Elle oblige plutôt à rattacher un renumérotage à un motif observable. LPD-4 exige parallèlement que le reliquat reste disponible pour les autres routeurs. Un espace non attribué dans une base n’est pas encore un espace que le service DHCPv6 sait remettre correctement.
Le bail ne prend son sens qu’avec son prochain saut
LPD-5 relie deux plans que les outils séparent souvent. Le routeur CE maintient une table de routage locale mise à jour dynamiquement à partir des baux et des prochains sauts associés. Le préfixe enfant doit donc être à la fois un objet de location et une destination acheminable.
Une réponse DHCPv6 prouve qu’un échange a produit un résultat. Elle ne prouve pas que l’installation de la route a réussi. Une route présente ne prouve pas que le bail qui l’autorisait est encore valide. Un compteur sur une route agrégée ne prouve pas que le prochain saut précis a transporté les paquets. L’enquête doit conserver les quatre affirmations, leurs horodatages et leurs sources.
La fin du bail est aussi structurée que son début. Lorsqu’un préfixe est libéré, ou lorsque sa durée valide expire sans renouvellement, la route associée doit disparaître et le préfixe doit revenir dans le pool. Une seule mention « expiré » masque donc au moins deux mutations. Si le pool récupère le préfixe avant que l’ancienne route ne soit retirée, deux gardes peuvent se chevaucher. Si la route part mais que le pool ne récupère rien, la capacité fuit. Si le filtre conserve une exception, la surface de sécurité survit à l’autorité qui la justifiait.
Une procédure robuste ne doit pas effacer ces divergences en choisissant arbitrairement le dernier état écrit. Elle doit montrer que le bail, la route et le pool ne sont plus d’accord, puis attribuer la remise en cohérence.
Le filtre doit suivre la délégation, pas une liste immobile
LPD-6 modifie la règle de filtrage du routeur CE : par défaut, il doit laisser passer les paquets dont l’en-tête IPv6 externe porte une source appartenant à un préfixe délégué, ainsi que les paquets réciproques du même flux. Il doit continuer à rejeter les adresses qui ne sont ni attribuées au LAN ni déléguées.
La frontière autorisée est donc calculée à partir de la garde en cours. Un préfixe passe de disponible à délégué, puis de délégué à expiré. Une règle statique peut être syntaxiquement correcte tout en référant à l’époque précédente. Un bail valide avec un refus résiduel produit une capacité muette. Une permission résiduelle sans bail courant accepte une identité de source dont le routeur n’est plus le gardien.
Un test de connectivité est utile parce qu’il confronte ces états au code en cours d’exécution. Mais il reste un échantillon. Il ne dit pas quelle délégation a autorisé la source, si le trajet retour utilisait la route attendue, ni combien de temps il restait au parent. L’observation du paquet complète la provenance ; elle ne la remplace pas.
L’horloge enfant ne peut dépasser l’horloge parente
LPD-10 fixe l’invariant temporel. La durée d’un préfixe délégué sur le LAN ne doit jamais dépasser la durée restante du préfixe correspondant appris sur le WAN. Le routeur CE ne peut céder une autorité plus longue que celle qu’il détient encore.
Comparer deux nombres de durée ne suffit pas. Le temps restant du parent dépend de l’instant où il a été observé. Le bail enfant peut être écrit par un autre processus, avec un autre point de référence. Renouvellement, rebind, redémarrage et dérive d’horloge peuvent séparer les représentations. La comparaison honnête porte sur les instants d’expiration rattachés à la même chaîne de garde.
Si l’amont renouvelle le parent, l’aval peut être prolongé par un échange valide. Si l’amont réduit sa durée ou cesse de renouveler, le CE ne doit pas continuer à annoncer une autorité qu’il perdra avant l’enfant. Un écran montrant « bail actif » sans l’expiration parente donne une conclusion que sa propre donnée ne peut soutenir.
LPD-7 établit /64 comme longueur par défaut pour l’aval, en cohérence avec SLAAC, tout en permettant une autre longueur configurée. LPD-8 maintient la fourniture de GUA même si le routeur génère aussi un ULA, et LPD-9 recommande de placer le GUA d’abord lorsque les deux sont délégués. Là encore, adresse locale et capacité globale restent deux faits.
Le reçu de garde du préfixe
Le reçu de garde du préfixe proposé ici commence par la délégation parente : interface WAN, préfixe exact, identités DHCPv6 pertinentes, IA, instants d’expiration préféré et valide, renouvellement et horloge d’observation. Il énumère ensuite les plages consommées par les liens locaux et le pool réellement disponible pour les enfants.
Pour chaque enfant, le reçu relie demande, réponse, client, IA_PD, préfixe, longueur, interface LAN, prochain saut et expirations. L’installation de route conserve son propre résultat, sa table, sa version et sa condition de retrait. Le volet filtrage désigne la politique effective qui autorise la source déléguée et le retour, sans aspirer un historique de trafic inutile.
Un contrôle de paquets borné enregistre direction, instant et résultat. La sortie de garde enregistre libération, expiration, réduction du parent, changement topologique ou décision locale, puis retrait de route, retrait d’autorisation et retour au pool. Une nouvelle attribution ne devrait être déclarée propre qu’après observation de cette sortie.
Ce reçu est local, minimisé et soumis au contrôle d’accès. Les identifiants DHCP, la topologie domestique ou d’entreprise et les observations de trafic sont sensibles. Il ne s’agit ni d’un registre central ni d’une extension du protocole. C’est une manière de ne plus convertir le succès d’un composant en verdict sur tout le service.
Une base commune ne tranche pas toutes les politiques
RFC 9818 est un document informationnel qui emploie un langage normatif pour établir une base fonctionnelle commune. Il laisse expressément hors de son périmètre les réseaux multi-préfixes avec plusieurs fournisseurs, car leur traitement exige du routage, du provisionnement et de la politique supplémentaires. « Hors périmètre » ne veut pas dire interdit.
L’IETF définit le comportement commun. Le fournisseur décide de la délégation parente. Le routeur CE orchestre DHCPv6, route et filtre. L’administrateur choisit certaines longueurs et la hiérarchie. Le routeur enfant exploite le réseau dérivé. La gouvernance correcte conserve ces autorités au lieu de les fondre dans une case « IPv6 disponible ».
La doctrine de Heng Lu impose de revenir aux faits exécutés : la RFC décrit l’obligation, le logiciel tente la jointure, les observations montrent ce qui s’est produit et l’autorité locale décide de la réparation. Le préfixe n’est une capacité que pendant l’accord de ces preuves.
Sources
- Fiche IETF Datatracker de RFC 9818
- Heng Lu : Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
- Heng Lu : On Why BTW Media Exists
- Heng Lu : The Policy Mirror
- Fiche RFC Editor de RFC 9818
- RFC 4862 : autoconfiguration IPv6 sans état
- RFC 6092 : fonctions de sécurité recommandées des CPE
- RFC 6177 : attribution IPv6 aux sites terminaux
- RFC 7084 : exigences de base des routeurs CE IPv6
- RFC 8200 : protocole IPv6
- RFC 8213 : sécurité des messages serveur-relais DHCPv6
- RFC 8415 : DHCP pour IPv6
- RFC 9818 : délégation de préfixe DHCPv6 sur les LAN des routeurs CE
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
