Qu'est-ce que le CGNAT ? Son fonctionnement comparé à l'IPv4 publique ?

Comment fonctionne le CGNAT ?

Le CGNAT effectue une traduction d’adresses réseau à l’intérieur du réseau du fournisseur de services.

Un réseau domestique typique utilise déjà le NAT :

Ordinateur portable / téléphone / TV
       ↓
Adresses IPv4 privées
192.168.x.x
       ↓
NAT du routeur domestique
       ↓
Adresse IPv4 publique
       ↓
Internet

Le routeur du client traduit le trafic provenant de plusieurs appareils privés vers l’adresse IPv4 publique attribuée à la connexion.

Avec le CGNAT, le fournisseur de services ajoute une couche supplémentaire de traduction :

Appareils du client
       ↓
Routeur domestique
       ↓
Adresse côté client
       ↓
CGNAT de l’ISP
       ↓
Pool IPv4 public partagé
       ↓
Internet

De nombreux déploiements comportent donc deux domaines de traduction : le NAT à l’intérieur du réseau du client et le CGNAT à l’intérieur du réseau du fournisseur.

L’IETF définit un Carrier-Grade NAT comme une fonction basée sur le NAT utilisée pour partager une même adresse IPv4 entre plusieurs abonnés, le CGN étant géré par le fournisseur de services plutôt que par les abonnés. Cette définition ainsi que les exigences opérationnelles courantes sont documentées dans RFC 6888: Common Requirements for Carrier-Grade NATs.

Le CGNAT partage les ports ainsi que les adresses

Le CGNAT ne distingue pas les abonnés uniquement à l’aide de l’adresse IP publique.

Les ports de la couche transport font également partie de la traduction.

Un exemple simplifié pourrait ressembler à ceci :

Abonné A
100.64.10.20:50001
       ↓
203.0.113.20:22001

Abonné B
100.64.20.30:51002
↓
203.0.113.20:22002

Abonné C
100.64.30.40:52003
↓
203.0.113.20:22003

Du point de vue d’un service externe, les trois abonnés peuvent sembler se connecter depuis :

203.0.113.20

La plateforme CGNAT maintient l’état des traductions afin que le trafic de retour puisse être associé au bon abonné et à la bonne connexion.

Ce partage des adresses et des ports permet à un pool IPv4 public relativement restreint de desservir un nombre beaucoup plus important d’utilisateurs.

Pourquoi les ISP utilisent-ils le CGNAT ?

Les ISP utilisent principalement le CGNAT pour réduire la quantité de capacité IPv4 publique requise par abonné.

Prenons l’exemple d’un fournisseur d’accès desservant des centaines de milliers de clients résidentiels. Attribuer à chaque connexion sa propre adresse IPv4 publique consomme un pool d’adresses proportionnellement important.

Le CGNAT fait passer le modèle d’allocation de :

1 abonné
=
1 IPv4 publique

à quelque chose de plus proche de :

plusieurs abonnés
=
capacité IPv4 publique partagée

Cela rend le CGNAT utile pour les réseaux haut débit, mobiles, sans fil et autres grands réseaux d’accès où la majorité du trafic des clients est sortante.

LARUS présente le CGNAT aux côtés d’autres approches de gestion des adresses dans son guide sur la manière dont les ISP gèrent les pénuries d’IPv4.

La distinction importante est simple :

Le CGNAT ne crée pas de nouvelles adresses IPv4. Il permet de partager plus intensivement la capacité IPv4 publique existante.

Qu’est-ce que la plage CGNAT 100.64.0.0/10 ?

Le préfixe IPv4 100.64.0.0/10 est un espace d’adressage partagé réservé aux réseaux des fournisseurs de services, notamment aux déploiements CGN.

La plage s’étend de :

100.64.0.0
à
100.127.255.255

L’IETF a réservé cet espace dans RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space. Le document distingue l’espace d’adressage partagé de l’espace d’adresses privées RFC 1918, car il est spécifiquement destiné à être utilisé au sein des réseaux des fournisseurs de services.

Il est donc différent des plages privées bien connues telles que :

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

100.64.0.0/10 n’est pas non plus un espace IPv4 public ordinaire routable à l’échelle mondiale.

