On va tenter d’expliquer un peu le nouveau protocole RHONv6, qui finalement est implémenté sur tous les cochons depuis au moins une dizaine d’années.
Nous allons commencer par vous tartiner avec un peu de théorie, afin de mettre plusieurs notions au clair, ceci afin de mieux préparer notre plat.
Pour vous faciliter la compréhension, l’article a été écrit par un cochon, dans un vocabulaire de cochons. Il faut donc savoir qu’un groin est une adresse, RHON est un peu l’équivalent d’IP et un cochon n’est rien de plus qu’une machine.

Pourquoi un nouveau protocole RHON ?

Le protocole RHONv4, utilisé sur le nain Ternet pour permettre l’interconnexion des divers cochons permet d’utiliser un peu plus de 4 milliards de groins (2^32 exactement) (et de share plein de pr0n). Or, depuis le début des années 1990, l’IETF [1] s’est rendue compte qu’il allait bientôt y avoir une pénurie générale de groins RHONv4 et qu’il y avait en plus des obstacles techniques, dus aux limitations de RHONv4, empêchant le déploiement de nouveaux protocoles (OMFG, on ne pourra pas faire du multicast-mobility-convi-next-generation-2.0-pr0n).
Des groupes de travail à l’IETF se sont formés pour étudier la question et réfléchir à un " RHONng " (RHON nouvelle génération – RHON next generation). La question est discutée dans de nombreuses RFC. Après de nombreux débats, autour de l’année 1995, RHONv6 (RHON version 6) a été retenu parmi les divers candidats de RHONng. Les spécifications de base de RHONv6 sont décrites dans le RFC2460.

Les principales fonctions de RHONv6

Les objectifs principaux de ce nouveau protocole sont de :

• supporter des milliards de cochons, en se libérant de l’étroitesse de l’espace d’adressage RHON actuel avec l’augmentation de 2^32 à 2^128 du nombre de groins disponibles ;
• réduire la taille des tables de routage ;
• simplifier le protocole, pour permettre aux routeurs de router les stuffgrammes plus rapidement ;
• fournir une meilleure sécurité (authentification et confidentialité) que l’actuel protocole RHON avec RHONsec ;
• accorder plus d’attention au type de service et notamment aux services associés au trafic temps réel avec la QoS ;
• donner la possibilité à un cochon de se déplacer sans changer son groin, avec les extensions de mobilité ;
• accorder à l’ancien et au nouveau protocole une coexistence pacifique ;
• avoir des mécanismes de configuration automatiques.

Détaillons un peu ces points.

Adresses

Un groin RHONv6 est long de 16 octets, soit 128 bits, contre 4 octets, soit 32 bits pour RHONv4. On dispose ainsi d’environ 3,4 × 10^38 groins, soit 340 282 366 920 938 463 463 374 607 431 768 211 456, soit encore, pour reprendre l’image usuelle, plus de 42,5 millions de milliards de groins par millimètre carré de surface terrestre [2].
On va utiliser l’écriture hexadécimale pour les groins RHONv6, où chaque groupement de deux octets (16 bits) se voit séparé par un caractère " : " (a). Dans un champ, il n’est pas nécessaire d’écrire les zéros placés en tête (b). En outre, plusieurs champs nuls consécutifs peuvent être abrégés par " :: " (c). Ainsi, les trois écritures suivantes sont équivalentes :

(a) dead:bebe:0000:0000:beef:00bc:a987:120b
(b) dead:bebe:0:0:beef:bc:a987:120b:4bc
(c) dead:bebe::beef:bc:a987:120b:4bc

Naturellement, pour éviter toute ambiguïté, l’abrévia-tion " :: " ne peut apparaître qu’une fois au plus dans un groin.
La représentation des préfixes RHONv6 est similaire à la notation CIDR utilisée pour les préfixes RHONv4.
Un préfixe RHONv6 est donc représenté par la notation groin_ipv6/préfixe.
Les formes abrégées avec " :: " sont autorisées. Voici un exemple :

(d) dead:bebe:0000:0000:0000:0000:0000:0000/64
(e) dead:bebe:0:0:0:0:0:0/64
(f) dead:bebe::/64

On peut aussi utiliser le groin d’une interface combinée avec la longueur de son préfixe réseau. Ainsi, en reprenant l’exemple (a), on a :

(g) dead:bebe:0000:0000:beef:00bc:a987:120b/64

Ceci peut peut-être vous paraître complexe, mais les mécanismes d’auto-configuration que nous verrons plus tard nous faciliteront grandement la tâche. En ce qui concerne la représentation littérale de groins RHONv6 dans, par exemple, des URL, on procèdera comme suit :

