Passa al contenuto principale

4.2. Protocol Packet Processing (Elaborazione dei pacchetti di protocollo)

OSPF per IPv6 viene eseguito direttamente sul livello di rete di IPv6. In quanto tale, è incapsulato in uno o più intestazioni IPv6 con il campo Next Header dell'intestazione IPv6 immediatamente incapsulante impostato sul valore 89.

Come per OSPF per IPv4, i pacchetti di protocollo di routing OSPF per IPv6 vengono inviati solo lungo le adiacenze (ad eccezione dei pacchetti Hello, che vengono utilizzati per scoprire le adiacenze). I tipi e le funzioni dei pacchetti OSPF sono gli stessi sia in IPv4 che in IPv6, codificati dal campo Type dell'intestazione del pacchetto OSPF standard.

4.2.1. Sending Protocol Packets (Invio di pacchetti di protocollo)

Quando un router IPv6 invia un pacchetto di protocollo di routing OSPF, riempie i campi dell'intestazione del pacchetto OSPF standard per IPv6 (vedere appendice A.3.1) come segue:

Version #

Impostato a 3, il numero di versione del protocollo come documentato in questa specifica.

Type

Il tipo di pacchetto OSPF, come Link State Update o pacchetto Hello.

Packet length (Lunghezza del pacchetto)

La lunghezza dell'intero pacchetto OSPF in byte, inclusa l'intestazione del pacchetto OSPF standard.

Router ID

L'identità del router stesso (chi sta originando il pacchetto).

Area ID

L'area OSPF per l'interfaccia su cui viene inviato il pacchetto.

Instance ID

L'ID di istanza OSPF associato all'interfaccia da cui viene inviato il pacchetto.

Checksum

Il checksum IPv6 Upper-Layer standard (come descritto nella sezione 8.1 di [IPV6]) che copre l'intero pacchetto OSPF e lo pseudo-header IPv6 anteposto (vedere appendice A.3.1).

La selezione degli indirizzi IPv6 di origine e destinazione dei pacchetti di protocollo di routing OSPF viene eseguita in modo identico alla logica IPv4 nella sezione 8.1 di [OSPFV2]. L'indirizzo di destinazione IPv6 viene scelto tra gli indirizzi AllSPFRouters, AllDRouters e l'indirizzo IP del vicino associato all'altra estremità dell'adiacenza (che in IPv6, per tutti i collegamenti tranne i collegamenti virtuali, è un indirizzo IPv6 link-local).

L'invio di pacchetti Link State Request e Link State Acknowledgment rimane invariato rispetto alle procedure IPv4 documentate nelle sezioni 10.9 e 13.5 di [OSPFV2] rispettivamente. L'invio di pacchetti Hello è documentato nella sezione 4.2.1.1, e l'invio di pacchetti Database Description nella sezione 4.2.1.2. L'invio di pacchetti Link State Update è documentato nella sezione 4.5.2.

4.2.1.1. Sending Hello Packets (Invio di pacchetti Hello)

IPv6 cambia il modo in cui vengono inviati i pacchetti OSPF Hello nei seguenti modi (confrontare con la sezione 9.5 di [OSPFV2]):

  • Prima che il pacchetto Hello venga inviato su un'interfaccia, l'ID di interfaccia dell'interfaccia deve essere copiato nel pacchetto Hello.

  • Il pacchetto Hello non contiene più una maschera di rete IP poiché OSPF per IPv6 viene eseguito per collegamento invece che per sottorete.

  • La scelta del router designato (Designated Router) e del router designato di backup (Backup Designated Router) è ora indicata negli Hello dai loro ID del router invece che dai loro indirizzi di interfaccia IP. Annunciare il router designato (o il router designato di backup) come 0.0.0.0 indica che il router designato (o il router designato di backup) non è ancora stato scelto.

  • Il campo Options nei pacchetti Hello si è spostato, diventando più grande nel processo. Sono ora possibili più bit Options. Quelli che devono essere impostati correttamente nei pacchetti Hello sono i seguenti. Il bit E è impostato se e solo se l'interfaccia si collega a un'area regolare, cioè non un'area stub o NSSA. Allo stesso modo, il bit N è impostato se e solo se l'interfaccia si collega a un'area NSSA (vedere [NSSA]). Infine, il bit DC è impostato se e solo se il router desidera sopprimere l'invio di futuri Hello sull'interfaccia (vedere [DEMAND]). I bit non riconosciuti nel campo Options del pacchetto Hello dovrebbero essere cancellati.

