La façon la plus simple de comprendre la différence entre les deux est via un exemple montrant la nature hiérarchique des préfixes.
Un exemple de hiérarchie
Un FAI s'est vu attribuer un préfixe à partir d'un RIR (Regional Internet Registry) qui, dans cet exemple, nous supposerons que c'est 2001:db8::/32
. Ce préfixe est différent de ceux transmis aux clients dans le sens où le FAI devra l'annoncer via BGP aux autres FAI avec lesquels il est homologue.
Le FAI va maintenant attribuer des préfixes à un client. Tout d'abord, ils attribuent 2001:db8:0:1::/64
à la liaison reliant le routeur ISP au routeur CPE (équipement client). Il s'agit d'un préfixe de lien car il est attribué à un lien. En règle générale, tous les préfixes de liens dans IPv6 devraient l'être /64
.
Le routeur ISP enverra des annonces de routeur annonçant ce préfixe et le CPE utilisera SLAAC pour construire une adresse pour l'interface externe pointant vers le routeur ISP dans le /64
. Supposons que l'interface externe ait obtenu l'adresse IP 2001:db8:0:1:42:ff:fe00:42/64
(dans cette notation /64
est incluse pour nous rappeler quelle est la longueur du préfixe de lien, mais j'aurais aussi bien pu la laisser de côté).
Ce préfixe de lien est suffisant pour que le routeur CPE communique avec le reste du monde, mais il n'aide pas le routeur CPE à prendre en charge les clients du LAN connectés à son interface interne. Le routeur CPE a besoin d'un préfixe pour le LAN qui est acheminé via ce routeur CPE, d'où ce qu'on appelle un préfixe routé .
Le préfixe routé peut être configuré de manière statique ou via DHCPv6. Les détails exacts de la façon dont le routeur CPE négocie une longueur de préfixe avec le serveur DHCPv6 fourni par le FAI n'entrent pas dans le cadre de cette réponse. Une recherche de délégation de préfixe peut vous en dire plus. Supposons que le préfixe routé finisse par être 2001:db8:1::/48
. Sur le routeur du FAI, une entrée de table de routage sera créée, indiquant qu'il 2001:db8:1::/48
doit être routé via la passerelle 2001:db8:0:1:42:ff:fe00:42
. Cette entrée de table de routage est la caractéristique qui définit le préfixe routé.
Le routeur CPE peut avoir plusieurs LAN internes, à partir de quoi /48
il peut attribuer un /64
préfixe de liaison à chaque LAN interne. Si nous supposons que l'un des réseaux locaux a été attribué 2001:db8:1:1::/64
comme préfixe de lien, un nœud sur ce lien peut obtenir l'adresse 2001:db8:1:1::42:ff:fe00:43
via SLAAC. Ce nœud peut être un routeur sans fil qui a besoin d'un préfixe pour son interface sans fil. Le CPE pourrait assigner 2001:db8:1:100::/60
comme préfixe routé pour le routeur sans fil, et le routeur sans fil pourrait assigner 2001:db8:1:100::/64
comme préfixe de liaison pour l'interface sans fil.
Maintenant, dans une telle configuration, nous avons une hiérarchie de préfixes. Les éléments suivants sont tous imbriqués les uns sous les autres:
2001:db8::/32
BGP a annoncé le préfixe
2001:db8:1::/48
préfixe routé
2001:db8:1:100::/60
préfixe routé
2001:db8:1:100::/64
préfixe de lien
Comment les paquets sont-ils réellement traités
Lorsque le routeur ISP reçoit un paquet pour 2001:db8:0:1::/64
lequel est un préfixe de liaison, il effectue une découverte de voisin pour trouver l'adresse MAC de l'hôte dans le /64
.
De cette façon, le routeur ISP va avoir besoin d'une entrée de cache de voisin distincte pour chaque adresse IP dans le préfixe de liaison.
Lorsque le routeur ISP reçoit un paquet pour 2001:db8:1::/48
lequel est un préfixe routé, il effectue une découverte de voisin pour trouver l'adresse MAC de la passerelle 2001:db8:0:1:42:ff:fe00:42
.
De cette façon, le routeur ISP n'a besoin que d'une seule entrée de cache de voisin pour la passerelle afin d'acheminer les paquets vers n'importe quelle adresse IP dans le préfixe routé. Cette propriété est cruciale pour l'évolutivité d'Internet.
Contourner le manque de préfixe routé
Parfois, les clients se retrouvent coincés avec un FAI qui ne fournira qu'un préfixe de lien et aucun préfixe routé. Dans une telle situation, il est possible pour le client d'installer un démon qui répond à la détection de voisin pour toutes les adresses IP dans une sous-plage spécifique du préfixe de lien. Cela aura un effet similaire à la configuration de ce préfixe en tant que préfixe routé. Mais il présente plusieurs inconvénients:
- En général, les préfixes routés sont censés être plus courts que
/64
, mais le démon répondant aux demandes de découverte de voisins ne peut créer qu'un préfixe "routé" qui est plus long que /64
.
- Il augmente légèrement la latence en raison d'un aller-retour supplémentaire chaque fois qu'une adresse IP n'est pas dans le cache voisin sur le routeur ISP.
- Il augmente la charge sur le routeur ISP en raison de la nécessité de découvrir des voisins beaucoup plus fréquents. Il est fort probable que le routeur ISP puisse transférer des paquets vers un préfixe de destination déjà connu uniquement sur le plan matériel, mais la découverte des voisins va se faire par logiciel.
- Il augmente la consommation de mémoire sur le routeur ISP. Si le FAI alloue un préfixe routé à chaque client, il peut facilement s'en tirer en n'ayant qu'une seule entrée de cache de voisin par client. Mais avec le démon du répondeur voisin, cela pourrait se traduire par des milliers d'entrées par client.
La surcharge de traitement sur le routeur ISP peut être un problème important. Certains routeurs ont été si mauvais à gérer un flot de paquets nécessitant la découverte de voisins qu'il s'est transformé en une véritable attaque DoS, et l'utilisation de préfixes de liaison plus longs (dans la plage /120
- 127
) a été utilisée comme solution de contournement pour de telles attaques DoS.
Même si le routeur n'est pas vulnérable à l'attaque DoS, la mémoire nécessaire pour les entrées de cache voisines lorsque la solution de contournement décrite ci-dessus est utilisée est beaucoup plus chère pour le FAI que ne le seraient les adresses IP pour un préfixe routé, donc il y a peu de raisons pour qu'un FAI refuse de distribuer un préfixe routé.
Cas particuliers concernant les liaisons point à point
Sur les liens point à point (tels que les tunnels 6 en 4 et les liens PPP), il n'est pas nécessaire de découvrir les voisins. Il n'y a qu'une seule direction pour envoyer un paquet sur une telle liaison et aucune adresse matérielle ne doit être recherchée avant d'envoyer le paquet.
Cela signifie que les frais généraux de la découverte de voisins ne sont pas un problème sur un tel lien. Donc, avoir une extrémité d'un lien point à point utilise beaucoup d'adresses n'est pas un problème, tant que les points de terminaison ont un certain accord sur qui utilise quelles adresses. Le manque de découverte de voisin signifie qu'il n'y a pas non plus de détection d'adresse en double, donc si les deux points de terminaison essaient d'utiliser la même adresse, cela ne fonctionnera pas comme prévu (sauf si vous vous attendez à ce qu'il se comporte comme une adresse anycast).
Il y a une mise en garde à garder à l'esprit concernant les liens point à point. Chaque point d'extrémité supposera que toutes les adresses sur le lien auquel il n'est pas affecté lui-même sont affectées à l'autre extrémité. Cela signifie que les adresses inutilisées sur une liaison point à point sont susceptibles de déclencher une boucle de routage. Une telle boucle de routage (et plusieurs autres cas de boucles de routage) peut être évitée par un point d'extrémité qui ne renvoie jamais un paquet directement au nœud d'où il a été reçu. Ainsi, un paquet reçu d'un lien point à point ne doit pas être renvoyé sur le même lien point à point, tant qu'un point d'extrémité obtient ce droit, la boucle de routage est rompue. En tant que nœud latéral sur Ethernet, il est valide pour recevoir un paquet et le retransmettre sur la même liaison, mais c'est une bonne idée d'éviter de le faire s'il serait retransmis à la même adresse MAC d'où il a été reçu.
Étant donné que la plupart des adresses sur un lien point à point vont simplement être transmises à l'autre extrémité du lien sans avoir besoin de découverte de voisin, cela ressemble beaucoup à un préfixe routé. Par exemple, si le FAI a attribué 2001: db8: 42 :: / 64 à une liaison point à point avec les points de terminaison auxquels des adresses ont été attribuées 2001: db8: 42 :: 1 et 2001: db8: 42 :: 2, puis des paquets à la plupart des adresses en 2001: db8: 42 :: / 64 sera transmis du FAI au client de la même manière que s'il s'agissait d'un préfixe routé utilisant 2001: db8: 42 :: 2 comme passerelle.
Cela signifie qu'un certain piratage est possible. Sur le CPE, il est possible de configurer réellement 2001: db8: 42 :: / 64 comme préfixe de liaison sur le LAN. Pour que le CPE sache sur laquelle des deux liaisons se trouve une certaine destination, la configuration réelle sur la liaison point à point vers le FAI devrait alors être modifiée en 2001: db8: 42 :: / 126. Cela fonctionnera tous avec une exception mineure, les hôtes sur le LAN ne peuvent pas communiquer avec les quatre adresses IP en 2001: db8: 42 :: / 126. Comme ils n'avaient probablement pas besoin de communiquer avec eux de toute façon, ce n'est pas un problème majeur. Cependant, il n'est pas recommandé d'utiliser ce hack, la configuration correcte est d'obtenir un préfixe routé du FAI.
Un autre hack pour enregistrer des adresses consiste à allouer uniquement des adresses globales pour un préfixe routé et à utiliser des adresses RFC 4193 pour la liaison point à point. Il s'agit cependant d'un hack stupide car il présente encore quelques inconvénients afin de résoudre un problème inexistant.
Il est également possible de ne pas attribuer de préfixe à une liaison point à point. Tant que chaque point de terminaison a une autre interface sur laquelle il a une adresse globale, ils peuvent utiliser l'adresse affectée à l'autre interface lors de la communication sur la liaison point à point. Je ne connais aucun inconvénient de cette approche, donc si vous trouvez que cette approche de liens point à point simplifie votre configuration réseau, n'hésitez pas à l'utiliser, mais ne l'utilisez pas comme mesure pour enregistrer des adresses.
Cas d'utilisation pour un préfixe routé
- Le routage hiérarchique, comme dans mon premier exemple, est conçu pour les préfixes routés.
- Les VPN / tunnels ajoutent une autre couche dans la hiérarchie des routeurs nécessitant des préfixes. Bien qu'ils soient virtuels plutôt que matériels réels, ils ne sont pas différents en termes d'adressage et ont besoin d'un préfixe routé comme le ferait un lien physique.
- Attribution de nombreuses adresses à un hôte . Il existe des cas d'utilisation pour attribuer un grand nombre d'adresses à un seul hôte. Pour quelques adresses, elles peuvent simplement être attribuées et gérées avec détection de voisin pour chacune et autant d'entrées de cache qu'il y a d'adresses. Mais si des milliers d'adresses sont nécessaires, un préfixe routé est préférable.
Un exemple plus détaillé du dernier point serait les récurseurs DNS. Étant donné que je ne vois pas DNSSEC obtenir beaucoup de traction jusqu'à ce que nous ayons fini de nous battre avec IPv4, d'autres mesures contre l'empoisonnement DNS sont nécessaires. Des efforts ont été faits pour obtenir le plus d'entropie possible dans les requêtes. L'ID et le numéro de port peuvent contenir au plus 32 bits d'entropie, quelques autres bits peuvent être conservés dans la demande si les majuscules et les minuscules sont mélangées dans le nom de domaine à résoudre. Vous obtiendrez rarement plus de 48 bits au total de cette façon. L'attribution d'un complet /64
au récurseur DNS permettrait d'augmenter l'entropie de 64 bits en une seule fois, ce qui est plus que tous les autres efforts combinés.