Der einfachste Weg, den Unterschied zwischen den beiden zu verstehen, ist ein Beispiel, das die hierarchische Natur der Präfixe zeigt.
Eine Beispielhierarchie
Einem ISP wurde ein Präfix von einem RIR (Regional Internet Registry) zugewiesen, von dem wir in diesem Beispiel ausgehen werden, dass es ist 2001:db8::/32
. Dieses Präfix unterscheidet sich von den an die Kunden weitergegebenen Präfixen in dem Sinne, dass der ISP es anderen ISPs, mit denen er konfrontiert ist, über BGP mitteilen muss.
Der ISP vergibt nun Präfixe an einen Kunden. Zuerst weisen 2001:db8:0:1::/64
sie die Verbindung zu, die den ISP-Router mit dem CPE- Router (Customer-Premises Equipment) verbindet. Dies ist ein Link-Präfix, da es einem Link zugewiesen ist. Als allgemeine Empfehlung sollten alle Link-Präfixe in IPv6 sein /64
.
Der ISP-Router sendet Routerankündigungen mit diesem Präfix, und das CPE verwendet SLAAC, um eine Adresse für die externe Schnittstelle zu erstellen, die auf den ISP-Router im Internet verweist /64
. Nehmen wir an, die externe Schnittstelle hat die IP-Adresse 2001:db8:0:1:42:ff:fe00:42/64
(in dieser Notation /64
ist enthalten, um uns daran zu erinnern, wie lang das Link-Präfix ist, aber ich hätte es auch weglassen können).
Dieses Verbindungspräfix reicht aus, damit der CPE-Router mit dem Rest der Welt kommunizieren kann, aber es hilft dem CPE-Router nicht, Clients im LAN zu unterstützen, die mit seiner internen Schnittstelle verbunden sind. Der CPE-Router benötigt ein Präfix für das LAN, das über diesen CPE-Router geleitet wird. Daher wird dies als geroutetes Präfix bezeichnet .
Das geroutete Präfix kann statisch oder über DHCPv6 konfiguriert werden. Die genauen Details, wie der CPE-Router eine Präfixlänge mit dem vom ISP bereitgestellten DHCPv6-Server aushandelt, liegen außerhalb des Bereichs dieser Antwort. Eine Suche nach Präfix-Delegierung kann Ihnen mehr darüber erzählen. Nehmen wir an, das geroutete Präfix ist am Ende 2001:db8:1::/48
. Auf dem ISP-Router wird ein Routing-Tabelleneintrag erstellt, der angibt, dass das Routing 2001:db8:1::/48
über das Gateway erfolgen muss 2001:db8:0:1:42:ff:fe00:42
. Dieser Routing-Tabelleneintrag ist das definierende Merkmal des Routing-Präfix.
Der CPE-Router verfügt möglicherweise über mehrere interne LANs, von denen /48
er /64
jedem internen LAN ein Verbindungspräfix zuweisen kann . Wenn wir annehmen, dass eines der LANs 2001:db8:1:1::/64
als Verbindungspräfix zugewiesen wurde, kann ein Knoten auf dieser Verbindung die Adresse 2001:db8:1:1::42:ff:fe00:43
über SLAAC erhalten. Dieser Knoten kann ein drahtloser Router sein, der zufällig ein Präfix für seine drahtlose Schnittstelle benötigt. Das CPE kann 2001:db8:1:100::/60
als Routing-Präfix für den WLAN-Router zugewiesen werden, und der WLAN-Router kann 2001:db8:1:100::/64
als Link-Präfix für die WLAN-Schnittstelle zugewiesen werden.
In einer solchen Konfiguration haben wir eine Hierarchie von Präfixen. Die folgenden Elemente sind untereinander verschachtelt:
2001:db8::/32
BGP kündigte Präfix an
2001:db8:1::/48
geroutetes Präfix
2001:db8:1:100::/60
geroutetes Präfix
2001:db8:1:100::/64
Link-Präfix
Wie werden Pakete tatsächlich behandelt?
Wenn der ISP-Router ein Paket empfängt, für 2001:db8:0:1::/64
das ein Verbindungspräfix vorliegt, führt er eine Nachbarerkennung durch, um die MAC-Adresse des Hosts in der zu finden/64
.
Auf diese Weise benötigt der ISP-Router für jede IP-Adresse im Verbindungspräfix einen eigenen Nachbar-Cache-Eintrag.
Wenn der ISP-Router ein Paket empfängt, für 2001:db8:1::/48
das ein geroutetes Präfix vorliegt, führt er eine Nachbarerkennung durch, um die MAC-Adresse des Gateways zu ermitteln 2001:db8:0:1:42:ff:fe00:42
.
Auf diese Weise benötigt der ISP-Router nur einen einzelnen Nachbar-Cache-Eintrag für das Gateway, um Pakete an eine beliebige IP-Adresse im gerouteten Präfix weiterzuleiten. Diese Eigenschaft ist entscheidend für die Skalierbarkeit des Internets.
Umgehen des Mangels an geroutetem Präfix
Gelegentlich stecken Kunden bei einem Internetdienstanbieter fest, der nur ein Verbindungspräfix und kein weitergeleitetes Präfix bereitstellt. In einer solchen Situation kann der Kunde einen Daemon installieren, der auf die Nachbarerkennung für alle IP-Adressen innerhalb eines bestimmten Unterbereichs des Verbindungspräfix reagiert. Dies hat einen ähnlichen Effekt wie die Konfiguration dieses Präfixes als geroutetes Präfix. Es hat jedoch mehrere Nachteile:
- Im Allgemeinen sollten weitergeleitete Präfixe kürzer sein als
/64
, aber der Dämon, der auf Anforderungen der Nachbarerkennung reagiert, kann nur ein "weitergeleitetes" Präfix erstellen, das länger als ist /64
.
- Dies erhöht die Latenz geringfügig, da jedes Mal, wenn sich eine IP-Adresse nicht im Nachbarcache des ISP-Routers befindet, ein zusätzlicher Roundtrip durchgeführt wird.
- Dies erhöht die Belastung des ISP-Routers, da häufigere Nachbarerkennungen erforderlich sind. Es ist sehr wahrscheinlich, dass der ISP-Router Pakete rein hardwaremäßig an ein bereits bekanntes Zielpräfix weiterleiten kann, die Nachbarerkennung jedoch über Software.
- Es erhöht den Speicherverbrauch auf dem ISP-Router. Wenn der ISP jedem Kunden ein weitergeleitetes Präfix zuweist, kann er problemlos davonkommen, dass nur ein Nachbar-Cache-Eintrag pro Kunde vorhanden ist. Beim Nachbar-Responder-Daemon kann dies jedoch zu Tausenden von Einträgen pro Kunde führen.
Der Verarbeitungsaufwand auf dem ISP-Router kann ein erhebliches Problem sein. Einige Router so schlimm gewesen , eine Flut von Paketen , um Neighbor Discovery bei der Handhabung , dass es in einem tatsächlichen DoS - Angriffen geworden, und mit mehr Link - Präfixe (im /120
- 127
Bereich) als Abhilfe für solche DoS - Attacken verwendet.
Selbst wenn der Router für den DoS-Angriff nicht anfällig ist, ist der für Einträge im Nachbarcache bei Verwendung der oben beschriebenen Problemumgehung erforderliche Speicher für den Internetdienstanbieter viel teurer als die IP-Adressen für ein geroutetes Präfix, weshalb es kaum einen Grund gibt Damit ein ISP die Weitergabe eines weitergeleiteten Präfixes verweigert.
Sonderfälle rund um Punkt-zu-Punkt-Verbindungen
Bei Punkt-zu-Punkt-Verbindungen (z. B. 6in4-Tunnel und PPP-Verbindungen) ist keine Nachbarerkennung erforderlich. Es gibt nur eine Richtung, um ein Paket auf einer solchen Verbindung zu senden, und es muss keine Hardwareadresse nachgeschlagen werden, bevor das Paket gesendet wird.
Dies bedeutet, dass der Overhead der Nachbarerkennung bei einem solchen Link kein Problem darstellt. Wenn also ein Ende eines Punkt-zu-Punkt-Links viele Adressen verwendet, ist dies kein Problem, solange die Endpunkte eine gewisse Übereinstimmung darüber haben, wer welche Adressen verwendet. Mangelnde Nachbarerkennung bedeutet, dass auch keine doppelte Adresserkennung vorhanden ist. Wenn beide Endpunkte versuchen, dieselbe Adresse zu verwenden, funktioniert dies nicht wie erwartet (es sei denn, Sie erwarten, dass sich die Adresse als Anycast-Adresse verhält).
Bei Punkt-zu-Punkt-Verknüpfungen ist eine Einschränkung zu beachten. Jeder Endpunkt geht davon aus, dass alle Adressen auf dem Link, dem er nicht selbst zugewiesen ist, dem anderen Ende zugewiesen sind. Dies bedeutet, dass nicht verwendete Adressen auf einer Punkt-zu-Punkt-Verbindung dazu neigen, eine Routing-Schleife auszulösen. Eine solche Routing-Schleife (und mehrere andere Fälle von Routing-Schleifen) kann vermieden werden, indem ein Endpunkt ein Paket niemals direkt an den Knoten zurücksendet, von dem es empfangen wurde. Ein von einer Punkt-zu-Punkt-Verbindung empfangenes Paket darf also nicht über dieselbe Punkt-zu-Punkt-Verbindung zurückgesendet werden. Solange ein Endpunkt dies richtig macht, ist die Routing-Schleife unterbrochen. Als Nebenknoten im Ethernet ist es zulässig, ein Paket zu empfangen und es wieder auf dieselbe Verbindung weiterzuleiten. Dies sollte jedoch vermieden werden, wenn es an dieselbe MAC-Adresse weitergeleitet wird, von der es empfangen wurde.
Da die meisten Adressen eines Punkt-zu-Punkt-Links nur an das andere Ende des Links weitergeleitet werden, ohne dass ein Nachbar ermittelt werden muss, ähnelt dies einem gerouteten Präfix. Wenn der ISP beispielsweise einer Punkt-zu-Punkt-Verbindung mit den Endpunkten, denen die Adressen 2001: db8: 42 :: 1 und 2001: db8: 42 :: 2 zugewiesen wurden, 2001: db8: 42 :: 2 zugewiesen hat, werden Pakete an die meisten Adressen gesendet in 2001: db8: 42 :: / 64 wird vom ISP genauso an den Kunden weitergeleitet, wie dies bei einem gerouteten Präfix mit 2001: db8: 42 :: 2 als Gateway der Fall wäre.
Dies bedeutet, dass ein bestimmter Hack möglich ist. Auf dem CPE ist es möglich, 2001: db8: 42 :: / 64 als Link-Präfix im LAN zu konfigurieren. Damit das CPE weiß, auf welcher der beiden Verbindungen sich ein bestimmtes Ziel befindet, müsste die tatsächliche Konfiguration der Punkt-zu-Punkt-Verbindung zum ISP auf 2001 geändert werden: db8: 42 :: / 126. Dies funktioniert mit einer kleinen Ausnahme: Hosts im LAN können 2001 nicht mit den vier IP-Adressen kommunizieren: db8: 42 :: / 126. Da sie wahrscheinlich sowieso nicht mit ihnen kommunizieren mussten, ist dies kein großes Problem. Es wird jedoch nicht empfohlen, diesen Hack zu verwenden. Die richtige Konfiguration besteht darin, ein geroutetes Präfix vom ISP abzurufen.
Ein weiterer Hack zum Speichern von Adressen besteht darin, nur globale Adressen für ein geroutetes Präfix zuzuweisen und RFC 4193-Adressen für die Punkt-zu-Punkt-Verbindung zu verwenden. Dies ist jedoch ein alberner Hack, da er immer noch einige Nachteile mit sich bringt, um ein nicht existierendes Problem zu lösen.
Es ist auch möglich, einem Punkt-zu-Punkt-Link überhaupt kein Präfix zuzuweisen. Solange jeder Endpunkt eine andere Schnittstelle hat, auf der er eine globale Adresse hat, können sie die Adresse verwenden, die der anderen Schnittstelle zugewiesen ist, wenn sie über die Punkt-zu-Punkt-Verbindung kommunizieren. Ich kenne keine Nachteile dieses Ansatzes. Wenn Sie also feststellen, dass dieser Ansatz zum Zeigen von Links Ihre Netzwerkkonfiguration vereinfacht, können Sie ihn verwenden, aber nicht als Maßnahme zum Speichern von Adressen.
Anwendungsfälle für ein weitergeleitetes Präfix
- Hierarchisches Routing wie in meinem ersten Beispiel ist das, wofür die gerouteten Präfixe entwickelt wurden.
- VPN / Tunnel fügen der Hierarchie der Router, die Präfixe benötigen, eine weitere Ebene hinzu. Obwohl es sich eher um virtuelle als um reale Hardware handelt, unterscheiden sie sich hinsichtlich der Adressierung nicht und benötigen ein geroutetes Präfix wie eine physische Verbindung.
- Einem Host viele Adressen zuweisen . Es gibt Anwendungsfälle für die Zuweisung vieler Adressen zu einem einzelnen Host. Für einige Adressen können sie einfach zugewiesen und mit der Nachbarerkennung für jeden und so viele Cache-Einträge verarbeitet werden, wie Adressen vorhanden sind. Wenn jedoch Tausende von Adressen benötigt werden, ist ein geroutetes Präfix besser.
Ein ausführlicheres Beispiel für den letzten Punkt wären DNS-Rekursoren. Da ich sehe, dass DNSSEC erst nach dem Kampf mit IPv4 eine große Wirkung erzielt, sind andere Maßnahmen gegen DNS-Vergiftungen erforderlich. Es wurde versucht, so viel Entropie wie möglich in Abfragen zu bringen. ID und Port-Nummer können höchstens 32 Bit Entropie enthalten, weitere wenige Bit können in der Anforderung enthalten sein, wenn Groß- und Kleinbuchstaben im aufzulösenden Domänennamen gemischt sind. Auf diese Weise werden Sie selten mehr als 48 Bit erreichen. Wenn Sie /64
dem DNS-Recursor einen vollständigen Wert zuweisen, kann die Entropie in einem Durchgang um 64 Bit erhöht werden. Dies ist mehr als alle anderen Bemühungen zusammen.