IPv6: Unterschiede zwischen "Routed Prefix" und "Link Prefix"?


14

Was sind die genauen Unterschiede zwischen "Routing-Präfix" und "Link-Präfix" für IPv6?
Wie machen sich diese Unterschiede in einem Wireshark-Trace bemerkbar? (Wenn Sie einen Host mit einem zugewiesenen "Routing-Präfix" oder einen Host mit einem zugewiesenen "Link-Präfix" beobachten).
Wie wirken sich diese Unterschiede im Neighbor Discovery Protocol aus? (aus der Sicht eines anderen / externen Host)
Haben sie arbeiten zusammen , diese beiden Arten von Präfixen?

Antworten:


19

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::/64sie 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 /64ist 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 /48er /64jedem internen LAN ein Verbindungspräfix zuweisen kann . Wenn wir annehmen, dass eines der LANs 2001:db8:1:1::/64als 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::/60als Routing-Präfix für den WLAN-Router zugewiesen werden, und der WLAN-Router kann 2001:db8:1:100::/64als 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::/64das 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::/48das 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- 127Bereich) 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 /64dem 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.


Ich hätte mit einem Q / A über CIDR verbunden, wenn ich einen guten gefunden hätte. Man muss CIDR auf jeden Fall verstehen, bevor man diese Antwort liest.
Kasperd

Für CIDR scheint der Wikipedia-Artikel in Ordnung zu sein, ein Link zu en.wikipedia.org/wiki/Classless_Inter-Domain_Routing ist meiner Meinung nach für das weitere Verständnis gut.
Erik

Ich habe einige Probleme mit Ihrer Antwort. Sie decken nicht das beobachtete Verhalten ab, nicht für meinen ISP zu Hause und nicht für den Hosting-Anbieter auf meinem Server (beide verwenden keine klassische Nachbarerkennung). <br /> Ich glaube, ich brauche eine detailliertere Beschreibung über den Hauptumfang meiner Frage. Sollte ich meine Frage aktualisieren oder auf eine andere bevorzugte Weise existieren? Entschuldigung, ich bin neu auf serverfault.com / StackExchange.
Erik

Ich bin verwirrt über die Situation, in der Sie sprechen. Meinen Sie einen ISP (zum Beispiel auf einer DSL-Leitung) für eine Internetverbindung für Privathaushalte oder einen Hosting-Anbieter, der Server (mit echtem Ethernet-basiertem LAN) verbindet?
Erik

1
@ 1'OR1-- Wenn ein Paket zu einer nicht verwendeten Adresse innerhalb des /48Pakets ein Nachbar-Anforderungspaket für die Ziel-IP ergibt, hört es sich in der Tat so an, als hätte der Provider das /48als Verbindungspräfix konfiguriert . Das Konfigurieren eines /48als Link-Präfix ist keine empfohlene Konfiguration, aber ich habe von Anbietern gehört, die es trotzdem tun. Wenn es sich um ein geroutetes Präfix handelte, würde unabhängig davon, auf welche IP-Adresse innerhalb /48eines Pakets abgezielt wurde, jedes Mal dieselbe IP-Adresse für die Nachbaranfrage angezeigt. Und wenn Sie darauf geantwortet haben, würden Sie keine Anwerbung von Nachbarn mehr sehen.
Kasperd

3

Zwischen Ihrem Router und Ihrem Internetdienstanbieter wird ein Verbindungspräfix verwendet.

Das geroutete Präfix wird in Ihrem Netzwerk verwendet.

Wenn Sie ein / 64-Routing-Präfix von Ihrem Internetdienstanbieter erhalten, muss Ihr Router dieses Präfix lediglich in Ihrem LAN ankündigen. Wenn Sie ein Präfix kleiner als / 64 (vielleicht ein / 48?) Haben, sollten Sie überlegen, wie Sie dieses Präfix auf logische Weise in ein Subnetz einbinden, damit es von allen Routern in Ihrer Organisation verwendet werden kann.

Abhängig davon, wo Sie die Pakete erfassen, wird in Wireshark möglicherweise nur das geroutete Präfix angezeigt (wenn Sie im LAN erfassen) oder es werden beide Präfixe angezeigt (wenn Sie im WAN erfassen).

In Bezug auf das Neighbor Discovery-Protokoll hängt es auch von der Verbindung ab. Auf der Verbindung zwischen dem ISP und Ihrem Router wird NDP verwendet, um die MAC-Adresse der WAN-Schnittstelle Ihres Routers und die MAC-Adresse des Upstream-Routers Ihres ISP zu ermitteln. Auf Ihrer LAN-Schnittstelle wird NDP verwendet, um die MAC-Adresse der Hosts in Ihrem LAN-Segment zu ermitteln.

Hoffe das hilft.


1
Es ist If you received a /64 from your ISP, then you would simply have your router advertise that prefix on your LANwahrscheinlich, dass der Satz weniger missverstanden wird, wenn Sie explizit angeben, dass /64er auf das weitergeleitete Präfix verweist.
Kasperd

2

Ein Präfix ist ein geroutetes Präfix, wenn Pakete zu diesem Präfix einen Router durchlaufen müssen, um ihr Ziel zu erreichen. Ein Präfix ist ein Link-Präfix, wenn es sich in einem Segment befindet, an das eine lokale Netzwerkschnittstelle angeschlossen ist.

Wenn ein Paket über das Internet übertragen wird, wird es als geroutetes Präfix festgelegt, bis Sie den letzten Hop erreichen. Dann wird es ein Link-Präfix sein.

Weitergeleitete Präfixe werden normalerweise aggregiert. Viele / 64-Adressen können zu einem einzelnen kürzeren Präfix zusammengefasst werden, um die Routingtabellen kleiner zu halten. An der Grenze zwischen Internetprovidern ist es üblich, eine maximale Präfixlänge von / 48 durchzusetzen.

Wenn ein Präfix zwischen / 0 und / 63 liegt, können Sie normalerweise davon ausgehen, dass es sich um ein geroutetes Präfix handelt. Wenn das Präfix / 64 lautet, benötigen Sie weitere Informationen, um festzustellen, ob es sich um ein geroutetes oder ein Link-Präfix handelt.

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.