Résumé

  • Dans un réseau IPv6 multi-préfixe, trois choix valides séparément peuvent former un chemin invalide : source, routeur de premier saut et résolveur DNS.
  • Le reçu utile rattache ces trois décisions à une même tentative sans confondre configuration reçue, choix local, acceptation en amont et résultat applicatif.

Une entreprise voit une requête échouer sur un portable pourtant « connecté » à trois reprises : au Wi-Fi, au réseau mobile et au VPN. Le nom a été résolu, une adresse source existe et un routeur par défaut est joignable. La panne ne vient pas de l’absence d’une pièce. Elle vient d’un assemblage : la réponse DNS appartient au VPN, l’adresse à l’accès fixe et le prochain saut au lien mobile.

La RFC 7157 donne un vocabulaire précis à ce défaut d’accord. Publiée en mars 2014 comme RFC informationnelle issue du consensus de l’IETF, elle s’intitule IPv6 Multihoming without Network Address Translation. O. Troan y figure comme éditeur, avec David Miles, Satoru Matsushima, Takashi Okimoto et Dan Wing. Cette attribution établit la participation d’Ole Trøan à un texte collectif. Elle ne lui attribue ni invention solitaire, ni maîtrise des déploiements, ni paternité sur les RFC ultérieures.

Le point de départ est moins l’adresse que la concentration des décisions. En IPv4, un routeur NAPT place souvent derrière une seule boîte l’adresse source externe, la résolution du prochain saut et parfois le DNS. La machine intérieure conserve une adresse privée. Elle ne voit pas nécessairement quel opérateur fournit l’adresse publique, quelle sortie porte le paquet ni quel résolveur donne la carte des noms.

Avec IPv6, un petit site peut recevoir un préfixe global de chaque fournisseur. Un appareil peut porter plusieurs adresses de même portée, garder plusieurs routeurs valides et apprendre plusieurs résolveurs. Cette richesse rétablit la possibilité d’une communication de bout en bout sans traducteur invisible. Elle fait aussi remonter vers l’hôte une question que la boîte avait absorbée : quelles informations appartiennent au même domaine de fourniture ?

La RFC 7157 formule trois décisions qui doivent être résolues avant le premier paquet. L’adresse source doit convenir au réseau amont. Le prochain saut doit conduire vers ce réseau. Le résolveur doit connaître l’espace de noms du service visé. Les filtres d’entrée rendent l’accord concret : un paquet portant le préfixe du fournisseur A peut être rejeté s’il sort chez B, même si l’adresse et le routeur étaient chacun parfaitement valides.

La première pièce est le choix de source. La RFC 6724 définit les algorithmes par défaut pour les adresses source et destination, avec une table de politique administrable. La RFC 7157 relève que ce comportement ne permet pas toujours de départager correctement plusieurs adresses de fournisseur. La RFC 7078 ajoute une option DHCPv6 pour distribuer une table de sélection. Il faut préserver la frontière de preuve : recevoir une option ne prouve ni son installation, ni sa fraîcheur, ni son utilisation pour le paquet étudié.

La deuxième pièce est le premier saut. Plusieurs Router Advertisements peuvent maintenir plusieurs routeurs par défaut dans un état valide. La simple disponibilité ne dit pas lequel accepte la source choisie. La RFC 8028, publiée plus tard sur la voie Standards Track, précise que la source est choisie avant le routeur de premier saut et que l’hôte doit remettre le paquet à un routeur ayant annoncé ce préfixe source. Ses auteurs sont Fred Baker et Brian Carpenter. Ole Troan est remercié pour un apport de texte important ; ce fait ne transforme pas sa contribution en qualité d’auteur.

La troisième pièce est le contexte DNS. Un VPN peut servir un nom interne ; un opérateur peut répondre différemment selon le réseau d’origine. Interroger le serveur le plus rapide ou accepter la première réponse ne garantit pas que l’adresse obtenue soit utile sur la sortie finalement choisie. La RFC 7157 examine une sélection fondée sur l’espace de noms et renvoie à la RFC 6731 pour la diffusion d’une politique DNS par DHCPv6. Une réponse DNS est donc un reçu de résolution dans un contexte donné, pas un reçu de livraison.

Les trois choix s’enchaînent sans appartenir à une seule autorité. L’application formule une intention et un nom. La politique de résolution désigne un contexte et retourne des destinations. La pile hôte choisit une source. La logique de routage choisit une porte. Le réseau amont applique ses filtres. Le serveur distant produit, ou non, une réponse. Dire ensuite « IPv6 fonctionne » réduit cette chaîne à son dernier voyant et rend le prochain incident presque inexplicable.

Le texte de 2014 conserve aussi une nuance utile sur les solutions. Il recommande d’éviter, si possible, NAT et NPTv6 afin de préserver la transparence de bout en bout. Mais il conclut que des solutions fondées sur DHCPv6 conviennent aux problèmes étudiés et que NPTv6 peut rester nécessaire comme étape intermédiaire. Transformer cette tension en slogan pour ou contre la traduction trahirait le document. Une architecture souhaitable et un chemin de migration incomplet peuvent coexister.

Les travaux suivants ont renforcé l’idée d’association. La RFC 7556 définit un domaine de fourniture, ou PvD, comme un ensemble cohérent d’informations réseau : préfixes source, résolveurs, suffixes DNS, passerelle et paramètres apparentés. Sa finalité est d’éviter le mélange involontaire de données venues de domaines différents. La RFC 8801 permet ensuite d’annoncer un identifiant PvD fondé sur un nom de domaine et de proposer des informations JSON facultatives. Ni l’identifiant ni le fichier ne prouvent à eux seuls la joignabilité ou la confiance.

Le bon objet de contrôle est donc une tentative de connexion documentée. Son identifiant relie le nom demandé, le PvD de résolution, le résolveur, la réponse et son TTL, la destination retenue, les sources candidates, la source choisie, la version de politique, les routeurs candidats, le premier saut, les préfixes annoncés, l’état voisin, la décision de filtrage et le résultat distant. Des horodatages monotones empêchent un ajustement d’horloge de briser l’ordre.

Chaque colonne garde son sens propre. Une adresse configurée n’est pas forcément sélectionnée. Une source choisie n’est pas forcément acceptée en amont. Une annonce de routeur ne démontre pas que ce routeur a transféré le paquet. Une réponse DNS ne démontre pas l’accès au service. Même un échange réussi n’atteste que ce chemin, à cet instant ; il ne valide pas les solutions de repli inutilisées.

C’est là que la contribution documentée de Trøan reste actuelle. La transparence n’est pas l’absence de politique. C’est la possibilité de voir quelle politique a rassemblé la source, la porte et la carte, qui pouvait la changer, combien de temps elle valait et comment revenir en arrière.

Sources