Passa al contenuto principale

2. Differences from OSPF for IPv4 (Differenze da OSPF per IPv4)

La maggior parte degli algoritmi di OSPF per IPv4 [OSPFV2] sono stati preservati in OSPF per IPv6. Tuttavia, alcuni cambiamenti sono stati necessari, sia a causa di modifiche nella semantica del protocollo tra IPv4 e IPv6, sia semplicemente per gestire la dimensione aumentata degli indirizzi IPv6.

Le seguenti sottosezioni descrivono le differenze tra questo documento e [OSPFV2].

IPv6 usa il termine "link" per indicare "una struttura di comunicazione o un mezzo attraverso il quale i nodi possono comunicare a livello di collegamento" ([IPV6]). Le "interfacce (Interfaces)" si connettono ai link. Più sottoreti IPv6 possono essere assegnate a un singolo link, e due nodi possono comunicare direttamente su un singolo link, anche se non condividono una sottorete IPv6 comune (prefisso IPv6 (IPv6 Prefix)).

Per questo motivo, OSPF per IPv6 funziona per-link invece del comportamento IPv4 per-sottorete-IP. I termini "rete (Network)" e "sottorete (Subnet)" utilizzati nella specifica OSPF IPv4 ([OSPFV2]) dovrebbero generalmente essere sostituiti da link. Allo stesso modo, un'interfaccia OSPF ora si connette a un link invece che a una sottorete IP.

Questo cambiamento influisce sulla ricezione dei pacchetti del protocollo OSPF, sul contenuto dei pacchetti Hello e sul contenuto dei Network-LSA.

2.2. Removal of Addressing Semantics (Rimozione della semantica di indirizzamento)​

In OSPF per IPv6, la semantica di indirizzamento è stata rimossa dai pacchetti del protocollo OSPF e dai principali tipi di LSA, lasciando un nucleo indipendente dal protocollo di rete. In particolare:

  • Gli indirizzi IPv6 non sono presenti nei pacchetti OSPF, eccetto nei payload LSA trasportati dai pacchetti di Link State Update (Link State Update Packets). Vedere la sezione 2.7 per i dettagli.

  • I Router-LSA e i Network-LSA non contengono più indirizzi di rete, ma esprimono semplicemente informazioni topologiche. Vedere la sezione 2.8 per i dettagli.

  • Gli ID router OSPF (Router IDs), gli ID area (Area IDs) e gli ID di stato di collegamento LSA (Link State IDs) rimangono alla dimensione IPv4 di 32 bit. Non possono più essere assegnati come indirizzi (IPv6).

  • I router vicini sono ora sempre identificati dall'ID router. Precedentemente, erano stati identificati da un indirizzo IPv4 sui link broadcast, NBMA (Non-Broadcast Multi-Access) e point-to-multipoint.

