ULA signifie Unique Local Adresses, soit en français, adresses locales uniques. Ces adresses reprennent une partie du concept des adresses privées ipv4 (10.0.0.0/8 et 192.168.0.0/16). Elles sont sur le préfixe fd00::/8 et ne sont pas routées sur internet.

Quel est l’intérêt de ces adresses ?

Des adresses constantes

Ces adresses permettent de définir un plan d’adressage interne constant, ce qui s’avère utile si vous avez un réseau avec une topologie particulière, que vos ipv6 sont dynamiques ou que vous changez de FAI fréquemment.

Certains FAI fournissent en effet des préfixes ipv6 dynamiques. C’est à dire que le préfixe change au fil du temps. Ceci signifie que vos adresses globales vont également changer de manière régulière. Vous ne pouvez donc pas compter sur les adresses globales pour faire l’adressage de vos appareils. Et de toute façon, à chaque changement de FAI, faut aussi tout refaire !

Alors que ces adresses locales uniques vous permettent d’avoir des adresses ipv6 permanentes pour toutes vos machines.

Des adresses non-routables

Comme ces adresses ne sont pas routables, cela signifie aussi qu’elles sont à priori à l’abri de toute forme de communication/attaque depuis internet. Par exemple, l’imprimante et le résolveur DNS ont tout intérêt à avoir ce type d’adresses.

Elles sont de plus assez haut dans la table de routage normalement. Ce qui signifie qu’elles seront utilisées en priorité, avant les adresses globales.

Pour un peu plus de concret, vous pouvez penser que ces adresses vous permettent de faire votre routage à votre sauce.

exemple

[stephane@jabberwocky content]$ ip -6 route
fd00:2016:22:dec::/64 dev eno1 proto kernel metric 256  expires 3455sec pref medium
2001:470:28:2d4::/64 dev eno1 proto kernel metric 256  expires 3455sec pref medium
fe80::/64 dev eno1 proto kernel metric 256  pref medium
default via fe80::20d:b9ff:fe3e:a812 dev eno1 proto ra metric 1024  expires 2255sec hoplimit 255 pref medium

Si une machine se trouve dans mon réseau local, elle devrait avoir une ipv4 privée, une ipv6 privée (fd00:2016:22:dec::) et une ipv6 globale (2001:470:28:2d4::). Et lors d’un appel DNS local, c’est l’ipv6 privée qui sera utilisée en premier.

De l’intérêt de contrôler le routeur

Tout ça c’est bien beau mais ce n’est possible que si vous contrôlez le routeur. En effet, si, comme la majorité des clients ADSL, vous changez de box à chaque changement de FAI, ça signifie aussi que vous devez refaire à chaque fois un plan d’adressage (si vous en faîtes un…). Ce qui fait aussitôt disparaître l’avantage number one de ces adresses.

NB: Vous devrez aussi redéfinir à chaque fois des mots de passe, la clé wifi, et la redirection de ports en ipv4, mais cela sort de l’article.

Au contraire, j’ai construit mon propre routeur, ce qui me donne la possibilité de contrôler comment et à qui je donne des adresses. À titre d’exemple, mon téléphone portable, dans le réseau local, n’a plus d’ipv4. Il est en ipv6-only. J’ai tout simplement interdit la distribution d’une ip(v4) à son identifiant/adresse MAC.

À quoi ressemblent ces adresses ?

Ces adresses sont dans le préfixe fd00::/8.

Comme ces adresses ne sont pas publiques, vous pouvez les choisir un peu comme vous voulez. J’ai donc décidé pour ma part de les faire en fd00:2016:22:dec::/64. Ce qui donne une date si vous lisez bien. J’aurais pu mettre ma date de naissance remarquez. Je n’y ai pas pensé.

C’est donc un avantage supplémentaire à ces adresses: vous pouvez les assigner de telle sorte que vous vous en rappeliez facilement (date ou mots simples et courts). Et ça, ça n’a pas de prix dans le monde ipv6.

Pour ceux qui veulent faire compliqué, il existe des générateurs de préfixes. On peut également les faire à peu près à la taille qu’on veut (on peut prendre la place qu’on veut dans fd00::/8, c’est énorme. On pourrait découper à la hache des réseaux en ::/10 ou autre comme on voudrait). La plupart des utilisateurs voudront des réseaux en ::/48 ou ::/64.

Comment distribuer ces adresses ?

Simple: assignez une adresse ULA à l’interface interne de votre routeur, et les messages de diffusion du routeur feront le reste.

Les machines s’attribueront une adresse statique en SLAAC, puis les autres adresses (adresses dynamiques temporaires, etc).

Vous pouvez aussi les activer en configuration statique.

Un exemple

