Par curiosité, bricolons un peu avec ces préfixes secondaires, en travaillant sur une architecture déjà rencontrée:

Le demoserver dispose toujours de deux interfaces configurées en version 6 comme ceci:

auto enp1s0 enp7s0
...
iface enp1s0 inet6 auto
iface enp7s0 inet6 static
  address 2a01:e0a:875:b1d2::1/64

L'interface enp1s0, reliée au routeur est pour l'instant toujours configurée en mode automatique (stateless). De l'autre côté du routeur, enp7s0 est ici configurée manuellement pour son adresse de lien global. En effet, Si l'on souhaite installer sur ce serveur un cache DNS, un serveur DHCP (IPv4 ou même IPv6), ces services nécessitent que leur adresse soit publiée aux clients via NDP, c'est-à-dire documentée dans la configuration du démon radvd.

Comme pour IPv4, il faut activer le routage en décommentant la ligne

net.ipv6.conf.all.forwarding=1

puis en forçant la relecture du fichier:

sysctl -p

Avec GNU/Linux, il existe plusieurs solutions pour réaliser un résolveur DNS. Pour créer un démon qui soit interrogeable par les nœuds du (sous)réseau, il y a dnsmasq ou bind9. dnsmasq est léger et cumule les fonctions de serveur DNS et DHCP, mais ne sait pas résoudre nativement les noms, il fait appel à au moins un serveur DNS récursif extérieur. Nous allons préférer bind9 qui est un vrai serveur DNS entièrement autonome, d'autant que l'étude de DNS plus loin sur ce site inclut son installation et sa configuration détaillées.

Pour l'instant, effectuons une installation sommaire selon la recette:

apt install bind9

puis modification du fichier /etc/bind/named.conf.options comme suit:

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        auth-nxdomain no;
        dnssec-validation auto;
        allow-query { any; };
        allow-recursion { any; };
        listen-on-v6 { any; };
        listen-on { any; };
};

et pour finir, relancer le serveur:

systemctl restart bind9

en s'assurant qu'il n'y a pas eu d'erreur avec un

systemctl status bind9

Il serait bien intéressant que ce routeur soit capable de permettre l'auto-configuration aux clients situés dans le second réseau. Il faut installer et configurer le démon radvd:

apt install radvd

Démon d'information de routeur IPv6 a beaucoup plus de capacité pour l'auto-configuration que IPv4. Mais pour que cette auto-configuration fonctionne sur les hôtes d'un réseau, les routeurs du réseau local doivent exécuter un programme qui répond aux requêtes d'auto-configuration émises par les hôtes. Sur Linux, ce programme est appelé radvd, qui signifie « Router ADVertisement Daemon », démon d'information de routeur. Ce démon écoute les sollicitations de routeurs (RS, « router solicitations ») et répond par des informations de routeur (RA, « routeur advertisement »). De plus, des RA non sollicitées sont émises de temps en temps.

Il faut créer un fichier de configuration /etc/radvd.conf qui contiendra ceci:

interface enp7s0
{
   AdvSendAdvert on;
   MaxRtrAdvInterval 60;
   prefix 2a01:e0a:875:b1d2::/64
   {
      AdvAutonomous on;
   };
   RDNSS 2a01:e0a:875:b1d2::1 fd0f:ee:b0::1
   {
      AdvRDNSSLifetime 120;
   };
};

N'oublions pas de relancer le démon:

systemctl restart radvd

Le routeur deverait annoncer le préfixe du (sous)réseau ainsi que l'adresse du résolveur DNS que nous venons d'installer. L'adresse suivante étant une «adresse locale unique» qui n'est autre que celle de la Freebox.

Sur democlient1 qui vient justement de démarrer:

 
 ip -6 addr ls enp1s0

2: enp1s0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet6 2a01:e0a:875:b1d2:5054:ff:feb7:6681/64 scope global dynamic mngtmpaddr 
       valid_lft 86380sec preferred_lft 14380sec
    inet6 fe80::5054:ff:feb7:6681/64 scope link 
       valid_lft forever preferred_lft forever

L'adresse globale est correctement configurée «sytateless», c'est que l'hôte a bien reçu le préfixe correspondant.

 
ip -6 route ls

