8. Considérations NAT

8.1. Pool NAT

L'AFTR PEUT être provisionné avec différents pools NAT. Les plages d'adresses des pools peuvent être disjointes mais NE DOIVENT PAS se chevaucher. Les opérateurs peuvent mettre en place des politiques sur l'AFTR pour répartir les clients entre différents pools. Par exemple, un AFTR peut avoir deux interfaces, chacune associée à un pool NAT disjoint. Une politique sur l'AFTR peut aussi spécifier qu'un ensemble de B4 utilisera le pool NAT 1 et un autre ensemble utilisera le pool NAT 2.

8.2. Conformité NAT

Un AFTR Dual-Stack Lite DOIT implémenter un comportement conforme aux meilleures pratiques actuelles, à savoir [RFC4787], [RFC5508] et [RFC5382]. Pour davantage de discussions sur les NAT « carrier-grade », voir [LSN-REQS].

8.3. Application Level Gateways (ALG)

L'AFTR effectue du NAT-44 et hérite des limitations du NAT. Certains protocoles requièrent des ALG dans le NAT pour être traversés (par exemple, FTP actif nécessite l'ALG correspondant). Les ALG consomment des ressources, et il en existe de très nombreux types. L'AFTR étant un équipement réseau partagé qui supporte un grand nombre d'éléments B4, il est impossible d'y implémenter tous les ALG actuels et futurs.

L'AFTR partage une seule IP entre plusieurs utilisateurs, ce qui améliore l'utilisation de l'espace IPv4. Cela soulève cependant certains problèmes, comme la journalisation et l'interception légale. Voir [RFC6269] pour plus de considérations sur le partage de l'espace de ports d'adresses IPv4.

8.5. Redirection de ports / Keep-alive

Le groupe de travail PCP standardise un plan de contrôle pour les NAT « carrier-grade » [LSN-REQS] à l'IETF. Le Port Control Protocol (PCP) permet aux applications de négocier directement avec le NAT pour ouvrir des ports et négocier des durées de vie afin d'éviter le trafic de keep-alive. Voir [PCP-BASE] pour plus d'informations sur PCP.