Si le routeur d’un client reçoit une adresse WAN comprise entre 100.64.0.0 et 100.127.255.255, cela constitue un indice fort de la présence possible d’un CGNAT.

Ce n’est toutefois pas une méthode de détection universelle. Les architectures des fournisseurs diffèrent et tous les déploiements d’adresses partagées ne doivent pas nécessairement apparaître de la même manière côté client.

CGNAT vs NAT : quelle est la différence ?

La principale différence entre le NAT traditionnel côté client et le CGNAT réside dans l’endroit où la traduction a lieu et les utilisateurs qui partagent l’adresse publique.

Le NAT traditionnel permet généralement aux appareils d’un même réseau client de partager une adresse publique contrôlée au niveau du routeur du client.

Le CGNAT ajoute une traduction au niveau du fournisseur de services, permettant à plusieurs réseaux d’abonnés indépendants de partager la capacité IPv4 publique.

Pour le modèle de traduction sous-jacent, consultez le guide de LARUS sur Network Address Translation et le fonctionnement du NAT .

Le CGNAT n’est donc pas simplement un autre nom pour le NAT domestique. Il déplace le partage d’adresses à grande échelle dans le réseau du fournisseur.

Pourquoi le CGNAT rend-il l’attribution des abonnés plus difficile ?

Une adresse IPv4 publique partagée peut représenter simultanément de nombreux abonnés.

Cela signifie qu’une adresse IP publique seule peut ne pas permettre d’identifier quel abonné a généré une connexion particulière.

Supposons qu’un signalement d’abus ne contienne que :

IP publique : 203.0.113.20
Heure :       14:35 UTC

Si des centaines d’abonnés partageaient cette adresse à 14:35, l’adresse seule peut être insuffisante pour une attribution précise.

Des informations plus utiles pourraient inclure :

IP publique :   203.0.113.20
Port source :   22002
Horodatage :    14:35:27 UTC
Protocole :     TCP

Le fournisseur de services peut alors corréler ces informations avec les attributions d’abonnés ou les enregistrements de traduction CGN.

La RFC 6888 traite de la journalisation CGN et souligne les implications opérationnelles liées à l’enregistrement d’informations suffisantes pour identifier l’abonné associé à une session traduite.

Cela crée un compromis d’ingénierie important :

Le CGNAT peut réduire la consommation d’IPv4 publique tout en augmentant l’importance d’une correspondance précise des sessions, des horodatages, de l’infrastructure de journalisation et des procédures de traitement des abus.

Quelles sont les limites du CGNAT ?

Le CGNAT fonctionne correctement pour de nombreuses applications Internet ordinaires reposant sur des connexions sortantes.

Les limites deviennent plus visibles lorsqu’une charge de travail dépend de connexions entrantes non sollicitées, d’un comportement prévisible des ports ou d’une adresse source publique distincte.

La RFC 6269: Issues with IP Address Sharing de l’IETF décrit plusieurs conséquences du partage d’adresses à grande échelle, notamment les effets sur les connexions entrantes, les applications supposant des adresses source uniques, la surveillance, la sécurité, l’allocation des ports et les contrôles basés sur l’IP.

La connectivité entrante peut devenir plus difficile

Un client derrière un CGNAT ne contrôle généralement pas la traduction côté public du fournisseur.

Cela peut compliquer :

• Les applications auto-hébergées

• Les services d’accès à distance

• Les serveurs exploités par le client

• Les applications peer-to-peer

• Certaines configurations VPN

• Les caméras de sécurité

• Certains scénarios de jeu en ligne

Les applications et les fournisseurs peuvent prendre en charge des mécanismes de traversée ou des conceptions alternatives, mais une connexion CGNAT ne doit pas automatiquement être considérée comme équivalente à une IPv4 publique directement utilisable.

La capacité des ports devient un élément de la planification réseau

Une adresse IPv4 publique dispose d’un espace de ports de transport limité.

Lorsque de nombreux abonnés partagent la même adresse, la plateforme CGN doit répartir les ports et maintenir l’état des traductions entre eux.

Les opérateurs doivent donc prendre en compte davantage que :

Combien d’adresses IPv4 publiques sont disponibles ?

