IPv6: différences entre «préfixe routé» et «préfixe de liaison»?


14

Quelles sont les différences exactes entre "préfixe routé" et "préfixe de liaison" pour IPv6?
Comment ces différences dans un wirehark-Trace? (si vous observez un hôte avec un "préfixe routé" affecté ou un hôte avec un "préfixe de liaison" affecté).
Comment ces différences dans le protocole de découverte des voisins? (du point de vue d'un autre hôte / externe)
Travaillent-ils ensemble , ces deux types de préfixes?

Réponses:


19

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 /64est 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::/48doit ê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 /48il peut attribuer un /64préfixe de liaison à chaque LAN interne. Si nous supposons que l'un des réseaux locaux a été attribué 2001:db8:1:1::/64comme préfixe de lien, un nœud sur ce lien peut obtenir l'adresse 2001:db8:1:1::42:ff:fe00:43via 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::/60comme préfixe routé pour le routeur sans fil, et le routeur sans fil pourrait assigner 2001:db8:1:100::/64comme 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::/64lequel 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::/48lequel 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 /64au 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.


J'aurais lié un Q / A sur le CIDR si j'en avais trouvé un bon. Il faut absolument comprendre le CIDR avant de lire cette réponse.
kasperd

Pour le CIDR, l'article Wikipedia me convient , à mon avis, un lien vers en.wikipedia.org/wiki/Classless_Inter-Domain_Routing est bon pour une meilleure compréhension.
Erik

J'ai quelques problèmes avec votre réponse. Ils ne couvrent pas le comportement observé, ni pour mon FAI à la maison ni pour le fournisseur d'hébergement sur mon serveur (les deux n'utilisent pas la découverte de voisin classique). <br /> Je pense que j'ai besoin d'une description plus détaillée de la portée principale de mon question. Dois-je mettre à jour ma question ou exister d'une autre manière préférée? Désolé, je suis nouveau sur serverfault.com / StackExchange.
Erik

Je suis confus au sujet de la situation dont vous parlez. Voulez-vous dire un FAI (par exemple sur une ligne DSL) pour une connexion Internet pour une maison privée ou voulez-vous dire un fournisseur d'hébergement qui connecte les serveurs (avec un véritable LAN basé sur Ethernet)?
Erik

1
@ 1'OR1-- Si un paquet vers une adresse inutilisée à l'intérieur des /48résultats se traduit par un paquet de sollicitation de voisin pour l'IP de destination, cela ressemble en effet au fait que le fournisseur a configuré le /48comme préfixe de lien. Configurer un /48comme préfixe de lien n'est pas une configuration recommandée, mais j'ai entendu dire que des fournisseurs le faisaient de toute façon. S'il s'agissait d'un préfixe routé, quelle que soit l'adresse IP à l'intérieur du /48paquet ciblée, la sollicitation de voisin que vous verriez serait pour la même adresse IP à chaque fois. Et une fois que vous avez répondu à cela, vous ne verriez plus de sollicitation de voisins.
kasperd

3

Un préfixe de lien est utilisé entre votre routeur et votre FAI.

Le préfixe routé est utilisé à l'intérieur de votre réseau.

Si vous recevez un préfixe routé / 64 de votre FAI, vous devrez simplement que votre routeur annonce ce préfixe sur votre réseau local. Si vous avez un préfixe inférieur à / 64 (peut-être un / 48?), Vous devez réfléchir à la manière de mettre en sous-réseau ce préfixe de manière logique, à utiliser par tous vos routeurs de votre organisation.

Dans Wireshark, selon l' endroit où vous capturez les paquets, vous pouvez voir uniquement le préfixe routé utilisé (si vous capturez sur le LAN) ou vous pouvez voir les deux préfixes utilisés (si vous capturez sur le WAN).

Concernant le protocole de découverte de voisin, cela dépend également du lien. Sur la liaison entre le FAI et votre routeur, NDP est utilisé pour découvrir l'adresse MAC de l'interface WAN de votre routeur et l'adresse MAC du routeur en amont de votre FAI. Sur votre interface LAN, NDP est utilisé pour découvrir l'adresse MAC des hôtes sur votre segment LAN.

J'espère que cela t'aides.


1
La phrase If you received a /64 from your ISP, then you would simply have your router advertise that prefix on your LANserait probablement moins susceptible d'être mal comprise si vous la rendiez explicite en /64faisant référence au préfixe routé.
kasperd

2

Un préfixe est un préfixe routé si les paquets vers ce préfixe doivent passer par un routeur pour atteindre leur destination. Un préfixe est un préfixe de lien s'il se trouve sur un segment auquel une interface réseau locale est attachée.

Lorsqu'un paquet circule sur Internet, le / 64 ciblé sera un préfixe routé jusqu'au dernier saut. Ce sera alors un préfixe de lien.

Les préfixes routés sont généralement agrégés. Beaucoup / 64 peuvent être agrégés en un seul préfixe plus court pour garder les tables de routage plus petites. À la frontière entre les fournisseurs Internet, il est courant d'appliquer une longueur maximale de préfixe de / 48.

Si un préfixe est compris entre / 0 et / 63, vous pouvez généralement supposer qu'il s'agit d'un préfixe routé. Si le préfixe est / 64, vous avez besoin de plus d'informations pour savoir s'il s'agit d'un préfixe routé ou d'un lien.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.