Passa al contenuto principale

RFC 4659 - Estensione delle reti private virtuali (VPN) IP BGP-MPLS per le VPN IPv6

  • Stato: Standard proposto
  • Pubblicato: settembre 2006
  • Flusso: IETF
  • Errata: Nessun errata

Informazioni sul documento​

  • Numero RFC: 4659
  • Titolo: Estensione delle reti private virtuali (VPN) IP BGP-MPLS per le VPN IPv6
  • Autori: J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur
  • Data: settembre 2006
  • Categoria: Percorso di standardizzazione
  • ISSN: 2070-1721

Sommario​

Questo documento descrive un metodo mediante il quale un fornitore di servizi può utilizzare la propria dorsale a commutazione di pacchetto per offrire servizi di rete privata virtuale (VPN) ai clienti IPv6. Il metodo riutilizza e, ove necessario, estende il metodo « BGP/MPLS IP VPN » per supportare IPv6. Nelle VPN IP BGP/MPLS, Multiprotocol BGP distribuisce le rotte VPN IPv4 sulla dorsale del fornitore, mentre MPLS inoltra i pacchetti VPN IPv4 sulla dorsale. Questo documento definisce una famiglia di indirizzi VPN IPv6 e descrive la corrispondente distribuzione delle rotte VPN IPv6 in Multiprotocol BGP. Il servizio VPN IPv6 è supportato sia su dorsali IPv4 sia su dorsali IPv6 e può utilizzare nel core varie tecniche di tunneling, tra cui MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) e tunnel protetti da IPsec. L’interfunzionamento tra un sito IPv4 e un sito IPv6 non rientra nell’ambito di questo documento.

Stato di questo memo​

Questo documento specifica un protocollo di monitoraggio degli standard Internet per la comunità Internet, e richiede discussioni e suggerimenti per miglioramenti. Si prega di fare riferimento all'edizione corrente degli "Standard Protocolli Ufficiali Internet" (STD 1) per lo stato di standardizzazione e lo stato di questo protocollo. La distribuzione di questo memo è illimitata.

Copyright (C) The Internet Society (2006).

Indice​

1. Introduzione​

Questo documento descrive un metodo con cui un fornitore di servizi può utilizzare la sua dorsale a commutazione di pacchetto per fornire servizi di rete privata virtuale per i suoi clienti IPv6.

Questo metodo riutilizza ed estende, ove necessario, il metodo "BGP/MPLS IP VPN" [BGP/MPLS-VPN] per il supporto di IPv6. In particolare, questo metodo utilizza lo stesso "modello peer" di [BGP/MPLS-VPN], in cui i router di bordo dei clienti ("router CE") inviano i loro percorsi IPv6 ai router di bordo del Service Provider ("router PE"). BGP ("Border Gateway Protocol," [BGP, BGP-MP]) viene poi utilizzato dal Service Provider per scambiare i percorsi di una particolare IPv6 VPN tra i router PE che sono collegati a tale IPv6 VPN. Alla fine, i router PE distribuiscono, ai router CE in una particolare VPN, i percorsi IPv6 da altri router CE in quella VPN. Come per le VPN IPv4, una caratteristica chiave di questo "modello peer" è che i router (IPv6) CE all'interno di una VPN (IPv6) non si interpellano tra loro; non c'è alcuna "overlay" visibile all'algoritmo di routing (IPv6) VPN.

Questo documento adotta le definizioni, gli acronimi e i meccanismi descritti in [BGP/MPLS-VPN]. Salvo diversa indicazione, i meccanismi di [BGP/MPLS-VPN] si applicano e non saranno ridescritti qui.

Si dice che una VPN sia una VPN IPv6 quando ogni sito di questa VPN è in grado di IPv6 ed è collegata nativamente tramite un'interfaccia IPv6 o una sotto-interfaccia alla dorsale del Service Provider (SP) tramite un dispositivo Provider Edge (PE).

Un sito può essere in grado sia IPv4 che IPv6. L'interfaccia logica su cui i pacchetti arrivano al PE può determinare la versione IP. In alternativa, la stessa interfaccia logica può essere utilizzata sia per IPv4 che IPv6, nel qual caso una ricerca per-packet al campo Versione dell'intestazione del pacchetto IP determina la versione IP.

Questo documento si riferisce solo alla gestione della comunicazione IPv6 tra host IPv6 situati su siti IPv6-capable. La gestione della comunicazione IPv4 tra host IPv4 situati su siti IPv4capable è al di fuori della portata di questo documento ed è coperta da [BGP/MPLS-VPN]. La comunicazione tra un host IPv4 situato in un sito IPv4 capace e un host IPv6 situato in un sito IPv6-capable è al di fuori della portata di questo documento.

