6. AFTR Element (Elemento AFTR)
6. AFTR Element (Elemento AFTR)
6.1 Definition (Definizione)
Un elemento AFTR è la combinazione di un endpoint di tunnel IPv4-in-IPv6 e un NAT IPv4-IPv4 implementato sullo stesso nodo.
6.2 Encapsulation (Incapsulamento)
Il tunnel è un tunnel IPv4-in-IPv6 point-to-multipoint che termina agli elementi B4.
Vedere la sezione 7.1 per ulteriori considerazioni sul tunneling.
Nota: a questo punto, DS-Lite definisce solo tunnel IPv4-in-IPv6; tuttavia, altri tipi di incapsulamento potrebbero essere definiti in futuro.
6.3 Fragmentation and Reassembly (Frammentazione e riassemblaggio)
Come già notato, frammentazione e riassemblaggio devono essere gestiti dagli endpoint del tunnel. Pertanto, l'AFTR DEVE eseguire frammentazione e riassemblaggio se la MTU del collegamento sottostante non può accomodare l'overhead dell'incapsulamento. La frammentazione DEVE avvenire dopo l'incapsulamento sul pacchetto IPv6. Il riassemblaggio DEVE avvenire prima del decapsulamento dell'intestazione IPv6. Una procedura dettagliata è stata specificata in [RFC2473] sezione 7.2.
La frammentazione al Tunnel Entry-Point (punto di ingresso del tunnel) è un'operazione leggera. In contrasto, il riassemblaggio al Tunnel Exit-Point (punto di uscita del tunnel) può essere costoso. Quando il Tunnel Exit-Point riceve il primo pacchetto frammentato, deve attendere l'arrivo del secondo pacchetto frammentato per poter riassemblare i due pacchetti IPv6 frammentati per il decapsulamento. Ciò richiede che il Tunnel Exit-Point metta in buffer e tenga traccia dei pacchetti frammentati. Considerare che l'AFTR è il Tunnel Exit-Point per molti tunnel. Se molti dispositivi originano simultaneamente un gran numero di pacchetti frammentati attraverso l'AFTR verso i suoi elementi B4 gestiti, ciò richiederà all'AFTR di mettere in buffer e consumare risorse enormi per tenere traccia dei flussi. Questo processo di riassemblaggio impatterà significativamente le prestazioni dell'AFTR. Tuttavia, questo impatto si verifica solo quando molti clienti originano simultaneamente grandi pacchetti IPv4. Poiché riteniamo che la maggior parte dei clienti riceverà grandi pacchetti IPv4 (come guardare stream video) invece di originarne (come originare stream video), il riassemblaggio è solo una frazione del carico di lavoro complessivo dell'AFTR.
Quando le risorse dell'AFTR scendono al di sotto di una soglia predefinita, l'AFTR DOVREBBE generare una notifica all'amministratore prima che le risorse siano completamente esaurite. La soglia e le procedure di notifica dipendono dall'implementazione e sono fuori dall'ambito del presente documento.
I metodi per evitare la frammentazione, come riscrivere l'opzione TCP Maximum Segment Size (MSS) o usare tecnologie come il Subnetwork Encapsulation and Adaptation Layer definito in [RFC5320], sono fuori dall'ambito del presente documento.
6.4 DNS
Come già notato, un nodo DS-Lite che implementa un elemento B4 eseguirà la risoluzione DNS su IPv6. Di conseguenza, non ci si attende che i pacchetti DNS passino attraverso l'elemento AFTR.
6.5 Well-Known IPv4 Address (Indirizzo IPv4 ben noto)
L'AFTR DOVREBBE usare l'indirizzo IPv4 ben noto 192.0.0.1 riservato dall'IANA per configurare il tunnel IPv4-in-IPv6. Tale indirizzo può quindi essere usato per segnalare problemi ICMP e apparirà negli output di traceroute.
6.6 Extended Binding Table (Tabella di binding estesa)
La tabella di binding NAT dell'elemento AFTR è estesa per includere l'indirizzo IPv6 sorgente dei pacchetti in ingresso. Tale indirizzo IPv6 è usato per disambiguare tra gli spazi di indirizzi IPv4 sovrapposti dei clienti del service provider.
Eseguendo una reverse lookup nella tabella di binding NAT IPv4 estesa, l'AFTR sa come ricostruire l'incapsulamento IPv6 quando i pacchetti tornano da Internet. In tal modo non è necessario mantenere una configurazione statica per ogni tunnel.