Mon blog

L'ancien modèle d'IP prévoyait seulement une adresse IP par interface réseau donc, pour la plupart des machines, une seule adresse IP tout court. Le choix de l'adresse IP à utiliser lorsque cette machine initiait une communication avec une autre machine était donc trivial. Mais ce modèle a changé, notamment avec l'arrivée d'IPv6, où la multiplicité des adresses devient la règle. Quelles adresses source et destination utiliser, dans ces conditions ? Le RFC 3484 exposait un mécanisme, qui a prouvé quelques limitations, menant à la conception d'un système amélioré dont notre RFC 5221 est le cahier des charges et le RFC 6724 la réalisation.

Le système du RFC 3484 a été mis en œuvre dans plusieurs systèmes d'exploitations. Par exemple, ceux utilisant la GNU libc disposent de la méthode de ce RFC et, en prime, ont /etc/gai.conf à leur disposition pour configurer manuellement le choix des adresses. Mais ce mécanisme n'est pas parfait et le RFC 5220 décrit les problèmes qu'il pose.

Le nouveau mécanisme va tenter de traiter ces problèmes, tout en gardant la possibilité d'un mécanisme totalement automatique (section 1).

La section 2 liste les onze exigences du nouveau système (je ne les cite pas toutes ci-dessous). Par exemple, 2.2 pose comme principe qu'il ne doit pas rendre la machine plus pénible à utiliser : le processus de sélection ne doit pas être long et il ne doit pas imposer une action manuelle. 2.5 exige que le mécanisme puisse être spécifique à chaque application, permettant à Firefox d'utiliser des règles différentes de celles de Thunderbird (via par exemple une API qui reste à définir). 2.7 insiste sur la nécessité pour l'administrateur système de pouvoir contrôler ce mécanisme, depuis un point central (comme /etc/gai.conf sur Debian ou Gentoo).

La sélection d'adresses IP source et destination a évidemment un impact sur la sélection du premier routeur à utiliser et ce point faisait l'objet du RFC 4191, et désormais de la section 2.8 de notre RFC.

Comme il n'est pas question de réécrire toutes les applications, le mécanisme envisagé doit évidemment être compatible avec l'API socket du RFC 3493 (section 2.9). Et, toujours sur la question de compatibilité, ce mécanisme doit marcher avec celui du RFC 3484.