In modo simile a come le rotte VPN IPv4 sono distribuite in [BGP/MPLS-VPN], BGP e le sue estensioni sono utilizzate per distribuire rotte da un sito VPN IPv6 a tutti gli altri router PE collegati a un sito della stessa IPv6 VPN. I PE utilizzano "tavole di inoltro e di inoltro VPN" (VPN Routing and Forwarding Tables) per mantenere separatamente le informazioni di raggiungibilità e di trasmissione di ogni VPN IPv6.

Come per le VPN IPv4 [BGP/MPLS-VPN], permettiamo a ciascuna VPN IPv6 di avere un proprio spazio di indirizzo IPv6, il che significa che un determinato indirizzo può indicare diversi sistemi in diverse VPN. Ciò avviene tramite una nuova famiglia di indirizzi, la famiglia di indirizzi VPN-IPv6, in modo simile a quello della famiglia di indirizzi VPN-IPv4, definita in [BGP/MPLS-VPN], che prepende un Route Distinguisher all'indirizzo IP.

Oltre al suo funzionamento su MPLS Label Switched Paths (LSP), la soluzione IPv4 BGP/MPLS VPN è stata estesa per consentire il funzionamento su altre tecniche di tunneling, tra cui tunnel GRE, tunnel IP-in-IP [2547-GRE/IP], tunnel L2TPv3 [MPLS-in-L2TPv3] e tunnel protetti IPsec [2547-IPsec]. In modo simile, questo documento consente il supporto di un servizio IPv6 VPN su LSP MPLS, così come su altre tecniche di tunneling.

Questo documento consente il supporto per un servizio VPN IPv6 su una dorsale IPv4, così come su una dorsale IPv6. Il servizio VPN IPv6 supportato è identico in entrambi i casi.

La soluzione IPv6 VPN definita in questo documento offre i seguenti vantaggi:

  • Sia dal punto di vista del Service Provider che del cliente, il servizio VPN che può essere supportato per i siti IPv6 è identico a quello supportabile per i siti IPv4.

  • Dal punto di vista del Service Provider, le operazioni del servizio VPN IPv6 richiedono le stesse competenze, procedure e meccanismi del servizio VPN IPv4.

  • Quando sia le VPN IPv4 che i servizi VPN IPv6 sono supportati su un nucleo IPv4, lo stesso insieme di relazioni di peering MP-BGP e la stessa rete singola PE-PE possono (MAY) essere utilizzati per entrambi.

  • Il servizio IPv6 VPN è indipendente dal fatto che il core funzioni IPv4 o IPv6. Ciò è in modo che il servizio IPv6 VPN supportato prima e dopo una migrazione del core da IPv4 a IPv6 non sia distinguibile dal cliente VPN.

Nota che il supporto ai servizi VPN IPv4 su un core IPv6 non è coperto da questo documento.

2. Famiglia di indirizzi VPN-IPv6​

Le estensioni multiprotocollo BGP [BGP-MP] consentono a BGP di trasportare rotte da più "famiglie di indirizzi." Introduciamo la nozione di "famiglia di indirizzi VPN-IPv6," che è simile alla famiglia di indirizzi VPN-IPv4 introdotta in [BGP/MPLS-VPN].

Un indirizzo VPN-IPv6 è una quantità di 24 oct, che inizia con un 8 octet "Route Distinguinger" (RD) e termina con un indirizzo IPv6 di 16 ottetti.

Lo scopo della RS è unicamente quello di consentire di creare rotte distinte verso un prefisso comune IPv6, simile allo scopo della RS definita in [BGP/MPLS-VPN]. Allo stesso modo in cui è possibile per [BGP/MPLS-VPN], la RD può essere utilizzata per creare più rotte diverse rispetto allo stesso sistema. Ciò può essere ottenuto creando due differenti rotte VPN-IPv6 che hanno la stessa parte IPv6 ma differenti RD. Ciò consente al provider di installare più rotte differenti allo stesso sistema e consente di utilizzare la politica per decidere quali pacchetti utilizzare quale rotta.

Inoltre, se due VPN usassero lo stesso prefisso IPv6 (che indica efficacemente diversi sistemi fisici), i PE li tradurrebbero in esclusivi prefisso VPN-IPv6 usando differenti RD. Ciò garantisce che se lo stesso indirizzo viene mai utilizzato in due VPN diverse, è possibile installare due percorsi completamente diversi a quell'indirizzo, uno per ogni VPN.

Poiché gli indirizzi VPN-IPv6 e IPv6 appartengono a diverse famiglie di indirizzi, BGP non li tratta mai come indirizzi comparabili.

Un VRF può avere più percorsi VPN-IPv6 a pari costo per un prefisso unico IPv6. Quando l'indirizzo di destinazione di un pacchetto è abbinato in un VRF contro un percorso VPN-IPv6, solo la parte IPv6 è effettivamente abbinata.

Il formato e la codifica del Route Distinguisher sono specificati in [BGP/MPLS-VPN].