L'invio di pacchetti Hello su reti NBMA procede per IPv6 esattamente nello stesso modo di IPv4, come documentato nella sezione 9.5.1 di [OSPFV2].

4.2.1.2. Sending Database Description Packets (Invio di pacchetti di descrizione del database)

L'invio di pacchetti Database Description differisce dalla sezione 10.8 di [OSPFV2] nei seguenti modi:

  • Il campo Options nei pacchetti Database Description si è spostato, diventando più grande nel processo. Sono ora possibili più bit Options. Quelli che devono essere impostati correttamente nei pacchetti Database Description sono i seguenti. Il bit DC è impostato se e solo se il router desidera sopprimere l'invio di Hello sull'interfaccia (vedere [DEMAND]). I bit non riconosciuti nel campo Options del pacchetto Database Description dovrebbero essere cancellati.

4.2.2. Receiving Protocol Packets (Ricezione di pacchetti di protocollo)

Ogni volta che un router riceve un pacchetto di protocollo OSPF, viene contrassegnato con l'interfaccia su cui è stato ricevuto. Per i router che hanno collegamenti virtuali configurati, potrebbe non essere immediatamente ovvio con quale interfaccia associare il pacchetto. Ad esempio, si consideri il router RT11 raffigurato nella figura 6 di [OSPFV2]. Se RT11 riceve un pacchetto di protocollo OSPF sulla sua interfaccia verso la rete N8, potrebbe voler associare il pacchetto con l'interfaccia verso l'area 2 o con il collegamento virtuale verso il router RT10 (che fa parte del backbone). Nel seguito, assumiamo che il pacchetto sia inizialmente associato al collegamento non virtuale.

Affinché il pacchetto venga passato a OSPF per l'elaborazione, devono essere eseguiti i seguenti test sulle intestazioni IPv6 incapsulanti:

  • L'indirizzo di destinazione IP del pacchetto deve essere uno degli indirizzi unicast IPv6 associati all'interfaccia ricevente (questo include gli indirizzi link-local), uno degli indirizzi multicast IPv6 AllSPFRouters o AllDRouters, o un indirizzo IPv6 globale (per i collegamenti virtuali).

  • Il campo Next Header dell'intestazione IPv6 immediatamente incapsulante deve specificare il protocollo OSPF (89).

  • Eventuali intestazioni di autenticazione IP incapsulanti (vedere [IPAUTH]) e payload di sicurezza incapsulanti IP (vedere [IPESP]) devono essere elaborati e/o verificati per garantire l'integrità e l'autenticazione/riservatezza degli scambi di routing OSPF. Questo è descritto in [OSPFV3-AUTH].

