Résumé

  • Dans un réseau à plusieurs préfixes IPv6, une connexion peut échouer malgré une adresse valide : l’appareil peut choisir une adresse source que le chemin disponible ne transporte pas. Les RFC coécrites par Fujisaki étudient ce choix au niveau de l’hôte.
  • À l’APNIC, la suppression d’un critère d’agrégation pour l’allocation initiale a été mise en œuvre ; plusieurs propositions ultérieures d’élargissement n’ont pas obtenu de consensus.
  • Ces archives attestent des mécanismes et des décisions, sans mesurer le déploiement de la RFC 7078 ni l’effet opérationnel des règles d’allocation.

Une adresse valide ne convient pas nécessairement au chemin

Une connexion peut échouer alors que l’application fonctionne et que l’appareil possède bien une adresse IPv6. Le problème peut venir de l’adresse source choisie par l’hôte : le réseau peut la filtrer, ou la réponse peut ne pas retrouver son chemin. La RFC 5220 décrit cette catégorie de décalages, notamment le filtrage d’entrée, un trajet asymétrique ou l’absence de route de retour. Le symptôme apparaît dans l’application, mais sa cause peut se situer dans la façon dont l’hôte et le réseau du site combinent leurs règles.

Publiée en juillet 2008, la RFC 5220 est un mémo informatif cosigné par Arifumi Matsumoto, Tomohiro Fujisaki, R. Hiromi et K. Kanayama. Elle décrit une catégorie de problèmes, pas un incident précis ni sa fréquence. Son périmètre privilégie les réseaux d’entreprise et les hôtes que l’on ne peut pas configurer individuellement. Pour un parc important, confier à chaque utilisateur l’entretien d’une table complexe n’est pas une solution générale.

La RFC 5221, des mêmes auteurs et publiée le même mois, transforme ces cas en exigences. L’information doit parvenir avant la sélection et pouvoir évoluer avec le réseau ; le mécanisme doit tenir compte des nœuds, des applications et des interfaces. Administration centrale, compatibilité avec l’algorithme existant et sécurité comptent aussi. Le texte formule des besoins, sans prétendre qu’ils sont tous satisfaits.

Distribuer une préférence sans commander le terminal

En 2014, la RFC 7078, écrite par Arifumi Matsumoto, Fujisaki et Tim Chown, a défini une option DHCPv6 pour le choix d’adresses. Un site peut diffuser une table et des paramètres qui modifient les valeurs par défaut de la RFC 6724. Le parcours documentaire passe ainsi du problème aux exigences, puis à un mécanisme normalisé.

Le serveur ne devient pas le contrôleur absolu de chaque appareil. La RFC décrit une information traitée par le nœud et reconnaît la configuration locale. Le réseau exprime une préférence ; l’implémentation et les réglages du terminal influencent encore le résultat.

La spécification décrit des risques concrets : un serveur DHCPv6 malveillant pourrait envoyer une politique trompeuse et pousser des clients vers une adresse filtrée, des coûts inattendus ou un chemin dangereux. Elle traite de canaux de confiance et cite l’inspection DHCP de couche 2 parmi les mesures possibles. Une table volumineuse peut aussi produire des messages difficiles à acheminer par certains clients, serveurs ou relais. L’existence du standard ne prouve pas sa prise en charge par les équipements installés.

L’allocation relève d’une autre décision

Les propositions de Fujisaki à l’APNIC portent sur l’espace disponible pour un plan d’adressage, non sur le choix d’un hôte. La prop-076, cosignée, voulait imposer l’agrégation de certaines allocations ultérieures ; elle a été retirée après discussion. La prop-082, également collective, proposait de supprimer le critère d’agrégation pour l’allocation IPv6 initiale. L’APNIC indique qu’elle a obtenu un consensus à APNIC 29, été approuvée par son conseil et mise en œuvre le 5 juillet 2010. Cela établit une modification de règle, pas son effet mesuré sur les réseaux.

Fujisaki a présenté la prop-087, qui visait une allocation initiale supérieure à /32 pour certaines étapes de déploiement décrites par RFC. Elle n’a pas obtenu de consensus et son auteur l’a retirée en août 2011. En 2014, la prop-111 a proposé une extension jusqu’à /29, sans consensus à APNIC 37 ni à APNIC 38. La prop-112, déposée en 2015 pour une autre voie d’extension aux titulaires d’anciens blocs IPv6, a également été abandonnée sans consensus.

Le bilan est nuancé : une règle d’allocation initiale a changé ; plusieurs propositions ultérieures d’élargissement n’ont pas abouti. Les archives ne prouvent ni que les propositions non adoptées étaient impossibles, ni que tous les opérateurs avaient besoin de blocs plus grands. Elles ne permettent pas non plus d’attribuer un motif commun aux opposants.

La page de candidature de l’APNIC au Number Council du NRO décrit Fujisaki comme ingénieur de recherche senior chez NTT, mentionne des travaux IPv6 depuis 1997 et répertorie des fonctions au Japon. Ces informations doivent être attribuées à cette candidature, non présentées comme une évaluation indépendante. Les procès-verbaux de l’APNIC consignent séparément sa nomination unanime au Number Council pour 2011.

Deux niveaux, deux types de preuve

La politique d’allocation influence le plan qu’un opérateur peut bâtir. La politique de sélection détermine laquelle des adresses configurées l’hôte emploie. Les sources ne montrent pas qu’un bloc plus grand corrige un mauvais choix d’adresse source, ni qu’une table DHCPv6 compense un plan inadapté.

Les RFC 5220 et 5221 comptent quatre auteurs chacune ; la RFC 7078 en compte trois. Les archives de l’APNIC distinguent les propositions écrites par Fujisaki seul de celles qu’il a cosignées. Cette précision permet de suivre son rôle sans lui attribuer seul une norme collective ou une décision institutionnelle.

La conclusion étayée reste circonscrite : un problème de sélection a été décrit, converti en exigences, puis associé à un mécanisme standardisé ; dans l’allocation, une modification a été mise en œuvre tandis que d’autres propositions échouaient au consensus. Les sources ne donnent ni taux d’adoption de la RFC 7078, ni résultats de performance, ni mesure de l’effet de la prop-082. Ces questions demandent des données d’exploitation.