Aller au contenu principal

RFC 4659 - Extension des réseaux privés virtuels (VPN) IP BGP-MPLS aux VPN IPv6

  • Statut: Proposition de norme
  • Publication: septembre 2006
  • Flux: IETF
  • Errata: Aucun erratum

Informations sur le document​

  • Numéro RFC: 4659
  • Titre: Extension des réseaux privés virtuels (VPN) IP BGP-MPLS aux VPN IPv6
  • Auteurs: J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur
  • Date: septembre 2006
  • Catégorie: Voie de normalisation
  • ISSN: 2070-1721

Résumé​

Ce document décrit une méthode permettant à un fournisseur de services d’utiliser son réseau fédérateur à commutation de paquets pour fournir des services de réseau privé virtuel (VPN) à ses clients IPv6. Cette méthode réutilise et, lorsque nécessaire, étend la méthode « BGP/MPLS IP VPN » afin de prendre en charge IPv6. Dans un VPN IP BGP/MPLS, Multiprotocol BGP distribue les routes VPN IPv4 sur le réseau fédérateur du fournisseur, tandis que MPLS achemine les paquets VPN IPv4. Le présent document définit une famille d’adresses VPN IPv6 et décrit la distribution correspondante des routes VPN IPv6 dans Multiprotocol BGP. Il prend en charge le service VPN IPv6 sur des réseaux fédérateurs IPv4 comme IPv6 et autorise diverses techniques de tunnel dans le cœur, notamment MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) et les tunnels protégés par IPsec. L’interfonctionnement entre un site IPv4 et un site IPv6 est hors du champ de ce document.

Statut de ce mémoire​

Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet et demande des discussions et des suggestions d'améliorations. Veuillez consulter la version actuelle des « Normes officielles du protocole Internet » (NDTS 1) pour connaître l'état de normalisation et l'état de ce protocole.

Avis de droit d'auteur​

Droit d'auteur (C) Société Internet (2006).

Table des matières​

1. Introduction​

Ce document décrit une méthode par laquelle un fournisseur de services peut utiliser son réseau central commuté par paquets pour fournir des services de réseau privé virtuel à ses clients IPv6.

Cette méthode réutilise et étend, si nécessaire, la méthode "BGP/MPLS IP VPN" [BGP/MPLS-VPN] pour le support d'IPv6. En particulier, cette méthode utilise le même "modèle de Pier" que [BGP/MPLS-VPN], dans lequel les routeurs de bord des clients (" routeurs CE") envoient leurs routes IPv6 aux routeurs de bord du fournisseur de services (" routeurs PE"). BGP ("Protocole de passerelle de la frontière", [BGP, BGP-MP]) est ensuite utilisé par le fournisseur de services pour échanger les routes d'un IPv6 VPN particulier parmi les routeurs PE qui sont attachés à ce VPN IPv6. Finalement, les routeurs PE distribuent, aux routeurs CE dans un VPN particulier, les routes IPv6 des autres routeurs CE dans ce VPN. Comme pour les VPN IPv4, une caractéristique clé de ce « modèle de pair » est que les routeurs CE (IPv6) dans un VPN (IPv6) ne sont pas en contact les uns avec les autres; il n'y a pas de « superposition » visible à l'algorithme de routage du VPN (IPv6).

Le présent document adopte les définitions, les acronymes et les mécanismes décrits dans [BGP/MPLS-VPN]. Sauf indication contraire, les mécanismes de [BGP/MPLS-VPN] s'appliquent et ne seront pas ré-décrits ici.

Un VPN est qualifié de VPN IPv6 lorsque chacun de ses sites prend en charge IPv6 et se raccorde nativement au réseau fédérateur du fournisseur de services (SP), par une interface ou sous-interface IPv6, au moyen d’un équipement Provider Edge (PE).

Un site peut être à la fois capable IPv4 et capable IPv6. L'interface logique sur laquelle les paquets arrivent au PE peut déterminer la version IP. La même interface logique peut aussi être utilisée pour IPv4 et IPv6, auquel cas une recherche par paquet sur le champ Version de l'en-tête du paquet IP détermine la version IP.

Ce document ne concerne que la gestion de la communication IPv6 entre les hôtes IPv6 situés sur des sites compatibles IPv6. La gestion de la communication IPv4 entre les hôtes IPv4 situés sur des sites compatibles IPv4 n'est pas visée par le présent document et est couverte par [BGP/MPLS-VPN]. La communication entre un hôte IPv4 situé sur un site compatible IPv4 et un hôte IPv6 situé sur un site compatible IPv6 n'est pas visée par le présent document.

De la même manière que les routes VPN IPv4 sont distribuées dans [BGP/MPLS-VPN], BGP et ses extensions sont utilisées pour distribuer des routes depuis un site VPN IPv6 vers tous les autres routeurs PE connectés à un site du même VPN IPv6. Les PE utilisent les tables de routage et de renvoi VPN (VRF) pour maintenir séparément les informations de accessibilité et de transmission de chaque VPN IPv6.

