IPv6-Adressierung / 127 vs eui-64


9

Es wird empfohlen, eine manuelle / 127-Adresse für die hier beschriebene Punkt-zu-Punkt-Adressierung zu verwenden. RFC2373

für EUI-64 schreibt ERFC 2373 den Konvertierungsprozess vor, der zwei Schritte umfasst. Die erste besteht darin, die 48-Bit-MAC-Adresse in einen 64-Bit-Wert umzuwandeln. Zu diesem Zweck teilen wir die MAC-Adresse in zwei 24-Bit-Hälften auf: den OUI (Organizationally Unique Identifier) ​​und den NIC-spezifischen Teil. Der 16-Bit-Hex-Wert 0xFFFE wird dann zwischen diese beiden Hälften eingefügt, um eine 64-Bit-Adresse zu bilden.

Ich verstehe genau, wo Sie die manuelle Adresszuweisung / 127 verwenden würden, aber ich kann die Vorteile der Verwendung des EUI-64 nicht wirklich erkennen. es sei denn, ich vermisse den eigentlichen Zweck dieser Adressfunktion völlig.

Kann jemand freundlicherweise etwas Licht auf die EUI-64-Anwendungsfälle speziell in einer ISP-WAN-Topologie werfen, wenn dies möglich ist? oder zeigen Sie mir bitte in Richtung Lesematerial.


1
Beachten Sie, dass RFC 2373 durch RFC 3513 veraltet ist, was durch RFC 4291 veraltet ist.
Belacqua

Antworten:


9

Dies ist das Thema einer großen Debatte, die schon eine Weile andauert.

Wenn es darauf ankommt, ist die Verwendung von / 127 für eine Punkt-zu-Punkt-Verbindung keine wirklich schreckliche Idee. RFC6164 zeigt, dass es möglicherweise eine gute Idee ist, eine / 127 zu verwenden. Es identifiziert einige der großen Probleme beim Wechsel zu einer / 127 auf einer P2P-Verbindung und spricht über die Schritte, die unternommen wurden, um gegebenenfalls Abhilfe zu schaffen. Die Angst vor Ping-Pong-Angriffen wurde in der neuesten Version von ICMP gemindert, und Angriffe auf die Erschöpfung des Nachbar-Cache auf P2P-Verbindungen werden mithilfe eines Präfixes / 127 tatsächlich beseitigt.

EUI-64 ist in Benutzer-Subnetzen im Allgemeinen vorzuziehen, da SLAAC im Allgemeinen unterbrochen wird, wenn / 64-Subnetze nicht verwendet werden. Bei P2P-Verbindungen, bei denen SLAAC nicht verwendet wird, ist das keine große Sache.

Zusammenfassend glaube ich, dass der allgemeine Konsens darin besteht, dass die Verwendung von a / 127 keine große Sache ist - tatsächlich möchten Sie möglicherweise eine einzelne / 64 für alle Ihre P2P-Links zuweisen. Ihre Routing-Tabelle kann einen kleinen Treffer erleiden, da nicht alle P2P-Präfixe leicht zusammenzufassen sind, es jedoch unwahrscheinlich ist, dass es sich um ein signifikantes Problem handelt. Beachten Sie einfach den von mir erwähnten RFC und befolgen Sie die darin enthaltenen Richtlinien.


3
SLAAC "bricht im Allgemeinen nicht", sondern gilt nur für ein LAN , wenn die Präfixlänge genau 64 beträgt. (Meine Kriegspartei ist immer noch auf der Suche nach den dafür verantwortlichen Genies.)
Ricky Beam

5

Die Verwendung von a / 127 ist praktisch, wenn Sie Punkt-zu-Punkt-Verbindungen manuell konfigurieren. Normalerweise reserviere ich eine / 64 in meinem Adressierungsplan (aus Gründen der Klarheit und Konsistenz mit anderen Nicht- / 127-Netzwerken) und konfiguriere sie dann xxxx:xxxx:xxxx:xxxx::a/127auf der einen Seite und xxx:xxxx:xxxx:xxxx::b/127auf der anderen Seite der Verbindung.

