Résumé

  • ILNP sépare l’identifiant d’un terminal du chemin utilisé pour le joindre, afin qu’un flux puisse suivre l’appareil quand ce chemin change, tout en gardant IPv6 sur le fil et les routeurs inchangés.
  • L’essai TCP de Saleem Bhatti a utilisé quatre interfaces et un cordon de 15 cm ; l’intégration aux distributions BSD et Linux reste le test d’adoption.

Le routeur n’a pas eu droit à une mise à jour. L’ordinateur, lui, en a besoin. C’est la tension au cœur de la démonstration de Saleem Bhatti à RIPE 93 : ILNP peut utiliser l’infrastructure IPv6 existante, mais son comportement nouveau doit être installé dans les systèmes d’extrémité.

Pour l’utilisateur, l’enjeu est qu’un appareil puisse changer de point d’accès sans obliger l’application à traiter une nouvelle identité IP : le flux reste associé au Node Identifier tandis que le Locator suit l’interface active. Cette séparation vise à rendre le changement de chemin transparent pour le flux. La démonstration en donne un test en laboratoire ; le passage dans les distributions BSD et Linux décidera si cette capacité de changer de chemin sort du laboratoire et devient accessible aux utilisateurs.

Lors du hackathon IETF 126, un client dans la salle a envoyé un flux TCP à un serveur du laboratoire de Bhatti, à St Andrews. L’équipe a activé quatre interfaces l’une après l’autre ; leurs préfixes provenaient d’un même /60, par commodité. Bhatti a décrit la diversité des chemins dans la salle comme un cordon de 15 cm entre un routeur et un commutateur. Le test établit le changement dynamique de localisateur sur un banc ; il ne fournit aucune mesure sur des chemins de réseaux indépendants.

ILNP répond à une surcharge de sens : l’adresse IP sert à la fois d’identité pour le nœud et d’indication topologique pour l’acheminement. Le protocole dissocie ces rôles. Le Node Identifier reste lié au flux ; les Locators peuvent être associés aux interfaces actives. Dans l’implémentation IPv6 présentée, chacun occupe 64 bits.

Les routeurs et commutateurs n’ont pas changé. Le système d’extrémité, si : l’équipe a modifié la pile réseau FreeBSD, une partie du traitement transport et getaddrinfo dans libc. Le DNS doit aussi fournir les nouveaux enregistrements ILNP définis par le RFC 6742. Les applications IPv6 existantes peuvent rester non recompilées parce que la bibliothèque système adapte la résolution à leur interface habituelle.

La question posée par Jim Reid pendant le débat était moins théorique : qui voudra intégrer lui-même un correctif au noyau ? Il a plaidé pour une inclusion dans les distributions. Bhatti a répondu qu’il souhaitait voir ILNP utilisé dans BSD et Linux et accueillir d’autres testeurs. La page du projet de l’Université de St Andrews répertorie des binaires FreeBSD 14.3 et un prototype Linux fondé sur le noyau 4.9. Elle n’établit pas qu’une distribution généraliste ait intégré ILNP en amont ; un paquet amont ou un pilote opérateur changerait ce constat.

Le RFC 6740 est un RFC expérimental publié par l’IRTF, sans statut formel dans le processus de normalisation de l’IETF. La prochaine preuve ne viendra donc pas d’un autre cordon sur un banc de test : elle viendra de la maintenance, du diagnostic et de la distribution du logiciel côté hôte.

Sources : transcription de la session RIPE 93 ; détails de l’intervention ; RFC 6740 ; RFC 6741, considérations d’ingénierie ; RFC 6742 ; projet ILNP de l’Université de St Andrews.