Passa al contenuto principale

9. Estensibilità - Elaborazione delle Opzioni (Extensibility - Option Processing)

Il protocollo Neighbor Discovery è progettato per essere estensibile attraverso l'aggiunta di nuove opzioni. Questa sezione descrive come i nodi elaborano le opzioni nei messaggi Neighbor Discovery ricevuti per garantire che le estensioni future possano coesistere con le implementazioni correnti.

9.1. Principi Generali (General Principles)​

Per garantire compatibilità retroattiva ed estensibilità futura:

  • Opzioni Non Riconosciute (Unrecognized Options): Tutti i nodi DEVONO (MUST) ignorare silenziosamente qualsiasi opzione che non riconoscono nei pacchetti Neighbor Discovery ricevuti e continuare l'elaborazione del pacchetto. Questo permette di definire nuove opzioni in futuro senza compromettere le implementazioni esistenti.

  • Opzioni Multiple (Multiple Options): Le opzioni possono apparire più volte nello stesso messaggio. I nodi DEVONO (MUST) essere preparati a gestire questo caso in modo appropriato.

  • Ordine delle Opzioni (Option Order): L'ordine in cui le opzioni appaiono in un messaggio generalmente non è significativo, a meno che non sia esplicitamente specificato per particolari tipi di opzioni.

  • Padding: Le opzioni dovrebbero essere riempite quando necessario per garantire che terminino sui loro limiti naturali a 64 bit.

9.2. Regole di Elaborazione (Processing Rules)​

Durante l'elaborazione di un messaggio Neighbor Discovery contenente opzioni:

  1. Analizzare Tutte le Opzioni (Parse All Options): Il nodo DEVE (MUST) analizzare tutte le opzioni nel messaggio, anche se alcune non sono riconosciute.

  2. Ignorare Opzioni Sconosciute (Ignore Unknown Options): Se un'opzione non è riconosciuta (in base al suo campo Type), il nodo DEVE (MUST) ignorarla e continuare l'elaborazione delle opzioni successive e del messaggio stesso.

  3. Validare Opzioni Conosciute (Validate Known Options): Per le opzioni riconosciute, il nodo DEVE (MUST) validare l'opzione secondo le regole specificate per quel tipo di opzione. Se un'opzione fallisce la validazione (ad esempio, lunghezza errata, valori di campo non validi), il comportamento dipende dal tipo specifico di opzione e di messaggio.

  4. Continuare l'Elaborazione (Continue Processing): Anche se una o più opzioni sono non valide o non riconosciute, il nodo DOVREBBE (SHOULD) continuare l'elaborazione del messaggio e di tutte le opzioni valide rimanenti, a meno che la specifica per un particolare tipo di messaggio o opzione non richieda diversamente.

9.3. Requisiti del Formato delle Opzioni (Option Format Requirements)​

Tutte le nuove opzioni definite per Neighbor Discovery DEVONO (MUST) seguire il formato generale delle opzioni specificato nella Sezione 4.6, con un campo Type e Length. Il campo Length è specificato in unità di 8 ottetti.

Quando si definiscono nuove opzioni, i progettisti di protocolli DOVREBBERO (SHOULD):

  • Assicurarsi che l'opzione possa essere ignorata in modo sicuro dai nodi che non la implementano, senza causare problemi operativi.
  • Considerare l'impatto sulla dimensione del messaggio e sul MTU del link.
  • Specificare regole di validazione chiare per l'opzione.

9.4. Estensioni Future (Future Extensions)​

Le future modifiche retrocompatibili al protocollo Neighbor Discovery possono:

  • Definire nuovi tipi di opzioni
  • Specificare l'uso dei campi attualmente Riservati nei formati dei messaggi
  • Definire nuovi bit di flag nei messaggi esistenti (con la comprensione che i flag non riconosciuti vengono ignorati)

Le modifiche non retrocompatibili richiederebbero la definizione di nuovi tipi di messaggi (usando valori ICMP Type o Code diversi) o la definizione di una nuova versione del protocollo.

9.5. Considerazioni sull'Implementazione (Implementation Considerations)​

Le implementazioni DOVREBBERO (SHOULD):

  • Essere progettate per accogliere facilmente nuovi tipi di opzioni senza richiedere modifiche sostanziali al codice.
  • Registrare o fornire informazioni diagnostiche sulle opzioni non riconosciute per facilitare il debug e il futuro deployment del protocollo.
  • Considerare le implicazioni di sicurezza durante l'elaborazione delle opzioni, in particolare quelle che potrebbero influenzare decisioni di routing o voci della cache.

9.6. Sicurezza ed Estensibilità (Security and Extensibility)​

Il meccanismo di estensibilità non fornisce intrinsecamente sicurezza. Le nuove opzioni possono introdurre nuove vulnerabilità di sicurezza se non progettate con attenzione. I progettisti di protocolli che definiscono nuove opzioni DOVREBBERO (SHOULD):

  • Considerare come l'opzione interagisce con Secure Neighbor Discovery (SEND) [RFC3971].
  • Analizzare potenziali attacchi che potrebbero sfruttare la nuova opzione.
  • Documentare considerazioni di sicurezza specifiche per la nuova opzione.

Le implementazioni DOVREBBERO (SHOULD) fornire meccanismi per abilitare o disabilitare selettivamente il supporto per tipi di opzioni specifici in base alla politica di sicurezza locale.

Ultimo aggiornamento il