http://www.bortzmeyer.org/7608.html
---------------------------- Auteur(s) du RFC: M. Boucadair (France Telecom), A. Petrescu (CEA, LIST), F. Baker (Cisco Systems) ---------------------------- Comme IPv4, IPv6 route les paquets en fonction d'un préfixe d'adresses, préfixe qui a une longueur comprise entre 0 (tout l'Internet) et 128 bits (une seule machine). Ce très court RFC a juste pour but de rappeler cette règle : la longueur d'un préfixe est quelconque, les mises en œuvres de IPv6, logicielles ou matérielles, ne doivent pas imposer ou favoriser une longueur de préfixe particulière (même pas 64, souvent considéré, à tort, comme spécial). Le routage se fait exclusivement sur le plus long préfixe, quelle que soit sa longueur. Il est normal qu'IPv6 et IPv4 fassent pareil, ce sont après tout deux versions du même protocole. IPv4 utilisait autrefois <http://www.bortzmeyer.org/fini-les-classes.html> un système différent mais, depuis CIDR, il suit les mêmes règles qu'IPv6 : le routage se fait sur la base d'un préfixe d'adresses de longueur quelconque. C'est le préfixe le plus long qui est choisi. Ainsi, pour prendre un exemple IPv4, si la destination est 203.0.113.51 et qu'il existe deux routes possibles, une vers le préfixe 203.0.113.0/26 (longueur 26 bits) et l'autre vers le préfixe 203.0.0.0/18, c'est la première, la plus spécifique (le préfixe le plus long) qui gagne. En IPv6, si on veut envoyer un paquet à 2001:db8:440:fe::25a:9ff et qu'il existe deux routes possibles, 2001:db8:440:fe::/80 (longueur 80 bits) et 2001:db8:440::/48, c'est la première qui est choisie. Le routage sur la base du préfixe le plus long, un concept fondamental d'IP, c'est juste ça. (Le terme de CIDR, introduit par le RFC 1380 et décrit dans le RFC 4632, terme très spécifique à IPv4 et aujourd'hui dépassé techniquement depuis l'abandon de l'ancien système des classes, n'est pas utilisé pour IPv6.) Mais pas mal de gens qui ne connaissent pas bien IPv6 ont des idées fausses à ce sujet et croient, par exemple, que les préfixes de longueur 64 bits ont un rôle particulier pour le routage, voire que les préfixes comme le /80 donné en exemple plus haut sont illégaux. Le RFC 4291, qui normalise l'adressage IPv6, dit bien (dans sa section 2.5) que n'importe quelle longueur de préfixe (« "arbitrary bit-length" ») est possible. Mais c'est vrai que la confusion peut venir du rôle particulier de certaines longueurs, notamment 64, dans d'autres utilisations que le routage. Ainsi, le RFC 7421 note que les préfixes plus longs que 64 bits ont des problèmes pour certaines utilisations, comme le SLAAC. Mais il s'agit là de questions liées à l'adressage : cela ne devrait pas affecter le routage, si on veut que les changements futurs de l'adressage n'empêchent pas les routeurs de fonctionner (deux exemples de changement d'adressage : au début d'IPv6, il était envisagé que ce soit /80 plutôt que /64 qui soit la longueur de préfixe « de référence » et, autre exemple, la recommendation pour les liens point à point a varié de /64 à /127, cf. RFC 6164). Donc, pour résumer, l'adressage est une chose (et les recommendations du RFC 7421, indiquant les avantages à utiliser du /64 pour un lien local, continuent à s'appliquer), le routage en est une autre : le routage IPv6 *doit* suivre l'algorithme du préfixe le plus long, et ne doit pas avoir de longueurs de préfixes privilégiées ou spéciales. Cette exigence est formalisée dans la section 2 de notre RFC : * Les routeurs IPv6 doivent suivre les règles de la section 5.1 du RFC 4632. * La transmission d'un paquet doit se faire sur la base du préfixe le plus long et toutes les longueurs sont également acceptables, même 128, même des valeurs qui ne sont pas un multiple de 8. Ces règles s'appliquent au code des routeurs : l'administrateur d'un routeur donné peut toujours avoir sa propre politique (par exemple, en BGP, ne pas accepter de préfixes plus longs que 48 bits) mais cela ne doit pas se retrouver dans le logiciel, autrement, les futures évolutions seraient sérieusement compliquées. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