Comme pour les VPN IPv4 [BGP/MPLS-VPN], nous permettons à chaque VPN IPv6 d'avoir son propre espace d'adresse IPv6, ce qui signifie qu'une adresse donnée peut indiquer différents systèmes dans différents VPN. Ceci est réalisé via une nouvelle famille d'adresses, la famille d'adresses VPN-IPv6, d'une manière similaire à celle de la famille d'adresses VPN-IPv4, définie dans [BGP/MPLS-VPN], qui prépend une route distinctive à l'adresse IP.

Outre son fonctionnement sur les chemins commutés MPLS Label (LSPs), la solution VPN IPv4 BGP/MPLS a été étendue pour permettre l'exploitation sur d'autres techniques de tunnelage, notamment les tunnels GRE, IP-in-IP [2547-GRE/IP], L2TPv3 [MPLS-in-L2TPv3] et IPsec protégé [2547-IPsec]. De la même manière, ce document permet de prendre en charge un service VPN IPv6 sur les LSP MPLS, ainsi que sur d'autres techniques de tunnelage.

Ce document permet de prendre en charge un service VPN IPv6 sur un épine dorsale IPv4, ainsi que sur un épine dorsale IPv6. Le service VPN IPv6 pris en charge est identique dans les deux cas.

La solution VPN IPv6 définie dans ce document offre les avantages suivants:

  • Du point de vue du fournisseur de services et du point de vue du client, le service VPN qui peut être pris en charge pour les sites IPv6 est identique à celui qui peut être pris en charge pour les sites IPv4.

  • Du point de vue du fournisseur de services, les opérations du service VPN IPv6 nécessitent les mêmes compétences, procédures et mécanismes que ceux du service VPN IPv4.

  • Lorsque les services VPN IPv4 et VPN IPv6 sont pris en charge sur un noyau IPv4, le même ensemble unique de relations de pair MP-BGP et le même mesh unique PE-PE tunnel peuvent (MAY) être utilisés pour les deux.

  • Le service VPN IPv6 est indépendant de la question de savoir si le noyau fonctionne IPv4 ou IPv6. C'est ainsi que le service VPN IPv6 pris en charge avant et après une migration du noyau d'IPv4 vers IPv6 est indétectable pour le client VPN.

Notez que les services VPN IPv4 pris en charge sur un noyau IPv6 ne sont pas couverts par ce document.

2. Famille d'adresses VPN-IPv6​

Les extensions multiprotocoles BGP [BGP-MP] permettent à BGP de transporter des itinéraires de plusieurs « familles d'adresses ». Nous introduisons la notion de « famille d'adresses VPN-IPv6 », qui est similaire à la famille d'adresses VPN-IPv4 introduite dans [BGP/MPLS-VPN].

Une adresse VPN-IPv6 est une quantité de 24 octets, commençant par un 8 octets "Route Distinguisher" (RD) et se terminant par une adresse IPv6 16 octets.

Le RD a uniquement pour but de permettre la création d'itinéraires distincts vers un préfixe d'adresse IPv6 commun, qui est similaire à l'objectif du RD défini dans [BGP/MPLS-VPN]. De la même manière qu'il est possible par [BGP/MPLS-VPN], le RD peut être utilisé pour créer plusieurs itinéraires différents vers le même système. Cela peut être réalisé en créant deux itinéraires VPN-IPv6 différents qui ont la même partie IPv6 mais différents RD. Cela permet au BGP du fournisseur d'installer plusieurs itinéraires différents vers le même système et permet d'utiliser la politique pour décider quels paquets utilisent quel itinéraire.

De plus, si deux VPN utilisaient le même préfixe d'adresse IPv6 (en dénotant effectivement différents systèmes physiques), les PE les traduireaient en préfixes d'adresse VPN-IPv6 uniques en utilisant différents RD. Cela garantit que si la même adresse est jamais utilisée dans deux VPN différents, il est possible d'installer deux routes complètement différentes à cette adresse, une pour chaque VPN.

Puisque les adresses VPN-IPv6 et IPv6 appartiennent à différentes familles d'adresses, BGP ne les traite jamais comme des adresses comparables.

Un VRF peut avoir plusieurs routes VPN-IPv6 à coût égal pour un préfixe d'adresse IPv6. Lorsque l'adresse de destination d'un paquet est appariée dans un VRF contre une route VPN-IPv6, seule la partie IPv6 est effectivement appariée.

Le format et l'encodage de la distinction de route sont tels que spécifiés dans [BGP/MPLS-VPN].

Lorsqu'un site est capable IPv4 et IPv6 capable, le même RD PEUT (MAY) être utilisé pour la publicité des adresses IPv6 et IPv4. Par ailleurs, un RD PEUT être utilisé pour la publicité des adresses IPv4 et des adresses IPv6. Notez toutefois que dans le champ d'application de cette spécification, les adresses IPv4 et IPv6 seront toujours traitées dans des contextes distincts et qu'aucune question et technique d'interfonctionnement IPv4-IPv6 ne sera discutée. (MAY)

