Mon blog

Lorsqu'un système connecté à Internet a plusieurs adresses IP, la question de savoir laquelle utiliser comme source se pose. Si ce système dispose d'adresses IP de familles différentes, par exemple IPv4 et IPv6, la question de la sélection de l'adresse de destination peut également survenir. Le RFC 3484 décrivait un mécanisme pour cette sélection, mais qui a posé des problèmes en pratique, problèmes que décrit notre RFC.

Le RFC 3484 est par exemple mis en œuvre dans le système GAI (à noter que ce système est très peu documenté) de la GNU libc (utilisée dans des systèmes comme Gentoo ou Debian). Ce système se configure via le fichier /etc/gai.conf et permet d'avoir des politiques comme « Privilégier systématiquement les adresses IPv6 » ou bien « Préferer IPv4 sauf pour tels préfixes ». C'est l'expérience avec des systèmes analogues (sur FreeBSD, c'est /etc/ip6addrctl.conf, cf. la documentation ; Solaris a un mécanisme proche) qui a donné naissance au travail actuel sur le successeur du RFC 3484, travail dont notre RFC 5220 décrit les motivations et dont le RFC 5221 donne le cahier des charges pour le prochain mécanisme. Le successeur a finalement été le RFC 6724, en septembre 2012.

La section 2 forme l'essentiel de notre RFC, en listant successivement plusieurs cas concrets et les solutions - ou l'absence de solution - que leur apporte le RFC 3484. La section 2.1.1, par exemple, analyse le cas où il y a deux routeurs sur le même lien. La sélection du premier routeur à utiliser ne dépendant typiquement pas de l'adresse IP source, un site connecté à deux FAI va avoir des problèmes puisque les paquets pourront être envoyés au « mauvais » routeur, celui connecté à un autre FAI que celui qui a attribué l'adresse source choisie (le cas de la section 2.1.2 est similaire et montre un FAI qui met en œuvre le RFC 2317, éliminant ainsi les paquets IP malchanceux).

La section 2.1.3 décrit par contre un cas qui peut être résolu par le RFC 3484, contrairement aux deux précédents. La machine y est connectée à l'Internet via un FAI et à un réseau privé, utilisant par exemple des adresses IP locales (RFC 4193). Dans ce cas, il suffit de donner la priorité aux adresses globales. Si le préfixe global est 2001:db8:1000::/48 et que le préfixe du réseau privé est 2001:db8:8000::/48, les règles suivantes dans gai.conf donneront le résultat attendu :

# Tout l'Internet
precedence  ::/0          40
# Le réseau privé, à n'utiliser que si le destinataire est dans ce réseau privé,
# grâce à la règle "longest matching rule" du RFC 3484, section 5,
# règle 8. On lui met une précédence plus faible.
precedence 2001:db8:8000::/48    20

La section 2.1.4 décrit un cas similaire.

La section 2.1.5 décrit le cas où le site change son préfixe (cf. RFC 4192) et où les machines doivent, pendant la transition, utiliser la bonne adresse source. Ce problème se résout également dans le cadre du RFC 3484. Mais il faut noter que, le RFC en question ne spécifiant pas de mécanisme d'auto-configuration, cela nécessitera d'aller éditer le gai.conf (ou équivalent) sur toutes les machines du site, ce qui rendra le renumérotage très pénible !

La section 2.1.7 étudie le cas des adresses « vie privée » du RFC 4941. Ces adresses ayant des propriétés spécifiques, il serait préférable de choisir ou non leur utilisation par service et pas globalement et le RFC 3484 ne permet pas cela (le RFC 5014 fournit une solution possible).

La section 2.2 couvre le cas de la sélection de l'adresse destination. Par exemple, 2.2.1 étudie le cas très courant où un site est connecté nativement en IPv4 mais, compte tenu du manque de FAI IPv6, utilise un tunnel lent et peu fiable pour se connecter en IPv6. La table par défaut du RFC 3484, section 2.1, prioritise IPv6, ce qui n'est pas une bonne idée dans ce cas. Il est donc préférable de pouvoir choisir IPv4, ce qui se fait par exemple avec la ligne suivante dans /etc/gai.conf :

# Always prefer IPv4
precedence ::ffff:0:0/96  100

où ::ffff:0:0 désigne les adresses IPv4 mappées (section 2.5.5.2 du RFC 4291). Ce cas ne nécessite donc pas de modification du RFC 3484. 2.2.2 est un cas similaire où il n'y a pas de connectivité Internet IPv6 du tout mais où le réseau local offre IPv6.