6. Élément AFTR
6. Élément AFTR
6.1. Définition
Un élément AFTR est la combinaison d'un point de terminaison de tunnel IPv4-in-IPv6 et d'un NAT IPv4-IPv4, implémentés sur le même nœud.
6.2. Encapsulation
Le tunnel est un tunnel IPv4-in-IPv6 point-vers-multipoint se terminant aux éléments B4.
Voir la section 7.1 pour des considérations supplémentaires sur le tunneling.
Note : à ce stade, DS-Lite ne définit que des tunnels IPv4-in-IPv6 ; d'autres types d'encapsulation pourront être définis à l'avenir.
6.3. Fragmentation et réassemblage
Comme indiqué précédemment, la fragmentation et le réassemblage doivent être pris en charge par les points de terminaison du tunnel. À ce titre, l'AFTR DOIT effectuer fragmentation et réassemblage si le MTU du lien sous-jacent ne peut pas accueillir la surcharge d'encapsulation. La fragmentation DOIT intervenir après l'encapsulation IPv6, et le réassemblage DOIT intervenir avant la décapsulation de l'en-tête IPv6. Une procédure détaillée est spécifiée à la section 7.2 de [RFC2473].
La fragmentation au point d'entrée du tunnel est une opération légère. À l'inverse, le réassemblage au point de sortie peut être coûteux. Lorsque le point de sortie reçoit le premier fragment, il doit attendre l'arrivée du second pour réassembler les deux paquets IPv6 fragmentés et procéder à la décapsulation. Cela impose au point de sortie de tampons et un suivi des paquets fragmentés. L'AFTR étant point de sortie pour de nombreux tunnels, si de nombreux périphériques émettent simultanément un grand nombre de paquets fragmentés à travers l'AFTR vers les B4 qu'il gère, l'AFTR devra mobiliser d'énormes ressources. Ce processus de réassemblage impactera significativement les performances de l'AFTR. Cependant, cet impact ne survient que lorsque de nombreux clients émettent simultanément de gros paquets IPv4. Comme on s'attend à ce que la majorité des clients reçoivent des gros paquets IPv4 (lecture de flux vidéo, par exemple) plutôt qu'à en émettre, le réassemblage ne représente qu'une fraction de la charge globale de l'AFTR.
Lorsque les ressources de l'AFTR descendent sous un seuil prédéfini, l'AFTR DEVRAIT générer une notification à l'administrateur avant l'épuisement complet. Le seuil et la procédure de notification dépendent de l'implémentation et sortent du périmètre de ce document.
Les méthodes pour éviter la fragmentation, comme la réécriture de l'option Maximum Segment Size (MSS) de TCP ou des technologies comme la Subnetwork Encapsulation and Adaptation Layer définie dans [RFC5320], sortent du périmètre de ce document.
6.4. DNS
Comme indiqué précédemment, un nœud DS-Lite implémentant un élément B4 effectuera la résolution DNS sur IPv6. Par conséquent, les paquets DNS ne sont pas censés transiter par l'élément AFTR.
6.5. Adresse IPv4 bien connue
L'AFTR DEVRAIT utiliser l'adresse IPv4 bien connue 192.0.0.1, réservée par l'IANA, pour configurer le tunnel IPv4-in-IPv6. Cette adresse pourra ensuite servir à signaler des problèmes ICMP et apparaîtra dans les sorties de traceroute.
6.6. Table de bindings étendue
La table de bindings NAT de l'AFTR est étendue pour inclure l'adresse IPv6 source des paquets entrants. Cette adresse permet de lever l'ambiguïté entre les espaces d'adresses IPv4 chevauchants des clients du fournisseur.
Par recherche inverse dans la table NAT IPv4 étendue, l'AFTR sait reconstruire l'encapsulation IPv6 lorsque les paquets reviennent de l'Internet. Aucune configuration statique n'est ainsi nécessaire pour chaque tunnel.