3. Distribution des routes VPN-IPv6​

3.1. Distribution des routes entre PE par BGP​

Comme décrit dans [BGP/MPLS-VPN], si deux sites d'un VPN se fixent à des PE qui se trouvent dans le même système autonome, les PE peuvent (MAY) distribuer des routes VPN les uns vers les autres au moyen d'une connexion interne (IPv4) du protocole de la passerelle frontalière (iBGP).

Les routeurs PE échangent, via MP-BGP [BGP-MP], des informations de accessibilité pour les préfixes IPv6 des VPN IPv6 et se font ainsi annoncer comme BGP Next Hop.

Les règles pour l'encodage des informations d'accessibilité et l'adresse BGP Next Hop sont spécifiées dans les sections suivantes.

3.2. Codage du NLRI VPN IPv6​

Lors de la distribution des routes VPN IPv6, le routeur PE publicitaire DOIT (MUST) assigner et distribuer les étiquettes MPLS avec les routes VPN IPv6. Essentiellement, les routeurs PE ne distribuent pas les routes VPN IPv6, mais les routes VPN IPv6 Labeled [MPLS-BGP]. Lorsque le PE publicitaire reçoit un paquet qui a cette étiquette publicitaire particulière, le PE va afficher cette étiquette à partir de la pile MPLS et traiter le paquet de manière appropriée (c'est-à-dire, le faire suivre directement selon l'étiquette ou effectuer une recherche dans le contexte IPv6-VPN correspondant).

Les extensions multiprotocoles de BGP [BGP-MP] servent à annoncer les routes VPN IPv6 dans les informations d’accessibilité de la couche réseau MP_REACH (NLRI). Les champs Address Family Identifier (AFI) et Subsequent Address Family Identifier (SAFI) MUST être définis comme suit :

  • AFI: 2; pour IPv6

  • SAFI: 128; pour les adresses VPN-IPv6 avec étiquette MPLS

Le champ NLRI lui-même est encodé comme spécifié dans [MPLS-BGP]. Dans le contexte de cette extension, le préfixe appartient à la famille d'adresses VPN-IPv6 et se compose donc d'un discriminant de route 8 octets suivi d'un préfixe IPv6 comme spécifié dans la section 2, ci-dessus.

3.2.1. Codage du prochain saut BGP​

L'encodage du BGP Next Hop dépend de la politique du haut-parleur BGP consistant à demander que le trafic VPN IPv6 soit transporté vers ce BGP Next Hop en utilisant le tunnelage IPv6 ("parleur BGP demandant le transport IPv6") ou en utilisant le tunnelage IPv4 ("parleur BGP demandant le transport IPv4).

La définition de cette politique (pour demander le transport sur le tunnel IPv4 ou le tunnel IPv6) est de la responsabilité de l'opérateur réseau et dépasse le cadre du présent document. Notez qu'il est possible pour cette politique de demander le transport sur le tunnel IPv4 (resp. IPv6) pendant que les haut-parleurs BGP échangent des informations de accessibilité IPv6 VPN sur IPv6 (resp. IPv4). Cependant, dans ce cas, un certain nombre d'incidences opérationnelles méritent d'être examinées. IPv6) le chemin de données en tunnel et ne touchant pas le chemin de données IPv6 (resp. IPv4) pourrait rester non détecté par BGP, ce qui pourrait à son tour entraîner un noir-couverture du trafic.

Le contrôle de cette politique dépasse le cadre du présent document et peut être basé sur la configuration de l'utilisateur.

3.2.1.1. Locuteur BGP demandant un transport IPv6​

Lorsque le trafic VPN IPv6 doit (SHALL) être transporté vers l'enceinte BGP en utilisant le tunnelage IPv6 (par exemple, les LSP IPv6 MPLS, les tunnels IPv6 protégés par IPsec), l'enceinte BGP doit annoncer un champ d'adresse réseau Next Hop contenant une adresse VPN-IPv6

  • dont la valeur de RD de 8 octets est fixée à zéro, et

  • dont l'adresse IPv6 16 octets est définie à l'adresse IPv6 globale du haut-parleur publicitaire BGP.

Ceci est potentiellement suivi d'une autre adresse VPN-IPv6

  • dont la valeur de RD de 8 octets est fixée à zéro, et

  • dont l'adresse IPv6 16 octets est définie à l'adresse IPv6 locale du haut-parleur publicitaire BGP.

La valeur de la longueur du champ Adresse réseau Next Hop dans l'attribut MP_REACH_NLRI doit être réglée à 24 lorsque seule une adresse globale est présente, et à 48 si une adresse link-local est également incluse dans le champ Next Hop.