2.3. Addition of Flooding Scope (Aggiunta dell'ambito di flooding)​

L'ambito di flooding (Flooding Scope) per i LSA è stato generalizzato ed è ora esplicitamente codificato nel campo del tipo LS del LSA. Ci sono ora tre ambiti di flooding separati per i LSA:

  • Ambito link-local (Link-local Scope). Il LSA viene floodato solo sul link locale e non oltre. Utilizzato per il nuovo Link-LSA. Vedere la sezione 4.4.3.8 per i dettagli.

  • Ambito area (Area Scope). Il LSA viene floodato solo in una singola area OSPF. Utilizzato per Router-LSA, Network-LSA, Inter-Area-Prefix-LSA, Inter-Area-Router-LSA e Intra-Area-Prefix-LSA.

  • Ambito AS (AS Scope). Il LSA viene floodato in tutto il dominio di routing. Utilizzato per AS-External-LSA. Un router che origina LSA con ambito AS è considerato un AS Boundary Router (ASBR) e imposterà il suo bit E (E-bit) nei Router-LSA per le aree regolari.

OSPF ora supporta la capacità di eseguire più istanze del protocollo OSPF su un singolo link. Ad esempio, questo potrebbe essere necessario su un segmento NAP (Network Access Point) condiviso tra diversi provider. I provider potrebbero supportare domini di routing OSPF separati che desiderano rimanere separati anche se hanno uno o più segmenti di rete fisica (cioè, link) in comune. In OSPF per IPv4, questo era supportato in modo disordinato utilizzando i campi di autenticazione nell'header OSPF per IPv4.

Un altro uso per l'esecuzione di più istanze OSPF è se si desidera, per una ragione o per l'altra, che un singolo link appartenga a due o più aree OSPF.

Il supporto per più istanze di protocollo su un link è realizzato tramite un "ID istanza (Instance ID)" contenuto nell'header del pacchetto OSPF e nelle strutture dati dell'interfaccia OSPF. L'ID istanza influisce esclusivamente sulla ricezione dei pacchetti OSPF e si applica alle interfacce OSPF normali e ai link virtuali (Virtual Links).

Gli indirizzi link-local IPv6 (Link-Local Addresses) sono destinati all'uso su un singolo link, per scopi di scoperta dei vicini (Neighbor Discovery), auto-configurazione (Auto-Configuration), ecc. I router IPv6 non inoltrano datagrammi IPv6 con indirizzi sorgente link-local [IP6ADDR]. Gli indirizzi unicast link-local (Link-Local Unicast Addresses) sono assegnati dall'intervallo di indirizzi IPv6 FE80/10.

OSPF per IPv6 presume che a ciascun router siano stati assegnati indirizzi unicast link-local su ciascuno dei link fisici collegati del router [IP6ADDR]. Su tutte le interfacce OSPF tranne i link virtuali, i pacchetti OSPF vengono inviati utilizzando l'indirizzo unicast link-local associato all'interfaccia come indirizzo sorgente. Un router apprende gli indirizzi link-local di tutti gli altri router collegati ai suoi link e utilizza questi indirizzi come informazioni sul prossimo hop durante l'inoltro dei pacchetti.

Sui link virtuali, un indirizzo IPv6 con ambito globale (Global Scope) deve (MUST) essere utilizzato come indirizzo sorgente per i pacchetti del protocollo OSPF.

Gli indirizzi link-local appaiono nei Link-LSA OSPF (vedere la sezione 4.4.3.8). Tuttavia, gli indirizzi link-local non sono consentiti in altri tipi di LSA OSPF. In particolare, gli indirizzi link-local non devono (MUST NOT) essere pubblicizzati negli Inter-Area-Prefix-LSA (sezione 4.4.3.4), AS-External-LSA (sezione 4.4.3.6), NSSA-LSA (sezione 4.4.3.7) o Intra-Area-Prefix-LSA (sezione 4.4.3.9).

2.6. Authentication Changes (Modifiche all'autenticazione)​

In OSPF per IPv6, l'autenticazione è stata rimossa dal protocollo OSPF. I campi "AuType" e "Authentication" sono stati rimossi dall'header del pacchetto OSPF, e tutti i campi relativi all'autenticazione sono stati rimossi dalle strutture dati dell'area e dell'interfaccia OSPF.

Quando eseguito su IPv6, OSPF si basa sull'IP Authentication Header (vedere [IPAUTH]) e sull'IP Encapsulating Security Payload (vedere [IPESP]) come descritto in [OSPFV3-AUTH] per garantire l'integrità e l'autenticazione/confidenzialità degli scambi di routing.

La protezione degli scambi di pacchetti OSPF contro la corruzione accidentale dei dati è fornita dal checksum standard di livello superiore IPv6 (IPv6 Upper-Layer Checksum, come descritto nella sezione 8.1 di [IPV6]), che copre l'intero pacchetto OSPF e l'intestazione pseudo IPv6 preposta (IPv6 Pseudo-Header, vedere l'appendice A.3.1).

2.7. Packet Format Changes (Modifiche al formato dei pacchetti)​

OSPF per IPv6 viene eseguito direttamente su IPv6. A parte questo, tutta la semantica di indirizzamento è stata rimossa dagli header dei pacchetti OSPF, rendendolo essenzialmente "indipendente dal protocollo di rete (Network-Protocol-Independent)". Tutte le informazioni di indirizzamento sono ora contenute solo nei vari tipi di LSA.

In dettaglio, le modifiche al formato dei pacchetti OSPF consistono in quanto segue:

  • Il numero di versione OSPF è stato incrementato da 2 a 3.

  • Il campo Options nei pacchetti Hello e nei pacchetti di Database Description è stato esteso a 24 bit.

  • I campi Authentication e AuType sono stati rimossi dall'header del pacchetto OSPF (vedere la sezione 2.6).

  • Il pacchetto Hello ora non contiene affatto informazioni sull'indirizzo. Piuttosto, ora include un ID interfaccia (Interface ID) che il router di origine ha assegnato per identificare in modo univoco (tra le sue stesse interfacce) la sua interfaccia al link. Questo ID interfaccia sarà utilizzato come ID di stato di collegamento del Network-LSA se il router diventa il Designated Router sul link.

  • Due bit Options, il "bit R (R-bit)" e il "bit V6 (V6-bit)", sono stati aggiunti al campo Options per l'elaborazione dei Router-LSA durante il calcolo SPF (vedere l'appendice A.2). Se il "bit R" è azzerato, uno speaker OSPF può partecipare alla distribuzione della topologia OSPF senza essere utilizzato per inoltrare il traffico di transito; questo può essere utilizzato negli host multi-homed (Multi-Homed Hosts) che desiderano partecipare al protocollo di routing. Il bit V6 specializza il bit R; se il bit V6 è azzerato, uno speaker OSPF può partecipare alla distribuzione della topologia OSPF senza essere utilizzato per inoltrare datagrammi IPv6. Se il bit R è impostato e il bit V6 è azzerato, i datagrammi IPv6 non vengono inoltrati ma i datagrammi appartenenti a un'altra famiglia di protocolli possono essere inoltrati.

  • L'header del pacchetto OSPF ora include un "ID istanza (Instance ID)" che consente l'esecuzione di più istanze del protocollo OSPF su un singolo link (vedere la sezione 2.4).

2.8. LSA Format Changes (Modifiche al formato LSA)​

Tutta la semantica di indirizzamento è stata rimossa dall'header LSA, dai Router-LSA e dai Network-LSA. Questi due LSA ora descrivono la topologia del dominio di routing in modo indipendente dal protocollo di rete. Nuovi LSA sono stati aggiunti per distribuire informazioni sull'indirizzo IPv6 e dati richiesti per la risoluzione del prossimo hop. I nomi di alcuni LSA di IPv4 sono stati modificati per essere più coerenti tra loro.

In dettaglio, le modifiche al formato LSA consistono in quanto segue:

  • Il campo Options è stato rimosso dall'header LSA, esteso a 24 bit e spostato nel corpo dei Router-LSA, Network-LSA, Inter-Area-Router-LSA e Link-LSA. Vedere l'appendice A.2 per i dettagli.

  • Il campo del tipo LSA è stato esteso (nello spazio Options precedente) a 16 bit, con i tre bit superiori che codificano l'ambito di flooding e la gestione dei tipi LSA sconosciuti (vedere la sezione 2.9).

  • Gli indirizzi nei LSA sono ora espressi come [prefisso (Prefix), lunghezza prefisso (Prefix Length)] invece di [indirizzo (Address), maschera (Mask)] (vedere l'appendice A.4.1). La route predefinita è espressa come un prefisso con lunghezza 0.

  • I Router-LSA e i Network-LSA ora non hanno informazioni sull'indirizzo e sono indipendenti dal protocollo di rete.

  • Le informazioni sull'interfaccia del router possono (MAY) essere distribuite su più Router-LSA. I ricevitori devono (MUST) concatenare tutti i Router-LSA originati da un determinato router durante l'esecuzione del calcolo SPF.

  • È stato introdotto un nuovo LSA chiamato Link-LSA. I Link-LSA hanno ambito di flooding link-local; non vengono mai floodati oltre il link con cui sono associati. I Link-LSA hanno tre scopi: 1) forniscono l'indirizzo link-local del router a tutti gli altri router collegati al link, 2) informano gli altri router collegati al link di un elenco di prefissi IPv6 da associare al link, e 3) consentono al router di pubblicizzare una raccolta di bit Options da associare al Network-LSA che sarà originato per il link. Vedere la sezione 4.4.3.8 per i dettagli.

  • In IPv4, il Router-LSA trasporta gli indirizzi dell'interfaccia IPv4 di un router, l'equivalente IPv4 degli indirizzi link-local. Questi vengono utilizzati solo quando si calcolano i prossimi hop durante il calcolo del routing OSPF (vedere la sezione 16.1.1 di [OSPFV2]), quindi non devono essere floodati oltre il link locale. Quindi, l'utilizzo di Link-LSA per distribuire questi indirizzi è più efficiente. Si noti che gli indirizzi link-local non possono essere appresi attraverso la ricezione di Hello in tutti i casi. Sui link NBMA, i router di prossimo hop non scambiano necessariamente Hello. Piuttosto, questi router vengono a conoscenza dell'esistenza reciproca tramite il Designated Router (DR).

  • Il campo Options nel Network-LSA è impostato sul OR logico (Logical OR) delle Options che ciascun router sul link pubblicizza nel suo Link-LSA.

  • I Summary-LSA di tipo 3 sono stati rinominati "Inter-Area-Prefix-LSA". I Summary-LSA di tipo 4 sono stati rinominati "Inter-Area-Router-LSA".

  • L'ID di stato di collegamento negli Inter-Area-Prefix-LSA, Inter-Area-Router-LSA, NSSA-LSA e AS-External-LSA ha perso la sua semantica di indirizzamento e ora serve esclusivamente a identificare singoli pezzi del database di stato di collegamento. Tutti gli indirizzi o gli ID router che erano precedentemente espressi dall'ID di stato di collegamento sono ora trasportati nei corpi LSA.

  • I Network-LSA e i Link-LSA sono gli unici LSA il cui ID di stato di collegamento porta un significato aggiuntivo. Per questi LSA, l'ID di stato di collegamento è sempre l'ID interfaccia del router di origine sul link descritto. Per questo motivo, i Network-LSA e i Link-LSA sono ora gli unici LSA la cui dimensione non può essere limitata: un Network-LSA deve (MUST) elencare tutti i router connessi al link e un Link-LSA deve (MUST) elencare tutti gli indirizzi di un router sul link.

  • È stato introdotto un nuovo LSA chiamato Intra-Area-Prefix-LSA. Questo LSA trasporta tutte le informazioni sul prefisso IPv6 che in IPv4 sono incluse nei Router-LSA e nei Network-LSA. Vedere la sezione 4.4.3.9 per i dettagli.

  • L'inclusione di un indirizzo di inoltro (Forwarding Address) o di un tag di route esterno (External Route Tag) negli AS-External-LSA è ora opzionale. Inoltre, gli AS-External-LSA possono ora fare riferimento a un altro LSA, per l'inclusione di attributi di route aggiuntivi che sono al di fuori dell'ambito del protocollo OSPF. Ad esempio, questo riferimento potrebbe essere utilizzato per collegare attributi di percorso BGP alle route esterne.

2.9. Handling Unknown LSA Types (Gestione dei tipi LSA sconosciuti)​

La gestione dei tipi LSA sconosciuti è stata resa più flessibile in modo che, in base al tipo LS, i tipi LSA sconosciuti siano trattati come aventi ambito di flooding link-local oppure siano memorizzati e floodati come se fossero compresi. Questo comportamento è esplicitamente codificato nel bit di gestione LSA (LSA Handling Bit) del campo del tipo LS dell'header di stato di collegamento (vedere il bit U nell'appendice A.4.2.1).

Il comportamento OSPF IPv4 di scartare semplicemente i tipi sconosciuti non è supportato a causa del desiderio di mescolare le capacità del router su un singolo link. Scartare i tipi sconosciuti causa problemi quando il Designated Router supporta meno opzioni rispetto agli altri router sul link.

2.10. Stub/NSSA Area Support (Supporto dell'area Stub/NSSA)​

In OSPF per IPv4, le aree stub e NSSA sono state progettate per minimizzare le dimensioni del database di stato di collegamento e della tabella di routing per i router interni delle aree. Questo consente ai router con risorse minime di partecipare anche a domini di routing OSPF molto grandi.

In OSPF per IPv6, il concetto di aree stub e NSSA è mantenuto. In IPv6, dei tipi LSA obbligatori, le aree stub trasportano solo Router-LSA, Network-LSA, Inter-Area-Prefix-LSA, Link-LSA e Intra-Area-Prefix-LSA. Le aree NSSA sono limitate a questi tipi e, naturalmente, NSSA-LSA. Questo è l'equivalente IPv6 dei tipi LSA trasportati nelle aree stub IPv4: Router-LSA, Network-LSA, Summary-LSA di tipo 3 e per le aree NSSA: tipi di area stub e NSSA-LSA.

2.11. Identifying Neighbors by Router ID (Identificazione dei vicini tramite ID router)​

In OSPF per IPv6, i router vicini su un determinato link sono sempre identificati dal loro ID router OSPF. Questo contrasta con il comportamento IPv4 in cui i vicini su reti point-to-point e link virtuali sono identificati dai loro ID router mentre i vicini su link broadcast, NBMA e point-to-multipoint sono identificati dai loro indirizzi dell'interfaccia IPv4.

Questo cambiamento influisce sulla ricezione dei pacchetti OSPF (vedere la sezione 8.2 di [OSPFV2]), sulla ricerca dei vicini (sezione 10 di [OSPFV2]) e sulla ricezione dei pacchetti Hello (sezione 10.5 di [OSPFV2]).

L'ID router 0.0.0.0 è riservato e non dovrebbe (SHOULD NOT) essere utilizzato.

Ultimo aggiornamento il