Quando un sito è in grado di IPv4 e IPv6 in grado, la stessa RD può (MAY) essere utilizzata per la pubblicità di indirizzi IPv6 e indirizzi IPv4. In alternativa, una diversa RD può essere utilizzata per la pubblicità degli indirizzi IPv4 e degli indirizzi IPv6. Nota, tuttavia, che nell'ambito di questa specifica, indirizzi IPv4 e indirizzi IPv6 saranno sempre gestiti in contesti separati, e che nessun IPv4-IPv6 problemi di interworking e tecniche saranno discussi. (MAY)

3. Distribuzione delle rotte VPN-IPv6​

3.1. Distribuzione delle rotte tra PE tramite BGP​

Come descritto in [BGP/MPLS-VPN], se due siti di un VPN si collegano a PE che si trovano nello stesso sistema autonomo, i PE possono (MAY) distribuire le rotte VPN tra loro tramite una connessione interna (IPv4) Border Gateway Protocol (iBGP). In alternativa, ogni PE può avere connessioni iBGP ai riflettori di rotta. Allo stesso modo, per la distribuzione IPv6 VPN, i PE possono utilizzare connessioni iBGP tra loro o utilizzare connessioni iBGP ai riflettori di rotta. Per IPv6 VPN, le connessioni iBGP possono essere su IPv4 o su IPv6.

I router PE si scambiano, tramite MP-BGP [BGP-MP], informazioni sulla raggiungibilità dei prefissi IPv6 nelle VPN IPv6 e si annunciano così come il BGP Next Hop.

Le regole per la codifica delle informazioni sulla raggiungibilità e l'indirizzo BGP Next Hop sono specificate nelle sezioni seguenti.

3.2. Codifica NLRI VPN IPv6​