Ils doivent également considérer :

Combien de traductions simultanées et de ports utilisables peuvent être pris en charge avec le ratio de partage prévu ?

Un partage agressif peut économiser de la capacité d’adressage tout en créant une pression ailleurs dans l’architecture du service.

Les adresses partagées peuvent entraîner des effets de réputation croisés

Les services externes utilisent souvent l’adresse IP source comme l’un des signaux lors de l’application de :

• Contrôles contre les abus

• Détection de fraude

• Filtrage anti-spam

• Limites de débit

• Politiques de sécurité

• Évaluation de réputation

Avec le CGNAT, des abonnés sans lien entre eux peuvent partager ce même signal.

Si une adresse IPv4 publique partagée est bloquée ou acquiert une mauvaise réputation, des clients qui n’ont rien à voir avec le comportement ayant déclenché le problème peuvent également rencontrer des difficultés.

La RFC 6269 aborde ce type d’impact collatéral comme l’une des conséquences du partage d’adresses IP à grande échelle.

CGNAT vs IPv4 publique : qu’est-ce qui change réellement ?

La comparaison la plus utile n’est pas CGNAT contre absence de NAT.

Il faut plutôt déterminer si le service nécessite un accès IPv4 sortant partagé ou des capacités IPv4 publiques directes.

Les deux architectures répondent à des problèmes différents.

Le CGNAT optimise l’utilisation des adresses. L’IPv4 publique donne à un réseau ou à un client une relation plus directe avec l’adresse visible sur Internet.

Les deux architectures répondent à des problèmes différents.

Le CGNAT optimise l’utilisation des adresses. L’IPv4 publique donne à un réseau ou à un client une relation plus directe avec l’adresse visible sur Internet.

Quand le CGNAT est-il adapté ?

Le CGNAT convient bien aux services dans lesquels les abonnés initient principalement des connexions sortantes et n’ont pas besoin de contrôler une adresse IPv4 exposée publiquement.

Les exemples typiques comprennent :

• Haut débit résidentiel

• Accès Internet mobile

• Grands réseaux grand public

• Wi-Fi public

• Connectivité IoT orientée vers les connexions sortantes

• Services Internet d’entrée de gamme

Pour ces clients, consacrer une adresse IPv4 publique à chaque abonné peut apporter peu de valeur opérationnelle supplémentaire par rapport à la quantité de capacité d’adressage consommée.

Le CGNAT permet à l’opérateur d’utiliser l’IPv4 publique de manière plus sélective.

Quand l’IPv4 publique est-elle mieux adaptée ?

L’IPv4 publique devient plus importante lorsqu’une charge de travail dépend de capacités réseau limitées par le partage d’adresses à grande échelle.

Les exemples comprennent :

• Hébergement d’applications publiques

• Passerelles VPN d’entreprise

• Listes blanches de pare-feu d’entreprise

• Infrastructure d’accès à distance

• Services entrants contrôlés par le client

• Équipements réseau nécessitant un adressage public prévisible

• Services sensibles à la réputation d’une IP partagée

• Connectivité d’entreprise nécessitant une adresse de sortie publique stable

Un fournisseur de services n’a pas besoin de choisir un seul modèle pour tous ses clients.

Une conception segmentée peut ressembler à ceci :

Résidentiel / haut débit de base
       ↓
CGNAT

Connectivité d’entreprise
↓
Option IPv4 publique

Hébergement / infrastructure
↓
Capacité IPv4 publique routée

Le CGNAT peut ainsi préserver la capacité d’adressage lorsque le partage correspond à la charge de travail, tandis qu’une IPv4 publique dédiée ou routée reste disponible pour les services qui en ont besoin.

Le CGNAT n’élimine pas la demande d’IPv4 publique

Une architecture CGNAT nécessite toujours de l’IPv4 publique du côté exposé à Internet.

Les opérateurs peuvent également avoir besoin d’une capacité d’adressage distincte pour les abonnés professionnels, les clients d’hébergement, les services publics, les produits d’infrastructure ou les clients qui nécessitent des exceptions au modèle d’adresses partagées.

À mesure que le réseau se développe, la planification de capacité devient donc une combinaison de :

