adressage ipv6 / 127 vs eui-64


9

La meilleure pratique consiste à utiliser une adresse manuelle / 127 pour l'adressage point à point décrit ici RFC2373

pour EUI-64 ERFC 2373 dicte le processus de conversion, qui comporte deux étapes. La première consiste à convertir l'adresse MAC 48 bits en une valeur 64 bits. Pour ce faire, nous décomposons l'adresse MAC en ses deux moitiés de 24 bits: l'identificateur organisationnel unique (OUI) et la partie spécifique NIC. La valeur hexadécimale 16 bits 0xFFFE est ensuite insérée entre ces deux moitiés pour former une adresse 64 bits.

Je comprends parfaitement où vous utiliseriez l'attribution d'adresse manuelle / 127, mais je ne vois vraiment pas les avantages de l'utilisation de l'EUI-64. sauf si je manque totalement le but réel de cette fonction d'adresse.

quelqu'un peut-il gentiment faire la lumière sur les cas d'utilisation EUI-64 spécifiquement dans une topologie WAN ISP si possible. ou pointez-moi vers du matériel de lecture s'il vous plaît.


1
Notez que RFC 2373 est obsolète par RFC 3513, qui est obsolète par RFC 4291.
belacqua

Réponses:


9

C'est le sujet d'un grand débat qui dure depuis un moment.

En fin de compte, utiliser un / 127 sur un lien point à point n'est pas vraiment une idée terrible. La RFC6164 illustre qu'il peut être judicieux d'utiliser un / 127 - elle identifie certains des gros problèmes pour passer à un / 127 sur une liaison P2P et parle des mesures qui ont été prises pour atténuer, le cas échéant. La peur des attaques de ping-pong a été atténuée dans la version la plus récente d'ICMP, et les attaques d'épuisement du cache voisin sont en fait éliminées sur les liaisons P2P en utilisant un préfixe / 127.

EUI-64 est généralement préférable sur les sous-réseaux d'utilisateurs, car SLAAC se rompt généralement si les sous-réseaux / 64 ne sont pas utilisés. Sur les liens P2P où SLAAC n'est pas utilisé, ce n'est pas si grave.

En conclusion, je crois que le consensus général est que l'utilisation d'un / 127 n'est pas un gros problème - en fait, vous voudrez peut-être allouer un seul / 64 pour toutes vos liaisons P2P. Votre table de routage peut prendre un petit coup car tous les préfixes P2P ne seront pas faciles à résumer, mais il est peu probable que ce soit un problème important. Gardez simplement à l'esprit le RFC que j'ai mentionné et assurez-vous de suivre les directives qu'il fournit.


3
SLAAC ne "casse généralement pas", il ne s'applique à un LAN que lorsque la longueur du préfixe est exactement 64. (ma warparty est toujours à la recherche des génies responsables de cela.)
Ricky Beam

5

L'utilisation de a / 127 est pratique lors de la configuration manuelle de liaisons point à point. Je réserve généralement un / 64 dans mon plan d'adressage (pour plus de clarté et de cohérence avec les autres réseaux non / 127), puis je configure xxxx:xxxx:xxxx:xxxx::a/127d'un côté et xxx:xxxx:xxxx:xxxx::b/127de l'autre côté de la liaison.

Les adresses EUI-64 sont beaucoup utilisées lors de la configuration automatique des interfaces. Link-local (fe80 :: / 10 adresses) les utilise souvent, et si le système reçoit une annonce de routeur avec des informations de préfixe, il prendra le préfixe / 64 comme les 64 premiers bits de son adresse et l'EUI-64 comme les 64 derniers. bits de l'adresse, pour former une adresse IPv6 de 128 bits complète. Le tout sans avoir besoin d'une configuration manuelle ou d'un serveur DHCP.


J'ai modifié votre notation d'adresse en :: et :: 1 car, par définition, vous ne pouvez pas avoir autre chose que 0 et 1.
Olipro

Olipro: vous vous trompez. :: a et :: b sont parfaitement valables pour a / 127. Je l'ai réédité.
Sander Steffann

1
Ah oui, bien sûr, le dernier bit 0xaest 0 et 0xb1, ce qui signifie que le sous-réseau est effectivementxxxx:...::a/127
Olipro

4

Utiliser un / 127 n'est pas terrible, mais le laisser entrer dans votre colonne vertébrale comme un / 127 l'est.

La raison en est que, essentiellement, la plupart des TCAM de routeur modernes ne peuvent généralement gérer que jusqu'à 64 bits de largeur d'adresse à la fois - cela signifie que si vous êtes dans une situation où toutes les routes sont / 64 ou plus courtes, des recherches peuvent se produire en un seul cycle. N'importe quoi de plus et il doit effectuer une autre opération de recherche. Même sur un TCAM qui n'a qu'une largeur de 32 ou 48 bits, aller au-delà de / 64 est évidemment toujours significatif.

Donc, ma recommandation personnelle est d'allouer un / 64 pour chaque lien P2P même si vous utilisez uniquement un / 127 sur le fil - de cette façon, lorsque vous amenez votre protocole de routage, vous pouvez ensuite agréger le / 127 à un / 64.

Mon préféré, cependant, est d'allouer une partie raisonnable de votre espace IPv6 uniquement pour faciliter les liaisons P2P (dans mon cas, j'ai réservé un / 48) - ce / 48 est ensuite bloqué sur toutes les interfaces de périphérie du réseau à l'entrée comme destination. De cette façon, vous êtes libre d'aller de l'avant et d'utiliser un / 64 sur vos liens P2P et d'avoir toujours des traceroutes, des erreurs ICMP et. travail, mais vous n'êtes pas vulnérable aux attaques du NPD de l'extérieur.

Évidemment, tout le monde ne s'en souciera pas et si le coût supplémentaire de l'utilisation de préfixes plus longs vous convient (ou si vous avez des TCAM 128 bits super-duper), vous pouvez bien sûr ignorer tout ce qui précède. Dans quelle mesure souhaitez-vous que votre réseau soit évolutif?


Nous utilisons une plate-forme Juniper MX80 et l'extrait ci-dessous me porte à croire que TCAM ne devrait pas être un problème critique.Le MX80 est un seul MPC utilisant les nouveaux Trio ASIC, ce qui signifie qu'il a à peu près le double de la capacité des DPC d'origine. Voir MX80 TCAM pour une explication complète
DrBru

Ce que vous avez lié fait référence aux adresses MAC, cela ne dit rien sur les routes IPv6. De plus, n'importe quel routeur peut généralement avoir des préfixes jusqu'à / 128 - le problème est le nombre de cycles que le TCAM doit parcourir pour trouver la correspondance.
Olipro
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.