Carrier-grade NAT
Pour les articles homonymes, voir CGN.
Le NAT de classe transporteur ou carrier-grade NAT (CGN), large scale NAT, ou NAT444 est un NAT à grande échelle utilisé par un fournisseur d'accès à Internet, dans le but de diminuer la quantité d'adresses IPv4 nécessaires aux clients, et ainsi faire face à l'épuisement des adresses IPv4.
Fonctionnement modifier
Il consiste à distribuer des adresses privées à la passerelle des nouveaux clients au lieu d'adresse publique et à traduire ces adresses en adresses publiques vers Internet. La succession du NAT chez le client et chez l'opérateur est parfois désignée sous le nom de « NAT444 »[1].
Le CGN utilise la traduction de port, de sorte qu'une seule adresse publique est utilisée par de nombreux clients simultanément. Un certain nombre de ports TCP et UDP sont réservés pour chacun des clients. Compte tenu du fait qu'il existe 65 535 numéros de ports possibles, et en supposant qu'une adresse publique est utilisée par 100 clients, chaque client dispose d'environ 650 numéros de port, c'est-à-dire autant de connexions simultanées possibles[2].
Pour permettre l'accès au trafic généré par le client, le forum UPnP développe une extension du protocole appelé Internet Gateway Device Protocol (en) (IGD) pour permettre l'ouverture de ports publics sur le CGN. L'IETF a créé un groupe de travail nommé Port Control Protocol (PCP) RFC 6887[3] dans le même but[4].
Bien qu'il réduise fortement le besoin d'adresse IPv4 publique, le CGN n'est pas un système de transition d'IPv4 vers IPv6 à proprement parler, mais il est utilisé en combinaison avec d'autres approches pour assurer la continuité de la connectivité avec l'Internet IPv4[5].
La RFC 6598[6] réserve le bloc d'adresses 100.64.0.0/10 pour l'utilisation à l'intérieur du réseau de l'opérateur.
Inconvénients du CGN modifier
Il est possible que certaines applications qui font usage de connexions initiées par des hôtes sur Internet, de tunnels ou de type p2p ne fonctionnent plus correctement avec ce système[7].
Il est possible que les plages d'adresses utilisées chez le client et chez le fournisseur d'accès se chevauchent, ce qui crée des problèmes additionnels décrits dans la RFC 5684[8].
D'autre part, les plages d'adresses privées réservées par la RFC 1918[9] ne sont pas illimitées : le réseau 10.0.0.0/8 peut numéroter de 10 à 16 millions de passerelles, en fonction de l'efficacité dans la distribution des adresses, ce qui peut s'avérer insuffisant pour certains opérateurs[10].
Il n'existe pas de consensus sur le nombre minimal de ports à attribuer à chaque client. Un nombre trop bas nuirait aux applications qui ouvrent de nombreuses connexions simultanées[11], comme Google Maps[12].
La géolocalisation des utilisateurs finaux grâce à leur adresse IP est également affectée[11].
Les applications qui n'utilisent pas TCP, UDP ou ICMP sont bloquées par ce mécanisme[11]. Ce sera notamment le cas des tunnels GRE (protocole 47) et 6in4 (protocole 41). Teredo est également concerné[13].
L'enregistrement des adresses IP ne permettrait plus d'identifier des utilisateurs individuels, les serveurs n'enregistrant généralement pas les numéros de ports utilisés par le client. Une alternative qui consisterait en l'enregistrement par le fournisseur d'accès à Internet de chaque flux représenterait une quantité considérable d'information à enregistrer et conserver. Ceci a des conséquences sur la capacité des services de police à identifier les auteurs de délits sur Internet[7],[11]. Cet usage est également critiqué par Europol, pour les mêmes raisons[14]. Ainsi, Europol recommande l'utilisation d'IPv6, le problème étant posé depuis 2014[15].
CGN pour la transition vers IPv6 modifier
Le CGN peut être utilisé pour une transition progressive vers IPv6 en encapsulant le trafic IPv6 dans un tunnel IPv4, dans un schéma similaire à 6rd[16].
CGN et DS-Lite modifier
À l'inverse, le CGN est utilisé dans la technique Dual-Stack Lite pour encapsuler le trafic IPv4 dans un tunnel IPv6 entre la passerelle du client (Customer-premises equipment (CPE)) et le CGN. Dans ce cas, il n'y a pas de succession de deux NAT, le CGN faisant office de NAT unique. Pour le trafic IPv4 encapsulé, le CGN identifie chaque client grâce à l'adresse IPv6 du CPE, le CPE n'a donc pas besoin d'adresse IPv4 (RFC 6333[17]).
Ceci suppose que le réseau de l'opérateur est capable de transporter nativement le trafic IPv6. Il requiert des CPE compatibles avec cette technique. Ceux-ci doivent être configurés avec l'adresse IPv6 du CGN (RFC 6333[18]).
Notes et références modifier
- Large Scale NAT Architectures, Jeff Doyle, .
- Distributed NAT for broadband deployments post IPv4 exhaustion, Internet Draft, A. Durand, .
- (en) Dan Wing, Stuart Cheshire, Mohamed Boucadair, Reinaldo Penno, Paul Selkirk, « Port Control Protocol (PCP) », Request for comments no 6887,
- (en) Christian Jacquenet, « Zero Addresses, One Solution, Two Problems », sur Internet Society, IETF Journal, (consulté le ).
- (en) T.Nishitani, I.Yamagata, S.Miyakawa, A.Nakagawa et H.Ashida, « Large Scale NAT(LSN) » [PDF], sur IETF, (consulté le ).
- (en) Request for comments no 6598
- Can Large Scale NAT Save IPv4?, Jeff Doyle, 4 octobre 2010
- (en) P. Srisuresh, B.Ford, « Unintended Consequences of NAT Deployments with Overlapping Address Space », Request for comments no 5684,
- (en) Request for comments no 1918
- Distributed NAT for broadband deployments post IPv4 exhaustion Internet Draft 2008
- RFC 6269 : Issues with IP Address Sharing, M. Ford et al, juin 2011
- IETF NAT tutorial, Dan Wing, IETF 78, mars 2010
- Assessing the Impact of NAT444 on Network Applications, Internet Draft, C. Donley et al, octobre 2010
- « Europol appelle à la fin des attributions communes d'adresses IPv4 par les FAI, qui peuvent parfois nuire au bon déroulement d'une enquête », sur Developpez.com (consulté le ).
- « Pénurie d'adresses IPv4 : les pratiques des opérateurs chagrinent Europol », sur ZDNet France (consulté le ).
- An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
- (en) A. Durand et al., « Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion », Request for comments no 6333,
- (en) Request for comments no 6333