Trafic adapté à l’IPv4 partagée
+
Trafic nécessitant une IPv4 publique
+
Capacité réservée à la croissance

C’est pourquoi le partage d’adresses n’est qu’une partie du problème plus large de rareté de l’IPv4 et de planification de capacité.

Si les produits IP pour entreprises, la demande d’hébergement, les exceptions d’adresses publiques, la croissance du nombre d’abonnés ou la pression sur les ports CGN augmentent, la question va au-delà de la simple configuration du NAT. Elle devient une décision de capacité IPv4 publique.

Vérifiez la disponibilité IPv4 et Continuity Assurance de LARUS afin d’évaluer une capacité IPv4 supplémentaire pour la production parallèlement à une architecture CGNAT existante.

LARUS fournit actuellement des services de location IPv4 de première partie à partir de son propre pool d’adresses et propose des contrôles de continuité couvrant notamment la validité du routage, le rDNS, la préparation RPKI/ROA, la réputation, le traitement des abus, la géolocalisation, les délais de réponse du support et le renouvellement.

Le coût opérationnel du partage d’adresses

Le CGNAT peut réduire la consommation d’IPv4 publique, mais il ajoute du travail opérationnel ailleurs.

Selon le réseau et les exigences, les opérateurs peuvent devoir gérer :

• Infrastructure de traduction

• Capacité des sessions

• Allocation des ports

• Correspondance des abonnés

• Synchronisation horaire

• Génération et stockage des journaux

• Enquêtes sur les abus

• Réputation des adresses partagées

• Exceptions pour les clients

• Niveaux de service avec IP publique dédiée

BTW.Media examine l’aspect journalisation de ce problème dans son analyse des obligations de journalisation CGNAT et des coûts liés à la rareté de l’IPv4, notamment l’infrastructure nécessaire aux enregistrements de traduction, à la précision temporelle, au stockage et à l’attribution des abonnés.

Pour les opérateurs, cela conduit à un choix de conception spécifique à la charge de travail : utiliser l’adressage partagé lorsqu’il répond aux besoins du client et conserver de la capacité IPv4 publique lorsque l’accessibilité directe, une adresse source distincte, l’isolation de la réputation ou un contrôle accru sont importants.

FAQ

100.64.0.0/10 est-elle une plage IP publique ?

Non. 100.64.0.0/10 est un espace d’adressage partagé réservé à l’utilisation par les fournisseurs de services. La RFC 6598 définit cette plage pour des scénarios comprenant le Carrier-Grade NAT et la distingue de l’espace IPv4 public ordinaire.

Comment savoir si je suis derrière un CGNAT ?

Comparez l’adresse IPv4 WAN affichée par votre routeur avec l’adresse IPv4 publique observée par un service Internet. Si elles sont différentes — et en particulier si le routeur possède une adresse comprise dans 100.64.0.0/10 — un CGNAT peut être présent. Les architectures des fournisseurs varient, votre ISP peut donc fournir une réponse définitive.

Le CGNAT empêche-t-il la redirection de ports ?

Le CGNAT rend généralement plus difficile la redirection entrante de ports contrôlée par le client, car celui-ci ne contrôle pas la couche de traduction externe du fournisseur. Certains fournisseurs ou certaines applications prennent en charge des mécanismes alternatifs ; le comportement exact dépend donc du déploiement. La RFC 6269 aborde les difficultés que le partage d’adresses crée pour les ports et connexions entrants.

Le CGNAT est-il mauvais pour les jeux, les VPN ou les applications peer-to-peer ?

Pas systématiquement. De nombreuses applications fonctionnent normalement, tandis que celles qui reposent sur des sessions entrantes, une connectivité directe entre pairs, un comportement NAT particulier ou des mappages de ports prévisibles peuvent rencontrer des limitations. Le résultat dépend de l’application et de l’implémentation CGN du fournisseur.

Le CGNAT résout-il l’épuisement d’IPv4 ?

Le CGNAT réduit le nombre d’adresses IPv4 publiques nécessaires par abonné en partageant les adresses, mais il ne crée pas de nouvel espace IPv4 public. Les fournisseurs ont toujours besoin d’IPv4 publique du côté du CGN exposé à Internet et pour les services nécessitant un adressage public direct.