Zum Hauptinhalt springen

RFC 4364 - BGP/MPLS IP Virtual Private Networks (VPN)

  • Status: Proposed Standard
  • Veröffentlichungsdatum: Februar 2006
  • Stream: IETF
  • Obsolet: RFC 2547
  • Errata: Keine Errata

Informationen zum Dokument​

  • RFC-Nummer: 4364
  • Titel: BGP/MPLS IP Virtual Private Networks (VPN)
  • Autoren: E. Rosen, Y. Rekhter
  • Datum: Februar 2006
  • Kategorie: Standards Track
  • Obsolet: RFC 2547
  • ISSN: 2070-1721

Zusammenfassung​

Dieses Dokument beschreibt eine Methode, mit der ein Diensteanbieter (Service Provider) sein IP-Backbone (backbone) nutzen kann, um für Kunden IP-Virtual Private Networks (VPN) bereitzustellen. Diese Methode verwendet ein „Peer-Modell“ (peer model): Die Kunden-Edge-Router (CE) senden ihre Routen an die Provider-Edge-Router (PE); der Routing-Algorithmus des Kunden sieht keinerlei „Overlay“ (overlay), und die CE-Router verschiedener Standorte sind nicht peer-zueinander. Die Datenpakete (data packet) werden durch das Backbone getunnelt (tunneled), sodass die Core-Router (core router) die VPN-Routen nicht kennen müssen.

Dieses Dokument obsolet RFC 2547.

Status dieses Memos​

Dieses Dokument spezifiziert ein Internet-Standard-Tracking-Protokoll für die Internetgemeinschaft und erbittet Diskussion und Verbesserungsvorschläge. Bitte konsultieren Sie die aktuelle Ausgabe der „Internet Official Protocol Standards“ (STD 1) für den Standardisierungsstatus und den Status dieses Protokolls. Die Verteilung dieses Memos ist unbeschränkt.

Urheberrechtshinweis​

Copyright (C) The Internet Society (2006).

Inhaltsverzeichnis​

  1. Einleitung
  2. Standorte und VPN
  3. VRF: Mehrere Forwarding-Tabellen in PEs
  4. VPN-Routenverteilung über BGP
  5. Label-Verteilung
  6. Die VPN-IPv4-Adressfamilie
  7. Wie VPN-IPv4-Adressen gebildet werden
  8. VPN-Routenauswahl
  9. VPN-Routenverteilung in BGP
  10. Route Reflectors
  11. Aufbau von VPN mit LSP-Tunneln
  12. Sicherheitsüberlegungen
  13. Danksagungen
  14. Normative Referenzen
  15. Informativ Referenzen

1. Einleitung​

Dieses Dokument beschreibt eine Methode, mit der ein Diensteanbieter sein IP-Backbone nutzen kann, um für Kunden IP-Virtual Private Networks (VPN) bereitzustellen. Diese Methode verwendet ein „Peer-Modell“, bei dem die Kunden-Edge-Router (CE) ihre Routen an die Provider-Edge-Router (PE) senden; der Routing-Algorithmus des Kunden sieht keinerlei „Overlay“ (overlay), und die CE-Router verschiedener Standorte sind nicht peer-zueinander. Die Pakete werden durch das Backbone getunnelt, sodass die Core-Router die VPN-Routen nicht kennen müssen.

2. Standorte und VPN​

Ein VPN ist eine Menge von Standorten (site), die einen gemeinsamen Satz an Routing-Informationen teilen. Ein Standort ist eine Menge von IP-Systemen, die ohne Nutzung des öffentlichen Internets miteinander kommunizieren können. Ein Standort kann ein einzelner Kundenstandort oder mehrere über private Leitungen verbundene Standorte sein.

3. VRF: Mehrere Forwarding-Tabellen in PEs​

Jeder PE-Router hält mehrere voneinander unabhängige Forwarding-Tabellen. Eine davon ist die „Default-Forwarding-Tabelle“ (default forwarding table), die Routen zum öffentlichen Internet enthält. Die übrigen sind die „VPN Routing and Forwarding“-Instanzen (VPN Routing and Forwarding instance, VRF). Jeder VRF ist mit einem oder mehreren Ports am PE-Router assoziiert.

4. VPN-Routenverteilung über BGP​

Die PE-Router nutzen BGP, um VPN-Routen untereinander zu verteilen. Wenn ein PE-Router eine Route von einem CE-Router empfängt, platziert er diese Route in den entsprechenden VRF. Er nutzt dann BGP, um diese Route an die anderen PE-Router zu verteilen.

5. Label-Verteilung​

MPLS-Labels (label) werden genutzt, um Pakete durch das Backbone zu tunneln. Wenn ein PE-Router eine VPN-Route über BGP verteilt, verteilt er gleichzeitig ein MPLS-Label für diese Route.

6. Die VPN-IPv4-Adressfamilie​

BGP wird erweitert, um eine neue Adressfamilie zu unterstützen — VPN-IPv4. Eine VPN-IPv4-Adresse besteht aus einem 8 Byte großen Route Distinguisher (RD) und einer 4 Byte großen IPv4-Adresse.

7. Wie VPN-IPv4-Adressen gebildet werden​

Der RD wird genutzt, um die IPv4-Adresse unter allen VPN eindeutig zu machen. Der RD wird der IPv4-Adresse vorangestellt (prepend), um die VPN-IPv4-Adresse zu bilden.

8. VPN-Routenauswahl​

Wenn ein PE-Router mehrere Routen zum selben Ziel empfängt, nutzt er den Entscheidungsprozess (decision process) von BGP, um die beste (best) Route auszuwählen.

9. VPN-Routenverteilung in BGP​

VPN-IPv4-Routen werden in BGP mittels der Multiprotocol Extensions for BGP-4 [RFC4760] verteilt.

10. Route Reflectors​

Ein Route Reflector (route reflector) kann genutzt werden, um die Skalierbarkeit des BGP-Mesh (mesh) zu verbessern.

11. Aufbau von VPN mit LSP-Tunneln​

LSP-Tunnel können genutzt werden, um VPN-Pakete durch das Backbone zu tunneln.

12. Sicherheitsüberlegungen​

Die mit dieser Methode bereitgestellten VPN sollten ein dem Frame-Relay- oder ATM-VPN vergleichbares Sicherheitsniveau bieten.

13. Danksagungen​

Die Autoren möchten den vielen Personen danken, die zu dieser Arbeit beigetragen haben.

14. Normative Referenzen​

  • [RFC4760] Bates, T., Chandra, R., Katz, D., und Y. Rekhter, „Multiprotocol Extensions for BGP-4“, RFC 4760, Januar 2007.

15. Informativ Referenzen​

  • [RFC2547] Rosen, E. und Y. Rekhter, „BGP/MPLS VPNs“, RFC 2547, März 1999.

Adressen der Autoren (Authors' Addresses)

Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719

EMail: [email protected]

Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089

EMail: [email protected]