Zum Hauptinhalt springen

RFC 4659 - BGP-MPLS-IP-VPN-Erweiterung für IPv6-VPNs

  • Status: Vorgeschlagener Standard
  • Veröffentlicht: September 2006
  • Dokumentenstrom: IETF
  • Errata: Keine Errata

Dokumentinformationen​

  • RFC-Nummer: 4659
  • Titel: BGP-MPLS-IP-VPN-Erweiterung für IPv6-VPNs
  • Autoren: J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur
  • Datum: September 2006
  • Kategorie: Standardisierungsverfahren
  • ISSN: 2070-1721

Zusammenfassung​

Dieses Dokument beschreibt ein Verfahren, mit dem ein Dienstanbieter sein paketvermitteltes Backbone nutzen kann, um seinen IPv6-Kunden Virtual-Private-Network-Dienste (VPN) bereitzustellen. Das Verfahren verwendet die BGP/MPLS-IP-VPN-Methode erneut und erweitert sie bei Bedarf für IPv6. Bei BGP/MPLS-IP-VPNs verteilt Multiprotocol BGP die IPv4-VPN-Routen über das Backbone des Dienstanbieters, während MPLS die IPv4-VPN-Pakete über das Backbone weiterleitet. Dieses Dokument definiert eine IPv6-VPN-Adressfamilie und beschreibt die entsprechende Verteilung von IPv6-VPN-Routen mit Multiprotocol BGP. Der IPv6-VPN-Dienst wird sowohl über IPv4- als auch über IPv6-Backbones unterstützt; im Kern können verschiedene Tunneltechniken eingesetzt werden, darunter MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) und IPsec-geschützte Tunnel. Die Zusammenarbeit zwischen einem IPv4- und einem IPv6-Standort liegt außerhalb des Geltungsbereichs dieses Dokuments.

Status dieses Memos​

Dieses Dokument gibt ein Internet-Standards-Trackprotokoll für die Internet-Community an und fordert Diskussionen und Verbesserungsvorschläge. Bitte beachten Sie die aktuelle Ausgabe der "Internet Official Protocol Standards" (STD 1) für den Standardisierungszustand und den Status dieses Protokolls. Die Verbreitung dieses Memos ist unbegrenzt.

Urheberrechtshinweis​

Copyright (C) Die Internet Society (2006).

Inhaltsverzeichnis​

1. Einleitung​

Dieses Dokument beschreibt eine Methode, mit der ein Service Provider sein paketgeschaltenes Backbone nutzen kann, um seinen IPv6-Kunden Virtual Private Network-Dienste bereitzustellen.