Quando si distribuiscono rotte IPv6 VPN, il router annunciante PE DEVE (MUST) assegnare e distribuire etichette MPLS con le rotte IPv6 VPN. Essenzialmente, i router PE non distribuiscono rotte IPv6 VPN, ma Etichettato IPv6 VPN percorsi [MPLS-BGP]. Quando il PE annunciante riceve un pacchetto che ha questa particolare etichetta pubblicizzata, il PE pop questa etichetta dalla pila MPLS e elaborare il pacchetto in modo appropriato (cioè, inoltrarlo direttamente in base all'etichetta o eseguire una ricerca nel corrispondente contesto IPv6-VPN).

Le estensioni multiprotocollo di BGP [BGP-MP] vengono utilizzate per annunciare le rotte VPN IPv6 nelle informazioni di raggiungibilità del livello di rete MP_REACH (NLRI). I campi Address Family Identifier (AFI) e Subsequent Address Family Identifier (SAFI) MUST essere impostati come segue:

  • AFI: 2; per IPv6

  • SAFI: 128; per indirizzi VPN-IPv6 con etichetta MPLS

Il campo NLRI stesso è codificato come specificato in [MPLS-BGP]. Nel contesto di questa estensione, il prefisso appartiene alla famiglia di indirizzi VPN-IPv6 e consiste quindi di un Route Distinguisher a 8 ottetti seguito da un prefisso IPv6 come specificato nella sezione 2, sopra.

3.2.1. Codifica del Next Hop BGP​

La codifica del BGP Next Hop dipende dalla politica dello speaker BGP: il traffico VPN IPv6 può essere trasportato verso tale Next Hop mediante tunneling IPv6 (speaker BGP che richiede il trasporto IPv6) oppure mediante tunneling IPv4 (speaker BGP che richiede il trasporto IPv4).

La definizione di questa politica (richiedere il trasporto attraverso il tunnel IPv4 o IPv6) è responsabilità dell'operatore di rete e va al di là del campo di applicazione del presente documento. Si noti che è possibile che tale politica richieda il trasporto su IPv4 (risp. IPv6), mentre gli altoparlanti BGP scambiano informazioni sulla raggiungibilità IPv6 VPN su IPv6 (risp. IPv4). Tuttavia, in questo caso, sono da considerare una serie di implicazioni operative. In particolare, un difetto non rilevato che colpisce l'IPv4 (risp. IPv6) percorso dati tunneling e non influenza il percorso dati IPv6 (resp. IPv4) potrebbe rimanere non rilevato da BGP, che a sua volta può causare il black-holing del traffico.

Il controllo di questa politica è al di là del campo di applicazione di questo documento e può essere basato sulla configurazione dell'utente.

3.2.1.1. Speaker BGP che richiede il trasporto IPv6​

Quando il traffico IPv6 VPN deve (SHALL) essere trasportato all'speaker BGP utilizzando il tunneling IPv6 (ad esempio, LSP IPv6 MPLS, tunnel IPv6 protetti da IPsec), l'speaker BGP DEVE annunciare un campo di indirizzo di rete Next Hop contenente un indirizzo VPN-IPv6

  • la cui RS a 8 ottetti è impostata a zero, e

  • il cui indirizzo IPv6 è impostato su IPv6 globale dell'altoparlante annunciante BGP.

Questo è potenzialmente seguito da un altro indirizzo VPN-IPv6

  • la cui RS a 8 ottetti è impostata a zero, e

  • il cui indirizzo IPv6 è impostato su un collegamento IPv6 locale dell'altoparlante annunciante BGP.

Il valore della lunghezza del campo Indirizzo di rete Hop successivo nell'attributo MP_REACH_NLRI è impostato a 24 quando è presente solo un indirizzo globale e a 48 se è incluso un indirizzo locale di collegamento nel campo Hop successivo.

Se gli altoparlanti BGP utilizzano solo il loro indirizzo IPv6 locale (ad esempio, nel caso in cui un indirizzo IPv6 CE sia pari a un PE IPv6 in cui il CE non abbia un indirizzo IPv6 globale e in cui l'eBGP sia ottenuto tramite gli indirizzi locali del collegamento), l'indirizzo non specificato ([V6ADDR]) viene utilizzato dall'speaker BGP annunciante per indicare l'assenza dell'indirizzo IPv6 globale nel campo Indirizzo di rete Next Hop.

L'indirizzo locale di collegamento è incluso nel campo Next Hop se e solo se l'speaker BGP annunciante condivide una sottorete comune con il pari la rotta viene pubblicizzata a [BGP-IPv6].

In tutti gli altri casi, un speaker BGP pubblicizzerà al suo pari nel campo Next Hop Network Address solo l'indirizzo IPv6 globale del prossimo hop.

Di conseguenza, un speaker BGP che pubblicizza un percorso verso un peer interno può modificare l'indirizzo di rete del campo Next Hop rimuovendo l'indirizzo IPv6 del prossimo hop.

Uno scenario di esempio in cui sia l'indirizzo IPv6 globale che l'indirizzo IPv6 locale sono inclusi nel campo di indirizzo BGP Next Hop è quello in cui il servizio IPv6 VPN è supportato da una dorsale multi-autonoma del sistema (AS) con ridistribuzione di VPN etichettata-

I percorsi IPv6 tra i Router di frontiera del sistema autonomo (ASBR) di diversi AS che condividono una rete IPv6 comune: in tal caso, sia l'indirizzo IPv6 globale che l'indirizzo IPv6 locale sono pubblicizzati dagli ASBR.

3.2.1.2. Speaker BGP che richiede il trasporto IPv4​

Quando il traffico IPv6 VPN deve (SHALL) essere trasportato all'speaker BGP utilizzando il tunneling IPv4 (ad esempio, IPv4 MPLS LSP, IPsec-protetto tunnel IPv4), l'speaker BGP DEVE annunciare al suo pari un campo di indirizzo di rete Next Hop contenente un indirizzo VPN-IPv6:

  • la cui RS a 8 ottetti è impostata a zero, e

  • il cui indirizzo IPv6 a 16 ottetti è codificato come indirizzo IPv4 mapped [V6ADDR] contenente l'indirizzo IPv4 dell'altoparlante annunciante BGP. Questo indirizzo IPv4 deve essere instradabile dall'altro speaker BGP.

3.3. Route Target​

L'uso del target di rotta è specificato in [BGP/MPLS-VPN] e si applica alle VPN IPv6. La codifica dell'attributo community esteso è definita in [BGP-EXTCOM].

3.4. Negoziazione delle capacità BGP​

Per scambiare due PE con gli NLRI IPv6 VPN, DEVONO (MUST) utilizzare le capacità di negoziazione BGP per garantire che siano in grado di trattare correttamente tali NLRI. Ciò avviene come specificato in [BGP-MP] e [BGP-CAP], utilizzando il codice di capacità 1 (multiprotocollo BGP), con i valori AFI e SAFI come specificato sopra, nella sezione 3.2.

4. Incapsulamento​

Il router PE di ingresso DEVE (MUST) trasportare in tunnel i dati VPN IPv6 sulla dorsale verso il router PE di Egress identificato come il BGP Next Hop per il prefisso IPv6 VPN corrispondente.

Quando l'indirizzo IPv6 a 16 ottetti contenuto nel campo BGP Next Hop è codificato come indirizzo IPv6 mapped (vedi Sezione 3.2.1.2), l'indirizzo PE INgress DEVE (MUST) usare il tunneling IPv4 a meno che non sia esplicitamente configurato per fare altrimenti. L'ingresso PE POSSO consentire, opzionalmente, attraverso una configurazione esplicita, l'uso del tunnel IPv6 quando l'indirizzo IPv6 a 16 ottetti contenuto nel campo BGP Next Hop viene codificato come indirizzo IPv6 mapped IPv6. Ciò consentirebbe di supportare ambienti di distribuzione particolari in cui è richiesto il tunneling IPv6, ma in cui gli indirizzi IPv6 mapped IPv6 sembrano essere utilizzati per la raggiungibilità IPv6 degli indirizzi PE invece degli indirizzi IPv6 globali. (MAY)

Quando l'indirizzo IPv6 a 16 ottetti contenuto nel campo BGP Next Hop non è codificato come indirizzo IPv4 (vedere Sezione 3.2.1.1), il PE di ingresso DEVE (MUST) usare il tunnel IPv6.

Quando un PE riceve un pacchetto da un CE allegato, esso osserva l'indirizzo di destinazione IPv6 del pacchetto nel VRF corrispondente a quel CE. Ciò gli permette di trovare una via VPN-IPv6. La rotta VPN-IPv6 avrà un'etichetta MPLS associata e un'etichetta BGP Next Hop. In primo luogo, questa etichetta MPLS viene spinta sul pacchetto come etichetta inferiore. Poi, questo pacchetto etichettato viene incapsulato nel tunnel per il trasporto al PE di egresso identificato dal BGP Next Hop. I dettagli di questa incapsulamento dipendono dalla tecnica di tunneling reale, come segue:

Come per le gallerie IPv4 VPN MPLS/BGP [2547-GRE/IP], quando si fa tunneling utilizzando tunnel IPv4 o tunnel IPv6 (resp. tunnel IPv4 GRE o tunnel IPv6 GRE), l'incapsulamento del pacchetto IPv6 VPN etichettato risulta in un pacchetto incapsulato MPLS-in-GRE (resp. MPLS-in-GRE) come specificato in [MPLS-in-IP/GRE]. Quando il tunneling viene fatto utilizzando L2TPv3, l'incapsulamento del pacchetto IPv6 VPN etichettato risulta in un pacchetto incapsulato MPLS-in-L2TPv3, come specificato in [MPLS-in-L2TPv3].

Come per MPLS/BGP per le VPN IPv4, quando si fa tunnel utilizzando un tunnel protetto IPsec [2547-IPsec], l'incapsulamento del pacchetto IPv6 VPN etichettato risulta in un pacchetto MPLS-in-IP- o MPLS-in-GRE-incapsulato [MPLS-in-IP/GRE]. La modalità di trasporto IPsec viene utilizzata per proteggere questo tunnel IPv4 o GRE dall'ingresso PE all'uscita PE.

Quando si fa il tunnel con tunnel IPv4 (se IPsec è protetto o no), il router Ingress PE DEVE (MUST) utilizzare l'indirizzo IPv4 codificato nel campo IPv6 mappato IPv6 del campo BGP successivo come indirizzo di destinazione dell'intestazione del tunnel IPv4 pre-peded. Usa uno dei suoi indirizzi IPv4 come indirizzo sorgente dell'intestazione del tunnel IPv4 pre-peded.

Quando si fa il tunnel usando tunnel IPv6 (se IPsec è protetto o no), il router Ingress PE DEVE (MUST) usare l'indirizzo IPv6 contenuto nel campo indirizzo IPv6 del campo successivo BGP come indirizzo di destinazione dell'intestazione del tunnel IPv6 pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre-pre

Quando si fa tunneling utilizzando LSP MPLS, gli LSP possono essere stabiliti utilizzando qualsiasi tecnica di distribuzione delle etichette (LDP [LDP], RSVP-TE [RSVP-TE], ecc.).

Quando si fa il tunnel usando gli LSP MPLS, il router PE di ingresso DEVE (MUST) spingere direttamente l'etichetta LSP del tunnel sull'etichetta del pacchetto IPv6 VPN (cioè senza dover prevedere alcun intestazione IPv4 o IPv6). L'etichetta spinta corrisponde all'etichetta LSP che inizia sull'ingresso PE Router e termina sull'egresso PE Router. Il campo BGP Next Hop viene utilizzato per identificare il router PE di uscita e a sua volta l'etichetta da spingere sullo stack. Quando l'indirizzo IPv6 nel campo BGP Next Hop è un indirizzo IPv6 IPv4, l'indirizzo IPv4 incorporato determinerà l'etichetta tunnel per premere sull'etichetta stack. In ogni altro caso, l'indirizzo IPv6 nel campo BGP Next Hop determinerà l'etichetta tunnel per spingere sull'etichetta stack.

Per garantire l'interoperabilità tra i sistemi che implementano questa architettura VPN, tutti questi sistemi DEVONO (MUST) supportare il tunnel utilizzando LSP MPLS stabiliti da LDP [LDP].

5. Tipi di indirizzi​

Poiché gli indirizzi unicast Link-local sono definiti per l'uso su un solo link, questi possono essere utilizzati sul link PE-CE, ma non sono supportati per la raggiungibilità su siti VPN IPv6 e non sono mai pubblicizzati tramite protocollo di gateway multiprotocollo-bordo (MP-BGP) su PE remoti.

Gli indirizzi unicast globali sono definiti come interfacce di identificazione univoca ovunque nell'Internet IPv6. Gli indirizzi globali dovrebbero essere comunemente utilizzati all'interno e all'interno dei Siti VPN IPv6. Essi sono ovviamente supportati da questa soluzione VPN IPv6 per la raggiungibilità attraverso i Siti VPN IPv6 e pubblicizzati tramite MP-BGP su PE remoti e vengono elaborati senza alcuna considerazione specifica per il loro scopo globale.

Citando da [UNIQUE-LOCAL]: "Questo documento definisce un formato di indirizzo IPv6 unicast che è unico a livello globale ed è destinato alle comunicazioni locali [IPv6]. Questi indirizzi sono chiamati Unique Local IPv6 Unicast Address e sono abbreviati in questo documento come indirizzi IPv6 Local. Non sono previsti per essere instradabili su Internet globale. Sono instradabili all'interno di un'area più limitata come un sito. Possono anche essere instradati tra un set limitato di siti."

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

In conformità a questo, Unici indirizzi IPv6 locali Unicast sono supportati dalla soluzione IPv6 VPN specificato in questo documento per la raggiungibilità attraverso i siti IPv6 VPN. Quindi, la raggiungibilità a tali indirizzi IPv6 locali Unici possono essere pubblicizzati tramite MP-BGP a PE remoti ed elaborati da PE allo stesso modo degli indirizzi Unicast globali.

Le raccomandazioni e le considerazioni per le quali tali tipi di indirizzi supportati dovrebbero essere utilizzati in ambienti VPN IPv6 non rientrano nell'ambito di applicazione del presente documento.

6. Multicast​

Le operazioni multicast non rientrano nell'ambito di applicazione del presente documento.

7. Carrier's Carrier​

A volte, una VPN IPv6 può essere la rete di un ISP IPv6, con le sue politiche di peering e routing. A volte, una VPN IPv6 può essere la rete di un SP che offre servizi VPN a sua volta ai propri clienti. Le VPN IPv6 come queste possono anche ottenere un servizio dorsale da un altro SP, il "Carrier's Carrier," utilizzando il metodo Carrier's Carrier descritto nella Sezione 9 di [BGP/MPLS-VPN], ma applicato al traffico IPv6. Tutte le considerazioni discusse in [BGP/MPLS-VPN] per il VPN Carrier di IPv4 si applicano per IPv6 VPN, ad eccezione del fatto che l'uso di MPLS (compresa la distribuzione di etichette) tra PE e CE riguarda rotte IPv6 invece di rotte IPv4.

8. Backbone multi-AS​

Le stesse procedure descritte nella sezione 10 di [BGP/MPLS-VPN] possono essere utilizzate (e hanno le stesse proprietà di scalabilità) per affrontare la situazione in cui due siti di una VPN IPv6 sono collegati a diversi sistemi autonomi. Tuttavia, alcuni punti aggiuntivi vanno segnalati

quando si applicano queste procedure per le VPN IPv6; queste sono descritte ulteriormente nel resto di questa sezione.

Approccio (a): connessioni VRF-to-VRF presso i router di confine AS (sistema autonomo).

Questo approccio è l'equivalente per le VPN IPv6 alla procedura (a) nella sezione 10 di [BGP/MPLS-VPN]. Nel caso delle VPN IPv6 IPv6 deve (MUST) essere attivato sulle inter-ASBR VRF-to-VRF (sotto) interfacce. In questo approccio, le rotte ASBRs di scambio IPv6 (in contrasto con le rotte VPN-IPv6) e possono essere inter-IPv6 o IPv4. Lo scambio di rotte IPv6 DEVE essere effettuato secondo [BGP-IPv6]. Questo metodo non utilizza LSP inter-AS.

Infine, si noti che con questa procedura, poiché ogni SA implementa in modo indipendente le procedure intra-AS per le VPN IPv6 descritte in questo documento, gli AS partecipanti possono utilizzare tutti internamente il tunneling IPv4, o il tunneling IPv6; o in alternativa, alcuni AS partecipanti possono utilizzare internamente il tunneling IPv4, mentre altri utilizzano il tunneling IPv6.

Approccio (b): ridistribuzione EBGP delle rotte VPN-IPv6 etichettate da AS a AS confinante.

Questo approccio è l'equivalente per le VPN IPv6 alla procedura (b) nella sezione 10 di [BGP/MPLS-VPN]. Con questo approccio, gli ASBR utilizzano EBGP per ridistribuire le rotte VPN-IPv4 etichettate per ASBR in altri ASBR.

In questo approccio, IPv6 può essere attivato o meno sui collegamenti inter-ASBR, poiché gli ASBR che scambiano rotte VPN-IPv6 possono stabilire il peering su IPv4 o IPv6 (in quest’ultimo caso IPv6 deve ovviamente essere attivato sul collegamento inter-ASBR). Lo scambio delle rotte VPN-IPv6 etichettate MUST essere eseguito secondo [BGP-IPv6] e [MPLS-BGP]. Quando il traffico VPN-IPv6 viene trasportato mediante tunnel IPv6, il campo BGP Next Hop SHALL contenere un indirizzo IPv6. Quando viene trasportato mediante tunnel IPv4, tale campo SHALL contenere un indirizzo IPv4 codificato come IPv4-mapped IPv6 address.

Questo approccio richiede che vi siano LSP inter-AS. Pertanto, le considerazioni (di sicurezza) corrispondenti descritte per la procedura (b) nella sezione 10 del [BGP/MPLS-VPN] si applicano ugualmente a questo approccio per IPv6.

Infine, si noti che con questa procedura, come con la procedura (a), poiché ogni AS implementa in modo indipendente le procedure intra-AS per le VPN IPv6 descritte in questo documento, gli AS partecipanti possono utilizzare tutti internamente tunneling IPv4 o tunneling IPv6; in alternativa, alcuni AS partecipanti possono utilizzare internamente tunneling IPv4 mentre altri utilizzano tunneling IPv6.

Approccio (c): ridistribuzione multihop EBGP delle rotte VPN-IPv6 etichettate tra sorgente e destinazione AS, con ridistribuzione EBGP delle rotte IPv4 o IPv6 etichettate da AS a AS contigue.

Questo approccio è equivalente per lo scambio di rotte VPN-IPv6 alla procedura (c) nella sezione 10 di [BGP/MPLS-VPN] per lo scambio di rotte VPN-IPv4.

Questo approccio richiede che gli AS partecipanti usino tutti il tunneling IPv4 o tutti usino il tunneling IPv6.

In questo approccio, le rotte VPN-IPv6 non vengono mantenute né distribuite dai router ASBR. I router ASBR non devono essere dual stack. Un ASBR deve mantenere le rotte IPv4 (o IPv6) ai router PE all'interno del proprio AS. Usa EBGP per distribuire queste rotte ad altri AS. Le ASBR in qualsiasi ASes transito dovranno anche utilizzare EBGP per passare lungo le rotte IPv4 (o IPv6) etichettate. Ciò si traduce nella creazione di un percorso di commutazione dell'etichetta IPv4 (o IPv6) dall'ingresso del router PE all'uscita del router PE. Ora, i router PE in diversi AS possono stabilire connessioni EBGP multi-hop tra loro tramite IPv4 o IPv6 e possono scambiare rotte VPN-IPv6 etichettate su quelle connessioni EBGP. Nota che il campo BGP Next Hop di queste rotte VPN-IPv6 distribuite conterrà un indirizzo IPv6 quando si usa il tunnel IPv6 o un indirizzo IPv4 mapped IPv6 quando si utilizza il tunnel IPv4.

Le considerazioni descritte per la procedura c) nella sezione 10 del [BGP/MPLS-VPN] riguardo al possibile uso di rivelatori di rotta, rispetto al possibile uso di una terza etichetta e rispetto ai LSP che coprono più AS si applicano ugualmente a questo approccio IPv6.

9. Accesso a Internet da una VPN​

I metodi proposti da [BGP/MPLS-VPN] per accedere a IPv4 Internet globale da un IPv4 VPN possono essere utilizzati nel contesto delle VPN IPv6 e dell'Internet IPv6 globale. Tuttavia, si noti che se i pacchetti IPv6 provenienti da siti IPv6 VPN e destinati all'Internet IPv6 globale hanno bisogno di attraversare la dorsale SP, e che se si tratta di un'unica dorsale IPv4, questi pacchetti devono essere tunnelati attraverso quella dorsale IPv4.

Chiaramente, come avviene al di fuori del contesto VPN, l'accesso a Internet IPv6 da una VPN IPv6 richiede l'uso di indirizzi IPv6 globali.

In particolare, gli indirizzi IPv6 locali unici non possono essere utilizzati per l'accesso a Internet IPv6.

10. VPN di gestione​

Le considerazioni di gestione discusse nella sezione 12 del [BGP/MPLS-VPN] si applicano alla gestione delle VPN IPv6.

Qualora il fornitore di servizi gestisca il sito VPN di IPv6, il fornitore di servizi può scegliere di utilizzare IPv4 per la comunicazione tra lo strumento di gestione e il CE per tali scopi di gestione. In tal caso, indipendentemente dal fatto che un sito IPv4 sia effettivamente collegato al sito CE (oltre al sito IPv6), il CE fa effettivamente parte di un sistema VPN di IPv4 oltre che di un sistema VPN di IPv6 (cioè, il CE è collegato a un VRF che supporta IPv4 oltre a IPv6). Le considerazioni presentate in [BGP/MPLS-VPN], su come garantire che lo strumento di gestione possa comunicare con tali CE gestiti da più VPN senza consentire la raggiungibilità non desiderata attraverso CE di diverse VPN, sono applicabili alla raggiungibilità IPv4 del VRF a cui il CE si lega.

Qualora il fornitore di servizi gestisca il sito VPN di IPv6, il fornitore di servizi può scegliere di utilizzare IPv6 per la comunicazione tra lo strumento di gestione e il CE per tali finalità di gestione. Le considerazioni presentate in [BGP/MPLS-VPN], su come garantire che lo strumento di gestione possa comunicare con tali CE gestiti da più VPN senza consentire una raggiungibilità non desiderata tra le VPN di diverse VPN, sono quindi applicabili alla raggiungibilità IPv6 del VRF a cui il CE si lega.

11. Considerazioni sulla sicurezza​

Le estensioni definite in questo documento permettono a MP-BGP di diffondere informazioni sulla raggiungibilità delle vie VPN IPv6.

Le considerazioni di sicurezza per il trasporto delle informazioni sulla raggiungibilità IPv6 utilizzando BGP sono discusse nella sezione 5 RFC2545 e sono ugualmente applicabili per le estensioni descritte nel presente documento.

Le estensioni descritte in questo documento per offrire le VPN IPv6 utilizzano lo stesso approccio descritto in [BGP/MPLS-VPN]. Come tali, le stesse considerazioni di sicurezza si applicano per quanto riguarda la sicurezza del Data Plane, la sicurezza del Control Plane e la sicurezza del dispositivo PE e P come descritto in [BGP/MPLS-VPN], Sezione 13.

12. Qualità del servizio​

Poiché tutti i meccanismi QoS discussi per le VPN IPv4 nella sezione 14 di [BGP/MPLS-VPN] operano nello stesso modo per IPv4 e IPv6 (Diffserv, Intserv, MPLS Traffic Engineering), le considerazioni QoS discusse in [BGP/MPLS-VPN] sono ugualmente applicabili alle VPN IPv6 (e ciò vale sia che si tratti di tunnel IPv4 o di tunnel IPv6 nella dorsale).

13. Scalabilità​

Ciascuna delle considerazioni di scalabilità riassunte per le VPN IPv4 nella sezione 15 di [BGP/MPLS-VPN] è ugualmente applicabile alle VPN IPv6.

14. Considerazioni IANA​

Questo documento specifica (cfr. sezione 3.2) l'uso del valore 2 dell'AFI BGP (Address Family Identifier) insieme al valore 128 dell'Address Family Identifier BGP (Subsequent Address Family Identifier) per rappresentare la famiglia di indirizzi "VPN-IPv6 Labeled Addresses," definita in questo documento.

L'uso del valore AFI 2 per IPv6 è come specificato attualmente nel registro IANA "Address Family Identifier," quindi IANA non deve prendere alcuna misura in merito.

L'uso di SAFI value 128 per "indirizzo VPN etichettato con MPLS" è attualmente specificato nel registro di sistema IANA "Subsequence Address Family Identifier," quindi IANA non deve prendere alcuna iniziativa in merito.

15. Ringraziamenti​

Ringraziamo Gerard Gastaud e Eric Levy-Abegnoli, che hanno contribuito a questo documento.

In memoriam​

Gli autori vorrebbero riconoscere il prezioso contributo di Tri T. Nguyen, scomparso nell'aprile 2002 dopo una malattia improvvisa.

16. Riferimenti​

16.1. Riferimenti normativi​

  • [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. Riferimenti informativi​

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

Indirizzi degli autori​

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]

Copyright (C) The Internet Society (2006).

Il presente documento è soggetto ai diritti, licenze e restrizioni contenuti nel BCP 78 e, salvo quanto stabilito in esso, gli autori conservano tutti i loro diritti.

Il presente documento e le informazioni in esso contenute sono fornite su base "così come è" e il Contributore, l'organizzazione che lo rappresenta o è SPONSORIATA (se del caso), la società internet e l'impresa di motorizzazione internazionale informano la Commissione di tutte le garanzie, espresse o implicite, comprese le garanzie che l'uso delle informazioni qui contenute non infliggerà alcun diritto o qualsiasi garanzia di Merchantability o di Fitness per un particolare scopo.

Proprietà intellettuale​

L'IETF non prende posizione sulla validità o sulla portata di diritti di proprietà intellettuale o di altri diritti che potrebbero essere rivendicati in relazione all'attuazione o all'uso della tecnologia descritta nel presente documento o sulla misura in cui una licenza in base a tali diritti potrebbe o non potrebbe essere disponibile; non rappresenta neppure uno sforzo indipendente per identificare tali diritti. Le informazioni sulle procedure relative ai diritti nei documenti RFC sono contenute nei BCP 78 e BCP 79.

Copie di informazioni sui DPI rese al Segretariato dell'IETF e di eventuali garanzie di licenze da mettere a disposizione, o il risultato di un tentativo di ottenere una licenza generale o un permesso per l'uso di tali diritti proprietari da parte di implementatori o utenti di questa specifica possono essere ottenute dal repository IETF on-line sui DPI all'indirizzo http://www.ietf.org/ipr.

L'IETF invita qualsiasi parte interessata a portare alla sua attenzione qualsiasi copyright, brevetto o domanda di brevetto, o altri diritti proprietari che possano riguardare la tecnologia che potrebbe essere necessaria per attuare questo standard. Si prega di rivolgersi all'IETF all'indirizzo [email protected].

Ringraziamento​

Il finanziamento della funzione RFC Editor è fornito dall'attività di supporto amministrativo IETF (IASA).

Ultimo aggiornamento il