Mon blog

Ce très court RFC normalise la façon d'indiquer la zone quand il faut écrire une adresse IPv6 locale. Il remplace le RFC 6874, et est très différent, notamment parce qu'il ne s'applique plus aux URI.

Les zones sont définies et expliquées dans le RFC 4007. En gros, une adresse IPv6 n'est pas forcément globale, elle peut avoir une signification limitée à une seule zone, une zone étant un ensemble de sous-réseaux contigus, souvent composé d'un seul lien Ethernet. Les adresses locales au lien, par exemple, celles qui sont dans le préfixe fe80::/10, sont dans ce cas, le lien qui les relie forme une zone. Une zone n'a de signification que locale, elle n'a pas de sens sur l'Internet public. Comment préciser la zone dans une interface qui accepte les adresses IPv6 ? La syntaxe de celles-ci est normalisée dans le RFC 4291 et le RFC 5952 mais ne prévoit rien pour la zone. C'est surtout ennuyeux pour les réseaux purement IPv6 (RFC 8925) ou essentiellement IPv6 (draft-ietf-v6ops-6mops). Notre RFC impose donc (section 5) que toute interface qui permet d'indiquer des adresses IP permette également d'indiquer la zone.

Indiquer la zone est utile pour les applications de déboguage (cf. l'exemple avec ping plus loin) ou pour configurer une machine (« ton serveur pour le service XXX est à l'adresse YYY »).

Pour indiquer cette zone, ce RFC normalise l'utilisation d'un %, puis l'identificateur de la zone, après l'adresse. La convention du % est décrite en section 11 du RFC 4007. Si l'interface utilisée pour entrer des adresses IP a un problème spécifique avec le %, le RFC autorise à utiliser le tiret à la place. Et si même cela est impossible, le RFC recommande deux champs, un pour l'adresse seule et un pour la zone. Ici, sur une machine Linux, avec le % :

% ping -c 3 fe80::f437:ded0:7b2:1241%enp1s0 
PING fe80::f437:ded0:7b2:1241%enp1s0 (fe80::f437:ded0:7b2:1241%enp1s0) 56 data bytes
64 bytes from fe80::f437:ded0:7b2:1241%enp1s0: icmp_seq=1 ttl=64 time=68.0 ms
64 bytes from fe80::f437:ded0:7b2:1241%enp1s0: icmp_seq=2 ttl=64 time=13.2 ms
64 bytes from fe80::f437:ded0:7b2:1241%enp1s0: icmp_seq=3 ttl=64 time=15.6 ms

--- fe80::f437:ded0:7b2:1241%enp1s0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.175/32.268/68.015/25.296 ms

On teste la machine fe80::f437:ded0:7b2:1241 reliée au réseau identifié par enp1s0 (dans le cas de Linux, c'est le nom d'une interface réseau mais d'autres systèmes d'exploitation peuvent utiliser une syntaxe différente, par exemple identifier les zones par un simple numéro comme le fait Microsoft Windows). Cette possibilité de désigner une zone spécifique est essentielle pour les activités de déboguage.

Notez que ce n'est pas ping qui a reconnu et traité l'indication de la zone mais le sous-programme getaddrinfo (RFC 3493). Autrement, on aurait pu utiliser un bricolage pour se connecter à une adresse lien local via une bibliothèque LD_PRELOAD, où l'application n'a pas besoin de connaitre cette syntaxe. Notez que la fonction inet_pton ne va pas accepter les adresses avec indication de zone, il faut utiliser getaddrinfo ou bien, séparement, inet_pton et if_nametoindex.

Autre exemples d'utilisation, comme indiqué plus haut, la configuration d'un équipement, par exemple pour lui indiquer « ton résolveur DNS est fe80::f437:ded0:7b2:1241%enp1s0 ». Ou bien les filtres utilisés pour ne capturer que le trafic d'une machine. Mais tcpdump (ou Wireshark) ne reconnaissent pas actuellement cette syntaxe :

 % tcpdump -n host fe80::f437:ded0:7b2:1241%enp1s0
tcpdump: can't parse filter expression: syntax error
  

(Pour tcpdump, il faudrait faire tcpdump -n -i enp1s0 host fe80::f437:ded0:7b2:1241.)

Plus pittoresque, le système OneNet Marine IPv6 Ethernet Networking Standard de la NMEA utilise uniquement des adresses locales au lien et doit donc absolument utiliser un mécanisme permettant d'indiquer la zone.

Le RFC ne liste pas les différences avec son prédécesseur RFC 6874 car elle sont trop nombreuses. Le principal changement est certainement l'abandon d'une standardisation des zones dans les URI, qui n'avait jamais vraiment marché (cf. draft-schinazi-httpbis-link-local-uri-bcp).