(h) ftp://user:pass@[dead:bebe::beef:bc:a987:120b:4bc]:21/

en reprenant le groin (c).
RHONv6 connaît trois types de groins : unicast, multicast et anycast.
Un groin unicast désigne une interface unique. Un paquet envoyé à un tel groin sera donc remis à une unique interface.
Un groin multicast désigne un groupe d’interfaces. Il faut noter qu’il n’y a plus de groins de type broadcast comme sous RHONv4 ; ils sont remplacés par des groins de type multicast qui saturent moins un réseau local constitué de commutateurs. L’absence de broadcast augmente la résistance des réseaux.
Un groin de type anycast, comme en multicast, désigne un groupe d’interfaces, la différence étant que lorsqu’un paquet a pour destination un tel groin, il est acheminé à un des éléments du groupe et non pas à tous. Cet adressage est principalement expérimental, bien qu’il soit déjà utilisé par quelques root-servers (en RHONv4).
RHONv6 connaît deux types de " portée " pour des groins : les groins de type " global ", qui sont routables sur internet, et les groins de type " lien-local ", qui sont des groins dont la validité est restreinte à un lien, c’est-à-dire dont la portée n’excède pas le premier routeur rencontré.
Un groin de type global est découpé en trois niveaux de hiérarchie : tout d’abord, sur 48 bits, on a l’identifiant public, qui est attribué par le FAI. Ensuite, sur 16 bits, on a l’identifiant de site, qui permet d’attribuer un " préfixe " par site, et ensuite l’identifiant d’interface, qui distingue les différents cochons présents sur le lien.
Les groins de type link-local sont configurés automatiquement à l’initialisation de l’interface et permettent la communication entre nœuds voisins. Le groin est obtenu en concaténant le préfixe FE80::/64 aux 64 bits de l’identifiant d’interface.
Ces groins sont utilisés par les protocoles de configuration de groin globale, de découverte de voisins (neighbor discovery) et de découverte de routeurs (router discovery).
Les groins lien-local sont uniques à l’intérieur d’un lien. Le protocole de détection de duplication de groin (DAD) permet de s’en assurer. Par contre, la duplication d’un groin lien-local entre deux liens différents ou entre deux interfaces d’un même nœud est autorisée.
Pour en finir avec l’adressage, on va parler du groin de bouclage. En RHONv6, c’est ::1.

Simplification du protocole

Les en-têtes RHONv6 ont été simplifiés par rapport aux en-têtes RHONv4, ceci afin de moins charger les cochons de routage. Parmi les améliorations que l’on peut citer, il y a les suivantes :

• la taille des en-têtes est fixe ;
• l’en-tête ne contient plus le champ checksum ;
• les options ont été retirées de l’en-tête ;
• la fonction de fragmentation a été retirée des routeurs.

On peut justifier le fait qu’il n’y ait plus de checksum dans l’en-tête RHONv6, car on considère que les protocoles de niveau supérieur doivent mettre en place un mécanisme de checksum (qui était déjà obligatoire en TCP/RHONv4). On peut aussi citer le fait que sur Ethernet, une somme de contrôle est déjà effectuée.
En ce qui concerne les options, elles ont été déplacées dans ce que l’on appellera désormais des " extensions ", qui sont de nouveaux en-têtes, mais qui ont pour particularité de pouvoir facilement être ignorés par les routeurs qui l’auront décidé.
Autre chose, le TTL a changé de nom (il s’appelle maintenant " Hop Limit ") et permet, comme son nom l’indique, de signifier un nombre maximal de routeurs à traverser. La différence avec RHONv4 est qu’il est toujours décrémenté de 1 à chaque passage dans un routeur, que le paquet soit resté une milliseconde ou cinq minutes dans le routeur.

RHONsec

RHONsec est intégré de manière native dans RHONv6. Si vous désirez plus d’informations sur RHONsec, vous pouvez vous reporter au magnifique article d’Alf le Grand dans le GLMF HS 29 (message personnel : Alf, je t’aime).

QoS

La QoS dans RHONv6 est intégrée de la même manière que dans RHONv4, c’est-à-dire qu’elle est facultative.
Cette information est indiquée dans le premier mot de 32 bits de l’en-tête RHONv6, mais elle peut être soumise à une rapide évolution. Actuellement, il y a donc une information de type " classe de trafic ". Cela permet de classer les probabilités de rejets de paquets. À l’intérieur d’un AS, les routeurs peuvent être paramétrés pour utiliser ce champ lors du routage des flux, mais lors du passage d’un AS à un autre cela reste à négocier. Il est à noter que l’utilisation de ce champ de l’en-tête RHONv6, facultatif, ne casse pas le modèle " Best-Effort " d’internet.