Unbound a beau tourner sur une machine qui fait aussi serveur web, serveur de courrier et autres services «publics», je n’ai aucun intérêt à ce qu’il écoute sur une adresse publique. J’ai au contraire tout intérêt à ce que son adresse ne soit pas routable (question de sécurité, de «on va pas exposer des services au monde entier quand on a pas besoin et qu’ils pourraient causer par mégarde un DDoS…») et constante (comme ça, pas besoin de changer sa conf lorsque je change de FAI, ni celle d’autres logiciels avec qui il discute).

J’ai donc Unbound qui écoute sur fd00:2016:22:dec::3 et ::1 quand NSD, serveur autoritaire pour mes domaines, écoute lui sur 2001:470:28:2d4::2, adresse publique. Les deux démons sont sur la même machine. Et tout va bien puisque les adresses écoutées ne sont pas les mêmes.

Unbound ira quand même bien sûr faire ses requêtes externes aux serveurs root et autres via une adresse globale. Mais il n’écoute pas sur cette adresse.

Tout ça c’est super quand on commence à faire des configurations croisées.

Par exemple, j’ai Dnsmasq (sur le routeur) et Unbound (sur le serveur) et ça me plaîs bien qu’ils discutent ensemble. Donc dans unbound.conf sur le serveur :

server:
    # verbosity number, 0 is least verbose. 1 is default.
    verbosity: 0

    interface: ::1
    interface: fd00:2016:22:dec::3
    interface: fe80::be5f:f4ff:fe73:a7e0%re0
    interface: 10.0.0.3
    interface: 127.0.0.1

    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.0.0.0/8 allow

    access-control: ::0/0 refuse
    access-control: ::1/128 allow
    access-control: fe80::/64 allow
    access-control: fd00::/8 allow

forward-zone:
    name: "10.in-addr.arpa."
    forward-addr: fd00:2016:22:dec::
    forward-addr: 10.0.0.1

forward-zone:
    name: "22decembre.eu."
    forward-addr: fd00:2016:22:dec::
    forward-addr: 10.0.0.1

Vous voyez, la configuration de Unbound est presque figée là. J’ai pas besoin de changer les adresses sur lesquelles il écoute, et il renvoie en fait toutes les requêtes vers mes zones sur Dnsmasq, sur le routeur.

À partir de maintenant, la seule chose que j’ai à mettre à jour pour Unbound (en dehors de vérifier les annonces de sécurité système, etc), c’est l’ajout d’une zone en forwarding.

Et justement dans dnsmasq.conf sur le routeur :

server=fd00:2016:22:dec::3

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only.
local=/22decembre.eu/22december.dk/
    
domain=22decembre.eu

dhcp-option=option6:dns-server,[::],[fd00:2016:22:dec::3]

Le fichier hosts du routeur (dont se sert Dnsmasq) :

127.0.0.1       localhost
::1             localhost

10.0.0.1        routeur

2001:470:28:2d4::   routeur
fd00:2016:22:dec::  routeur

10.0.0.2                     blackblock
2001:470:28:2d4::22:dec      blackblock
fd00:2016:22:dec::2          blackblock

fd00:2016:22:dec::3  unbound
10.0.0.3             unbound

Et voila, toute cette partie de la configuration système du serveur et du routeur restera pour ainsi dire constante, sauf évolution majeure ou nécessité impérieuse.

Les machines clientes du réseau local reçoivent donc toutes une ipv6 locale ula, et une ipv6 globale. Et tout le trafic DNS local passera par les adresses locales d’Unbound et Dnsmasq.

De même, l’adresse de la passerelle par défaut du serveur, indiquée dans mygate.conf, est représentée par l’adresse ula du routeur. Cette partie, je suis pas sûr que ça passe tout le temps sur tous les systèmes. Mais OpenBSD est visiblement assez intelligent pour comprendre la multiplicité d’adresses d’une machine.

Lorsque j’aurais de la connectivité ipv6 native, d’ici une semaine, toutes mes ip publiques (ip du serveur par exemple, mais aussi ip des ordinateurs à l’intérieur du réseau) changeront. Mais par contre, toute cette partie, qui n’est pas publique, n’aura pas besoin d’être changée. Et c’est tout autant de temps de gagné, d’énervement en moins.

Bonus

Vous avez remarqué aussi ? Unbound a aussi un nom d’hôte.

Ce qui fait que je peux faire ça :

dig @unbound blackblock.22decembre.eu

J’obtiendrais alors l’adresse de blackblock telle que mon réseau local la voit (Unbound renverra la requête sur Dnsmasq, puisqu’il s’agit d’une requête sur une zone forwardée).

dig @blackblock blackblock.22decembre.eu

J’obtiendrais alors l’adresse publique de blackblock, telle qu’elle est renvoyée par NSD.

Et ça, pour faire les débuggages DNS, c’est le pied !

PS: Si l’article vous a plu ou vous semble utile, ou si vous m’aimez bien, tout simplement, alors n’hésitez pas à tiper ou donner via liberapay.