Si les haut-parleurs BGP utilisent uniquement leur adresse IPv6 locale (par exemple, lorsqu'un pair IPv6 CE avec un IPv6 PE, où le CE n'a pas d'adresse IPv6 globale, et où l'eBGP est réalisé par rapport aux adresses locales), la "adresse non précisée" ([V6ADDR]) est utilisée par le haut-parleur BGP publicitaire pour indiquer l'absence de l'adresse IPv6 globale dans le champ Adresse réseau Next Hop.

L'adresse link-local est incluse dans le champ Next Hop si et seulement si le haut-parleur publicitaire BGP partage un sous-réseau commun avec le pair, l'itinéraire est annoncé à [BGP-IPv6].

Dans tous les autres cas, un haut-parleur BGP ne fait de publicité à son pair dans le champ Adresse réseau Next Hop que l'adresse IPv6 globale du prochain houblon.

Par conséquent, un haut-parleur BGP qui annonce une route vers un pair interne peut modifier le champ Adresse réseau de Next Hop en supprimant l'adresse IPv6 locale de l'autre houblon.

Un exemple dans lequel les adresses IPv6 globale et link-local doivent toutes deux figurer dans le champ BGP Next Hop est celui d’un service VPN IPv6 fourni sur un réseau fédérateur multi-systèmes autonomes (AS), avec redistribution de routes VPN-IPv6 étiquetées entre les ASBR de différents AS partageant un même sous-réseau IPv6.

Les itinéraires IPv6 entre les routeurs frontaliers du système autonome (ASBR) de différents AS partageant un sous-réseau IPv6 commun: dans ce cas, l'adresse IPv6 globale et l'adresse IPv6 locale de liaison sont annoncés par les ASBR.

3.2.1.2. Locuteur BGP demandant un transport IPv4​

Lorsque le trafic VPN IPv6 doit (SHALL) être transporté vers l'enceinte BGP en utilisant le tunnelage IPv4 (par exemple, les LSP IPv4 MPLS, les tunnels IPv4 protégés par IPsec), l'enceinte BGP doit faire la publicité à son pair d'un champ d'adresse réseau Next Hop contenant une adresse VPN-IPv6 :

  • dont la valeur de RD de 8 octets est fixée à zéro, et

  • dont l'adresse IPv6 16 octets est encodée comme une adresse IPv6 [V6ADDR] à mémoire IPv4 contenant l'adresse IPv4 du haut-parleur publicitaire BGP. Cette adresse IPv4 doit être routable par l'autre haut-parleur BGP.

3.3. Cible de route​

L'utilisation de la cible de route est spécifiée dans [BGP/MPLS-VPN] et s'applique aux VPN IPv6. Le codage de l'attribut communautaire étendu est défini dans [BGP-EXTCOM].

3.4. Négociation des capacités BGP​

Pour que deux PE échangent des IPv6 VPN NLRI étiquetés, ils DOIVENT (MUST) utiliser la négociation des capacités BGP pour s'assurer qu'ils sont tous deux capables de traiter correctement ces NLRI. Ceci est fait comme spécifié dans [BGP-MP] et [BGP-CAP], en utilisant le code de capacité 1 (multiprotocole BGP), avec les valeurs AFI et SAFI comme spécifié ci-dessus, dans la section 3.2.

4. Encapsulation​

Le routeur PE d’entrée MUST transporter les données VPN IPv6 dans un tunnel à travers le réseau fédérateur jusqu’au routeur PE de sortie identifié comme BGP Next Hop pour le préfixe VPN IPv6 de destination.

Lorsque l'adresse IPv6 16 octets contenue dans le champ BGP Next Hop est encodée comme une adresse IPv6 mapée IPv4 (voir section 3.2.1.2), l'entrée PE DOIT (MUST) utiliser le tunnelage IPv4 sauf configuration explicite pour faire autrement. L'entrée PE MAY permet en option, par configuration explicite, l'utilisation du tunnelage IPv6 lorsque l'adresse IPv6 16 octets contenue dans le champ BGP Next Hop est encodée comme une adresse IPv4 mapée IPv6. Cela permettrait de prendre en charge des environnements de déploiement particuliers où le tunnelage IPv6 est souhaité, mais où les adresses IPv4-mapés sont utilisées pour l'accessibilité IPv6 des PE au lieu des adresses IPv6 globales.

Lorsque l'adresse IPv6 16 octets contenue dans le champ BGP Next Hop n'est pas codée comme adresse IPv4-mapée (voir la section 3.2.1.1), l'entrée PE DOIT (MUST) utiliser le tunnelage IPv6.

Lorsqu'un PE reçoit un paquet d'un CE attaché, il recherche l'adresse de destination IPv6 du paquet dans le VRF correspondant à ce CE. Cela lui permet de trouver une route VPN-IPv6. Le chemin VPN-IPv6 aura une étiquette MPLS associée et une BGP Next Hop associée. D'abord, cette étiquette MPLS est poussée sur le paquet comme l'étiquette inférieure. Ensuite, ce paquet étiqueté est encapsulé dans le tunnel pour le transport vers l'Egress PE identifié par le BGP Next Hop. Les détails de cette encapsulation dépendent de la technique de tunnelage actuelle, comme suit:

