Appendix B. Changes since RFC 3484 (Modifiche rispetto all'RFC 3484)

Sono state apportate alcune modifiche alla policy table predefinita che sono state ritenute universalmente utili e non causano danni in nessun ambiente di rete ragionevole. Nel farlo, è stata prestata attenzione per utilizzare gli stessi valori di preferenza ed etichetta dell'RFC 3484 quando possibile e per nuove righe per utilizzare valori di etichetta meno propensi a collidere con valori che potrebbero già essere in uso in righe aggiuntive su alcuni host. Queste modifiche sono:

1. Aggiunto il prefisso Teredo [RFC4380] (2001::/32), con i valori di preferenza ed etichetta già ampiamente utilizzati nelle implementazioni popolari.

2. Aggiunta una riga per gli ULA (fc00::/7) sotto l'IPv6 nativo poiché non sono raggiungibili globalmente, come discusso nella Sezione 10.6.

3. Aggiunta una riga per gli indirizzi site-local (fec0::/10) al fine di depreferenziarli, per coerenza con l'esempio nella Sezione 10.3, poiché sono deprecati [RFC3879].

4. Depreferenziato 6to4 (2002::/32) sotto l'IPv4 nativo poiché la connettività 6to4 è meno affidabile oggi (e si prevede che venga eliminata gradualmente nel tempo, piuttosto che diventare più affidabile). Rimane sopra Teredo poiché 6to4 è più efficiente in termini di tempo di stabilimento della connessione, larghezza di banda e carico del server.

5. Depreferenziati gli indirizzi IPv4-Compatible (::/96) poiché ora sono deprecati [RFC4291] e non sono di uso comune.

6. Aggiunta una riga per gli indirizzi di test 6bone (3ffe::/16) al fine di depreferenziarli poiché sono stati anche eliminati gradualmente [RFC3701].

7. Aggiunta la capacità opzionale per un'implementazione di aggiungere righe automatiche alla tabella per i prefissi ULA specifici del sito e i prefissi nativi 6to4 specifici del sito.

Similmente, sono state apportate alcune modifiche alle regole, come segue:

1. Modificata la definizione di CommonPrefixLen() per confrontare solo i bit fino alla lunghezza del prefisso dell'indirizzo sorgente. La definizione precedente utilizzava l'intero indirizzo sorgente, piuttosto che solo il suo prefisso. Di conseguenza, quando un indirizzo sorgente e un indirizzo di destinazione avevano lo stesso prefisso, i bit comuni nell'interface ID avrebbero precedentemente comportato l'override del bilanciamento del carico DNS [RFC1794] forzando la scelta dell'indirizzo di destinazione con il maggior numero di bit in comune. La definizione aggiornata consente al bilanciamento del carico DNS di continuare a essere utilizzato come tiebreaker.

2. Aggiunta la Rule 5.5 per consentire la scelta di un indirizzo sorgente da un prefisso pubblicizzato dal next-hop scelto per una determinata destinazione. Questo consente una migliore connettività in presenza di filtraggio in ingresso BCP 38 [RFC2827] e filtraggio in uscita. In precedenza, l'RFC 3484 aveva problemi con più reti in uscita raggiunte tramite la stessa interfaccia, come discusso in [RFC5220].

3. Rimossa la restrizione contro gli indirizzi anycast nell'insieme di candidati degli indirizzi sorgente, poiché la restrizione contro l'uso di indirizzi anycast IPv6 come indirizzi sorgente è stata rimossa nella Sezione 2.6 dell'RFC 4291 [RFC4291].

4. Modificata la mappatura degli indirizzi RFC 1918 [RFC1918] all'ambito globale nella Sezione 3.2. In precedenza, erano mappati all'ambito site-local. Tuttavia, l'esperienza ha portato le implementazioni attuali a utilizzare già l'ambito globale. Quando erano mappati a site-local, la Destination Address Selection Rule 2 (Prefer matching scope) avrebbe causato la preferenza di IPv6 in scenari come quello descritto nella Sezione 10.7. La modifica all'ambito globale consente la configurabilità tramite la policy table dei prefissi.

5. Modificata la raccomandazione predefinita per la Source Address Selection Rule 7 per preferire gli indirizzi temporanei piuttosto che gli indirizzi pubblici, fornendo al contempo un override amministrativo (oltre all'override specifico dell'applicazione che era già specificato). Questa modifica è stata apportata a causa della crescente importanza delle considerazioni sulla privacy, nonché del fatto che le implementazioni ampiamente distribuite hanno preferito gli indirizzi temporanei per molti anni senza problemi significativi nelle applicazioni.

Infine, sono state apportate alcune modifiche editoriali, tra cui:

1. Modificati gli indirizzi IP globali negli esempi per utilizzare intervalli riservati per la documentazione.

2. Aggiunti esempi aggiuntivi nelle Sezioni 10.6 e 10.7.

3. Aggiunta la Sezione 10.3.1 su IPv6 "non funzionante".

4. Aggiornati i riferimenti.