Diese Methode verwendet und erweitert bei Bedarf die Methode „BGP/MPLS IP VPN" [BGP/MPLS-VPN] zur Unterstützung von IPv6. Insbesondere verwendet diese Methode dasselbe „Peer-Modell" wie [BGP/MPLS-VPN], in dem die Edge-Router („CE Router") der Kunden ihre IPv6-Routen an die Edge-Router des Service Providers („PE Router") senden. BGP („Border Gateway Protocol", [BGP, BGP-MP]) wird dann vom Service Provider verwendet, um die Routen eines bestimmten IPv6 VPN unter den PE Routern auszutauschen, die an das IPv6 VPN angeschlossen sind. Schließlich verteilen die PE Router, an die CE Router in einem bestimmten VPN, die IPv6 Routen von anderen CE Routern in diesem VPN. Wie bei IPv4 VPNs, ein Schlüsselmerkmal dieses "Peer-Modell" ist, dass die (IPv6) CE Router innerhalb eines (IPv6) VPN nicht miteinander zu Peer; es gibt keine "Überlagerung" sichtbar für die (IPv6) VPN Routing-Algorithmus.

Dieses Dokument nimmt die Definitionen, Akronyme und Mechanismen an, die in [BGP/MPLS-VPN] beschrieben sind. Sofern nicht anders angegeben, gelten die Mechanismen von [BGP/MPLS-VPN] und werden hier nicht neu beschrieben.

Ein VPN soll ein IPv6 VPN sein, wenn jede Site dieses VPN IPv6 fähig ist und über eine IPv6 Schnittstelle oder eine Unterschnittstelle mit dem Service Provider (SP) Backbone über ein Provider Edge Gerät (PE) nativ verbunden ist.

Eine Seite kann sowohl IPv4 fähig als auch IPv6 fähig sein. Die logische Schnittstelle, auf der Pakete an der PE ankommen, kann die IP-Version bestimmen. Alternativ kann die gleiche logische Schnittstelle sowohl für IPv4 und IPv6 verwendet werden, in diesem Fall ein per-Paket Blick auf das Feld Version des IP-Paketkopfes bestimmt die IP-Version.

Dieses Dokument betrifft sich nur mit der IPv6-Kommunikation zwischen IPv6-Hosts auf IPv6-fähigen Standorte. Der Umgang mit IPv4-Hosts auf IPv4-fähigen Standorte ist außerhalb des Geltungsbereichs dieses Dokuments und ist in [BGP/MPLS-VPN] abgedeckt. Die Kommunikation zwischen einem IPv4-Host in einer IPv4-fähigen Standort und einem IPv6-Host in einer IPv6-fähigen Standort liegt außerhalb des Geltungsbereichs dieses Dokuments.

Ähnlich wie IPv4 VPN-Routen in [BGP/MPLS-VPN] verteilt werden, werden BGP und seine Erweiterungen verwendet, um Routen von einer IPv6 VPN-Standort an alle anderen PE-Router zu verteilen, die mit einer Standort desselben IPv6 VPN verbunden sind. PEs verwenden "VPN Routing and Forwarding tables" (VRFs), um die Erreichbarkeitsinformationen und die Weiterleitungsinformationen jedes IPv6 VPN separat zu pflegen.

Wie bei IPv4 VPNs [BGP/MPLS-VPN] ermöglichen wir jedem IPv6 VPN einen eigenen IPv6 Adressraum, was bedeutet, dass eine bestimmte Adresse verschiedene Systeme in verschiedenen VPNs bezeichnen kann. Dies wird über eine neue Adressfamilie erreicht, die VPN-IPv6 Adressfamilie, ähnlich der der VPN-IPv4 Adressfamilie, die in [BGP/MPLS-VPN] definiert ist, die eine Route Distinguisher zur IP-Adresse vorstellt.

Zusätzlich zu seinem Betrieb über MPLS Label Switched Paths (LSPs) wurde die IPv4 BGP/MPLS VPN-Lösung erweitert, um den Betrieb über andere Tunneltechniken zu ermöglichen, einschließlich GRE-Tunnel, IP-in-IP-Tunnel [2547-GRE/IP], L2TPv3-Tunnel [MPLS-in-L2TPv3] und IPsec-geschützte Tunnel [2547-IPsec]. In ähnlicher Weise ermöglicht dieses Dokument die Unterstützung eines IPv6 VPN-Dienstes über MPLS LSPs sowie über andere Tunneltechniken.

Dieses Dokument ermöglicht die Unterstützung eines IPv6 VPN-Dienstes über ein IPv4 Backbone sowie über ein IPv6 Backbone. Der unterstützte IPv6 VPN-Dienst ist in beiden Fällen identisch.

Die in diesem Dokument definierte IPv6 VPN-Lösung bietet folgende Vorteile:

  • Sowohl aus der Sicht des Service Providers als auch aus der Sicht des Kunden ist der VPN-Dienst, der für IPv6-Sites unterstützt werden kann, identisch mit dem, der für IPv4-Sites unterstützt werden kann.

  • Aus Sicht des Service Providers erfordern die Operationen des IPv6 VPN-Dienstes genau dieselben Fähigkeiten, Verfahren und Mechanismen wie die des IPv4 VPN-Dienstes.

  • Werden sowohl IPv4-VPN als auch IPv6-VPN-Dienste über einen IPv4-Kern unterstützt, werden für beide die gleichen MP-BGP-Peering-Beziehungen und das gleiche PE-PE-Tunnelnetz verwendet. (MAY)

  • Der IPv6 VPN-Dienst ist unabhängig davon, ob der Kern IPv4 oder IPv6 läuft. Damit ist der vor und nach einer Migration des Kerns von IPv4 auf IPv6 unterstützte IPv6 VPN-Dienst für den VPN-Kunden unwiderruflich.

Beachten Sie, dass die Unterstützung von IPv4 VPN-Diensten über einen IPv6-Kern nicht in diesem Dokument enthalten ist.

2. Die VPN-IPv6-Adressfamilie​

Die BGP Multiprotokoll-Erweiterungen [BGP-MP] ermöglichen es BGP, Routen von mehreren „Adressenfamilien" zu tragen. Wir führen den Begriff der „VPN-IPv6-Adressenfamilie" ein, der der VPN-IPv4-Adressenfamilie ähnlich ist, die in [BGP/MPLS-VPN] eingeführt wurde.

Eine VPN-IPv6-Adresse ist eine 24-Oktett-Menge, beginnend mit einem 8-Oktett "Route Distinguisher" (RD) und endet mit einer 16-Oktett IPv6-Adresse.

Der Zweck der RD ist es, nur zu erlauben, dass man verschiedene Routen zu einem gemeinsamen IPv6-Adressen-Präfix, die dem Zweck der RD definiert in [BGP/MPLS-VPN] ähnlich ist. In der gleichen Weise wie es möglich ist, ist es pro [BGP/MPLS-VPN], die RD verwendet werden kann, um mehrere verschiedene Routen zu dem gleichen System zu erstellen. Dies kann durch die Schaffung von zwei verschiedenen VPN-IPv6-Routen, die den gleichen IPv6-Teil, aber verschiedene RDs. Dies ermöglicht den Anbieter BGP, mehrere verschiedene Routen auf das gleiche System zu installieren und ermöglicht es, Politik verwendet werden, um zu entscheiden, welche Pakete verwenden, welche Route.

Wenn zwei VPNs das gleiche IPv6-Adressenpräfix verwenden würden (wirksamerweise verschiedene physikalische Systeme benennen), würden die PEs diese in einzigartige VPN-IPv6-Adressenpräfixe mit verschiedenen RDs übersetzen. Dies stellt sicher, dass es möglich ist, zwei völlig unterschiedliche Routen zu dieser Adresse, eine für jedes VPN, zu installieren, wenn dieselbe Adresse jemals in zwei verschiedenen VPNs verwendet wird.

Da VPN-IPv6-Adressen und IPv6-Adressen zu verschiedenen Adressfamilien gehören, behandelt BGP sie nie als vergleichbare Adressen.

Ein VRF kann mehrere gleich kostende VPN-IPv6-Routen für ein einzelnes IPv6-Adressen-Präfix haben. Wenn die Zieladresse eines Pakets in einem VRF gegen eine VPN-IPv6-Route angepasst wird, wird nur der IPv6-Teil tatsächlich angepasst.

Das Format und die Kodierung der Route Distinguisher sind in [BGP/MPLS-VPN] angegeben.

Wenn eine Seite IPv4 fähig und IPv6 fähig ist, wird dieselbe RD MAY für die Anzeige von IPv6 Adressen und IPv4 Adressen verwendet. Alternativ wird eine andere RD MAY für die Anzeige der IPv4 Adressen und der IPv6 Adressen verwendet. Beachten Sie jedoch, dass im Rahmen dieser Spezifikation IPv4 Adressen und IPv6 Adressen immer in separaten Kontexten behandelt werden und keine IPv4-IPv6 Interworking Probleme und Techniken diskutiert werden.

3. Verteilung von VPN-IPv6-Routen​

3.1. Routenverteilung zwischen PEs mittels BGP​

Wenn zwei Standorte eines VPNs an PEs anhängen, die sich im gleichen autonomen System befinden, können die PEs über eine interne Verbindung zwischen ihnen (IPv4) VPN-Routen untereinander verteilen. Alternativ kann jede PE iBGP-Verbindungen zu Routenreflektoren haben. Ebenso können PEs für IPv6 VPN-Routenverteilung iBGP-Verbindungen zwischen ihnen verwenden oder iBGP-Verbindungen zu Routenreflektoren verwenden. Für IPv6 VPN sind die iBGP-Verbindungen MAY über IPv4 oder IPv6. [BGP/MPLS-VPN]

Die PE Router tauschen über MP-BGP [BGP-MP] die IPv6-Präfixe in den IPv6 VPNs aus und melden sich damit als BGP Next Hop.

Die Regeln für die Kodierung der Erreichbarkeitsinformationen und der BGP Next Hop Adresse sind in den folgenden Abschnitten festgelegt.

3.2. Codierung der VPN-IPv6-NLRI​

Bei der Verteilung von IPv6 VPN-Routen muss (MUST) der Werbe-PE-Router MPLS-Labels mit den IPv6 VPN-Routen zuweisen und verteilen. Im Wesentlichen verteilen PE-Router keine IPv6 VPN-Routen, sondern beschriftete IPv6 VPN-Routen [MPLS-BGP]. Wenn die Werbe-PE dann ein Paket erhält, das dieses spezielle beworbene Label hat, wird das PE dieses Label vom MPLS-Stack aus aufschlagen und das Paket entsprechend verarbeiten (d.h. es direkt nach dem Label weiterleiten oder im entsprechenden IPv6-VPN-Kontext einen Lookup durchführen).

Die BGP-Multiprotokollerweiterungen [BGP-MP] werden verwendet, um IPv6-VPN-Routen in den MP_REACH Network Layer Reachability Information (NLRI) anzukündigen. Die Felder Address Family Identifier (AFI) und Subsequent Address Family Identifier (SAFI) MUST wie folgt gesetzt werden:

  • AFI: 2; für IPv6

  • SAFI: 128; für MPLS-markierte VPN-IPv6-Adressen

Das NLRI-Feld selbst ist gemäß [MPLS-BGP] kodiert. Im Rahmen dieser Erweiterung gehört das Präfix zur VPN-IPv6 Adressfamilie und besteht somit aus einem 8-Oktett-Route Distinguisher, gefolgt von einem IPv6-Präfix gemäß Abschnitt 2 oben.

3.2.1. Codierung des BGP-Next-Hop​

Die Kodierung des BGP Next Hop hängt davon ab, ob die Richtlinie des BGP-Lautsprechers die Übertragung des IPv6 VPN-Verkehrs an diesen BGP Next Hop mit Hilfe von IPv6-Tunnel ("BGP-Lautsprecher, der IPv6-Transport anfordert") oder mit IPv4-Tunnel ("BGP-Lautsprecher, der IPv4-Transport anfordert") fordert.

Die Definition dieser Richtlinie (Transport über IPv4-Tunnel oder IPv6-Tunnel) liegt in der Verantwortung des Netzbetreibers und liegt außerhalb des Geltungsbereichs dieses Dokuments. Beachten Sie, dass es möglich ist, Transport über IPv4 (Resp. IPv6) zu fordern, während die BGP-Sprecher IPv6 VPN-Erreichbarkeitsinformationen über IPv6 (Resp. IPv4) austauschen. In diesem Fall sind jedoch eine Reihe von betrieblichen Implikationen zu berücksichtigen. Insbesondere ein nicht erkannter Fehler, der den IPv4 (Resp. IPv6) Tunneldatenpfad und nicht beeinflussen den IPv6 (Resp. IPv4) Datenpfad könnte durch BGP nicht erkannt bleiben, was wiederum zu Black-Holing des Verkehrs führen kann.

Die Kontrolle dieser Richtlinie liegt außerhalb des Geltungsbereichs dieses Dokuments und kann auf der Benutzerkonfiguration basieren.

3.2.1.1. BGP-Sprecher fordert IPv6-Transport an​

Wenn der IPv6 VPN-Datenverkehr über IPv6 Tunnel zum BGP-Lautsprecher transportiert werden soll (SHALL) (z.B. IPv6 MPLS LSPs, IPsec-geschützte IPv6-Tunnel), werben die BGP-Lautsprecher ein Next Hop Network Address Feld mit einer VPN-IPv6 Adresse

  • dessen 8-Oktett-RD auf Null gesetzt ist und

  • dessen 16-Octet IPv6-Adresse auf die globale IPv6-Adresse des Werbe-BGP-Lautsprechers gesetzt ist.

Dies wird möglicherweise von einer anderen VPN-IPv6-Adresse gefolgt

  • dessen 8-Oktett-RD auf Null gesetzt ist und

  • dessen 16-Octet IPv6-Adresse auf die link-local IPv6-Adresse des Werbe-BGP-Lautsprechers gesetzt ist.

Der Wert der Länge des Feldes Next Hop Network Address im MP_REACH_NLRI-Attribut ist auf 24 zu setzen, wenn nur eine globale Adresse vorhanden ist, und auf 48, wenn eine link-local-Adresse auch im Feld Next Hop enthalten ist.

Wenn die BGP-Lautsprecher nur ihre link-local IPv6-Adresse verwenden (z. B. wenn ein IPv6-CE-Peer mit IPv6-PE, bei dem die CE keine IPv6-Globaladresse hat und bei dem eBGP-Peering über die link-local-Adressen erreicht wird), wird die "unspezifizierte Adresse" ([V6ADDR]) von der Werbe-BGP-Lautsprecherin verwendet, um das Fehlen der globalen IPv6-Adresse im Feld Next Hop Network Address anzuzeigen.

Die link-local Adresse wird im Feld Next Hop eingetragen, wenn und nur, wenn der WerbebGP-Sprecher ein gemeinsames Subnetz mit dem Peer teilt, die Route an [BGP-IPv6] geworben wird.

In allen anderen Fällen soll ein BGP-Sprecher im Feld Next Hop Network Address nur die globale IPv6-Adresse des nächsten Hops an seinen Peer ankündigen.

Als Folge kann ein BGP-Sprecher, der eine Route zu einem internen Peer annonciert, die Netzwerkadresse des Next Hop-Feldes ändern, indem er die link-local IPv6-Adresse des nächsten Hop entfernt.

Ein Beispiel, bei dem sowohl die globale IPv6-Adresse als auch die link-local IPv6-Adresse in das BGP Next Hop-Adressenfeld aufgenommen werden soll, ist, dass der IPv6-VPN-Dienst über ein multi-autonomes System (AS)-Backbone mit Umverteilung von beschrifteten VPN-

IPv6-Routen zwischen autonomen System-Grenzroutern (ASBR) verschiedener ASes, die ein gemeinsames IPv6-Subnetz teilen: In diesem Fall werden sowohl die globale IPv6-Adresse als auch die link-local IPv6-Adresse von den ASBRs ausgeschrieben.

3.2.1.2. BGP-Sprecher fordert IPv4-Transport an​

Wenn der IPv6 VPN-Verkehr über IPv4-Tunnel (z.B. IPv4 MPLS LSPs, IPsec-geschützte IPv4-Tunnel) zum BGP-Lautsprecher transportiert werden soll (SHALL), werben die BGP-Lautsprecher für ein Next Hop Network Address-Feld mit einer VPN-IPv6-Adresse:

  • dessen 8-Oktett-RD auf Null gesetzt ist und

  • dessen 16-Octet IPv6-Adresse als IPv4-gemappete IPv6-Adresse [V6ADDR] mit der IPv4-Adresse des WerbebGP-Lautsprechers kodiert ist. Diese IPv4-Adresse muss vom anderen BGP-Lautsprecher verlötbar sein.

3.3. Route Target​

Die Verwendung von Routenzielen ist in [BGP/MPLS-VPN] angegeben und gilt für IPv6 VPNs. Die Kodierung des erweiterten Community-Attributs ist in [BGP-EXTCOM] definiert.

3.4. Aushandlung von BGP-Fähigkeiten​

Damit zwei PEs mit dem Namen IPv6 VPN NLRIs austauschen können, müssen (MUST) sie BGP Capabilities Negotiation verwenden, um sicherzustellen, dass beide diese NLRIs ordnungsgemäß verarbeiten können. Dies geschieht gemäß den Angaben in [BGP-MP] und [BGP-CAP], indem sie den Code 1 (Multiprotokoll BGP) mit AFI- und SAFI-Werten wie oben in Abschnitt 3.2 verwenden.

4. Kapselung​

Der ingress PE Router MUSS (MUST) IPv6 VPN-Daten über das Backbone zum Egress PE Router tunneln, der als BGP Next Hop für das entsprechende Ziel IPv6 VPN-Präfix identifiziert wurde.

Wenn die im BGP Next Hop-Feld enthaltene IPv6-Adresse mit 16 Oktett als IPv4-fähige IPv6-Adresse kodiert wird (siehe Abschnitt 3.2.1.2), muss (MUST) der Eingang PE IPv4-Tunnel verwenden, sofern nicht ausdrücklich anders konfiguriert. Optional erlaubt der Eingang PE MAY durch explizite Konfiguration die Verwendung von IPv6-Tunnel, wenn die im BGP Next Hop-Feld enthaltene IPv6-Adresse mit 16 Oktett als IPv4-gemapte IPv6-Adresse kodiert wird. Dies würde die Unterstützung bestimmter Bereitstellungsumgebungen ermöglichen, in denen IPv6 Tunneling gewünscht wird, in denen IPv6 Adressen aber für IPv6 erreichbar sind, anstatt für globale IPv6 Adressen.

Wenn die im BGP Next Hop-Feld enthaltene IPv6-Adresse mit 16 Oktett nicht als IPv4-fähige Adresse kodiert ist (siehe Abschnitt 3.2.1.1), muss (MUST) der Eingang PE IPv6-Tunnel verwenden.

Wenn ein PE ein Paket von einer angeschlossenen CE erhält, schaut es die IPv6 Zieladresse des Pakets in der VRF entsprechend dieser CE auf. Dies ermöglicht es, eine VPN-IPv6 Route zu finden. Die VPN-IPv6 Route wird ein zugehöriges MPLS Label und ein zugehöriges BGP Next Hop haben. Zuerst wird dieses MPLS Label auf das Paket als unteres Etikett gedrückt. Dann wird dieses beschriftete Paket in den Tunnel eingekapselt, um den vom BGP Next Hop identifizierten Egress PE zu transportieren. Details dieser Verkapselung hängen von der tatsächlichen Tunneltechnik ab, wie folgt:

Wie bei MPLS/BGP für IPv4 VPNs [2547-GRE/IP] ergibt sich bei Tunneln mit IPv4 Tunneln oder IPv6 Tunneln (bzw. IPv4 GRE Tunneln oder IPv6 GRE Tunneln) die Verkapselung des beschrifteten IPv6 VPN Pakets in einem MPLS-in-IP (bzw. MPLS-in-GRE) kapselten Paket gemäß [MPLS-in-IP/GRE]. Wenn Tunneln mit L2TPv3 durchgeführt wird, ergibt sich bei der Verkapselung des beschrifteten IPv6 VPN Pakets ein MPLS-in-L2TPv3-verkapseltes Paket, wie in [MPLS-in-L2TPv3] angegeben.

Wie bei MPLS/BGP für IPv4 VPNs führt auch bei Tunneln mit einem IPsec-gesicherten Tunnel [2547-IPsec] die Verkapselung des beschrifteten IPv6 VPN-Pakets zu einem MPLS-in-IP- oder MPLS-in-GRE-verkapselten Paket [MPLS-in-IP/GRE]. Der IPsec-Transportmodus dient dazu, diesen IPv4 oder GRE-Tunnel vor dem Eindringen PE zu sichern und PE zu verlassen.

Wenn Tunnel mit IPv4-Tunneln durchgeführt werden (ob IPsec gesichert ist oder nicht), muss (MUST) der Ingress PE Router die IPv4-Adresse verwenden, die im IPv4-gemappeten IPv6-Adressfeld des nächsten Hop-Feldes als Zieladresse des vorgefertigten IPv4-Tunnelskopfes kodiert ist. Er verwendet eine seiner IPv4-Adressen als Quelladresse des vorgefertigten IPv4-Tunnelskopfes.

Wenn Tunnel mit IPv6 Tunneln durchgeführt werden (ob IPsec gesichert ist oder nicht), muss (MUST) der Ingress PE Router die IPv6 Adresse verwenden, die im IPv6 Adressfeld des nächsten Hopfeldes des BGP als Zieladresse des vorgezeichneten IPv6 Tunnelkopfes enthalten ist. Er verwendet eine seiner IPv6 Adressen als Quelladresse des vorgezeichneten IPv6 Tunnelkopfes.

Wenn der Tunnel mit MPLS LSPs durchgeführt wird, können die LSPs mit jeder beliebigen Labelverteilungstechnik (LDP [LDP], RSVP-TE [RSVP-TE], etc.) erstellt werden.

Wenn der Tunnel mit MPLS LSPs durchgeführt wird, muss (MUST) der ingress PE Router das LSP Tunnel Label direkt auf den Labelstapel des beschrifteten IPv6 VPN Pakets schieben (d.h. ohne Vorauszahlung eines IPv4 oder IPv6 Headers). Dieses geschobene Label entspricht dem LSP, das auf dem ingress PE Router beginnt und auf dem egress PE Router endet. Das BGP Next Hop Feld dient zur Identifizierung des egress PE Routers und wiederum dem Label, das auf dem Stack geschoben wird. Wenn die IPv6-Adresse im BGP Next Hop-Feld eine IPv4-gemappete IPv6-Adresse ist, bestimmt die eingebettete IPv4-Adresse das Tunneletikett, das auf den Etikettenstapel gedrückt wird. In jedem anderen Fall bestimmt die IPv6-Adresse im BGP Next Hop-Feld das Tunneletikett, um den Etikettenstapel zu drücken.

Um die Interoperabilität zwischen Systemen zu gewährleisten, die diese VPN-Architektur implementieren, müssen (MUST) alle Systeme den Tunnelbau mit Hilfe von MPLS-LSPs unterstützen, die von LDP [LDP] eingerichtet wurden.

5. Adresstypen​

Da die Link-local Unicast-Adressen nur für einen einzigen Link definiert sind, können diese auf dem PE-CE-Link verwendet werden, werden sie jedoch nicht für die Erreichbarkeit über IPv6 VPN-Sites unterstützt und werden niemals über MultiProtokoll-Border Gateway Protocol (MP-BGP) zu entfernten PEs beworben.

Globale Unicast-Adressen werden als einzigartige Schnittstellen überall im IPv6 Internet definiert. Globale Adressen werden voraussichtlich häufig innerhalb und über IPv6 VPN-Sites verwendet. Sie werden offensichtlich von dieser IPv6 VPN-Lösung unterstützt, um IPv6 VPN-Sites zu erreichen und über MP-BGP an entfernte PEs anzukündigen und werden ohne spezifische Überlegungen zu ihrem globalen Anwendungsbereich verarbeitet.

Zitat aus [UNIQUE-LOCAL]: „Dieses Dokument definiert ein weltweit einzigartiges IPv6-Unicast-Adressformat, das für die lokale Kommunikation bestimmt ist [IPv6]. Diese Adressen werden Unique Local IPv6 Unicast-Adressen genannt und werden in diesem Dokument als lokale IPv6-Adressen abgekürzt. Sie werden im globalen Internet nicht im globalen Internet routbar sein. Sie sind innerhalb eines eingeschränkteren Bereichs wie einer Standort routingfähig. Sie können auch zwischen einer begrenzten Anzahl von Standorte geroutet werden."

  • [UNIQUE-LOCAL] also says in its Section 4.7: "Local IPv6 addresses can be used for inter-site Virtual Private Networks (VPN) if appropriate routes are set up. Because the addresses are unique these VPNs will work reliably and without the need for translation. They have the additional property that they will continue to work if the individual sites are renumbered or merged."

Entsprechend werden die Unicast Adressen von Unicast Adressen von Unicast Adressen unterstützt, die IPv6 VPN Lösungen für die Erreichbarkeit über IPv6 VPN Seiten in diesem Dokument spezifiziert. Daher kann die Erreichbarkeit solcher Unicast Adressen über MP-BGP an entfernte PEs geworben und von PEs in der gleichen Weise wie globale Unicast Adressen verarbeitet werden.

Empfehlungen und Überlegungen, für welche dieser unterstützten Adresstypen in gegebenen IPv6 VPN-Umgebungen verwendet werden sollen, liegen außerhalb des Geltungsbereichs dieses Dokuments.

6. Multicast​

Multicast-Operationen sind nicht in den Anwendungsbereich dieses Dokuments fallen.

7. Carrier's Carrier​

Manchmal kann ein IPv6 VPN tatsächlich das Netzwerk eines IPv6 ISP sein, mit eigenen Peering- und Routing-Richtlinien. Manchmal kann ein IPv6 VPN das Netzwerk eines SP sein, das wiederum VPN-Dienste für seine eigenen Kunden anbietet. IPv6 VPNs wie diese können auch Rückgrat-Service von einem anderen SP, dem "Carrier's Carrier", erhalten, wobei die Carrier' Carrier-Methode in Abschnitt 9 [BGP/MPLS-VPN] beschrieben wird, aber auf IPv6-Verkehr angewendet wird. Alle in [BGP/MPLS-VPN] für IPv4 VPN Carriers' Carrier erörterten Überlegungen gelten für IPv6 VPN, mit der Ausnahme, dass die Verwendung von MPLS (einschließlich Label-Distribution) zwischen der PE und der CE auf IPv6-Routen statt IPv4-Routen erfolgt.

8. Multi-AS-Backbones​

Die gleichen Verfahren wie in Abschnitt 10 [BGP/MPLS-VPN] beschrieben können verwendet werden (und haben die gleichen Skalierbarkeitseigenschaften), um die Situation zu adressieren, in der zwei Standorte eines IPv6 VPN mit verschiedenen Autonomen Systemen verbunden sind.

bei der Anwendung dieser Verfahren für IPv6 VPNs; diese werden im übrigen Abschnitt näher beschrieben.

Ansatz (a): VRF-zu-VRF-Verbindungen an den AS-Grenzroutern (Autonomes System).

Dieser Ansatz ist der Äquivalent für IPv6 VPNs zu Prozedur (a) in Abschnitt 10 von [BGP/MPLS-VPN]. Bei IPv6 VPNs muss (MUST) IPv6 auf den inter-ASBR VRF-to-VRF (Sub)-Schnittstellen aktiviert werden. In diesem Ansatz tauschen die ASBRs IPv6 Routen (im Gegensatz zu VPN-IPv6 Routen) aus und können über IPv6 oder über IPv4 peeren. Der Austausch von IPv6 Routen MUSS gemäß [BGP-IPv6] durchgeführt werden. Diese Methode verwendet keine inter-AS LSPs.

Schließlich ist darauf hinzuweisen, dass die teilnehmenden ASs mit diesem Verfahren, da jedes AS unabhängig die in diesem Dokument beschriebenen Intra-AS-Verfahren für IPv6 VPNs implementiert, alle internen IPv4-Tunnel verwenden können, oder alternativ können einige teilnehmende ASs IPv4-Tunnel verwenden, während andere IPv6-Tunnel verwenden.

Ansatz (b): EBGP-Umverteilung der beschrifteten VPN-IPv6-Routen von AS zu benachbarten AS.

Dieser Ansatz ist für IPv6 VPNs mit Prozedur (b) in Abschnitt 10 [BGP/MPLS-VPN] vergleichbar. Mit diesem Ansatz verwenden die ASBRs EBGP, um beschriftete VPN-IPv4-Routen zu ASBRs in anderen ASs umzuverteilen.

Bei diesem Ansatz kann IPv6 auf den Inter-ASBR-Verbindungen aktiviert sein oder nicht, da die ASBRs, die VPN-IPv6-Routen austauschen, über IPv4 oder IPv6 peeren können (im letzteren Fall muss IPv6 auf der Inter-ASBR-Verbindung selbstverständlich aktiviert sein). Der Austausch markierter VPN-IPv6-Routen MUST gemäß [BGP-IPv6] und [MPLS-BGP] erfolgen. Wird der VPN-IPv6-Verkehr über IPv6-Tunnel transportiert, SHALL das BGP-Next-Hop-Feld eine IPv6-Adresse enthalten. Wird er über IPv4-Tunnel transportiert, SHALL dieses Feld eine als IPv4-mapped IPv6 address codierte IPv4-Adresse enthalten.

Dieser Ansatz erfordert die Schaffung von inter-AS-LSPs. Daher gelten die entsprechenden (Sicherheits-) Überlegungen, die für das Verfahren (b) in Abschnitt 10 [BGP/MPLS-VPN] beschrieben werden, für diesen Ansatz für IPv6 gleichermaßen.

Schließlich ist darauf hinzuweisen, dass mit diesem Verfahren, wie bei Verfahren (a), da jedes AS unabhängig die in diesem Dokument beschriebenen Intra-AS-Verfahren für IPv6 VPNs implementiert, die teilnehmenden ASs alle intern IPv4 Tunneling oder IPv6 Tunneling verwenden können; alternativ können einige teilnehmende ASs intern IPv4 Tunneling verwenden, während andere IPv6 Tunneling verwenden.

Vorgehensweise (c): Multihop EBGP Umverteilung der beschrifteten VPN-IPv6-Routen zwischen Quell- und Ziel-ASes, mit EBGP Umverteilung der beschrifteten IPv4- oder IPv6-Routen von AS zu benachbartem AS.

Dieser Ansatz ist für den Austausch von VPN-IPv6-Routen zum Verfahren (c) in Abschnitt 10 [BGP/MPLS-VPN] für den Austausch von VPN-IPv4-Routen äquivalent.

Dieser Ansatz erfordert, dass die teilnehmenden ASes entweder alle IPv4-Tunnel verwenden oder alle IPv6-Tunnel verwenden.

In diesem Ansatz werden VPN-IPv6-Routen weder von den ASBR-Routern gewartet noch verteilt. Die ASBR-Router müssen nicht Dual-Stack-fähig werden. Ein ASBR muss die beschrifteten IPv4 (oder IPv6)-Routen zu den PE-Routern innerhalb seiner AS beibehalten. Es verwendet EBGP, um diese Routen auf andere ASes zu verteilen. ASBRs in jedem Transit ASes müssen auch EBGP verwenden, um die beschrifteten IPv4 (oder IPv6)-Routen zu passieren. Dies führt zur Schaffung eines IPv4 (oder IPv6)-Label-Schaltpfads vom ingress PE-Router zum austretenden PE-Router. Nun können PE Router in verschiedenen ASs über IPv4 oder IPv6 EBGP-Verbindungen mit mehreren Hop-Verbindungen miteinander aufbauen und beschriftete VPN-IPv6-Routen über diese EBGP-Verbindungen austauschen. Beachten Sie, dass das BGP-Nächster Hop-Feld dieser verteilten VPN-IPv6-Routen eine IPv6-Adresse bei IPv6-Tunnel oder eine IPv4-gemappete IPv6-Adresse bei IPv4-Tunnel verwendet.

Die in Abschnitt 10 [BGP/MPLS-VPN] beschriebenen Überlegungen zu einer möglichen Verwendung von Streckenreflektoren in Bezug auf die mögliche Verwendung eines dritten Labels und in Bezug auf LSPs, die mehrere ASs umfassen, gelten gleichermaßen für diesen IPv6 VPN-Ansatz.

9. Internetzugriff aus einem VPN​

Die von [BGP/MPLS-VPN] vorgeschlagenen Methoden, um über IPv4 VPN auf das globale IPv4 Internet zuzugreifen, können im Kontext von IPv6 VPNs und dem globalen IPv6 Internet verwendet werden. Beachten Sie jedoch, dass, wenn die IPv6 Pakete von IPv6 VPN-Sites und für das globale IPv6 Internet bestimmt sind, das SP-Backbone durchqueren müssen und wenn es sich um ein IPv4 nur Backbone handelt, diese Pakete durch dieses IPv4 Backbone getunnelt werden müssen.

Wie auch außerhalb des VPN-Kontexts erfordert der Zugriff auf das IPv6 Internet von einem IPv6 VPN eindeutig die Verwendung globaler IPv6-Adressen.

Insbesondere können eindeutige lokale IPv6-Adressen nicht für IPv6-Internetzugang verwendet werden.

10. Management-VPN​

Die in Abschnitt 12 [BGP/MPLS-VPN] erörterten Managementüberlegungen gelten für die Verwaltung von IPv6 VPNs.

Wenn der Service Provider die CE der IPv6 VPN-Standort verwaltet, kann der Service Provider IPv4 für die Kommunikation zwischen dem Managementtool und dem CE für solche Managementzwecke verwenden. In diesem Fall ist die CE, unabhängig davon, ob ein Kunde IPv4 Site tatsächlich mit der CE verbunden ist (zusätzlich zur IPv6 Site), tatsächlich Teil eines IPv4 VPN neben der Zugehörigkeit zu einem IPv6 VPN (d.h., die CE ist an eine VRF angeschlossen, die IPv4 zusätzlich zu IPv6) unterstützt. Die in [BGP/MPLS-VPN] dargelegten Überlegungen, wie sichergestellt werden kann, dass das Management-Tool mit solchen verwalteten CEs von mehreren VPNs kommunizieren kann, ohne dass unerwünschte Erreichbarkeit über CEs verschiedener VPNs hinweg möglich ist, gelten für die IPv4-Erreichbarkeit des VRF, an den die CE anknüpft.

Wenn der Service Provider die CE der IPv6 VPN-Standort verwaltet, kann der Service Provider IPv6 für die Kommunikation zwischen dem Managementtool und dem CE für solche Managementzwecke verwenden. Überlegungen, die in [BGP/MPLS-VPN] dargelegt werden, wie das Managementtool sicherstellen kann, dass mit solchen verwalteten CEs von mehreren VPNs kommuniziert werden kann, ohne dass unerwünschte Erreichbarkeit über CEs verschiedener VPNs hinweg möglich ist, gelten dann für die IPv6-Erreichbarkeit des VRF, an die die CE anschließt.

11. Sicherheitsüberlegungen​

Die in diesem Dokument definierten Erweiterungen ermöglichen es MP-BGP, Informationen über IPv6 VPN-Routen zu verbreiten.

Sicherheitsaspekte für den Transport von IPv6-Erreichbarkeitsinformationen mit BGP werden in RFC2545, Abschnitt 5, erörtert und gelten gleichermaßen für die in diesem Dokument beschriebenen Erweiterungen.

Die in diesem Dokument beschriebenen Erweiterungen für IPv6 VPNs verwenden den exakt gleichen Ansatz wie der in [BGP/MPLS-VPN] beschriebene Ansatz. Daher gelten die gleichen Sicherheitsüberlegungen in Bezug auf Data Plane Security, Control Plane Security und PE- und P-Gerätesicherheit wie in [BGP/MPLS-VPN], Abschnitt 13.

12. Dienstgüte​

Da alle QoS-Mechanismen, die für IPv4-VPN in Abschnitt 14 [BGP/MPLS-VPN] diskutiert wurden, für IPv4 und IPv6 (Diffserv, Intserv, MPLS Traffic Engineering) in gleicher Weise funktionieren, gelten die in [BGP/MPLS-VPN] diskutierten QoS-Überlegungen gleichermaßen für IPv6-VPN (und dies gilt für die Verwendung von IPv4-Tunnel oder IPv6-Tunnel im Rückgrat).

13. Skalierbarkeit​

Jede der für IPv4 VPNs in Abschnitt 15 [BGP/MPLS-VPN] zusammengefassten Skalierbarkeitsüberlegungen gilt gleichermaßen für IPv6 VPNs.

14. IANA-Erwägungen​

Dieses Dokument gibt (siehe Abschnitt 3.2) die Verwendung des BGP AFI (Address Family Identifier) Wertes 2 zusammen mit dem BGP SAFI (Nachfolgender Adress Family Identifier) Wert 128 an, um die Adressfamilie "VPN-IPv6 Beschriftete Adressen" darzustellen, die in diesem Dokument definiert ist.

Die Verwendung von AFI-Wert 2 für IPv6 ist wie derzeit in der IANA-Registrierung "Address Family Identifier" angegeben, so dass IANA keine Maßnahmen in Bezug darauf ergreifen muss.

Die Verwendung von SAFI Wert 128 für "MPLS-beschriftete VPN-Adresse" ist wie derzeit in der IANA-Registrierung "Nachfolgen Address Family Identifier" angegeben, so dass IANA keine Maßnahmen in Bezug darauf ergreifen muss.

15. Danksagungen​

Wir danken Gerard Gastaud und Eric Levy-Abegnoli, die zu diesem Dokument beigetragen haben.

Zum Gedenken​

Die Autoren möchten den wertvollen Beitrag zu diesem Dokument von Tri T. Nguyen, der im April 2002 nach einer plötzlichen Krankheit verstorben ist, würdigen.

16. Referenzen​

16.1. Normative Referenzen​

  • [BGP/MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

  • [BGP-EXTCOM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.

  • [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

  • [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

  • [MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.

  • [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.

  • [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.

  • [BGP-IPv6] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.

16.2. Informative Referenzen​

  • [V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

  • [UNIQUE-LOCAL] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

  • [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", Work in Progress.

  • [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", Work in Progress, August 2005.

  • [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

  • [MPLS-in-IP/GRE] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.

  • [MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over Layer-2 Tunneling Protocol Version 3", Work in Progress, February 2006.

  • [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

Anschriften der Autoren​

Jeremy De Clercq
Alcatel
Copernicuslaan 50, 2018 Antwerpen, Belgium

EMail: [email protected]

Dirk Ooms
OneSparrow
Belegstraat 13, 2018 Antwerpen, Belgium

EMail: [email protected]

Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - France

EMail: [email protected]

Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France

EMail: [email protected]

Vollständige Urheberrechtserklärung​

Copyright (C) Die Internet Society (2006).

Dieses Dokument unterliegt den Rechten, Lizenzen und Einschränkungen, die in BCP 78 enthalten sind, und außer in der darin enthaltenen Fassung behalten die Autoren alle ihre Rechte.

Dieses Dokument und die hierin enthaltenen Informationen werden auf der Grundlage von „AS IS" und dem KONTRIBUTOR, DER ORGANISATION, DIE ER/SIE VERTRETERT ODER VON (falls vorhanden), DER INTERNETGESELLSCHAFT UND DER INTERNETVEREINIGUNG VON TASKVERTRÄGEN ALLE WARRANTIEN, AUSDRUCK ODER AUSSCHLIESSLICH GEWÄHRT WERDEN, EINSCHLIESSLICH DER NICHT VERBINDLICHKEIT, DASS DIE INFORMATIONEN HIER NICHT RECHTE ODER RECHTE ODER RECHTE VON MERCHANTABILITÄT ODER RECHTE FÜR EIN TEILKULARZWERDEN VERWÄHRT WERDEN.

Geistiges Eigentum​

Die IETF nimmt keine Stellung in Bezug auf die Gültigkeit oder den Umfang der Rechte an geistigem Eigentum oder anderer Rechte, die in diesem Dokument beschrieben sind oder in welchem Umfang eine Lizenz aus solchen Rechten verfügbar sein könnte oder nicht, und vertritt auch nicht, dass sie sich unabhängig darum bemüht hat, solche Rechte zu identifizieren. Informationen über die Verfahren in Bezug auf Rechte in RFC-Dokumenten finden sich in BCP 78 und BCP 79.

Kopien der IPR-Mitteilungen, die dem Sekretariat des IETF gemacht wurden, sowie jegliche Zusicherungen über die zur Verfügung zu stellenden Lizenzen oder das Ergebnis eines Versuches, eine allgemeine Lizenz oder Erlaubnis für die Nutzung solcher Eigentumsrechte durch Implementatoren oder Nutzer dieser Spezifikation zu erhalten, können im Online-IPR-Repository der IETF unter http://www.ietf.org/ipr abgerufen werden.

Die IETF bittet alle interessierten Parteien, ihr alle Urheberrechte, Patente oder Patentanmeldungen oder sonstigen Schutzrechte, die sich auf Technologien beziehen können, die zur Umsetzung dieses Standards erforderlich sind, zur Kenntnis zu bringen. Bitte richten Sie die Informationen an die IETF unter [email protected].

Danksagung​

Die Finanzierung der RFC-Editor-Funktion wird durch die IETF Administrative Support Activity (IASA) bereitgestellt.

Letztes Update am