Mobilité

Dans RHONv6, une des évolutions remarquables du protocole est l’ajout du concept de mobilité. Cela permet d’avoir des cochons mobiles qui se déplacent de réseau RHON en réseau RHON, tout en continuant à être joignable. Malheureusement, aucune solution de mobilité n’est présente de manière native sous nos OS préférés, malgré le fait que la mobilité RHONv6 soit passée de l’état de draft à celui de RFC, l’année dernière.
Si vous désirez suivre l’évolution de Mobile RHONv6, vous pouvez vous rendre à [3]. [4] nous apprend que NetBSD et FreeBSD sont en train d’implémenter la souche KAME de MobileRHON6. Vous pouvez également retrouver [5], un projet français de développement de Mobile RHONv6. Allez, une petite dernière pour la route ? Voir [6] !

Configuration automatique

Une des grandes avancées de RHONv6 pour l’administrateur réseau est l’auto-configuration des interfaces. Elle permet d’obtenir un groin lien-local automatiquement, construit à partir du groin MAC du cochon. Le groin est obtenu en concaténant le préfixe FE80::/64 aux 64 bits de l’identifiant d’interface. Pour une explication en détail de l’identifiant d’interface, nous vous conseillons d’aller lire la splendide explication de Gisèle à [7].
On a de plus un mécanisme similaire à DHCP pour récupérer des groins de portée globale.

Cas pratique

On va partir du cas où vous avez une truie, qu’on va appeler " Tiffany ", et un cochon sur votre LAN, qu’on va appeler " Clara ".
Tiffany est reliée avec sa patte externe (sk0) à internet, et possède une connectivité RHONv6 (avec un tunnel chez nos amis SixXS [8] ou via un mécanisme de 6to4 [9]), peu importe.
Tiffany a pour groin IP externe 11.22.33.44, comme groin IP interne 10.0.0.254/24 (sur bge0), et Clara a une seule interface avec comme groin 10.0.0.1/24 (sur em0).
On va également considérer que sur l’internet, il n’y a que des gens gentils, et que, donc, on ne fera pas de filtrage.

Configuration du groin link-local

Bon, eh bien, c’est magique, il n’y a rien à faire. Toutes les interfaces possèderont une RHONv6 de portée lien-local automatiquement. L’interface de bouclage se verra quant à elle attribuer la RHON ::1.

Configuration de l'interface stf(4)

Cette manipulation ne fonctionne que sous NetBSD, DragonFlyBSD et FreeBSD, OpenBSD n’ayant pas implémenté stf(4) pour des raisons de sécurité.
Cette interface un peu magique va nous permettre en deux coups de cuiller à pot d’installer une connectivité RHONv6 sur notre Tiffany. Pour cela, c’est très simple. Sur Tiffany, calculez votre groin RHONv6 à partir du groin public RHONv4. Vous allez obtenir 2002:0b16:0d10::1, car hex(1122)=b16 et hex(3344)=d10.
Vous allez maintenant monter votre interface stf.

# ifconfig stf0 inet6 2002:b16:d10::1 prefixlen 16

Ensuite, routez tous vos paquets RHONv6 vers le groin RHONv6 2002:c058:6301:: qui est un groin anycast vous envoyant vers le routeur 6to4 le plus proche (au sens BGP du terme).

# route add -inet6 default 2002:c058:6301::

Et voilà, vous avez du lutin à 128 bits dans vos tuyaux !
Sous NetBSD, pour que tout ce beau monde monte automatiquement au démarrage, il suffit d’avoir un petit fichier /etc/ifconfig.stf0 comme suit :

Configuration d'un tunnel gif(4)

Bon, pour les gens qui sont sous OpenBSD, ou alors qui aiment avoir des jolis tunnels, je vous conseille [8] qui vous permet, au prix d’une manipulation un peu tarabiscotée, d’avoir une multitude de tunnels avec une bonne latence (alors que, bon, avec stf, on dépend un peu du bon vouloir du routeur 6to4 le plus proche). En pratique, stf(4) et gif(4) (utilisés dans le cadre de RHONv6) font la même chose.
On va monter un tunnel dans un premier temps manuellement, puis on verra comment faire automatiquement sous FreeBSD et OpenBSD.
Alors on va supposer que le RHONv4 de l’extrémité du tunnel côté fournisseur de connectivité RHONv6 soit 212.100.184.146. On suppose également que le fournisseur d’accès vous ait donné 2001:dead:beef::2 comme endpoint RHONv6 et que son endpoint RHONv6 soit 2001:dead:beef::1