EUI-64-Adressen werden häufig bei der automatischen Konfiguration von Schnittstellen verwendet. Link-local (fe80 :: / 10-Adressen) verwendet sie häufig. Wenn das System eine Router-Ankündigung mit Präfixinformationen empfängt, wird das Präfix / 64 als die ersten 64 Bits seiner Adresse und das EUI-64 als die letzten 64 verwendet Bits der Adresse, um eine vollständige 128-Bit-IPv6-Adresse zu bilden. Alles ohne manuelle Konfiguration oder einen DHCP-Server.


Ich habe Ihre Adressnotation auf :: und :: 1
geändert

Olipro: Du liegst falsch. :: a und :: b sind für a / 127 vollkommen gültig. Ich habe es zurück bearbeitet.
Sander Steffann

1
Ah ja, natürlich ist das letzte Bit in 0xa0 und 0xb1, was bedeutet, dass das Subnetz effektiv istxxxx:...::a/127
Olipro

4

Die Verwendung einer / 127 ist nicht schrecklich, aber es ist wie eine / 127, sie in Ihr Rückgrat zu lassen.

Der Grund dafür ist, dass die meisten modernen Router-TCAMs im Allgemeinen nur bis zu 64 Bit Adressbreite gleichzeitig verarbeiten können. Dies bedeutet, dass in Situationen, in denen alle Routen / 64 oder kürzer sind, Suchvorgänge auftreten können in einem einzigen Zyklus. Alles länger und es muss ein weiterer Suchvorgang ausgeführt werden. Selbst bei einem TCAM mit nur 32 oder 48 Bit Breite ist es offensichtlich immer noch wichtig, über / 64 hinauszugehen.

Meine persönliche Empfehlung lautet daher, jeder P2P-Verbindung eine / 64 zuzuweisen, auch wenn Sie nur eine / 127 auf dem Kabel verwenden. Auf diese Weise können Sie beim Aufrufen Ihres Routing-Protokolls die / 127 zu einer / 64 aggregieren.

Mein persönlicher Favorit ist es jedoch, einen angemessenen Teil Ihres IPv6-Speicherplatzes nur zur Erleichterung von P2P-Verbindungen zuzuweisen (in meinem Fall habe ich eine / 48 reserviert) - diese / 48 wird dann auf allen Netzwerkkantenschnittstellen beim Eingang als Ziel blockiert. Auf diese Weise können Sie einfach ein / 64 für Ihre P2P-Links verwenden und haben immer noch Traceroutes, ICMP-Fehler usw. Sie arbeiten, sind aber nicht anfällig für NDP-Angriffe von außen.

Offensichtlich wird sich nicht jeder darum kümmern, und wenn die zusätzlichen Kosten für die Verwendung längerer Präfixe für Sie akzeptabel sind (oder Sie Super-Duper-128-Bit-TCAMs haben), können Sie natürlich alles oben Genannte ignorieren. Wie skalierbar soll Ihr Netzwerk sein?


Wir verwenden eine Juniper MX80-Plattform, und der folgende Auszug lässt mich glauben, dass TCAM kein kritisches Problem sein sollte. MX80 ist ein einzelner MPC mit den neuen Trio-ASICs, was bedeutet, dass die Kapazität der ursprünglichen DPCs ungefähr doppelt so hoch ist. Siehe MX80 TCAM für eine vollständige Erklärung
DrBru

Was Sie verlinkt haben, bezieht sich auf MAC-Adressen, es sagt nichts über IPv6-Routen aus. Darüber hinaus kann jeder Router im Allgemeinen Präfixe bis zu / 128 haben - das Problem ist die Anzahl der Zyklen, die der TCAM durchlaufen muss, um die Übereinstimmung zu finden.
Olipro
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.