3. Distribuzione delle route VPN-IPv6

3.1. Distribuzione delle route tra i PE tramite BGP

Come descritto in [BGP/MPLS-VPN], se due siti di una VPN sono connessi a PE situati nello stesso sistema autonomo, questi PE possono scambiarsi le route VPN tramite la loro connessione (IPv4) iBGP (Internal Border Gateway Protocol). In alternativa, ciascun PE può stabilire una connessione iBGP con un route reflector. Analogamente, per la distribuzione delle route IPv6 VPN, i PE possono utilizzare la loro connessione iBGP tra loro, o una connessione iBGP verso un route reflector. Per la VPN IPv6, la connessione iBGP può essere basata su IPv4 o IPv6.

I router PE scambiano, tramite MP-BGP [BGP-MP], le informazioni di raggiungibilità dei prefissi IPv6 nella VPN IPv6 e si annunciano di conseguenza come hop successivo BGP (BGP Next Hop).

La codifica delle informazioni di raggiungibilità e le regole relative all'indirizzo dell'hop successivo BGP sono specificate nelle sezioni seguenti.

3.2. Codifica della NLRI VPN IPv6

Nella distribuzione delle route IPv6 VPN, il router PE che effettua l'annuncio DEVE allocare e distribuire un'etichetta MPLS per tali route. In sostanza, il router PE distribuisce non una normale route IPv6 VPN, ma una route IPv6 VPN etichettata [MPLS-BGP]. Quando il router PE che effettua l'annuncio riceve un pacchetto che trasporta l'etichetta annunciata, il PE estrae tale etichetta dallo stack MPLS ed elabora il pacchetto di conseguenza (ovvero, inoltro diretto basato sull'etichetta, o ricerca nel contesto IPv6-VPN appropriato).

Le estensioni multiprotocollo di BGP [BGP-MP] vengono utilizzate per annunciare le route IPv6 VPN nella NLRI (Network Layer Reachability Information) MP_REACH. I campi dell'identificatore della famiglia di indirizzi (AFI) e dell'identificatore della famiglia di indirizzi successiva (SAFI) DEVONO essere impostati come segue:

• AFI: 2; per IPv6

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

La codifica del campo NLRI stesso è specificata in [MPLS-BGP]. Nel contesto di questa estensione, il prefisso appartiene alla famiglia di indirizzi VPN-IPv6 e pertanto è composto da un Route Distinguisher di 8 byte, seguito dal prefisso IPv6 descritto nella sezione 2 precedente.

3.2.1. Codifica dell'hop successivo BGP

La codifica dell'hop successivo BGP dipende dalla politica dello speaker BGP: richiede che il traffico VPN IPv6 sia trasportato verso tale hop successivo BGP tramite un tunnel IPv6 («speaker BGP che richiede il trasporto IPv6»), o tramite un tunnel IPv4 («speaker BGP che richiede il trasporto IPv4»)?

La definizione di questa politica (richiedere il trasporto tramite tunnel IPv4 o IPv6) ricade sotto la responsabilità dell'operatore di rete ed è al di fuori dell'ambito di questo documento. Si noti che tale politica può richiedere il trasporto tramite tunnel IPv4 (rispettivamente IPv6) mentre lo speaker BGP scambia le informazioni di raggiungibilità IPv6 VPN tramite IPv6 (rispettivamente IPv4). In tal caso, tuttavia, vi sono alcuni aspetti operativi che meritano considerazione. In particolare, un guasto non rilevato che interessa il percorso dati del tunnel IPv4 (rispettivamente IPv6) senza interessare il percorso dati IPv6 (rispettivamente IPv4) potrebbe non essere rilevato da BGP e così causare un black hole del traffico.

Il controllo di questa politica è al di fuori dell'ambito di questo documento e può essere realizzato sulla base di una configurazione utente.

3.2.1.1. Speaker BGP che richiede il trasporto IPv6

Quando il traffico VPN IPv6 deve essere trasportato verso lo speaker BGP tramite un tunnel IPv6 (ad esempio un LSP MPLS IPv6, un tunnel IPv6 protetto da IPsec), lo speaker BGP DOVREBBE annunciare un campo indirizzo di rete dell'hop successivo contenente un indirizzo VPN-IPv6:

• il cui RD di 8 byte è impostato a zero, e

• il cui indirizzo IPv6 di 16 byte è impostato sull'indirizzo IPv6 globale dello speaker BGP che effettua l'annuncio.

Può seguire un ulteriore indirizzo VPN-IPv6:

• il cui RD di 8 byte è impostato a zero, e

• il cui indirizzo IPv6 di 16 byte è impostato sull'indirizzo IPv6 link-local dello speaker BGP che effettua l'annuncio.

Nell'attributo MP_REACH_NLRI, il valore della lunghezza del campo indirizzo di rete dell'hop successivo DOVREBBE essere impostato a 24 (quando è presente solo l'indirizzo globale), oppure a 48 (quando l'indirizzo link-local è incluso anche nel campo dell'hop successivo).

Se lo speaker BGP utilizza solo il proprio indirizzo IPv6 link-local (ad esempio quando il CE IPv6 stabilisce un peering con il PE IPv6 e il CE non dispone di alcun indirizzo IPv6 globale, e il peering eBGP è realizzato tramite l'indirizzo link-local), lo speaker BGP che effettua l'annuncio utilizza l'«indirizzo non specificato» ([V6ADDR]) per rappresentare l'assenza dell'indirizzo IPv6 globale nel campo indirizzo di rete dell'hop successivo.

Il campo dell'hop successivo include un indirizzo link-local solo se lo speaker BGP che effettua l'annuncio e il peer della route annunciata condividono una subnet comune [BGP-IPv6].

In tutti gli altri casi, lo speaker BGP annuncia al proprio peer, nel proprio campo indirizzo di rete dell'hop successivo, solo l'indirizzo IPv6 globale dell'hop successivo.

Pertanto, uno speaker BGP che annuncia una route a un peer interno PUÒ modificare il campo indirizzo di rete dell'hop successivo rimuovendo l'indirizzo IPv6 link-local dell'hop successivo.

Uno scenario esemplificativo che richiede l'inclusione sia dell'indirizzo IPv6 globale che dell'indirizzo IPv6 link-local nel campo indirizzo dell'hop successivo BGP è quando il servizio VPN IPv6 è realizzato su un backbone multi-sistema autonomo (AS) e le route VPN-IPv6 etichettate vengono ridistribuite tra gli ASBR (Autonomous System Boundary Router) di AS diversi (che condividono una subnet IPv6 comune); in tal caso, gli ASBR DOVREBBERO annunciare sia l'indirizzo IPv6 globale che l'indirizzo IPv6 link-local.

3.2.1.2. Speaker BGP che richiede il trasporto IPv4

Quando il traffico VPN IPv6 deve essere trasportato verso lo speaker BGP tramite un tunnel IPv4 (ad esempio un LSP MPLS IPv4, un tunnel IPv4 protetto da IPsec), lo speaker BGP DOVREBBE annunciare al proprio peer un campo indirizzo di rete dell'hop successivo contenente un indirizzo VPN-IPv6:

• il cui RD di 8 byte è impostato a zero, e

• il cui indirizzo IPv6 di 16 byte è codificato come un indirizzo IPv6 mappato in IPv4 [V6ADDR] contenente l'indirizzo IPv4 dello speaker BGP che effettua l'annuncio. Tale indirizzo IPv4 DEVE essere instradabile dagli altri speaker BGP.

3.3. Route Target

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

3.4. Negoziazione delle capacità BGP

Affinché due PE possano scambiare una NLRI VPN IPv6 etichettata, esse DEVONO utilizzare la negoziazione delle capacità BGP per assicurarsi che entrambe possano elaborare correttamente tale NLRI. La procedura è quella specificata in [BGP-MP] e [BGP-CAP], ovvero l'uso del codice di capacità 1 (BGP multiprotocollo) con i valori AFI e SAFI specificati nella sezione 3.2 precedente.