Comme pour MPLS/BGP pour IPv4 VPNs [2547-GRE/IP], lorsque le tunnelage est effectué en utilisant des tunnels IPv4 ou IPv6 (à la suite de tunnels IPv4 GRE ou de tunnels IPv6 GRE), l'encapsulation du paquet VPN étiqueté IPv6 donne lieu à un paquet encapsulé MPLS-in-IP (à la suite de MPLS-in-GRE) comme spécifié dans [MPLS-in-IP/GRE]. Lorsque le tunnelage est effectué en utilisant L2TPv3, l'encapsulation du paquet VPN étiqueté IPv6 donne lieu à un paquet encapsulé MPLS-in-L2TPv3, comme spécifié dans [MPLS-in-L2TPv3].

Comme pour MPLS/BGP pour IPv4 VPN, lorsque le tunnelage est effectué à l'aide d'un tunnel sécurisé IPsec [2547-IPsec], l'encapsulation du paquet VPN IPv6 étiqueté donne lieu à un paquet MPLS-in-IP- ou MPLS-in-GRE-encapsulé [MPLS-in-IP/GRE]. Le mode de transport IPsec est utilisé pour sécuriser ce tunnel IPv4 ou GRE de l'entrée PE à l'évacuation PE.

Lorsque le tunnelage est effectué à l'aide de tunnels IPv4 (qu'il soit sécurisé ou non par IPsec), le routeur PE d'entrée DOIT (MUST) utiliser l'adresse IPv4 encodée dans le champ d'adresse IPv6 de la prochaine zone de saut de BGP comme adresse de destination de l'en-tête de tunnelage IPv4 pré-pendé. Il utilise l'une de ses adresses IPv4 comme adresse source de l'en-tête de tunnelage IPv4 prépendé.

Lorsque le tunnelage est effectué à l'aide de tunnels IPv6 (qu'il soit sécurisé ou non par IPsec), le routeur PE d'entrée DOIT (MUST) utiliser l'adresse IPv6 contenue dans le champ d'adresse IPv6 du champ de saut suivant BGP comme adresse de destination de l'en-tête de tunnelage IPv6 pré-pendé. Il utilise l'une de ses adresses IPv6 comme adresse source de l'en-tête de tunnelage IPv6 prépendé.

Lorsque le tunnelage est effectué à l'aide de LSP MPLS, les LSP peuvent être établis à l'aide de n'importe quelle technique de distribution d'étiquettes (LDP [LDP], RSVP-TE [RSVP-TE], etc.).

Lorsque le tunnelage est effectué avec les LSP MPLS, le routeur PE d'entrée DOIT (MUST) pousser directement l'étiquette du tunnel LSP sur la pile d'étiquette du paquet VPN IPv6 étiqueté (c'est-à-dire sans précéder aucun en-tête IPv4 ou IPv6). Cette étiquette poussée correspond au LSP commençant sur le routeur PE d'entrée et se terminant sur le routeur PE d'entrée. Le champ BGP Next Hop est utilisé pour identifier le routeur PE d'entrée et à son tour l'étiquette à pousser sur la pile. Lorsque l'adresse IPv6 dans le champ BGP Next Hop est une adresse IPv6 en format IPv4, l'adresse IPv4 intégrée déterminera l'étiquette du tunnel pour pousser sur la pile d'étiquettes. Dans tous les autres cas, l'adresse IPv6 dans le champ BGP Next Hop déterminera l'étiquette du tunnel pour pousser sur la pile d'étiquettes.

Pour assurer l'interopérabilité entre les systèmes qui mettent en œuvre cette architecture VPN, tous ces systèmes DOIVENT (MUST) supporter le tunnelage en utilisant les LSP MPLS établis par LDP [LDP].

5. Types d'adresses​

Comme les adresses unicast locales de Link sont définies pour une utilisation sur un seul lien, celles-ci peuvent être utilisées sur le lien PE-CE, mais elles ne sont pas prises en charge pour la accessibilité à travers les sites VPN IPv6 et ne sont jamais annoncées via le protocole de passerelle multiprotocole-border (MP-BGP) vers les PE distants.

Les adresses unicast globales sont définies comme identifiant des interfaces uniques n'importe où dans l'Internet IPv6. Les adresses globales devraient être couramment utilisées dans et sur les sites VPN IPv6. Elles sont évidemment prises en charge par cette solution VPN IPv6 pour la accessibilité des sites VPN IPv6 et annoncées via MP-BGP vers des PE distants et sont traitées sans aucune considération spécifique à leur portée globale.