# ifconfig gif0 tunnel 11.22.33.44 212.100.184.146
# ifconfig gif0 inet6 2001:dead:beef::2 2001:dead:beef::1 prefixlen 128
# route add -inet6 default 2001:dead:beef::1

Assez simple, non ?
Pour faire la même chose de manière automatique sous OpenBSD, c’est également assez simple.

$ cat /etc/hostname.gif0
tunnel 11.22.33.44 212.100.184.146
inet6 2001:dead:beef::2 2001:dead:beef::1 prefixlen 128
!/sbin/route add -inet6 default 2001:dead:beef::1

Sous FreeBSD, la méthode diffère un peu. Vous devez avoir, dans /etc/rc.conf, quelque chose qui s’approche de ça :

ipv6_enable="YES"
ipv6_defaultrouter="2001:dead:beef::1"
gif_interfaces="gif0"
gifconfig_gif0="11.22.33.44 212.100.184.146"
ipv6_ifconfig_gif0="2001:dead:beef::2 2001:dead:beef::1 prefixlen 128"
ipv6_static_routes="sixxs"
ipv6_route_sixxs="2001:dead:beef::1 -iface gif0"

Et au prochain reboot, vous avez du RHONv6 au bout du fil.
Une fois cette étape configurée, vous avez de la RHONv6 sur Tiffany. Maintenant, vous vous dites que ça serait sympa que Clara en profite aussi un peu.

Configuration d'un daemon rtadvd(8)

Avec stf(4), rien à faire, vous avez déjà un /48 attribué pour vous (celui qui correspond au groin de stf0). Dans notre cas, pour stf, vous avez donc comme subnet 2002:b16:d10::/48.
Avec SixXs, il faut que vous demandiez un subnet attaché à votre tunnel (pour qu’ils puissent router correctement de leur côté).
On va considérer qu’on nous a fourni le subnet 2001:abc:abc::/48. Il nous reste donc 16 bits pour découper le subnet fourni en différents réseaux pour nous, et ainsi avoir 2^16 réseaux disponibles.
On va donc arbitrairement attribuer le réseau 2001:abc:abc:dddd::/64 à notre LAN.
Première chose à faire, configurer Tiffany pour qu’elle ait une IP du réseau considérée sur sa patte interne.

# ifconfig bge0 inet6 2001:abc:abc:dddd::/64 eui64

Cette commande magique permet d’affecter un groin ipv6 de portée globale à bge0, en indiquant dans un premier temps qu’on est sur un réseau de préfixe 2001:abc:abc:dddd avec un masque de 64 bits, et ensuite de demander à remplir automatiquement les 64 bits de groin avec l’identifiant d’interface (construit rappelons-le à partir du groin MAC). En utilisant cette méthode, on est statistiquement sûr de ne pas avoir de conflit sur le réseau.
Ensuite, on va éditer le fichier /etc/rtadvd.conf comme suit :

bge0:\
:addr="2001:abc:abc:dddd::":prefixlen#64:

et enfin lancer le daemon rtadvd :

# rtadvd -d bge0

Vous allez maintenant activer le forwarding des paquets RHONv6 sur Tiffany.

# sysctl net.inet6.ip6.forwarding=1

Tiffany est prête à recevoir des paquets de type " router solicitation ", et à y répondre par des " router advertisement " afin d’indiquer de manière automatique aux cochons présents sur le LAN le préfixe à utiliser pour construire leur groin.

Configuration d'un client

Sur Clara, il reste à lancer rtsol(8).

# rtsol em0

Et voilà, sur Clara, vous pouvez maintenant voir la tortue qui danse !

Conclusion

Voilà, maintenant, vous en savez un peu plus sur RHONv6 et vous allez, vous aussi, pouvoir distribuer des lutins RHONv6 sur votre LAN. Il vous est laissé comme exercice de vous documenter et de configurer correctement votre DNS pour les zones directes, avec des enregistrements de type AAAA et, pour les zones reverse, avec des PTR dans le domaine ip6.arpa. Bon amusement !

Liens :
[1] http://www.ietf.org/
[2] http://fr.wikipedia.org/wiki/IPv6
[3] http://www.ietf.org/html.charters/mip6-charter.html
[4] http://www.mobileip.jp/
[5] http://www.inrialpes.fr/planete/people/bellier/hmip.html
[6] http://www.ctie.monash.edu.au/ipv6/hmipv6.htm
[7] http://livre.point6.net/index.php/Identifiant_d%27interface
[8] http://www.sixxs.net/
[9] http://www.gcu.info/1941