On 1 May 2013, at 22:15, <[email protected]> wrote: >> les CGN [...] sont d'ores et déjà une réalité douloureuse dans de nombreux >> pays d'Asie et peut-être demain sur d'autres continents > La contamination a déjà commencé: j'en ai croisé en prod avec pas mal de > clients en Allemagne chez 2 operateurs, et bientôt aux pays bas, suisse et > d'autres... >
Chacun voit les choses comme il veut, moi je vois plus une évolution logique pour étendre la durée de vie des v4 face a un déploiement encore trop faible des v6... Comme personne joue le jeu faut bien des palliatifs... > erik > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Stephane Bortzmeyer > Sent: mercredi 1 mai 2013 11:04 > To: [email protected] > Subject: [FRnOG] [TECH] RFC 6888: Common requirements for Carrier Grade NATs > (CGNs) > > http://www.bortzmeyer.org/6888.html > > ---------------------------- > > Auteur(s) du RFC: S. Perreault (Viagenie), I. Yamagata, S. Miyakawa (NTT > Communications), A. Nakagawa (Japan Internet Exchange (JPIX)), H. Ashida (IS > Consulting G.K.) > > > ---------------------------- > > > Qu'on les approuve (ce qui n'est pas mon cas) ou pas, les CGN, ces gros > routeurs NAT installés dans le réseau du FAI et gérant des centaines ou des > milliers de clients, sont d'ores et déjà une réalité douloureuse dans de > nombreux pays d'Asie et peut-être demain sur d'autres continents. Pour > limiter les dégâts qu'ils causent, ce RFC 6888 pose un certain nombre de > règles que *devraient* respecter ces CGN. > > D'abord, qu'est-ce qu'un CGN ? Fonctionnellement, il ressemble au petit > routeur NAT (RFC 2663) que vous avez chez vous. Comme lui, il fait du NAPT > ("Network Address and Port Translation"), c'est-à-dire qu'il traduit > dynamiquement des adresses IP du réseau interne vers celles utilisées à > l'extérieur (et vice-versa pour les paquets dans l'autre sens). La grosse > différence avec le petit routeur ou "box" chez vous est qu'il travaille pour > de nombreux clients du FAI. Au lieu que l'adresse IP externe soit partagée > uniquement entre les membres de votre cercle de famille, elle sera partagée > avec des centaines d'inconnus. > > Avec le CGN, il y a souvent « double NAT », une fois dans le CPE et une fois > dans le CGN. Mais ce n'est pas obligatoire. Lorsqu'il y a double NAT, on > parle souvent de NAT444 <http://www.bortzmeyer.org/nats.html> > (deux traductions, d'IPv4 en IPv4). > > Sur cette image, on voit > du double NAT. Un FAI gère un CGN. Les adresses IP publiques du FAI, allouées > par son RIR sont ici 198.51.100.0/25. Ce sont celles qui seront vues, par > exemple, par les sites Web où se connectent les clients du FAI. Le FAI n'a > pas assez d'adresses IP publiques pour son réseau interne et il utilise donc > le 10.0.0.0/8 du RFC 1918. Prenons maintenant le client 1 : son réseau local > a des adresses dans la plage 192.168.3.0/24. Les paquets seront donc émis > avec ces adresses, NATés une première fois par la machine CPE 2, vers > l'adresse 10.0.5.22. Ils seront ensuite NATés une seconde fois par le CGN. > > Le CGN a des conséquences, par exemple dans le domaine légal (vous pourrez > voir les agents de la HADOPI débarquer chez vous parce qu'un autre > utilisateur du même CGN a téléchargé illégalement, cf. RFC 6269). > Et cela limite sérieusement les activités que vous pourrez avoir sur > l'Internet. Par exemple, un moyen courant d'accepter les connexions > entrantes, normalement interdites par le NAPT, est de configurer sa "box" > pour rediriger tel numéro de port vers tel service sur le réseau local (par > exemple pour faire fonctionner des applications pair-à-pair > <http://www.bortzmeyer.org/emule-ports-linux.html>). Le routeur CGN étant > partagé entre de nombreuses personnes qui ne se connaissent pas, cela n'est > plus possible. Contrairement au routeur NAT à la maison, le CGN n'est *pas* > géré par les abonnés, qui ne peuvent pas modifier sa configuration. > > D'autre part, la simple taille du CGN en fait un engin compliqué et fragile, > et sa panne affecte bien plus de clients que le redémarrage d'une "box". > Enfin, ayant moins de ports sources à sa disposition par client, par rapport > au routeur de la maison ou du SOHO, il risque plus souvent de tomber à cours, > si les clients font beaucoup de connexions sortantes. > > Mais, alors, pourquoi met-on des CGN ? Juste pour embêter les clients ? > En fait, les FAI n'ont pas forcément beaucoup le choix. La pénurie d'adresses > IPv4 <http://www.bortzmeyer.org/epuisement-adresses-ipv4.html>, bien que niée > par beaucoup de négationnistes, est réelle depuis de nombreuses années. Par > exemple, cela fait longtemps qu'on ne peut plus avoir une adresse IP par > machine à la maison. Mais, jusqu'à récemment, on pouvait encore avoir une > adresse IP publique par foyer. Désormais, l'espace d'adressage IPv4 > disponible se resserrant chaque jour, ce n'est même plus le cas. S'il n'y a > pas d'adresse IPv4 publique disponible pour chaque client, le CGN est la > seule solution pour pouvoir continuer à faire de l'IPv4 (passer à IPv6 ferait > moins de travail mais les acteurs du marché sont frileux). > > Cela, c'était la raison avouable pour mettre des CGN. Il y en a une moins > avouable, c'est que le CGN, grosse machine centrale et point de passage > obligatoire pour tous les abonnés, est bien en phase avec la mentalité des > opérateurs telco traditionnels. C'est ainsi que, dans l'Internet mobile où > les libertés sont bien plus limitées, et l'utilisateur bien plus restreint > dans ce qu'il a le droit de faire, tous les opérateurs 3G ont déployé cette > solution depuis longtemps, refusant de donner une adresse IPv4 publique à > chaque abonné, même avant l'épuisement complet des réserves. Comme le note > prudemment le RFC, « "there are driving forces other than the shortage of > IPv4 addresses" ». > > À noter qu'un RFC décrit le déploiement de CGN comme une des techniques > pouvant aider à la transition vers IPv6 : RFC 6264. Le CGN est un des > composants de la solution DS-Lite, décrite dans le RFC 6333 et ce composant > doit donc suivre les règles données plus loin. > > Maintenant qu'on a présenté les CGN, que contient ce RFC ? Il liste des > conseils qui, s'ils étaient appliqués, rendraient les CGN un peu moins > insupportables. Comme le note la section 1, la publication de ce RFC ne > signifie *pas* que l'IETF approuve ou même accepte les CGN, simplement que, > puisqu'ils existent, autant essayer de limiter leurs effets négatifs. Comme > un CGN est un routeur NAT, les précédents documents du groupe de travail > Behave <http://tools.ietf.org/wg/behave>, concernant tous les types de NAT, > s'appliquent aussi au CGN : RFC 4787, RFC 5382 et RFC 5508 notamment. > > Les section 3 à 5 représentent donc le cœur de ce RFC. Elles contiennent les > recommandations spécifiques pour les CGN. Chacune est nommée REQ-n où n est > un numéro d'ordre. Ainsi, REQ-1 dit que, pour chaque protocole de transport, > le CGN doit suivre les recommandations spécifiques à ce protocole (RFC 4787 > pour UDP, RFC 5382 pour TCP, RFC > 5508 pour ICMP, et RFC 5597 pour DCCP). Notons que les autres protocoles de > transport (comme SCTP) ont donc de sérieuses chances de ne pas fonctionner au > travers du CGN. > > Exigence suivante, REQ-2, qui dit que le comportement de l'"IP address > pooling" doit être "paired". Cela signifie quoi ? Qu'une machine donnée doit > toujours obtenir la même adresse IP externe (un CGN, contrairement au petit > routeur NAT de la maison, a en général plusieurs adresses IP externes à sa > disposition). Cela limite les risques de casser les applications. Le RFC > 4787, section 4.1, donne les détails sur ce concept de "paired". > > À propos du nombre d'adresses externes disponible pour le CGN : REQ-3 exige > que ces adresses puissent être en nombre quelconque et dans des plages > non-contigües (avec l'épuisement des adresses IPv4, il sera de plus en plus > dur de trouver des plages contigües). > > REQ-4 traite un problème spécifique aux CGN, que n'avaient pas les petits > routeurs NAT de la maison : il faut pouvoir limiter le nombre de ports > utilisables par un utilisateur donné. Dans le NAPT, il y a moins d'adresses > externes que d'adresses internes. On se sert donc des ports pour désambigüer. > Un seul utilisateur gourmand pourrait lancer plein de sessions et épuiser à > lui seul la plage de ports disponibles (cela peut même être volontaire, pour > faire un déni de service, cf. section 8). > C'est pour se protéger contre cette attaque que REQ-4 exige une limitation, > configurable, par client. Le RFC recommande aussi qu'on puisse limiter le > rythme de création de sessions par utilisateur. C'est nécessaire pour > protéger les autres utilisateurs, mais c'est un des gros inconvénients du > CGN, qui casse sérieusement la transparence du réseau et le principe de bout > en bout. Les routeurs NAT cassaient ces principes mais uniquement entre > membres d'un même foyer ou d'un même SOHO. Avec le CGN, on dépend de gens > dont on ne connait rien. > > Même chose avec REQ-5, consacrée à d'autres ressources partagées dans le CGN, > comme sa mémoire. Un CGN a des problèmes d'équité que n'ont pas les routeurs > NAT classiques, vue son utilisation entre personnes qui n'ont rien en commun > a priori. > > Parfois, les cibles que vise l'utilisateur sont situées dans le réseau du > FAI, et donc atteignables sans traduction d'adresse. Pour ce cas, > REQ-6 demande que le CGN puisse être configuré pour ne pas traduire si la > destination est dans une liste d'adresses configurées par l'administrateur > réseaux. > > Lorsqu'un routeur NAT accepte des paquets entrants du moment qu'il a, dans sa > table des traductions, une entrée pour ce couple {adresse,port} de > destination, indépendemment de l'adresse IP source d'émission, on dit qu'il > fait du "Endpoint-Independent Filtering" (RFC 4787, section > 5 ?). REQ-7 souhaite que ce soit le comportement du CGN, car il casse moins > d'applications (notamment jeux en ligne et pair-à-pair) que le > "Address-Dependent Filtering" (où les paquets sont refusés si l'adresse > source n'est pas celle dans l'entrée de la table). > > REQ-8 légifère sur la réutilisation d'un port externe lorsqu'il n'est plus > utilisé. Par défaut, il devrait rester réservé pendant deux minutes, le > "Maximum Segment Lifetime" de TCP (RFC 793, section 3.3), après lequel on est > sûr que le paquet ne traîne plus dans le réseau. > Cela permet d'éviter une collision entre une ancienne correspondance et une > nouvelle, qui utiliserait le même port externe et recevrait par erreur de > vieux paquets. Des exceptions sont prévues, notamment : > * Si le CGN met en œuvre la machine à états de TCP, il peut savoir quand une > connexion est terminée et réutiliser alors tout de suite le port, > * Si certains ports sont statiquement affectés, ils restent utilisables en > permanence. > > > REQ-9 est plus ambitieux car il exige quelque chose qui n'existe pas dans les > CGN actuels : un mécanisme permettant à l'utilisateur de changer les > affectations de port, et que ce mécanisme soit de préférence PCP ("Port > Control Protocol", RFC 6887). Aujourd'hui, sur les petits routeurs NAT de la > maison ou du SOHO, ce mécanisme d'affectation manuelle des correspondances > {adresse externe, port externe} -> {adresse interne, port interne} est > typiquement fait par l'interface Web d'administration du routeur, ou bien par > UPnP. La disparition d'un tel mécanisme dans les CGN actuels est un des plus > gros problèmes que posent les CGN. IL était donc nécessaire de le rétablir, > pour que toutes les applications puissent bien fonctionner. > Mais PCP est encore très récent et peu déployé. > > REQ-10 concerne plutôt les besoins de l'opérateur plus que ceux des simples > utilisateurs : il demande que les routeurs CGN soient gérables (MIB du RFC > 4008, etc). > > Une autre exigence, REQ-11 concerne le traitement des erreurs. Si un routeur > CGN ne peut pas créer une corrrespondance entre adresse+port externe > etinterne, il doit jeter le paquet et devrait renvoyer un message ICMP > "Destination unreachable" / code 1 ("Host unreachable"). > et déclencher une "trap" SNMP. Le « devrait --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