Citation de [UNIQUE-LOCAL] : « Ce document définit un format d'adresse IPv6 unicast qui est unique au niveau mondial et qui est destiné aux communications locales [IPv6]. Ces adresses sont appelées adresses IPv6 Unicast locales uniques et sont abrégées dans ce document en adresses IPv6. Elles ne sont pas censées être routables sur l'Internet mondial. Elles sont routables à l'intérieur d'une zone plus limitée comme un site. Elles peuvent également être acheminées entre un ensemble limité de sites. »

  • [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."

C'est ainsi que les adresses IPv6 Unicast locales uniques sont prises en charge par la solution IPv6 VPN spécifiée dans ce document pour une accessibilité à travers les sites IPv6. Ainsi, la accessibilité à ces adresses IPv6 locales uniques peut être annoncée via MP-BGP vers des PE distants et traitée par des PE de la même manière que les adresses Unicast mondiales.

Les recommandations et considérations pour lesquelles ces types d'adresses pris en charge devraient être utilisés dans les environnements VPN IPv6 ne sont pas du domaine d'application du présent document.

6. Multidiffusion​

Les opérations multicast ne relèvent pas du présent document.

7. Réseaux d'opérateurs imbriqués​

Parfois, un VPN IPv6 peut être le réseau d'un FAI IPv6, avec ses propres politiques de mise en relation et de routage. Parfois, un VPN IPv6 peut être le réseau d'un SP qui offre des services VPN à son tour à ses propres clients. Les VPN IPv6 comme ceux-ci peuvent également obtenir un service de base d'un autre SP, le « Carrier's Carrier », en utilisant la méthode Carriers décrite dans la section 9 de [BGP/MPLS-VPN] mais appliquée au trafic IPv6. Toutes les considérations abordées dans [BGP/MPLS-VPN] pour IPv4 VPN Carriers' Carriers demandent IPv6 VPN, à l'exception du fait que l'utilisation de MPLS (y compris la distribution d'étiquettes) entre le PE et le CE concerne les routes IPv6 au lieu des routes IPv4.

8. Dorsales multi-AS​

Les mêmes procédures décrites à la section 10 de [BGP/MPLS-VPN] peuvent être utilisées (et ont les mêmes propriétés d'évolutivité) pour traiter la situation où deux sites d'un VPN IPv6 sont connectés à différents systèmes autonomes.

lors de l'application de ces procédures pour les VPN IPv6; celles-ci sont décrites plus en détail dans le reste de cette section.

Approche a) : Connexions VRF-VRF aux routeurs frontières AS (Système autonome).

Cette approche est l'équivalent pour les VPN IPv6 à la procédure a) de la section 10 de [BGP/MPLS-VPN]. Dans le cas des VPN IPv6, IPv6 doit (MUST) être activé sur les interfaces entre les VRF et les VRF (sous-) inter-ASBR. Dans cette approche, les ASBR échangent des routes IPv6 (par opposition aux routes VPN-IPv6) et peuvent effectuer des correspondances sur IPv6 ou sur IPv4. L'échange des routes IPv6 DOIT être effectué conformément à [BGP-IPv6]. Cette méthode n'utilise pas les LSP inter-AS.

Enfin, notez qu'avec cette procédure, puisque chaque AS met en œuvre de manière indépendante les procédures intra-AS pour les VPN IPv6 décrites dans ce document, les AS participants peuvent tous utiliser en interne le tunnelage IPv4 ou le tunnelage IPv6; ou encore, certains AS participants peuvent utiliser en interne le tunnelage IPv4 tandis que d'autres utilisent le tunnelage IPv6.

Approche b) : redistribution EBGP des routes VPN-IPv6 étiquetées de l'AS à l'AS voisin.

Cette approche est l'équivalent pour les VPN IPv6 à la procédure (b) de la Section 10 de [BGP/MPLS-VPN]. Avec cette approche, les ASBR utilisent EBGP pour redistribuer les routes VPN-IPv4 étiquetées vers les ASBR dans d'autres ASes.

Dans cette approche, IPv6 peut être activé ou non sur les liaisons inter-ASBR, car les ASBR qui échangent des routes VPN-IPv6 peuvent établir leur session sur IPv4 ou IPv6 (dans ce dernier cas, IPv6 doit évidemment être activé sur la liaison inter-ASBR). L’échange des routes VPN-IPv6 étiquetées MUST être effectué conformément à [BGP-IPv6] et [MPLS-BGP]. Lorsque le trafic VPN-IPv6 est transporté dans un tunnel IPv6, le champ BGP Next Hop SHALL contenir une adresse IPv6. Lorsqu’il est transporté dans un tunnel IPv4, ce champ SHALL contenir une adresse IPv4 codée sous la forme d’une IPv4-mapped IPv6 address.

Cette approche exige l'existence de PSL inter-AS. Ainsi, les considérations de sécurité correspondantes décrites pour la procédure b) à la section 10 de [BGP/MPLS-VPN] s'appliquent également à cette approche pour IPv6.