Dopo aver elaborato le intestazioni IPv6 incapsulanti, viene elaborata l'intestazione del pacchetto OSPF. I campi specificati nell'intestazione devono corrispondere a quelli configurati per l'interfaccia OSPFv3 ricevente. Se non corrispondono, il pacchetto dovrebbe essere scartato:

  • Il campo del numero di versione deve specificare la versione del protocollo 3.

  • Il checksum IPv6 Upper-Layer (come descritto nella sezione 8.1 di [IPV6]), che copre l'intero pacchetto OSPF e lo pseudo-header IPv6 anteposto, deve essere verificato (vedere appendice A.3.1).

  • L'Area ID e l'Instance ID trovati nell'intestazione OSPF devono essere verificati. Se entrambi i seguenti casi falliscono, il pacchetto dovrebbe essere scartato. L'Area ID e l'Instance ID specificati nell'intestazione devono:

    1. Corrispondere a uno degli Area ID e Interface Instance ID per il collegamento ricevente. A differenza di IPv4, l'indirizzo sorgente IPv6 non è limitato a trovarsi nella stessa sottorete IPv6 del collegamento ricevente. IPv6 OSPF viene eseguito per collegamento invece che per sottorete IP.

    2. Corrispondere all'area backbone e ad altri criteri per un collegamento virtuale configurato. Il router ricevente deve essere un ABR (Area Border Router) e il Router ID specificato nel pacchetto (il router sorgente) deve essere l'altra estremità di un collegamento virtuale configurato. Inoltre, il collegamento ricevente deve avere un'interfaccia OSPFv3 che si collega all'area di transito configurata del collegamento virtuale e l'Instance ID deve corrispondere all'Instance ID del collegamento virtuale. Se tutti questi controlli hanno successo, il pacchetto viene accettato ed è associato al collegamento virtuale (e all'area backbone).

  • I pacchetti originati localmente non dovrebbero essere elaborati da OSPF tranne che per il supporto di più interfacce collegate allo stesso collegamento come descritto nella sezione 4.9. I pacchetti originati localmente hanno un indirizzo sorgente uguale a uno degli indirizzi locali del router.

  • I pacchetti la cui destinazione IPv6 è AllDRouters dovrebbero essere accettati solo se lo stato dell'interfaccia OSPFv3 ricevente è DR o Backup (vedere sezione 9.1 [OSPFV2]).

Dopo l'elaborazione dell'intestazione, il pacchetto viene ulteriormente elaborato in base al suo tipo di pacchetto OSPF. I tipi e le funzioni dei pacchetti OSPF sono gli stessi per IPv4 e IPv6.

Se il tipo di pacchetto è Hello, dovrebbe quindi essere ulteriormente elaborato dall'elaborazione del pacchetto Hello come descritto nella sezione 4.2.2.1. Tutti gli altri tipi di pacchetti vengono inviati/ricevuti solo sulle adiacenze. Questo significa che il pacchetto deve essere stato inviato da uno dei vicini attivi del router. Il vicino è identificato dal Router ID che appare nell'intestazione OSPF del pacchetto ricevuto. I pacchetti che non corrispondono a nessun vicino attivo vengono scartati.

L'elaborazione di ricezione dei pacchetti Database Description, Link State Request e Link State Acknowledgment è quasi identica alle procedure IPv4 documentate nelle sezioni 10.6, 10.7 e 13.7 di [OSPFV2] rispettivamente con le eccezioni indicate di seguito.

  • I LSA con tipi LS sconosciuti nei pacchetti Database Description che hanno un ambito di flooding accettabile vengono elaborati allo stesso modo dei LSA con tipi LS conosciuti. In OSPFv2 [OSPFV2], questi porterebbero all'interruzione dell'adiacenza con un evento SequenceMismatch.

La ricezione di pacchetti Hello è documentata nella sezione 4.2.2.1 e la ricezione di pacchetti Link State Update è documentata nella sezione 4.5.1.

4.2.2.1. Receiving Hello Packets (Ricezione di pacchetti Hello)

L'elaborazione di ricezione dei pacchetti Hello differisce dalla sezione 10.5 di [OSPFV2] nei seguenti modi:

  • Su tutti i tipi di collegamento (ad esempio, broadcast, NBMA, point-to-point, ecc.), i vicini sono identificati esclusivamente dal loro OSPF Router ID. Per tutti i tipi di collegamento tranne i collegamenti virtuali, l'indirizzo IP del vicino è impostato sull'indirizzo sorgente IPv6 nell'intestazione IPv6 del pacchetto OSPF Hello ricevuto.

  • Non c'è più un campo Network Mask nel pacchetto Hello.

  • La scelta del vicino per il router designato e il router designato di backup è ora codificata come un OSPF Router ID invece che come un indirizzo di interfaccia IP.