2a01:e0a:875:b1d2::/64 dev enp1s0 proto kernel metric 256 expires 86385sec pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default via fe80::5054:ff:fe78:2d7e dev enp1s0 proto ra metric 1024 expires 165sec hoplimit 64 pref medium

La route par défaut passe par le lien local de notre serveur.

Vérifions la résolution des noms:

 
host -v www.debian.org

...
;; QUESTION SECTION:
;www.debian.org.			IN	A

;; ANSWER SECTION:
www.debian.org.		300	IN	A	194.177.211.216
www.debian.org.		300	IN	A	130.89.148.77

Received 64 bytes from 2a01:e0a:875:b1d2::1#53 in 251 ms
...
;; QUESTION SECTION:
;www.debian.org.			IN	AAAA

;; ANSWER SECTION:
www.debian.org.		300	IN	AAAA	2001:648:2ffc:deb:216:61ff:fe2b:6138
www.debian.org.		300	IN	AAAA	2001:67c:2564:a119::77

Received 88 bytes from 2a01:e0a:875:b1d2::1#53 in 31 ms
...

C'est bien notre résolveur DNS qui a répondu.

Test ultime:

tcptraceroute6 -n www.debian.org

traceroute vers www.debian.org (2001:67c:2564:a119::77) de 2a01:e0a:875:b1d2:5054:ff:feb7:6681, port 80, du port 64316, 30 sauts max, 60 octets/paquet
 1  2a01:e0a:875:b1d2::1  0.519 ms  0.427 ms  0.396 ms
 2  2a01:e0a:875:b1d0::1  1.021 ms  0.907 ms  0.350 ms
 3  2a01:e02:1004:f836:aac1::ffff  4.380 ms  2.674 ms  2.652 ms 
 4  2a01:e02:1004:1700::ffff  2.807 ms  2.308 ms  2.657 ms 
 5  2a01:e02:1003::1  2.813 ms  2.844 ms  2.445 ms 
 6  2a01:e02:1001::2  3.071 ms  * *
 7  * 2a01:e02:600b::2  16.218 ms  16.229 ms 
 8  2a01:e00:6006::5  15.433 ms  * 16.297 ms 
 9  2a02:10:1:2::5  15.894 ms  16.136 ms  23.625 ms 
10  2a02:10:1:1::7  25.079 ms  24.391 ms  24.750 ms 
11  2a02:10:0:1::190:10  32.385 ms  32.730 ms  46.167 ms 
12  2001:610:e00:2::2a  30.427 ms  30.465 ms  30.189 ms 
13  2001:610:fc7:0:145:145:0:78  30.663 ms  30.332 ms  30.832 ms 
14  2001:610:f00:4044::46  30.657 ms  30.203 ms  30.257 ms 
15  2001:67c:2564:aa13::193  31.421 ms  30.972 ms  30.883 ms 
16  2001:67c:2564:aa21::253  31.617 ms  30.199 ms  30.594 ms 
17  2001:67c:2564:a119::77  29.952 ms [ouvert]  29.774 ms  29.500 ms 

1. Le hop 1, c'est bien notre demoserver
2. le hop 2, c'est la Freebox.

Le reste nous intéresse moins ici.

Et bien entendu, dans l'autre sens, depuis irp.nain-t.net:

traceroute -6 -N1 -q1 2a01:e0a:875:b1d2:5054:ff:feb7:6681

traceroute to 2a01:e0a:875:b1d2:5054:ff:feb7:6681 (2a01:e0a:875:b1d2:5054:ff:feb7:6681), 30 hops max, 80 byte packets
...
22  2a01:e0a:875:b1d0:5054:ff:fe74:45f2 (2a01:e0a:875:b1d0:5054:ff:fe74:45f2)  19.060 ms
23  2a01:e0a:875:b1d2:5054:ff:feb7:6681 (2a01:e0a:875:b1d2:5054:ff:feb7:6681)  20.656 ms

Seuls les deux derniers hops nous intéressent:

1. le hop 22, c'est notre demoserver vu du côté Freebox,
2. le hop 23, c'est notre democlient1, ce qui prouve encore une fois que les adresses de lien global sont bien joignables depuis l'extérieur.

L'avantage ici, c'est que nous pourrions installer un pare-feu sur demoserver pour protéger l'ensemble du préfixe 2a01:e0a:875:b1d2::/64.