Stéphane Bortzmeyer

Merci pour cette note - je ne connaissais pas /etc/gai.conf. Je sens que ça va être drôle de débugger les interactions entre /etc/gai.conf et la table de routage...

Plusieurs choses me semblent contestables dans ce RFC :-)

D’abord le choix des adresses locales avant les adresses globales ne me semble pas optimal pour plusieurs raisons :
– tout d’abord qu’est ce qui assure que les adresses soient vraiment locales ? Si des adresses fe80: :/10 se retrouvent annoncées par le DNS ou tout autre moyen de configuration, est-on sûr que ce soit vraiment sûr le même réseau ? Et si j’ai plusieurs interfaces, j’ai plusieurs fe80: :/64, je choisis comment la source ?? J’ai loupé quelque chose ?
– Je suis administrateur système, est-ce que je tiens vraiment à avoir dans mes logs des adresses LL de serveur plutôt que mes adresses globales ou de site qu’évidemment je configure statiquement et avec un reverse DNS ? Ces adresses sont susceptibles de changer avec le hardware, ne parlons même pas de la virtualisation.

Ensuite l’argument du monsieur qui a eu un problème me semble toujours valide, croire que deux adresses IP « plus proches » vont bien marcher ensemble c’est bien un truc de l’IETF ça ... Evidemment dans l’exemple il y a un /48 et un /32, c’est simple on est probablement chez le même FAI. Bref il aurait mieux valu écrire dans le RFC que la meilleure solution est de tirer au sort ...

Drôle de RFC aussi ou l’on parle de sélection de la source avant celle de la destination, dont elle dépend fortement.

[Un avertissement, d’abord, je n’ai suivi que de loin le développement de ce RFC donc je ne peux pas parler pour ses auteurs, qui ont peut-être d’autres justifications pour leurs choix.]

« Qu’est ce qui assure que les adresses soient vraiment locales ? Si des adresses fe80 : :/10 se retrouvent annoncées par le DNS ou tout autre moyen de configuration, est-on sûr que ce soit vraiment sur le même réseau ? »

Un bon routeur IPv6 ne doit jamais router des paquets ayant une adresse source ou destination locale au lien, fe80 : :/10 (RFC 4291, section 2.5.6). Cela garantit normalement, si on voit un tel paquet, qu’il est bien local et si on l’envoie, qu’il ne sortira pas.

« Et si j’ai plusieurs interfaces, j’ai plusieurs fe80 : :/64, je choisis comment la source ? »

Les adresses locales au lien doivent être accompagnées de l’indication de l’interface. Publier fe80::1 dans le DNS ne donnerait rien.

[Attention, SeenThis ne permet hélas pas de mettre du code, avec indentation respectée.]

% ping6 fe80::21a:a0ff:feac:4a0c
connect : Invalid argument

% ping6 fe80::21a:a0ff:feac:4a0c%eth1
PING fe80::21a:a0ff:feac:4a0c%eth1(fe80::21a:a0ff:feac:4a0c) 56 data bytes
64 bytes from fe80::21a:a0ff:feac:4a0c : icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from fe80::21a:a0ff:feac:4a0c : icmp_seq=2 ttl=64 time=0.025 ms
...

« Je suis administrateur système, est-ce que je tiens vraiment à avoir dans mes logs des adresses LL de serveur plutôt que mes adresses globales »

Là, c’est simple : si l’admin’ ne veut pas avoir des adresses locales au lien dans ses journaux, il lui suffit de ne pas se connecter avec de telles adresses. Lorsqu’Alice se connecte à Bob, Alice trouve une liste d’adresses de destination possibles pour Bob (elle la trouve typiquement dans le DNS ou bien dans sa configuration statique). Si Bob ne veut pas voir d’adresses locales au lien dans ses journaux, il ne publie pas d’adresses locales au lien dans le DNS. S’il ne veut pas qu’Alice se connecte quand même par configuration manuelle, il configure son démon pour ne pas écouter sur les adresses locales au lien.

« croire que deux adresses IP « plus proches » vont bien marcher ensemble c’est bien un truc de l’IETF ça »

C’est un reproche qu’on pouvait faire au RFC 3484. Dans le nouveau RFC, c’est moins vrai.

Bonjour,

Au sujet du DNS, j’aurais tendance à dire que c’est à ce moment qu’intervient le split-horizon DNS. On aura peut être tendance à publier les adresses site-local dans le DNS de l’entreprise pour s’assurer qu’en cas de changement du préfixe IPv6 de l’entreprise, seuls les clients distants seront impactés, ou alors pour éviter de faire passer les requêtes locales par le frontal de l’entreprise.
De la même manière les adresses link-local peuvent avoir été transmises par un split-horizon DNS ou bien par du MDNS. Mais dans tous les cas, quelque soit la préférence donnée à telle ou telle adresse lors de la sélection des adresses source et destination, un PC situé dans un réseau correctement administré n’est pas sensé recevoir dans sa réponse DNS d’adresses sur lesquelles il ne peut joindre le serveur. C’est à l’administrateur de s’assurer de cela, en utilisant par exemple la technique précédemment cité.

A propos des adresses link-local, la question à se poser est aussi quel serait l’intérêt de publier ces adresses dans un DNS. Je ne sais pas trop. Par contre, par MDNS cela peut avoir un sens.

Cordialement.

Emmanuel Thierry