Enfin, notez qu'avec cette procédure, comme avec la procédure a), puisque chaque AS met en œuvre de manière indépendante les procédures intra-AS pour les VPN IPv6 décrites dans ce document, les AS participants peuvent tous utiliser en interne le tunnelage IPv4 ou le tunnelage IPv6; en alternative, certains AS participants peuvent utiliser en interne le tunnelage IPv4 tandis que d'autres utilisent le tunnelage IPv6.

Approche (c) : redistribution EBGP multihop des routes VPN-IPv6 étiquetées entre la source et la destination ASes, avec redistribution EBGP des routes IPv4 ou IPv6 étiquetées de AS à AS voisin.

Cette approche est équivalente pour l'échange des routes VPN-IPv6 à la procédure (c) dans la section 10 de [BGP/MPLS-VPN] pour l'échange des routes VPN-IPv4.

Cette approche exige que les AS participants utilisent soit le tunnelage IPv4 soit le tunnelage IPv6.

Dans cette approche, les routes VPN-IPv6 ne sont ni entretenues ni distribuées par les routeurs ASBR. Les routeurs ASBR n'ont pas besoin d'être double pile. Un ASBR doit maintenir les routes IPv4 (ou IPv6) étiquetées vers les routeurs PE dans son AS. Il utilise EBGP pour distribuer ces routes vers d'autres ASes. Les ASBR dans tout transit ASes devront également utiliser EBGP pour passer le long des routes IPv4 (ou IPv6) étiquetées. Cela entraîne la création d'un chemin de commutation IPv4 (ou IPv6) label de routeur PE à l'entrée. Maintenant, les routeurs PE de différents AS peuvent établir des connexions EBGP multi-hop les unes aux autres sur IPv4 ou IPv6 et peuvent échanger des routes VPN-IPv6 étiquetées sur ces connexions EBGP. Notez que le champ BGP Next Hop de ces routes VPN-IPv6 distribuées contiendra une adresse IPv6 lorsque le tunnelage IPv6 est utilisé ou une adresse IPv4-mapée IPv6 lorsque le tunnelage IPv4 est utilisé.

Les considérations décrites pour la procédure c) à la section 10 de [BGP/MPLS-VPN] en ce qui concerne l'utilisation éventuelle de réflecteurs de route, en ce qui concerne l'utilisation éventuelle d'une troisième étiquette, et en ce qui concerne les LSP couvrant plusieurs AS s'appliquent également à cette approche VPN IPv6.

9. Accès à Internet depuis un VPN​

Les méthodes proposées par [BGP/MPLS-VPN] pour accéder à l'Internet IPv4 global à partir d'un VPN IPv4 peuvent être utilisées dans le contexte des VPN IPv6 et de l'Internet IPv6. Notez toutefois que si les paquets IPv6 des sites VPN IPv6 et destinés à l'Internet IPv6 global doivent traverser l'épine dorsale SP, et que si c'est un seul pilier IPv4, ces paquets doivent être tunnelés à travers cet épine dorsale IPv4.

De toute évidence, comme c'est le cas en dehors du contexte VPN, l'accès à l'Internet IPv6 à partir d'un VPN IPv6 nécessite l'utilisation d'adresses IPv6 globales.

En particulier, les adresses IPv6 locales uniques ne peuvent pas être utilisées pour l'accès à Internet IPv6.

10. VPN de gestion​

Les considérations de gestion examinées à la section 12 de [BGP/MPLS-VPN] s'appliquent à la gestion des VPN IPv6.

