Re: [FRnOG] [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Damien Fleuriot]

On 1 May 2013, at 22:15,  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: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of 
> Stephane Bortzmeyer
> Sent: mercredi 1 mai 2013 11:04
> To: frnog-t...@frnog.org
> 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 
> (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 
> ). 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 , 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 p

RE: [FRnOG] [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[erik.linder]

> 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...

erik
-Original Message-
From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of 
Stephane Bortzmeyer
Sent: mercredi 1 mai 2013 11:04
To: frnog-t...@frnog.org
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 
(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 
). 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 , 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 e

Re: [FRnOG] [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Gunther Ozerito]

> 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).

Non, car la loi est heureusement assez bien faite, et il faut une
authentification jugée unique pour débarquer chez quelqu'un (c'est déjà le
cas sur les infras mobile depuis des années). Donc, soit le FAI fournit une
liste de 200 clients lorsque la gendarmerie se pointe avec une info du type
"qui avait cette @IP publique à telle heure ?", soit on sera obligé d'aller
plus loin dans le controle, avec des solutions de type DPI (ce qui n'est
pas sans poser des questions sur la tracabilité des users).

Par contre, la gestion des logs coté FAI va être joyeuse, et couter un
bras, voire une couille ou deux. Des solutions à la Splunk risquent d'avoir
le vent dans le dos (pour ceux qui veulent investir en bourse, hein). On
risque de voir pousser des DC complets juste pour stocker les logs, si on
suit à la lettre la loi en vigueur...

Du coup, cela aura un impact direct sur le prix de reviens d'un abonné,
donc probablement sur les prix des abonnements.

Evidemment, tout cela ne sera vrai qu'en IPv4, à moins qu'un taré ne
déploie du CGN en v6 (on est à l'abris de rien), donc ça pourrait aussi
avoir un impact positif sur le déploiement d'IPv6 coté FAI.


Le 1 mai 2013 11:04, Stephane Bortzmeyer  a écrit :

> 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 
> (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
> ). 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

[FRnOG] [TECH] Si vous voyez de l'UDP IPv6 sans somme de contrôle, ne vous inquiétez plus

[Stephane Bortzmeyer]

RFC 6935 : IPv6 and UDP Checksums for Tunneled Packets

http://www.bortzmeyer.org/6935.html



Auteur(s) du RFC: M. Eubanks (AmericaFree.TV LLC), P. Chimento (Johns Hopkins 
University Applied Physics Laboratory, M. Westerlund (Ericsson)



Ne dites plus qu'en IPv6, la somme de contrôle est toujours obligatoire 
dans les en-têtes des paquets UDP. Depuis ce RFC 6935, ce n'est plus 
vrai dans tous les cas. Lors de l'encapsulation de paquets dans un 
tunnel UDP, on a désormais le droit de ne pas mettre de somme de 
contrôle dans les paquets UDP, essentiellement pour des raisons de 
performance.

Le principal demandeur de cette modification était le protocole LISP 
(RFC 6830), qui dépend énormement de tunnels UDP. Même si le calcul de 
la somme de contrôle Internet est rapide (RFC 1071), comme ce calcul 
peut se faire des millions de fois par seconde pour un routeur très 
actif, on peut chercher à l'économiser. D'autant plus qu'il n'est pas 
forcément utile puisque, dans le cas d'un tunnel, le protocole qui 
circule dans le tunnel est déjà protégé par une somme de contrôle. À 
noter que d'autres protocoles que LISP (comme ceux utilisés pour le 
"multicast") peuvent bénéficier de cette nouvelle indulgence. Mais elle 
ne s'applique pas aveuglément à tout UDP (comme l'avaient proposé 
certains au début de la discussion), uniquement aux tunnels.

La norme actuelle sur IPv6, le RFC 2460, imposait (dans sa section 8.1) 
une somme de contrôle pour les paquets UDP (en IPv4, elle était 
facultative). En effet, IPv6 n'a pas de somme de contrôle dans la 
couche 3 (contrairement à son prédecesseur).

Ce RFC est un produit du groupe de travail IETF 6man 
, qui produit inlassablement 
d'innombrables RFC  pour combler tous les petits 
problèmes qui trainent encore dans IPv6 et sont révélés par son 
utilisation dans le vrai monde.

