12.1 Requesting router behavior (Comportamento del router richiedente)

Il router richiedente utilizza un messaggio Request per popolare gli IA_PD con i prefissi. Il router richiedente include una o più opzioni IA_PD nel messaggio Request. Il router delegante restituisce quindi i prefissi per gli IA_PD al router richiedente in opzioni IA_PD in un messaggio Reply.

Il router richiedente include opzioni IA_PD in tutti i messaggi Renew o Rebind inviati dal router richiedente. L'opzione IA_PD include tutti i prefissi che il router richiedente attualmente ha associato a quell'IA_PD.

In alcune circostanze il router richiedente può aver bisogno di verificare che il router delegante abbia ancora un binding valido per il router richiedente. Esempi di momenti in cui un router richiedente può richiedere tale verifica includono:

• Il router richiedente si riavvia.

• Il collegamento upstream del router richiedente si interrompe.

• Il router richiedente viene fisicamente disconnesso da una connessione cablata.

Se tale verifica è necessaria il router richiedente DEVE avviare uno scambio di messaggi Rebind/Reply come descritto nella sezione 18.1.4, "Creation and Transmission of Rebind Messages" di RFC 3315, con l'eccezione che i parametri di ritrasmissione DOVREBBERO essere impostati come per il messaggio Confirm, descritto nella sezione 18.1.2, "Creation and Transmission of Confirm Messages" di RFC 3315. Il router richiedente include tutti gli IA_PD, insieme ai prefissi associati a quegli IA_PD nel suo messaggio Rebind.

Ogni prefisso ha durate valide e preferite le cui durate sono specificate nell'opzione IA_PD Prefix per quel prefisso. Il router richiedente utilizza i messaggi Renew e Rebind per richiedere l'estensione delle durate di un prefisso delegato.

Il router richiedente utilizza un messaggio Release per restituire un prefisso delegato a un router delegante. I prefissi da rilasciare DEVONO essere inclusi negli IA_PD.

I tipi di messaggio Confirm e Decline non vengono utilizzati con Prefix Delegation.

Alla ricezione di un messaggio Reply valido, per ciascun IA_PD il router richiedente assegna una sottorete da ciascuno dei prefissi delegati a ciascuno dei collegamenti a cui sono collegate le interfacce associate, con la seguente eccezione: il router richiedente NON DEVE assegnare alcun prefisso delegato o sottoreti dai prefissi delegati al collegamento attraverso il quale ha ricevuto il messaggio DHCP dal router delegante.

Quando un router richiedente suddivide in sottoreti un prefisso delegato, deve assegnare bit aggiuntivi al prefisso per generare prefissi unici e più lunghi. Ad esempio, se al router richiedente nella Figura 1 fosse delegato 3FFE:FFFF:0::/48, potrebbe generare 3FFE:FFFF:0:1::/64 e 3FFE:FFFF:0:2::/64 per l'assegnazione ai due collegamenti nella rete dell'abbonato. Se al router richiedente fossero delegati 3FFE:FFFF:0::/48 e 3FFE:FFFF:5::/48, potrebbe assegnare 3FFE:FFFF:0:1::/64 e 3FFE:FFFF:5:1::/64 a uno dei collegamenti, e 3FFE:FFFF:0:2::/64 e 3FFE:FFFF:5:2::/64 per l'assegnazione all'altro collegamento.

Se il router richiedente assegna un prefisso delegato a un collegamento a cui il router è collegato e inizia a inviare annunci di router per il prefisso sul collegamento, il router richiedente DEVE impostare la durata valida in quegli annunci in modo che non sia successiva alla durata valida specificata nell'opzione IA_PD Prefix. Un router richiedente PUÒ utilizzare la durata preferita specificata nell'opzione IA_PD Prefix.

La gestione delle opzioni Status Codes nei messaggi Reply ricevuti è descritta nella sezione 18.1.8, "Receipt of Reply Messages" di RFC 3315. Il codice di stato NoPrefixAvail viene gestito nello stesso modo del codice di stato NoAddrsAvail.