Lorsque le fournisseur de services gère le CE du site VPN IPv6, le fournisseur de services peut choisir d'utiliser IPv4 pour communiquer entre l'outil de gestion et le CE à de telles fins de gestion. Dans ce cas, que le client soit ou non connecté au site IPv4 (en plus du site IPv6), le CE fait effectivement partie d'un VPN IPv4 en plus de l'appartenance à un VPN IPv6 (c'est-à-dire que le CE est rattaché à un VRF qui prend en charge IPv4 en plus de IPv6). Les considérations présentées dans [BGP/MPLS-VPN], sur la façon de garantir que l'outil de gestion puisse communiquer avec ces EEC gérés à partir de plusieurs VPN sans permettre une accessibilité indésirable entre les EEC de différents VPN, sont applicables à la accessibilité IPv4 du VRF auquel le CE est attaché.

Lorsque le fournisseur de services gère le CE du site VPN IPv6, le fournisseur de services peut choisir d'utiliser IPv6 pour communiquer entre l'outil de gestion et le CE à de telles fins de gestion. Les considérations présentées dans [BGP/MPLS-VPN], sur la façon de garantir que l'outil de gestion peut communiquer avec ces CE gérés à partir de plusieurs VPN sans permettre une accessibilité indésirable entre les CE de différents VPN, sont alors applicables à la accessibilité IPv6 du VRF auquel le CE attache.

11. Considérations de sécurité​

Les extensions définies dans ce document permettent à MP-BGP de propager des informations de accessibilité sur les routes VPN IPv6.

Les considérations de sécurité relatives au transport des informations IPv6 sur la facilité d'accès à l'aide de BGP sont examinées à la section 5 de la RFC2545 et sont également applicables aux extensions décrites dans le présent document.

Les extensions décrites dans ce document pour offrir des VPN IPv6 utilisent exactement la même approche que celle décrite dans [BGP/MPLS-VPN]. Ainsi, les mêmes considérations de sécurité s'appliquent en ce qui concerne la sécurité des plans de données, la sécurité des plans de contrôle et la sécurité des dispositifs PE et P, comme décrit dans [BGP/MPLS-VPN], section 13.

12. Qualité de service​

Puisque tous les mécanismes QoS discutés pour les VPN IPv4 dans la section 14 de [BGP/MPLS-VPN] fonctionnent de la même manière pour IPv4 et IPv6 (Diffserv, Intserv, MPLS Traffic Engineering), les considérations QoS discutées dans [BGP/MPLS-VPN] sont également applicables aux VPN IPv6 (et ceci tient compte du fait que le tunnelage IPv4 ou le tunnelage IPv6 est utilisé dans l'épine dorsale).

13. Évolutivité​

Chacune des considérations de scalabilité résumées pour les VPN IPv4 dans la section 15 de [BGP/MPLS-VPN] s'applique également aux VPN IPv6.

14. Considérations relatives à l'IANA​

Ce document spécifie (voir la section 3.2) l'utilisation de la valeur 2 de l'AFI BGP (identificateur de famille d'adresses) ainsi que de la valeur 128 de l'AFI BGP (identificateur de famille d'adresses subséquentes) pour représenter la famille d'adresses « VPN-IPv6 Etiquetées », définie dans ce document.

L'utilisation de la valeur AFI 2 pour IPv6 est telle qu'elle est actuellement spécifiée dans le registre IANA "Adresse Identification de la famille", de sorte que IANA n'a pas à prendre de mesures à cet égard.

L'utilisation de la valeur SAFI 128 pour "adresse VPN marquée par MPLS" est actuellement spécifiée dans le registre IANA "Identificateur de famille d'adresses ultérieures", de sorte que IANA n'a pas besoin de prendre de mesures à son égard.

15. Remerciements​

Nous tenons à remercier Gerard Gastaud et Eric Levy-Abegnoli, qui ont contribué à ce document.

In memoriam​

Les auteurs tiennent à souligner la contribution précieuse de Tri T. Nguyen, décédé en avril 2002 après une maladie soudaine.

16. Références​

16.1. Références normatives​

  • [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. Références informatives​

  • [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.

Adresses des auteurs​

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]

Déclaration complète de droit d'auteur​

Droit d'auteur (C) Société Internet (2006).

Ce document est soumis aux droits, licences et restrictions contenus dans la BCP 78 et, sauf disposition contraire, les auteurs conservent tous leurs droits.

Le présent document et les renseignements contenus dans le présent document sont fournis sur la base du document « SAIS » et LE CONTRIBUTEUR, L'ORGANISATION, PAR LE REPRÉSENTANT OU PAR LE SAISI, LA SOCIÉTÉ INTERNET ET LA TASQUE INTERNET DIVULGENT TOUTES LES GARANTIES, EXPRESS OU IMPLIÉES, NOTAMMENT QUE L'UTILISATION DES INFORMATIONS ICI NE FERME PAS D'UN RÉGIME OU D'UNE GARANTIE IMPLIÉES DE MÉRANTABILITÉ OU D'AIDE POUR UN OBJET PARTICULIER.

Propriété intellectuelle​

L'IETF ne prend aucune position quant à la validité ou à la portée des droits de propriété intellectuelle ou autres droits qui pourraient être revendiqués en rapport avec la mise en œuvre ou l'utilisation de la technologie décrite dans le présent document ou quant à la mesure dans laquelle une licence en vertu de ces droits pourrait ou ne pourrait pas être disponible; elle ne signifie pas non plus qu'elle a fait un effort indépendant pour identifier ces droits.

Des copies des divulgations de droits de propriété intellectuelle faites au secrétariat de l'IETF et de toute assurance de licences à mettre à disposition, ou le résultat d'une tentative d'obtenir une licence générale ou une autorisation d'utilisation de ces droits de propriété par les exécutants ou les utilisateurs de cette spécification, peuvent être obtenus auprès du dépôt de droits de propriété intellectuelle en ligne de l'IETF à l'adresse suivante: http://www.ietf.org/ipr.

L'IETF invite toute partie intéressée à porter à son attention les droits d'auteur, brevets ou demandes de brevet, ou autres droits de propriété qui peuvent couvrir des technologies qui pourraient être nécessaires pour mettre en œuvre cette norme. Veuillez adresser les informations à l'IETF à l'IETF à l'adresse [email protected].

Remerciement​

Le financement de la fonction de rédacteur en chef du CCF est assuré par l'IETF (Activity Administrative Support Attachment - IASA).

Dernière mise à jour le