Notez bien que cette dispense de somme de contrôle n'est pas générale : 
elle concerne les cas où il y a un tunnel et où il utilise UDP. 
Pourquoi UDP, alors qu'il existe des protocoles de tunnel qui s'en 
dispensent ? Parce que l'Internet est hélas de plus en plus ossifié, et 
que des "middleboxes" stupides et boguées sont partout sur le trajet 
des pauvres paquets. Les techniques de tunnel directement sur IP (comme 
l'excellent GRE du RFC 2784) sont souvent bloquées, alors qu'UDP passe 
partout. On aura donc un protocole X (LISP ou un autre) à l'intérieur 
du tunnel et de l'UDP à l'extérieur. Hier, cet UDP à l'extérieur était 
forcément protégé par une somme de contrôle. Pour un routeur qui sert 
de terminaison à des dizaines de milliers de tunnels (ce qui n'aurait 
rien d'étonnant avec LISP), calculer et vérifier ces sommes peut être 
très douloureux. D'autant plus que le protocole X a souvent sa propre 
somme de contrôle : ne serait-ce pas mieux pour tout le monde que le 
tunnel soit non sécurisé, ses éventuelles corruptions de paquets étant 
détectées par le protocole X uniquement ?

La section 4 discute plus en détail de certains aspects du problème 
mais il vaut mieux consulter le RFC 6936 pour tout savoir. Cet autre 
RFC précise notamment dans quels cas supprimer la somme de contrôle est 
une bonne idée et dans quels cas il vaut mieux la garder. La section 4 
de notre RFC note particulièrement que les paquets de *contrôle* du 
tunnel, ceux qui servent à la signalisation, devraient rester protégés 
(s'ils sont corrompus, le tunnel peut cesser de fonctionner, 
c'est-à-dire que la corruption d'*un* paquet va affecter d'autres 
paquets). Notons que certains protocoles de tunnel comme GRE n'ont 
aucun mécanisme de contrôle. Lorsqu'il y en a un, il est souvent 
utilisé pour établir un contexte au début, avec choix des paramètres 
pour le tunnel : ce peut être le bon moment pour négocier le non-usage 
des sommes de contrôle sur les paquets de données.

Autre piège rigolo : certaines "middleboxes" vont tiquer en voyant les 
paquets UDP sans somme de contrôle (bien que, normalement, la somme de 
contrôle soit de bout en bout et ne regarde pas ces équipements 
intermédiaires). Bien que ce soit désormais légal, il va falloir 
attendre longtemps avant que tous ces engins soient mis à jour (section 
4.3). En attendant ce jour, il est prudent que le tunnel détecte les 
problèmes en envoyant des paquets avec et sans somme de contrôle au 
début : si seuls les premiers passent, c'est qu'on a une "middlebox" 
agressive sur le trajet et qu'il faut renoncer à appliquer ce RFC 6935. 
Le test est d'ailleurs à répéter de temps en temps : la route peut 
changer et on peut donc se retrouver soudain à traverser une nouvelle 
"middlebox".

La section 4.1 conseille également de tenter de détecter la corruption 
avant de décapsuler, par exemple en examinant l'adresse IP source, pour 
minimiser le risque d'envoyer au protocole encapsulé un paquet reçu 
corrompu. Mais cette détection ne marchera pas à tous les cas (sinon, 
on pourrait 

[FRnOG] [TECH] Extension de RADIUS

[Stephane Bortzmeyer]

RFC 6929 : Remote Authentication Dial In User Service (RADIUS) Protocol 
Extensions

http://www.bortzmeyer.org/6929.html



Auteur(s) du RFC: Alan DeKok (Network RADIUS), Avi Lior

Chemin des normes




RADIUS, un protocole utilisé pour l'authentification (et la 
configuration) d'accès à l'Internet, est ancien et marche toujours. 
Lorsque vous accédez à l'Internet depuis chez vous, sans vous en rendre 
compte, vous avez probablement indirectement utilisé RADIUS. Il marche 
toujours très bien mais, rançon du succès, il a été tellement étendu 
qu'un certain nombre de champs du message RADIUS sont désormais 
pleins : toutes les options possibles seront allouées très bientôt. Ce 
nouveau RFC décrit un mécanisme d'extension de RADIUS, permettant de 
continuer l'enregistrement de nouvelles options, au prix de quelques 
bricolages.

Il y a peu de gens qui manipulent RADIUS (RFC 2865) explicitement. Ce 
protocole se trouve en effet caché dans le réseau du FAI, entre la 
machine qui contrôle l'accès (le NAS) et un serveur RADIUS qui contient 
les données sur les utilisateurs. RADIUS permet de ne pas avoir à 
copier les informations d'authentification, ou les paramètres d'un 
utilisateur donné, directement dans tous les NAS, mais de les 
centraliser dans un petit nombre de serveurs RADIUS.

La requête, et surtout la réponse RADIUS peuvent contenir un certain 
nombre d'*attributs* (RFC 2865, section 5) comme « nom de 
l'utilisateur », « mot de passe », « adresse IP à attribuer », etc. Le 
champ « "Attribute" » est en TLV et le type (User-Name = 1, 
User-Password = 2, Framed-IP-Address = 8, etc) est encodé sur un seul 
octet. La liste (un registre IANA 
) est aujourd'hui bien remplie et devrait l'être complètement en 
2014 ou 2015. C'est le principal problème de RADIUS aujourd'hui 
(section 1 de notre RFC). Mais il y en a d'autres comme le fait que la 
longueur d'un attribut soit codé sur un octet seulement (donc 253 
octets maximum pour la valeur d'un attribut, puisqu'il faut retirer le 
type et la longueur).

Notre RFC fait donc les changements suivants :
* Définition du format "Extended Type" : certains types d'attributs ont 
désormais ce format, qui inclut un second champ Type d'un octet dans la 
partie Valeur de l'attribut. Le nouveau type sera donc indiqué par la 
combinaison du Type et du nouveau champ (donc, deux octets, et le type 
sera noté N.M où N et M sont les valeurs des deux octets). Ça fait un 
peu bricolage, mais cela permet l'interopérabilité entre les nouvelles 
implémentations et les anciennes. Ce format est utilisé par quatre 
nouveaux attributs (de 241 à 244) et permet donc environ 1000 types 
nouveaux. La taille maximale des attributs a donc diminué d'un octet 
mais le deuxième changement, ci-dessous, résoud cela.
* Définition du format "Long Extended Type" qui ajoute un octet (après 
le type) dans le champ Valeur, pour pouvoir ajouter des nouvelles 
fonctions au protocole. Deux attributs (245 et 246) utiliseront ce 
format, soit environ 500 possibilités.
* En utilisant ce format, définition d'un mécanisme permettant de dire 
que la valeur est stockée sur plusieurs attributs consécutifs. Cette 
« fragmentation » permettra d'utiliser des attributs de plus de 253 
octets. Elle est indiquée par un bit (nommé M pour "More", s'il est à 
Un, cela indique que d'autres attributs suivent) dans le nouvel octet 
réservé.
* Les types de données disponibles dans le champ Valeur étaient au 
nombre de cinq (les classiques, nombre entier, adresse IP, temps, texte 
et suite de bits). Notre RFC 6929 en ajoute deux, TLV (qui va donc 
permettre de structurer les données puisqu'un TLV pourra en contenir 
d'autres, et récursivement) et entier de 64 bits (certaines valeurs, 
par exemple le nombre d'octets transmis, dans les messages de 
comptabilité, ne tenaient plus toujours en 32 bits).
Voilà, c'est l'essentiel du RFC. Ceux qui étendent le protocole RADIUS 
vont sans doute migrer vers les nouveaux types, dès aujourd'hui, ou 
bien lorsque les anciens seront épuisés.

Des exemples d'encodage figurent en section 9. Par exemple, un attribut 
utilisant un type étendu (ici, 241.1) et ayant une valeur de type texte 
(la chaîne "bob") se représentera f1 06 01 62 6f 62 (f1, le type, 241, 
06 la longueur totale, 01 le sous-type du type étendu, 1 (à la place du 
premier octet de la valeur), 62 6f 62 la vraie valeur, la chaîne de 
caractères). Plus compliqué, un attribut 241.2 contenant un TLV dont le 
type est 1, la longueur 4 et la valeur 23 45, sera représenté f1 07 02 
01 04 23 45.

Avec les étendus longs ("Long Extended Type"), un attribut 245.1 
contenant le même "bob" sera f5 07 01 00 62 6f 62 (f5 est le type, la 
longueur est de sept octets, 01 est la suite du type, l'octet 
supplémentaire est à 0 (donc le bit M aussi : pas d'autres attributs à 
attendre) et la valeur est la chaîne "bob"

Re: [FRnOG] [TECH] Contact orange (Too many SMTP connections)

[Francois Petillon]

On 05/01/2013 02:10 AM, Eric ROLLAND wrote:

~# cat /etc/postfix/transport
wanadoo.com slow:
wanadoo.fr slow:
orange.com slow:
orange.fr slow:
free.fr slow:
yahoo.fr slow:
yahoo.com slow:
sfr.fr slow:


Certes mais il y a quoi dans le transport "slow" ?

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] L2L SFR, Le vortex spatio-temporel

[Jérémy Martin]

A priori, ça a été fait avec iperf entre deux machines linux.
Je ne fais que retranscrire les conclusions de mon collègue pour le 
coup, n'ayant pas fait ces tests moimême.


Cordialement,
Jérémy Martin

Le 01/05/2013 11:21, Jérémie Courrèges-Anglas a écrit :

Jérémy Martin  writes:


Bonjour à tous,

Salutations,

[...]


On a également un problème de débit. La MTU contractuelle est de 1500 octets.
Mais on arrive sans problème à faire passer des packets de 65 000 octets.Bien
sur,sur des packets standard à 1500 octets, on atteint pas 25 Mb/s. SFR fait
ses tests sans limite de MTU et nous indique donc que le 1 Gb/s est bien
présent de bout à bout à 65 000 octets.

Vous les faites comment, vos tests de MTU ? Parce que sans bit 'DF'
(Don't fragment), on peut monter assez haut…

[...]





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] L2L SFR, Le vortex spatio-temporel

[Jérémie Courrèges-Anglas]

Jérémy Martin  writes:

> Bonjour à tous,

Salutations,

[...]

> On a également un problème de débit. La MTU contractuelle est de 1500 octets.
> Mais on arrive sans problème à faire passer des packets de 65 000 octets.Bien
> sur,sur des packets standard à 1500 octets, on atteint pas 25 Mb/s. SFR fait
> ses tests sans limite de MTU et nous indique donc que le 1 Gb/s est bien
> présent de bout à bout à 65 000 octets.

Vous les faites comment, vos tests de MTU ? Parce que sans bit 'DF'
(Don't fragment), on peut monter assez haut…

[...]

-- 
Jérémie Courrèges-Anglas
Empreinte PGP : 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Stephane Bortzmeyer]

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  
(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 
). 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 
, 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 u

[FRnOG] [TECH] Tiens, qui a du PCP dans ses boxes ?

[Stephane Bortzmeyer]

Qui offre déjà ce protocole dans ses boxes / CPE ?

RFC 6887 : Port Control Protocol (PCP)

http://www.bortzmeyer.org/6887.html



Auteur(s) du RFC: D. Wing (Cisco), S. Cheshire (Apple), M. Boucadair (France 
Telecom), R. Penno (Cisco), P. Selkirk (ISC)

Chemin des normes




Aujourd'hui, l'utilisateur de l'Internet ne bénéficie que rarement 
d'une connexion neutre, d'un simple tuyau le connectant à toutes les 
autres machines de l'Internet. La plupart du temps, il est au contraire 
bloqué derrière des engins comme les routeurs NAT ou les pare-feux. Par 
défaut, ces engins bloquent les connexions entrantes, limitant 
l'utilisateur à un usage type Minitel. Dans ce cas, on a souvent besoin 
de dire à l'engin sur le trajet « laisse entrer des connexions vers tel 
port » (par exemple pour le pair à pair 
). Cela se fait 
aujourd'hui en général par une interface spécifique (par exemple une 
page Web d'administration du routeur NAT) ou par le protocole privé 
UPnP. Il y avait donc une demande pour un protocole standard, adapté 
aux mécanismes d'aujourd'hui comme les CGN : c'est ce nouveau 
protocole, PCP ("Port Control Protocol").

Voici un exemple de configuration manuelle comme on fait souvent 
aujourd'hui, via une interface Web, ici celle d'une Freebox : Image (, 
http://www.bortzmeyer.org/images/freebox-config-ports.jpg) Avec PCP, 
ces interfaces vont-elles disparaître complètement ?

Le principe est simple : un serveur PCP tourne sur l'engin bloquant 
(routeur NAT ou pare-feu) et autorise des clients PCP à lui parler et à 
demander des services comme l'ouverture d'un port entrant, ou comme une 
durée de vie plus longue pour les sessions en cours. Redonnant du 
contrôle à la machine de l'utilisateur, il rétablit un peu de 
neutralité dans le réseau. Avec PCP, on a un moyen propre de gérer un 
serveur (acceptant des connexions entrantes) derrière un routeur NAT et 
même derrière un CGN. Rappelez-vous qu'accepter des connexions 
entrantes n'est pas seulement utile si on a un serveur Web à la maison, 
c'est également une fonction demandée par les protocoles de voix sur IP 
comme SIP ou bien par le pair-à-pair.

Une fois que le client PCP a obtenu une réponse positive du serveur PCP 
(« OK, j'envoie les connexions entrantes sur le port 8080 à 172.19.1.1, 
port 80, comme tu me l'as demandé »), il peut alors prévenir le reste 
du monde. Cette information sur le rendez-vous n'est pas gérée par 
PCP : on se sert de fonctions spécifiques au protocole (SIP REGISTER 
auprès du mandataire, pour SIP, par exemple), ou bien du DNS 
(éventuellement avec mise à jour dynamique du RFC 2136 pour cela). Les 
enregistrements SRV du DNS (RFC 2782) sont la solution idéale, 
puisqu'ils permettent d'indiquer le numéro de port.

On notera que PCP diminue le besoin d'ALG dans les engins 
intermédiaires. Une nouvelle application n'aura pas besoin d'attendre 
que des ALG apparaissent, elle pourra contrôler les connexions dont 
elle a besoin elle-même, via PCP.

Même si on n'accepte pas de connexions entrantes, qu'on est un pur 
client, PCP peut être utile. Les routeurs NAT et les pare-feux coupent 
typiquement la session au bout de N minutes d'inactivité. Pour empêcher 
cela, les applications qui doivent rester connectées longtemps (SSH, 
par exemple), envoient régulièrement des paquets "keepalive". Avec PCP, 
ce n'est plus nécessaire, l'application peut dire au serveur PCP 
« augmente N, s'il te plait ».

PCP est conçu, au contraire d'UPnP, pour une large gamme de besoins : 
du NAT traditionnel (RFC 3022), au NAPT commun aujourd'hui dans les 
"boxes" (cf. RFC 3022, section 2.2), en passant par le CGN (RFC 6888) 
et des choses plus exotiques comme DS-Lite (RFC 6333 et RFC 6619), 
NAT64 (RFC 6146), et même NAT66/NPT (RFC 6296).

PCP est prévu pour fonctionner avec les protocoles de transport qui ont 
la notion de port (UDP, TCP, SCTP, DCCP, etc). Pour les autres (ICMP, 
RSVP, ESP...), PCP ne fournit que des services partiels.

Autre limitation : PCP suppose que la machine de M. Toutlemonde n'a 
qu'une seule connexion à l'Internet, passant par l'équipement qui 
héberge le serveur PCP. Le but est de garantir que l'équipement qui 
répond en PCP verra bien passer *tous* les paquets. Ce modèle convient 
à la maison ou à la petite entreprise actuelle, avec son réseau local 
connecté via une unique "box". Le dessin 1 en section 4 du RFC illustre 
ce modèle.

Les sections suivantes fournissent les détails du protocole. Celui-ci 
manipulant souvent des adresses IP, la représentation de celles-ci 
(section 5) va servir souvent : PCP utilise systématiquement un champ 
de taille fixe de 128 bits (même pour des adresses IPv4, qui sont alors 
représentées préfixées du :::0:0/96), car c'est plus simple.

Une description de haut niveau du protocole est en section 6. À 
première vue, PCP pourrait être traité comme un protocole 
requête/réponse (un

RE: [FRnOG] [TECH] L2L SFR, Le vortex spatio-temporel

[Bruno CAVROS / SKIWEBCENTER]

Tu t'es fait vendre des SDSL agrégées ? :)

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Jérémy Martin
Envoyé : mercredi 1 mai 2013 10:03
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] L2L SFR, Le vortex spatio-temporel

Bonjour à tous,

On est en train de mettre en prod un L2L entre notre DC à Valenciennes, 
et le DC CIV à Lille (sainghain en mélantois). En tout, il doit y avoir 
50 km environs.

Depuis la mise en prodde vendredi dernier, nous mesurons 22 ms de ping. 
Sur un autre L2L (completel, distance identique), nous mesurons 1.7 ms. 
Du coup, je me demande si on a pas une faille spatio-temporel sur le 
chemin qui nous ferais perdre 20 ms ?!

Réponse du service réseau d'SFR : 22 ms sont dans les limites 
contractuelles du produit. (sympa quand on fait du serveur de jeu !)

On a également un problème de débit. La MTU contractuelle est de 1500 
octets. Mais on arrive sans problème à faire passer des packets de 65 
000 octets.Bien sur,sur des packets standard à 1500 octets, on atteint 
pas 25 Mb/s. SFR fait ses tests sans limite de MTU et nous indique donc 
que le 1 Gb/s est bien présent de bout à bout à 65 000 octets.

Bref, j'ai l'impression de me fait enthuber par le chef de projet qui 
n'a pas le courage d'escalader les constatations au service concerné 
chez SFR. Du coup, si quelqu'un chez SFR a la possibilité de nous filer 
un coup de main, ça serais vraiment génial.

Commentaires et remarques pertinentes bienvenue :)


-- 
Cordialement,
Jérémy Martin
Directeur Technique FirstHeberg.com

Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30)
Standard : 09 72 125 539 (tarif local)
Ligne directe : 03 66 72 03 42
Mail : j.martin AT freeheberg.com
Web : http://www.firstheberg.com


__
FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle !
PHP + Mysql + Espace 2 à 20 Go


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] L2L SFR, Le vortex spatio-temporel

[Jérémy Martin]

Bonjour à tous,

On est en train de mettre en prod un L2L entre notre DC à Valenciennes, 
et le DC CIV à Lille (sainghain en mélantois). En tout, il doit y avoir 
50 km environs.


Depuis la mise en prodde vendredi dernier, nous mesurons 22 ms de ping. 
Sur un autre L2L (completel, distance identique), nous mesurons 1.7 ms. 
Du coup, je me demande si on a pas une faille spatio-temporel sur le 
chemin qui nous ferais perdre 20 ms ?!


Réponse du service réseau d'SFR : 22 ms sont dans les limites 
contractuelles du produit. (sympa quand on fait du serveur de jeu !)


On a également un problème de débit. La MTU contractuelle est de 1500 
octets. Mais on arrive sans problème à faire passer des packets de 65 
000 octets.Bien sur,sur des packets standard à 1500 octets, on atteint 
pas 25 Mb/s. SFR fait ses tests sans limite de MTU et nous indique donc 
que le 1 Gb/s est bien présent de bout à bout à 65 000 octets.


Bref, j'ai l'impression de me fait enthuber par le chef de projet qui 
n'a pas le courage d'escalader les constatations au service concerné 
chez SFR. Du coup, si quelqu'un chez SFR a la possibilité de nous filer 
un coup de main, ça serais vraiment génial.


Commentaires et remarques pertinentes bienvenue :)


--
Cordialement,
Jérémy Martin
Directeur Technique FirstHeberg.com

Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30)
Standard : 09 72 125 539 (tarif local)
Ligne directe : 03 66 72 03 42
Mail : j.martin AT freeheberg.com
Web : http://www.firstheberg.com


__
FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle !
PHP + Mysql + Espace 2 à 20 Go


---
Liste de diffusion du FRnOG
http://www.frnog.org/