Re: [MISC] [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[David Ponzone]

> Le 11 mai 2020 à 10:50, Xavier Beaudouin  a écrit :
> 
> Parce que reproduire le NAT c'est essayer de se rassurer des techniques 
> largement
> déployées partout et que les nouveau "ops" n'ont vu que ça.
> Certains font partie des dinos, qui avaient en réseau interne et sans 
> firewall dans
> les années 90 leur réseau interne et a poil sur le net.
> Ca fait science fiction ? bah oui les firewall n'existaient a peine, ssh 
> était a 
> ses début et les seules protections étaient ... les ACL sur un cisco 2500 
> (quand
> on les mettais).
> 

Je le prends pour moi ça :)

Alors déjà, y avait pas d’attaques/exploits significatives. La gangrène avait 
pas encore atteint Internet.
Jusqu’à 1995, l’accès Grand Public était quasi-inexistant, donc pas de PC.
Avant 1995, avec un shell root sur n’importe quelle WS (Sun, HP, IBM), tu 
pouvais rentrer sur environ 20-30% des autres WS Sun en France (y compris dans 
des labos de recherche) avec un simple rsh, à cause de la légendaire conf par 
défaut foireuse de /etc/rhosts.
Qu’est-ce qu’on a pu rigoler avec ça…
C’était donc pas la peine de trouver un exploit à base de buffer overflow 
complexe :)

L’X hébergeait un serveur de warez, exploitant un protocole UDP-based tombé 
dans l’oubli depuis.

Donc oui, il est clair que la sécurité n’état pas une pré-occupation :)


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

[MISC] [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[JCLB]

Bonjour,

Page 57 Jordi parle des mécanismes de transition, ça n'est pas vraiment pour 
remplacer le NAT.

Dans un premier temps pour déployer du v6, on utilisait généralement des 
tunnels Maintenant ça se répand pour économiser des v4 en les partageant, y 
compris sur des abonnées fixes, via d'autres mécanismes plus performants.

Free a inversé son 6rd en 4rd pour partager les IPv4 entre 4 abonnés Le MAP T 
ou E est étudié par Bouygues pour son réseau fixe grand public SFR semble faire 
du NAT444 avec la box (1re fois le NAT de RFC1918 comme partout, seconde fois 
avec le préfixe 100.64/10 RFC6598 et un Carrier Grade NAT centralisé)

Un opérateur mobile faisait déjà du NAT44 en central, il fait maintenant du 
NAT64 avec les mêmes équipements et NAT finalement moins de sessions qu'avant 
vu que certaines s'établissent dès lors en IPv6 (coucou Orange et Bouygues)

Android fait du XLAT464 dans l'OS, l'iPhone le propose en tethering ainsi que 
dans la gestion des URL dans webkit afin d'éviter de casser des URL IPv4 en 
dur, de mêmes webkit sait valider un certificat TLS avec une IPv4 au travers de 
NAT64 (inutile en temps normal puisqu’on utilise le nom de domaine) Reste le 
problème de DNSEC, et le futur proche problème de DoH (un Firefox Android qui 
ferait du DoH casserait le DNS64 nécessaire au NAT64)
https://lafibre.info/ipv6/ipv6-iphonex/msg689355/#msg689355

Tout cela est de la salade interne d'ISP pour économiser les IPv4 d'une part, 
et éviter le surcout du dual stack de bout en bout.
Mais in fine on arrive à des cas où v6 est natif et v4 non, preuve de la 
considérable avancée du sujet.


Pour en revenir au sujet du NAT, un client lamba particulier a besoin qu'un 
logiciel puisse s'ouvrir un port si besoin sans intervention manuelle (skype, 
torrent, jeu en ligne,...) On le fait avec de l'UPnP et sa partie NAT-PMP, PCP 
le remplace et supporte l'ouverture de port IPv6. Cette dernière n'est plus un 
port forward, mais une véritable ACL dynamique

Bien évidemment on doit avoir des routeurs domestiques qui bloquent par défaut 
le trafic entrant en dehors des besoins UPnP et de certains messages ICMP.
Là-dessus, mention spéciale à Free, qui a mis 10 années à implémenter un FW 
dans la feebox ! Et ne permet toujours pas d'ouvrir un port en IPv6  -_- La 
livebox le permet, mais l'implémentation actuelle est boguée. 
https://lafibre.info/orange-internet/firewall-ipv6-livebox/

La seule translation utile en IPv6, c'est NPTv6, pour changer le préfixe à la 
volée Typiquement changer le /56 attribué par son opérateur sur un petit site, 
car on ne veut pas tout reparamétrer si on change d'opérateur, où parce qu'on 
utilise l'adressage privé IPv6 en interne et non du global.
Ou encore, pour une grande entreprise, avec son propre préfixe, permettre à la 
solution SD-WAN ou autre d'utiliser le préfixe de l'opérateur pour faire du 
Local BreakOut vers internet histoire d'aller plus vite vers son CRM ou sa 
suite bureautique préférée en SaaS.


Un problème majeur d'IPv6 pour les particuliers et les PME, est qu'il n'est pas 
facile de reproduire la configuration manuelle IPv4 dans le LAN pour un 
serveur, une imprimante...
"récupère le préfixe opérateur dynamiquement, mais ensuite assigne le reste de 
ton IPv6 avec ces bits que j'ai choisis sur la portion 65 à 128e bit"

Au mieux on peut faire du DHCP, mais Android ne le gère pas, on peut aussi 
utiliser l'adresse EUI-64 à partir de la mac en désactivant les privacy 
extension, mais si on change de carte bah...
On peut enfin utiliser du privé pour le lan et laisser de l'assignation 
automatique pour sortir vers internet, mais ça représente plus de travail et 
peut être source de comportement indésirable notamment avec DNS...

L'idéal serait donc un jour que chaque entreprise puisse annoncer son propre 
/48 de site directement vers l'opérateur et internet, et donc de faire du 
peering.
Utopiste, mais qui sait...

JC Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Michel Py 
Envoyé : lundi 11 mai 2020 03:53 À : 'Pierre Emeriaud'  Cc 
: frnog@frnog.org Objet : RE: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: 
Message important concernant les élections du RIPE

Je fais d'une Pierre deux coups :P ou de deux Pierres un coup :P

> Pierre Lagoutte a écrit :
> Hallucinant... On en est à discuter du réalisme d'une proposition  
> "d'extension" et "rétrocompatible"
> pourquoi a-t-on oublié le sens des mots ??? une "extension" n'est 
> JAMAIS rétrocompatible, sauf si elle a été prévue comme telle à la 
> conception, auquel cas, ce n'est pas une "extension", c'est un "phasage".

Exactement, mais c'est trop tard pour en parler. Mea culpa, il y a 20 ans 
j'avais pas vu çà.

> Nous sommes en train de discuter d'un franc délire:
> - OUI, IPv6 est une catastrophe
> - OUI nous avons besoin d'une évolution de l'ARCHITECTURE de 
> l'internet réellement COMPATIBL

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Xavier Beaudouin]

Hello Michel et la liste..

> Cà fait longtemps qu'on a perdu l'adressage de bout-en-bout, de toute façon. 
> Il
> y a 20 ans, quand je croyais encore à IPv6, il y avait un vague consensus que
> faire IPv6 avec NAT çà ne marcherait jamais. Regardons ou nous en sommes
> aujourd'hui, écrit par Monsieur IPv6 lui-même :
> https://www.slideshare.net/RNIDS/ipv6-transition-and-coexistance-jordi-palet
> Allez à la page 57. J'ai loupé quelque chose, ou IPv6 n'a que 9 types de NAT
> différents, dont aucun ne marche ?

Parce que reproduire le NAT c'est essayer de se rassurer des techniques 
largement
déployées partout et que les nouveau "ops" n'ont vu que ça.
Certains font partie des dinos, qui avaient en réseau interne et sans firewall 
dans
les années 90 leur réseau interne et a poil sur le net.
Ca fait science fiction ? bah oui les firewall n'existaient a peine, ssh était 
a 
ses début et les seules protections étaient ... les ACL sur un cisco 2500 (quand
on les mettais).

[...]

>> Pierre Emeriaud a écrit :
>> Mon point concernait la sécurité. IPv6 la boite de pandore, oulala y'a plus 
>> de
>> nat, on va tous se faire pirater.
> 
> Ah j'avais loupé çà. NAT == Sécurité, tout le monde le sait :P
> 
> Ceci étant dit, et même si çà fait des lustres que çà ne fait plus 
> grand-chose,
> NAT continue à emmerder la vie de tout le monde, bien ou mal. Impossible de
> faire sans, et en fait le pare-feu "diode" que NAT procure à toutes ces
> merdasses IoT qui ont du code écrit avec les pieds, c'est pas si pire. La
> caméra ou le thermomètre achetés pour 20€ sur banggood ou wish connecté IPv6
> directement accessible de l'extérieur, çà me fait carrément peur.

Ah ce putain de firewall diode... Heureusement qu'on ne charge pas le accu 
lithium
qu'avec une diode, sinon on en aurais des VE qui exploseraient a 250KVA de 
charge...

(Juste pour donner une idée de la betise du NAT).

> Je préfère la merdasse IoT IPv4 derrière NAT avec uPNP désactivé que la même
> merdasse IoT avec IPv6 pas sec et qui ne sera jamais fixé.

Idem, mon IOT est dans un vlan ipv4 only, avec pas de sortie autorisée sauf 
quelques
devices prévu avec des bonne ACL (par exemple j'ai un peu relouté netatmo pour 
avoir
la liste des ips de leur cloud).

Xavier


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

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Remi Desgrange]

euh... Y'a que moi que ça fait tiquer vos truc de "j'ai une ip publique==je 
peux initier une connexion depuis le net sur votre device" Dans toute les box 
et autre routeurs que j'ai eu entre les mains y'a une petite case "IPv6 WAN to 
LAN". Et ça fait un bout de temps que j'ai pas vu de device qui gère pas la 
RFC4941 (mais ça dois forcement exister :-) ).

Cordialement/Best Regards, Rémi Desgrange

On May 11 2020, at 8:26 am, Stéphane Rivière  wrote:
> > https://www.slideshare.net/RNIDS/ipv6-transition-and-coexistance-jordi-palet
> >  Pour un newbie like me, synthèse intéressante. > Ah j'avais loupé çà. NAT 
> > == Sécurité, tout le monde le sait :P +1000 > Ceci étant dit, et même si çà 
> > fait des lustres que çà ne fait plus grand-chose, NAT continue à emmerder 
> > la vie de tout le monde, bien ou mal. Impossible de faire sans, et en fait 
> > le pare-feu "diode" que NAT procure à toutes ces merdasses IoT qui ont du 
> > code écrit avec les pieds, c'est pas si pire. Parce ce que mettre le souk 
> > dans ton intranet, voire mater et ressortir tranquille car ton NAT "diode" 
> > n'est pas un "diac" (deux diodes têtes-bêches) et laisse tout partir, c'est 
> > cool ;) ? >La caméra ou le thermomètre achetés pour 20€ sur banggood ou 
> > wish connecté IPv6 directement accessible de l'extérieur, çà me fait 
> > carrément peur. Bien au chaud dans le NAT, c'est... mieux ? Imho, le NAT, 
> > c'est juste un truc qui devrait pas exister. On vit très bien sans NAT. 
> > Non, correction, on vit mieux, beaucoup mieux sans cette aberration. Il 
> > suffit d'avoir fait je job, avec un FW sur chaque entité. On fait bien ça 
> > depuis toujours pour nos VM exposées... Le généraliser est juste mettre 
> > l'ensemble au niveau. Là où je te rejoins : - C'est pas demain la veille 
> > que les NAT et ipv4 vont disparaître, au moins dans les intranet, afin 
> > d'amortir le matériel ; - Oui, la communication de bout en bout. 
> > Nécessairement, et de ce point de vue uniquement, l'intérêt d'ipV6 sera un 
> > peu tempéré. -- Be Seeing You Number Six --- Liste 
> > de diffusion du FRnOG http://www.frnog.org/


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

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Stéphane Rivière]

> https://www.slideshare.net/RNIDS/ipv6-transition-and-coexistance-jordi-palet
Pour un newbie like me, synthèse intéressante.

> Ah j'avais loupé çà. NAT == Sécurité, tout le monde le sait :P
+1000

> Ceci étant dit, et même si çà fait des lustres que çà ne fait plus 
> grand-chose, NAT continue à emmerder la vie de tout le monde, bien ou mal. 
> Impossible de faire sans, et en fait le pare-feu "diode" que NAT procure à 
> toutes ces merdasses IoT qui ont du code écrit avec les pieds, c'est pas si 
> pire.

Parce ce que mettre le souk dans ton intranet, voire mater et ressortir
tranquille car ton NAT "diode" n'est pas un "diac" (deux diodes
têtes-bêches) et laisse tout partir, c'est cool ;) ?

>La caméra ou le thermomètre achetés pour 20€ sur banggood ou wish connecté 
>IPv6 directement accessible de l'extérieur, çà me fait carrément peur.

Bien au chaud dans le NAT, c'est... mieux ?

Imho, le NAT, c'est juste un truc qui devrait pas exister. On vit très
bien sans NAT. Non, correction, on vit mieux, beaucoup mieux sans cette
aberration. Il suffit d'avoir fait je job, avec un FW sur chaque entité.
On fait bien ça depuis toujours pour nos VM exposées... Le généraliser
est juste mettre l'ensemble au niveau.

Là où je te rejoins :
- C'est pas demain la veille que les NAT et ipv4 vont disparaître, au
moins dans les intranet, afin d'amortir le matériel ;

- Oui, la communication de bout en bout. Nécessairement, et de ce point
de vue uniquement, l'intérêt d'ipV6 sera un peu tempéré.

-- 
Be Seeing You
Number Six


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

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Vincent Bernat]

 ❦ 11 mai 2020 01:53 +00, Michel Py:

> Cà fait longtemps qu'on a perdu l'adressage de bout-en-bout, de toute
> façon. Il y a 20 ans, quand je croyais encore à IPv6, il y avait un
> vague consensus que faire IPv6 avec NAT çà ne marcherait jamais.
> Regardons ou nous en sommes aujourd'hui, écrit par Monsieur IPv6
> lui-même :
> https://www.slideshare.net/RNIDS/ipv6-transition-and-coexistance-jordi-palet
> Allez à la page 57. J'ai loupé quelque chose, ou IPv6 n'a que 9 types
> de NAT différents, dont aucun ne marche ?

T'as loupé quelque chose. Il décrit des mécanismes qui ont chacun leur
avantage et inconvénient. Cela n'a aucun impact sur le trafic pur IPv6
qui est n'est concerné par aucun de ces mécanismes. Ces mécanismes sont
une réalité pour de nombreux ISP qui n'ont pas l'air eu d'avoir ton mémo
sur le fait qu'IPv6 ne marchera jamais. Et ils sont la principale
motivation pour inciter les content providers à passer à IPv6, vu qu'ils
ont tous un impact sur la qualité.

>> - Mais nous n'avons surtout pas besoin d'une bidouille comme cet IPv4+, qui
>> n'est pas compatible de grand chose, et génèrera des tonnes d’embêtement.
>
> Attention de ne pas généraliser la merde à 32bits-et-demi de Elad
> Chohen et le reste. Même si la probabilité d'une évolution d'IPv4 avec
> "juste" plus de bits est improbable, çà reste une possibilité.

Non. Comme indiqué par Kavé, cela nécessite d'introduire une nouvelle
famille et cela impacte absolument toutes les couches, des applications
aux ASIC. Personne n'a envie de faire ça pour quelques bits
supplémentaires alors que le travail est fait pour IPv6. D'ailleurs, il
n'y a que des propositions farfelues sur le sujet.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)


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

RE: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Michel Py]

Je fais d'une Pierre deux coups :P ou de deux Pierres un coup :P

> Pierre Lagoutte a écrit :
> Hallucinant... On en est à discuter du réalisme d'une proposition  
> "d'extension" et "rétrocompatible"
> pourquoi a-t-on oublié le sens des mots ??? une "extension" n'est JAMAIS 
> rétrocompatible, sauf si elle
> a été prévue comme telle à la conception, auquel cas, ce n'est pas une 
> "extension", c'est un "phasage".

Exactement, mais c'est trop tard pour en parler. Mea culpa, il y a 20 ans 
j'avais pas vu çà.

> Nous sommes en train de discuter d'un franc délire:
> - OUI, IPv6 est une catastrophe
> - OUI nous avons besoin d'une évolution de l'ARCHITECTURE de l'internet 
> réellement COMPATIBLE
> IPv4 (au moins au niveau des installations terminales; même s'il faut 
> sacrifier des vieilles
> lunes comme l'adressage de bout-en-bout), car il me semble bien parti pour 
> l'éternité.

Cà fait longtemps qu'on a perdu l'adressage de bout-en-bout, de toute façon. Il 
y a 20 ans, quand je croyais encore à IPv6, il y avait un vague consensus que 
faire IPv6 avec NAT çà ne marcherait jamais. Regardons ou nous en sommes 
aujourd'hui, écrit par Monsieur IPv6 lui-même :
https://www.slideshare.net/RNIDS/ipv6-transition-and-coexistance-jordi-palet
Allez à la page 57. J'ai loupé quelque chose, ou IPv6 n'a que 9 types de NAT 
différents, dont aucun ne marche ?

> - Mais nous n'avons surtout pas besoin d'une bidouille comme cet IPv4+, qui
> n'est pas compatible de grand chose, et génèrera des tonnes d’embêtement.

Attention de ne pas généraliser la merde à 32bits-et-demi de Elad Chohen et le 
reste. Même si la probabilité d'une évolution d'IPv4 avec "juste" plus de bits 
est improbable, çà reste une possibilité.


> Pierre Emeriaud a écrit :
> Mon point concernait la sécurité. IPv6 la boite de pandore, oulala y'a plus 
> de nat, on va tous se faire pirater.

Ah j'avais loupé çà. NAT == Sécurité, tout le monde le sait :P

Ceci étant dit, et même si çà fait des lustres que çà ne fait plus grand-chose, 
NAT continue à emmerder la vie de tout le monde, bien ou mal. Impossible de 
faire sans, et en fait le pare-feu "diode" que NAT procure à toutes ces 
merdasses IoT qui ont du code écrit avec les pieds, c'est pas si pire. La 
caméra ou le thermomètre achetés pour 20€ sur banggood ou wish connecté IPv6 
directement accessible de l'extérieur, çà me fait carrément peur.

Je préfère la merdasse IoT IPv4 derrière NAT avec uPNP désactivé que la même 
merdasse IoT avec IPv6 pas sec et qui ne sera jamais fixé.

Michel.


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Pierre Lagoutte]

Bonjour la liste

Hallucinant... On en est à discuter du réalisme d'une proposition 
"d'extension" et "rétrocompatible"
pourquoi a-t-on oublié le sens des mots ??? une "extension" n'est JAMAIS 
rétrocompatible, sauf si elle a été prévue comme telle à la conception, 
auquel cas, ce n'est pas une "extension", c'est un "phasage".


Nous sommes en train de discuter d'un franc délire:

- OUI, IPv6 est une catastrophe

- OUI nous avons besoin d'une évolution de l'ARCHITECTURE de l'internet 
réellement COMPATIBLE IPv4 (au moins au niveau des installations 
terminales; même s'il faut sacrifier des vieilles lunes comme 
l'adressage de bout-en-bout), car il me semble bien parti pour l'éternité.


- Mais nous n'avons surtout pas besoin d'une bidouille comme cet IPv4+, 
qui n'est pas compatible de grand chose, et génèrera des tonnes 
d’embêtement.


Bonne journée à tous

   Pierre

===

Le 10/05/2020 à 11:44, Michael Hallgren a écrit :

Hello,

Pour moi également,  Christian serait un bon choix.

En ce que concerne la discussion 4+/6... skål ! 

Cheers,
mh

De : Thomas BRENAC via frnog 
Envoyé : samedi 9 mai 2020 23:53
À : Clement Cavadore; frnog@frnog.org
Objet : Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les 
élections du RIPE

Hello,

Comme il n'y a pas de français dans la liste des candidats il est
toujours un peux plus difficile de se faire une idée. Et on doit voter
pour 3 sièges.

Assez d'accord pour Christian Kauffman, je m'en remet a l'avis de clément.

Pour ma part je connais bien Sergey Myasoedov, pour avoir travaille avec
lui chez un des tout premier ISP post Soviétique en Russie puis ensuite
a Prague. Un bon technicien au sens noble du terme, pas un grand
communicant mais un personne qui travailles bien ses sujets. Un gars
consciencieux. Après il est un peux sponsorise par quelques Russes qui
on peur (a juste titre) que le gouvernement Russe récupère la gestion
Nationale des IP, et donc leur permettre d'avoir un accès un peux plus
profond dans le RIPE, via Sergey, mais après tout, c'est de bonne guerre.

Qui a un avis sur Maria Hall, qui en effet apporterai un peux de mixité ?


Thomas



     Sergey Myasoedov

Le 08/05/2020 à 20:35, Clement Cavadore a écrit :

Hello,

En ce qui me concerne, je donnerai mon support à Christian Kauffman,
qui se présente à sa propre succession au sein du Board.
Il a toute ma confiance, étant donné que c'est également un membre du
Board de France-IX, ou je siège également: J'ai pu donc constater qu'il
était très sérieux dans ce genre de contexte, et le trouve efficace
lorsqu'il anime les réunions de board aux meetings/AG du RIPE.

Je n'ai pas (encore) d'avis objectif sur les deux autres pour qui voter
(il y a trois membres à élire). Je vous rapporte donc ses suggestions
en l'état (je l'ai sondé à ce sujet), afin que vous puissiez vous faire
votre propre avis (chose que je ferai):


PS: If you don’t know for who else you wanted to vote, then please
have a look at Sylvester and Maria background and motivation
statements.

A vous de voir, donc. Juste, je vous conseille d'éviter Elad Cohen,
mais vous pouviez vous en douter, j'imagine.



Les candidats (ainsi que leurs bio) sont listés ici:
https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates
A noter que deux Iraniens semblent avoir retiré leur candidature (on le
voit sur la page que j'ai linkée ci-dessus).


Bon week-end !


Clément


On Fri, 2020-05-08 at 20:23 +0200, Damien DUJARDIN wrote:

Tu aurais du lire mieux (troll gratuit du vendredi)

Techniquement il utilise un bit réservé dans l'entête donc ça peut
fonctionner.

Par contre la modif est énorme puisque ce bit doit être pris en
compte dans
tout ce qui manipule de l'ipv4.
C'est encore plus risqué que la transition ipv6 car le matériel non
compatible ne verra pas ce bit et routera donc vers la mauvaise
cible. Bon
courage pour le troubleshoot.

Il relativise la modification en promettant immédiatement monts et
merveilles aux membres. Méthodes classique des politiciens.
Tous le marketing est bien rodé, il vend du rêve.
Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si
je
suis élu"
Ça en dit tout sur le personnage.

Sinon d'après vous, on est sur quels profils du côté des votants,
plutôt
technique ou plutôt managers politiciens ?

Pour ma part, c'est technique, et ça sera mon premier vote au RIPE

Que pensez vous des autres candidats (en dehors des iraniens bien
sûr)?

Bonne soirée

Damien

Le ven. 8 mai 2020 à 20:00, Julien Escario 
a

écrit :


Il faudrait peut être expliquer pourquoi sa proposition est une
aberration totale ?

Si j'ai bien compris, le monsieur propose de jouer sur la
représentation
de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-
255] en
[0-65535].[0-65535].
Ce qui est une connerie abominable au niveau technique puisque da

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Pierre Emeriaud]

Le dim. 10 mai 2020 à 06:34, Michel Py
 a écrit :
>
> > Pierre Emeriaud a écrit :
> > FUD.
>
> Pierre excuse moi, mais en termes de FUD le miracle IPv6 qu'on nous conte 
> depuis 20+ années bat tous les records.

Mon point concernait la sécurité. IPv6 la boite de pandore, oulala y'a
plus de nat, on va tous se faire pirater.

> Bon, le IPv4+ d'Elad Cohen c'est à mourir de rire, changer le monde entier 
> pour passer de 32 bits à 32 bits-et-demi c'est du Elad Cohen pur porc (!) 
> mais en terme de FUD, IPv6 est le champion du monde toutes catégories.
> La stratégie de déploiement d'IPv6 est entièrement basée sur la FUD, et j'en 
> sais quelque chose : j'en ai écrit une partie, il y a longtemps.

> Le principal problème d'IPv6, c'est dual-stack pendant 35 ans ou 40 ans. 
> Dual-stack, c'est 2 fois le boulot et 3 fois les emmerdes, çà fait 20 ans que 
> tout le monde le sait, donc faudrait un peu arrêter de nous briser les 
> couilles avec la FUD qui a 20 ans d'âge. Pour la grande majorité des lecteurs 
> de cette liste, tout le monde a compris que dans 10 ans on va encore avoir 
> IPv4; toi et moi on a discuté de ce sujet plusieurs fois, je suis un peu 
> surpris par ta dernière contrib.

Je me trimbale encore du x25/XoT, du frame et de l'atm en plus de l'ip
et de l'ipv6. Et même du dlsw pour du sna chez certains clients. Le
dual^wmillefeuille de protocoles, je vois ce que ça peut donner. Et
quand je vois qu'on n'en n'a toujours pas fini avec ces vieux
protocoles, j'imagine très bien combien d'années encore il va falloir
se trimbaler ipv4.

De toute façon aujourd'hui, combien de réseau d'opérateurs pourraient
fonctionner sans ipv4 ? Accroche toi au cable, j'enlève ldp...

> IPv4 ne va pas mourir. Si je pouvais lire dans l'avenir, je dirais qu'il y a 
> encore 10% ou 20% de chances qu'une forme d'IPv4+ (certainement pas la merde 
> que nous propose Cohen) puisse voir le jour.

IPv4+ j'y crois pas. Aujourd'hui je suis obligé de me palucher des
vieux tromblons genre esr10k pour les vieux protocoles, c'est plus
supporté, c'est pas ça (ou les futures vieilleries) qui va me
permettre d'utiliser une variante incompatible d'ipv4.


> Moi, je ne suis pas pressé. En fait, je suis en train de regarder le marché 
> pour savoir si je devrais acheter un /24 pour la maison. Je suis con, j'en ai 
> eu plusieurs dans les mains de la mare que j'aurais pu garder.

J'ai rajouté ce mois-ci de l'ipv4 à mon as perso, parce que bon... hein.


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Michael Hallgren]

Hello,

Pour moi également,  Christian serait un bon choix.

En ce que concerne la discussion 4+/6... skål ! 

Cheers, 
mh

De : Thomas BRENAC via frnog 
Envoyé : samedi 9 mai 2020 23:53
À : Clement Cavadore; frnog@frnog.org
Objet : Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les 
élections du RIPE

Hello, 

Comme il n'y a pas de français dans la liste des candidats il est 
toujours un peux plus difficile de se faire une idée. Et on doit voter 
pour 3 sièges. 

Assez d'accord pour Christian Kauffman, je m'en remet a l'avis de clément. 

Pour ma part je connais bien Sergey Myasoedov, pour avoir travaille avec 
lui chez un des tout premier ISP post Soviétique en Russie puis ensuite 
a Prague. Un bon technicien au sens noble du terme, pas un grand 
communicant mais un personne qui travailles bien ses sujets. Un gars 
consciencieux. Après il est un peux sponsorise par quelques Russes qui 
on peur (a juste titre) que le gouvernement Russe récupère la gestion 
Nationale des IP, et donc leur permettre d'avoir un accès un peux plus 
profond dans le RIPE, via Sergey, mais après tout, c'est de bonne guerre. 

Qui a un avis sur Maria Hall, qui en effet apporterai un peux de mixité ? 


Thomas 



    Sergey Myasoedov 

Le 08/05/2020 à 20:35, Clement Cavadore a écrit : 
> Hello, 
> 
> En ce qui me concerne, je donnerai mon support à Christian Kauffman, 
> qui se présente à sa propre succession au sein du Board. 
> Il a toute ma confiance, étant donné que c'est également un membre du 
> Board de France-IX, ou je siège également: J'ai pu donc constater qu'il 
> était très sérieux dans ce genre de contexte, et le trouve efficace 
> lorsqu'il anime les réunions de board aux meetings/AG du RIPE. 
> 
> Je n'ai pas (encore) d'avis objectif sur les deux autres pour qui voter 
> (il y a trois membres à élire). Je vous rapporte donc ses suggestions 
> en l'état (je l'ai sondé à ce sujet), afin que vous puissiez vous faire 
> votre propre avis (chose que je ferai): 
> 
>> PS: If you don’t know for who else you wanted to vote, then please 
>> have a look at Sylvester and Maria background and motivation 
>> statements. 
> A vous de voir, donc. Juste, je vous conseille d'éviter Elad Cohen, 
> mais vous pouviez vous en douter, j'imagine. 
> 
> 
> 
> Les candidats (ainsi que leurs bio) sont listés ici: 
> https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates
>  
> A noter que deux Iraniens semblent avoir retiré leur candidature (on le 
> voit sur la page que j'ai linkée ci-dessus). 
> 
> 
> Bon week-end ! 
> 
> 
> Clément 
> 
> 
> On Fri, 2020-05-08 at 20:23 +0200, Damien DUJARDIN wrote: 
>> Tu aurais du lire mieux (troll gratuit du vendredi) 
>> 
>> Techniquement il utilise un bit réservé dans l'entête donc ça peut 
>> fonctionner. 
>> 
>> Par contre la modif est énorme puisque ce bit doit être pris en 
>> compte dans 
>> tout ce qui manipule de l'ipv4. 
>> C'est encore plus risqué que la transition ipv6 car le matériel non 
>> compatible ne verra pas ce bit et routera donc vers la mauvaise 
>> cible. Bon 
>> courage pour le troubleshoot. 
>> 
>> Il relativise la modification en promettant immédiatement monts et 
>> merveilles aux membres. Méthodes classique des politiciens. 
>> Tous le marketing est bien rodé, il vend du rêve. 
>> Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si 
>> je 
>> suis élu" 
>> Ça en dit tout sur le personnage. 
>> 
>> Sinon d'après vous, on est sur quels profils du côté des votants, 
>> plutôt 
>> technique ou plutôt managers politiciens ? 
>> 
>> Pour ma part, c'est technique, et ça sera mon premier vote au RIPE 
>> 
>> Que pensez vous des autres candidats (en dehors des iraniens bien 
>> sûr)? 
>> 
>> Bonne soirée 
>> 
>> Damien 
>> 
>> Le ven. 8 mai 2020 à 20:00, Julien Escario >> a 
>> écrit : 
>> 
>>> Il faudrait peut être expliquer pourquoi sa proposition est une 
>>> aberration totale ? 
>>> 
>>> Si j'ai bien compris, le monsieur propose de jouer sur la 
>>> représentation 
>>> de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0- 
>>> 255] en 
>>> [0-65535].[0-65535]. 
>>> Ce qui est une connerie abominable au niveau technique puisque dans 
>>> un 
>>> paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est 
>>> strictement 
>>> la même chose. 
>>> 
>>> J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des 
>>> années 
>>> lumières de la connaissance technique qu'il

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Paul Rolland (ポール・ロラン)]

Bonjour,

On Sat, 9 May 2020 16:38:23 +0200
Johann  wrote:

> TECHNIQUEMENT PARLANT :
> Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui
> utiliserait la même structure de paquet et qui serait en plus
> rétrocompatible. Cela permettrait de doubler le nombre d'IPv4 disponible

Tout est dit : ca ne peut pas etre retrocompatible car cela impliquerait de
donner retro-activement une signification a un bit "reserved", ce qui est
tout simplement impossible.

Cette proposition est techniquement farfelue, elle ignore completement
l'existant. 

Meme en cas d'abus de Stroh, on ne peut que la classer dans la categorie
des trolls velus et immondes ;)

Paul


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

RE: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Michel Py]

> Radu-Adrian Feurdean a écrit :
> Tu n'as jamais pense de vraiment livrer gratuitement "un bouton sur 
> l'interface, la, en dessous de celui-ci"?
> Juste le bouton, qui ne fait rien histoire d'expliquer avec des exemples 
> pourquoi le devis... 

:-D

> Pierre Emeriaud a écrit :
> FUD.

Pierre excuse moi, mais en termes de FUD le miracle IPv6 qu'on nous conte 
depuis 20+ années bat tous les records.

Bon, le IPv4+ d'Elad Cohen c'est à mourir de rire, changer le monde entier pour 
passer de 32 bits à 32 bits-et-demi c'est du Elad Cohen pur porc (!) mais en 
terme de FUD, IPv6 est le champion du monde toutes catégories.
La stratégie de déploiement d'IPv6 est entièrement basée sur la FUD, et j'en 
sais quelque chose : j'en ai écrit une partie, il y a longtemps.

Le principal problème d'IPv6, c'est dual-stack pendant 35 ans ou 40 ans. 
Dual-stack, c'est 2 fois le boulot et 3 fois les emmerdes, çà fait 20 ans que 
tout le monde le sait, donc faudrait un peu arrêter de nous briser les couilles 
avec la FUD qui a 20 ans d'âge. Pour la grande majorité des lecteurs de cette 
liste, tout le monde a compris que dans 10 ans on va encore avoir IPv4; toi et 
moi on a discuté de ce sujet plusieurs fois, je suis un peu surpris par ta 
dernière contrib.

Les mecs (et les nanas), arrêtez de vous branler avec IPv6. J'étais sur le 
6bone, il y a 20 ans j'avais même incorporé IPv6 dans la classe de réseau que 
j'enseignais à l'Université de Californie, çà fait 20 ans que la FUD dure, 
faudrait arrêter la connerie.

IPv4 ne va pas mourir. Si je pouvais lire dans l'avenir, je dirais qu'il y a 
encore 10% ou 20% de chances qu'une forme d'IPv4+ (certainement pas la merde 
que nous propose Cohen) puisse voir le jour.

Moi, je ne suis pas pressé. En fait, je suis en train de regarder le marché 
pour savoir si je devrais acheter un /24 pour la maison. Je suis con, j'en ai 
eu plusieurs dans les mains de la mare que j'aurais pu garder.

Michel.


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Thomas BRENAC via frnog]

Hello,

Comme il n'y a pas de français dans la liste des candidats il est 
toujours un peux plus difficile de se faire une idée. Et on doit voter 
pour 3 sièges.


Assez d'accord pour Christian Kauffman, je m'en remet a l'avis de clément.

Pour ma part je connais bien Sergey Myasoedov, pour avoir travaille avec 
lui chez un des tout premier ISP post Soviétique en Russie puis ensuite 
a Prague. Un bon technicien au sens noble du terme, pas un grand 
communicant mais un personne qui travailles bien ses sujets. Un gars 
consciencieux. Après il est un peux sponsorise par quelques Russes qui 
on peur (a juste titre) que le gouvernement Russe récupère la gestion 
Nationale des IP, et donc leur permettre d'avoir un accès un peux plus 
profond dans le RIPE, via Sergey, mais après tout, c'est de bonne guerre.


Qui a un avis sur Maria Hall, qui en effet apporterai un peux de mixité ?


Thomas



   Sergey Myasoedov

Le 08/05/2020 à 20:35, Clement Cavadore a écrit :

Hello,

En ce qui me concerne, je donnerai mon support à Christian Kauffman,
qui se présente à sa propre succession au sein du Board.
Il a toute ma confiance, étant donné que c'est également un membre du
Board de France-IX, ou je siège également: J'ai pu donc constater qu'il
était très sérieux dans ce genre de contexte, et le trouve efficace
lorsqu'il anime les réunions de board aux meetings/AG du RIPE.

Je n'ai pas (encore) d'avis objectif sur les deux autres pour qui voter
(il y a trois membres à élire). Je vous rapporte donc ses suggestions
en l'état (je l'ai sondé à ce sujet), afin que vous puissiez vous faire
votre propre avis (chose que je ferai):


PS: If you don’t know for who else you wanted to vote, then please
have a look at Sylvester and Maria background and motivation
statements.

A vous de voir, donc. Juste, je vous conseille d'éviter Elad Cohen,
mais vous pouviez vous en douter, j'imagine.



Les candidats (ainsi que leurs bio) sont listés ici:
https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates
A noter que deux Iraniens semblent avoir retiré leur candidature (on le
voit sur la page que j'ai linkée ci-dessus).


Bon week-end !


Clément


On Fri, 2020-05-08 at 20:23 +0200, Damien DUJARDIN wrote:

Tu aurais du lire mieux (troll gratuit du vendredi)

Techniquement il utilise un bit réservé dans l'entête donc ça peut
fonctionner.

Par contre la modif est énorme puisque ce bit doit être pris en
compte dans
tout ce qui manipule de l'ipv4.
C'est encore plus risqué que la transition ipv6 car le matériel non
compatible ne verra pas ce bit et routera donc vers la mauvaise
cible. Bon
courage pour le troubleshoot.

Il relativise la modification en promettant immédiatement monts et
merveilles aux membres. Méthodes classique des politiciens.
Tous le marketing est bien rodé, il vend du rêve.
Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si
je
suis élu"
Ça en dit tout sur le personnage.

Sinon d'après vous, on est sur quels profils du côté des votants,
plutôt
technique ou plutôt managers politiciens ?

Pour ma part, c'est technique, et ça sera mon premier vote au RIPE

Que pensez vous des autres candidats (en dehors des iraniens bien
sûr)?

Bonne soirée

Damien

Le ven. 8 mai 2020 à 20:00, Julien Escario 
a

écrit :


Il faudrait peut être expliquer pourquoi sa proposition est une
aberration totale ?

Si j'ai bien compris, le monsieur propose de jouer sur la
représentation
de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-
255] en
[0-65535].[0-65535].
Ce qui est une connerie abominable au niveau technique puisque dans
un
paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est
strictement
la même chose.

J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des
années
lumières de la connaissance technique qu'il faut pour causer de ça.
Si
même moi, avec mes quelques notions de réseau je comprends ça (tout
en
ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a
juste
rien à faire ni au RIPE, ni à proposer un draft.

Juste ou j'aurais dû lire mieux ?

Julien

Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :

Est-ce que c’est un troll ?

Dans le cas contraire, ce genre de propos est franchement indigne
d’une

ML comme FRnOG…

Hugues
AS57199 - AS50628


On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA 

wrote:

Hello,

Je ne connais pas ce fameux candidat mais au vu de la
complexité

d'adoption

de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de
solution est
intelligent et encourageant !

A suivre...

Bruno LEAL DE SOUSA
06.01.23.45.96

Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a

écrit :

Bonjour,
Avez vous reçu cette information pour augmenter le nombre
d’ipv4 ? Quel
est votre avis ?
A bon entendeur.
Christophe

De : Elad Cohen 
Envoyé : vendredi 8 mai 2020 00:06
À : contact 
Objet : Message important concernant les élections du RIPE

Bonjour,

Je m'appelle Elad Cohen et je suis candidat au conseil

d'administration du

RIPE lors des prochaines 

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Radu-Adrian Feurdean]

On Sat, May 9, 2020, at 21:05, Oliver varenne wrote:

> du temps, il faut chiffrer" on me répond "mais.. c'est juste un bouton 
> a ajouter sur l'interface, la, en dessous de celui-là, c'est tout!

Tu n'as jamais pense de vraiment livrer gratuitement "un bouton sur 
l'interface, la, en dessous de celui-ci"? Juste le bouton, qui ne fait rien 
histoire d'expliquer avec des exemples pourquoi le devis... 


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

[MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Oliver varenne]

>> 4) Il sous-estime totalement le processus de mise à jour. Non ça ne sera pas 
>> qu'une simple "petite mise à jour software".

Ça me fait penser quand des clients me demandent une modification, gratuite 
bien sûr, d'une application, et que lorsque je dis "ça prend du temps, il faut 
chiffrer" on me répond "mais.. c'est juste un bouton a ajouter sur l'interface, 
la, en dessous de celui-là, c'est tout! 
(mention spéciale à ceux qui me disent ensuite "vous savez, j'ai fait du 
développement aussi, je sais ce que c'est!"


Cordialement,
 

Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Johann
Envoyé : samedi 9 mai 2020 16:38
À : Bruno LEAL DE SOUSA 
Cc : Christophe PLESSIS ; frnog-tech 
Objet : Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les 
élections du RIPE

Bonjour Bruno,

Pour répondre un peu plus sur la partie technique, car j'imagine que beaucoup 
de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
Ou n'ont tout simplement pas le background technique suffisant (ce n'est pas 
une insulte) pour juger en profondeur de celle-ci.

TECHNIQUEMENT PARLANT :
Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui utiliserait la 
même structure de paquet et qui serait en plus rétrocompatible.
Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter 
l'apocalypse. Ça c'est la promesse papier électorale.

Humainement parlant, on aurait les IPv4 classiques 
[0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG du 
header IPv4 pour indiqué si c'est de l'IPv4+.
Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une plage 
d'IP réservée est souvent difficile à utilisé dans le futur.

Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de la 
technique et du déploiement.
Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF (don't 
fragment) et MF (more fragment), qui eux sont utilisés dans nos réseaux  pour 
la gestion de la fragmentation.
C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce qui est 
mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de 
destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.

Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces bits :
- Le champs ToS peut être modifié sur le chemin
- Le champs IP-ID peut être modifié sur le chemin
- Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)

Ce monsieur justifie que les bits de fragmentation sont "optional by design" et 
que si on connait la MTU, on en a en faite pas besoin.
Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
On ne peut pas connaitre la MTU sans MTU Path discovery, qui se base sur...
le DF bit (et ICMP, souvent filtré d'ailleurs). Aie.
D'ailleurs, on ne peut pas être sur que le chemin aura la même MTU dans le 
temps. Vous pouvez très bien avoir un changement de route au milieu du chemin 
qui change la MTU maximal disponible.
Si un routeur sur le chemin passe d'un réseau à un autre avec une MTU plus 
petite, il fragmentera de lui-même les paquets si le bit DF n'est pas activé.
Alors bien sur, par contre  il pense bien à créé une nouvelle méthode de 
détection de MTU pour son IPv4+, mais ça ne semble pas le déranger plus que 
cela de casser celle d'IPv4.
Je pense que cela vient du fait qu'il ne sait simplement comment fonctionne la 
fragmentation et BGP.

Bon déjà à ce moment la, on sait que c'est mort.
Mais si on continue de lire un peu son idée de déploiement, on tombe 
littéralement de sa chaise :
- Il suffit de réunir une table ronde avec les 5 RIR, une personne 
représentante par d'OS, et une personne de chaque équipementier. Et magiquement 
cela sera adopté par tous.
- Il suffira de mettre à jour chaque OS via les mises à jour automatiques (il 
aime beaucoup insisté sur les mises à jour automatiques dans ses
messages) et chaque routeur BGP (parfois automatiquement, parfois non).
- Et hop, voila ça fonctionnera comme par magie

L'argument fort serait que les LIR pourraient avoir beaucoup de nouvelles IPs 
et donc qu'ils feront pression sur leurs fournisseurs pour que IPv4+ soit 
disponible sur leurs réseaux.
On a vu ce que donnait IPv6 qui rajoute encore plus d'adresse IP, mais on va 
dire que ce n'est pas toute à fait la même chose ;-) Et encore plus fort, c'est 
que pour lui, on peut partir sur un déploiement en 2, 4, allez au pire 8 
semaines (!). En proposant plein d'IP d'un coup si on déploie vite.
En effet, on aurait la mise à jour automatique des OS et seul les routeurs BGP 
devrait avoir une "petite mise à jour".
Parceque ce n'

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Alarig Le Lay]

On Sat 09 May 2020 18:25:10 GMT, Pierre Emeriaud wrote:
> Le sam. 9 mai 2020 à 16:52, Bruno LEAL DE SOUSA
>  a écrit :
> >
> > Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal
> > organisé aujourd'hui. Beaucoup vont se casser les dents en termes de
> > sécurité dans les années à venir à cause de ce changement trop brutal.
> 
> FUD.
> Les stacks ipv6 ont toutes eu des problèmes de jeunesse tels qu'ipv4 a
> pu avoir dans le passé, mais aujourd'hui les problèmes de sécurité je
> les constate tout autant en ipv4 qu'en ipv6. Et même plus en ipv4 pour
> tout un pan d'attaques - ddos volumétriques, bruteforces etc.
> 
> IPv6 ne se firewall pas moins bien qu'ipv4. Même mieux j'aurais
> tendance à dire, grâce aux subnets moins "gruyère suisse" ou "sous-sol
> parisien" : de bonnes tranches d'ip qu'on a attribué selon
> l'expérience du subnetting ipv4, pas de cruft à supporter, on fait
> moins de bêtises, c'est plus propre dès le départ.
> 
> Avoir de l'ipv6 et une ip globalement routable n'est pas forcément
> synonyme d'être exposé à tout internet, juste parce qu'il n'y a plus
> de nat.

Je plussoie totalement.

-- 
Alarig


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

[TECH] Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Christophe PLESSIS]

Merci Johann, Bruno, et autres personnes du groupe, 
Vos retours d’expert et vos précisions technique confirme ma position et ont 
approfondie ma connaissance sur le sujet. 


Christophe Plessis

> Le 9 mai 2020 à 16:39, Johann  a écrit :
> 
> Bonjour Bruno,
> 
> Pour répondre un peu plus sur la partie technique, car j'imagine que
> beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
> Ou n'ont tout simplement pas le background technique suffisant (ce n'est
> pas une insulte) pour juger en profondeur de celle-ci.
> 
> TECHNIQUEMENT PARLANT :
> Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui utiliserait
> la même structure de paquet et qui serait en plus rétrocompatible.
> Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter
> l'apocalypse. Ça c'est la promesse papier électorale.
> 
> Humainement parlant, on aurait les IPv4 classiques
> [0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
> Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG
> du header IPv4 pour indiqué si c'est de l'IPv4+.
> Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une
> plage d'IP réservée est souvent difficile à utilisé dans le futur.
> 
> Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de la
> technique et du déploiement.
> Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF
> (don't fragment) et MF (more fragment), qui eux sont utilisés dans nos
> réseaux  pour la gestion de la fragmentation.
> C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce qui
> est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
> Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de
> destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.
> 
> Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces
> bits :
> - Le champs ToS peut être modifié sur le chemin
> - Le champs IP-ID peut être modifié sur le chemin
> - Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)
> 
> Ce monsieur justifie que les bits de fragmentation sont "optional by
> design" et que si on connait la MTU, on en a en faite pas besoin.
> Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
> On ne peut pas connaitre la MTU sans MTU Path discovery, qui se base sur...
> le DF bit (et ICMP, souvent filtré d'ailleurs). Aie.
> D'ailleurs, on ne peut pas être sur que le chemin aura la même MTU dans le
> temps. Vous pouvez très bien avoir un changement de route au milieu du
> chemin qui change la MTU maximal disponible.
> Si un routeur sur le chemin passe d'un réseau à un autre avec une MTU plus
> petite, il fragmentera de lui-même les paquets si le bit DF n'est pas
> activé.
> Alors bien sur, par contre  il pense bien à créé une nouvelle méthode de
> détection de MTU pour son IPv4+, mais ça ne semble pas le déranger plus que
> cela de casser celle d'IPv4.
> Je pense que cela vient du fait qu'il ne sait simplement comment fonctionne
> la fragmentation et BGP.
> 
> Bon déjà à ce moment la, on sait que c'est mort.
> Mais si on continue de lire un peu son idée de déploiement, on tombe
> littéralement de sa chaise :
> - Il suffit de réunir une table ronde avec les 5 RIR, une personne
> représentante par d'OS, et une personne de chaque équipementier. Et
> magiquement cela sera adopté par tous.
> - Il suffira de mettre à jour chaque OS via les mises à jour automatiques
> (il aime beaucoup insisté sur les mises à jour automatiques dans ses
> messages) et chaque routeur BGP (parfois automatiquement, parfois non).
> - Et hop, voila ça fonctionnera comme par magie
> 
> L'argument fort serait que les LIR pourraient avoir beaucoup de nouvelles
> IPs et donc qu'ils feront pression sur leurs fournisseurs pour que IPv4+
> soit disponible sur leurs réseaux.
> On a vu ce que donnait IPv6 qui rajoute encore plus d'adresse IP, mais on
> va dire que ce n'est pas toute à fait la même chose ;-)
> Et encore plus fort, c'est que pour lui, on peut partir sur un déploiement
> en 2, 4, allez au pire 8 semaines (!). En proposant plein d'IP d'un coup si
> on déploie vite.
> En effet, on aurait la mise à jour automatique des OS et seul les routeurs
> BGP devrait avoir une "petite mise à jour".
> Parceque ce n'est "qu'une petite modification du header".
> 
> Bon, un peu de sérieux.
> 
> Les problématiques de sa proposition :
> 1) Il casse la fragmentation d'IPv4
> 2) Il utilise un bit réservé qui posera sans doute soucis sur des vieux
> équipements
> 3) Une table ronde, si elle avait la moindre chance d’exister un jour (ce
> que je doute), ne garantie en rien le résultat d'adoption universelle. Et
> un concours de muscle ne changera rien.
> 
> 4) Il sous estime totalement le processus de mise à jour. Non ça ne sera
> pas qu'une simple "petite mise à jour software".
> 
> Déjà parceque beaucoup d'équipements actif sur internet ne recoivent 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Pierre Emeriaud]

Le sam. 9 mai 2020 à 16:52, Bruno LEAL DE SOUSA
 a écrit :
>
> Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal
> organisé aujourd'hui. Beaucoup vont se casser les dents en termes de
> sécurité dans les années à venir à cause de ce changement trop brutal.

FUD.
Les stacks ipv6 ont toutes eu des problèmes de jeunesse tels qu'ipv4 a
pu avoir dans le passé, mais aujourd'hui les problèmes de sécurité je
les constate tout autant en ipv4 qu'en ipv6. Et même plus en ipv4 pour
tout un pan d'attaques - ddos volumétriques, bruteforces etc.

IPv6 ne se firewall pas moins bien qu'ipv4. Même mieux j'aurais
tendance à dire, grâce aux subnets moins "gruyère suisse" ou "sous-sol
parisien" : de bonnes tranches d'ip qu'on a attribué selon
l'expérience du subnetting ipv4, pas de cruft à supporter, on fait
moins de bêtises, c'est plus propre dès le départ.

Avoir de l'ipv6 et une ip globalement routable n'est pas forcément
synonyme d'être exposé à tout internet, juste parce qu'il n'y a plus
de nat.


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Frederic Dhieux]

Bonjour,

D'une part la proposition a 20 ans de retard (c'est pas le premier à 
chercher à gratter de la place dans le header pour étendre l'IPv4), mais 
les problèmes sont les mêmes que pour IPv6 hormis la double stack.


La réalité (et c'est expliqué environ 50 fois dans le thread du RIPE), 
c'est que tu dois adapter quand même les équipements concernés, que le 
bit en question peut être réécrit ou reset ou utilisé et dans ce cas tu 
perds l'extension, que pire encore sur une non prise en compte de ce 
bit, tu peux te retrouver avec une IP dupliquée qui peut poser des 
problèmes sur des ACL et que comme dit Radu, à un moment en end point tu 
as une IP qui est 32 bits sans rien d'autre et que voilà.


Si c'est pour taper dans les trucs non prévus, autant exploiter la 
classe E 240.0.0.0/4 réservée pour utilisation future (quel futur ?). A 
priori Windows le gère pas, mais ce serait surement plus simple de 
débloquer ça qu'utiliser un bit "magique".


La proposition n'a aucun fondement concret, aucune sous couche 
technique, aucun POC, aucune proposition solide.


Le mec utilise une méthode bien à la mode pour essayer de se faire élire 
en promettant des trucs magiques (sa proposition anti-spam est du même 
accabit), c'est du Trump like quoi. Sachant que le RIPE n'est pas 
l'organisme qui décide de tout ça en plus.


Je suis effrayé de voir qu'un tel ce non sens a réussi à générer autant 
de volume de discussions et je m'inquiète de voir des gens croire en ce 
marabout de l'an 2020. Entre Trump et les débilités qu'on voit 
concernant Coronavirus et la 5G régulièrement, j'espère qu'au moins la 
communauté des membres du RIPE a globalement plus de discernement que ça.


Voilà que même au RIPE on se tape de promesses de politiciens...

Fred

Le 09/05/2020 à 16:51, Bruno LEAL DE SOUSA a écrit :

Bonjour Johann et bonjour à tous,

Merci pour ces explications mais j'ai juste répondu un peu vite et pas dans
le bon sens.
En effet lorsqu'on regarde en détail sa proposition et surtout ses méthodes
cela fait peur et l'application semble impossible voir catastrophique.

Après je pense que la réflexion qu'il a apporté a juste 10 ou 20 ans de
retard. Il aurait fallu y songer avant de propulseur IPv6.
Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal
organisé aujourd'hui. Beaucoup vont se casser les dents en termes de
sécurité dans les années à venir à cause de ce changement trop brutal.
Un changement ne peut être réussi que quand il est adapté, pas trop brusque
et accompagné. Je trouve donc dommage que ce genre de proposition ou de
réflexion apparaissent bien trop tard.

Maintenant il est certain que ces propositions manquent de sens et de
possibilité de réalisation. Des belles promesses de politiciens encore...

Espérons qu'il ne réussisse pas à gagner le combat des élections.

Bonne journée à tous.

Bruno LEAL DE SOUSA
06.01.23.45.96

Le sam. 9 mai 2020 à 16:38, Johann  a écrit :


Bonjour Bruno,

Pour répondre un peu plus sur la partie technique, car j'imagine que
beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
Ou n'ont tout simplement pas le background technique suffisant (ce n'est
pas une insulte) pour juger en profondeur de celle-ci.

TECHNIQUEMENT PARLANT :
Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui
utiliserait la même structure de paquet et qui serait en plus
rétrocompatible.
Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter
l'apocalypse. Ça c'est la promesse papier électorale.

Humainement parlant, on aurait les IPv4 classiques
[0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG
du header IPv4 pour indiqué si c'est de l'IPv4+.
Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une
plage d'IP réservée est souvent difficile à utilisé dans le futur.

Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de
la technique et du déploiement.
Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF
(don't fragment) et MF (more fragment), qui eux sont utilisés dans nos
réseaux  pour la gestion de la fragmentation.
C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce
qui est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de
destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.

Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces
bits :
- Le champs ToS peut être modifié sur le chemin
- Le champs IP-ID peut être modifié sur le chemin
- Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)

Ce monsieur justifie que les bits de fragmentation sont "optional by
design" et que si on connait la MTU, on en a en faite pas besoin.
Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
On ne peut pas connaitre la MTU sans MTU 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Bruno LEAL DE SOUSA]

Bonjour Johann et bonjour à tous,

Merci pour ces explications mais j'ai juste répondu un peu vite et pas dans
le bon sens.
En effet lorsqu'on regarde en détail sa proposition et surtout ses méthodes
cela fait peur et l'application semble impossible voir catastrophique.

Après je pense que la réflexion qu'il a apporté a juste 10 ou 20 ans de
retard. Il aurait fallu y songer avant de propulseur IPv6.
Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal
organisé aujourd'hui. Beaucoup vont se casser les dents en termes de
sécurité dans les années à venir à cause de ce changement trop brutal.
Un changement ne peut être réussi que quand il est adapté, pas trop brusque
et accompagné. Je trouve donc dommage que ce genre de proposition ou de
réflexion apparaissent bien trop tard.

Maintenant il est certain que ces propositions manquent de sens et de
possibilité de réalisation. Des belles promesses de politiciens encore...

Espérons qu'il ne réussisse pas à gagner le combat des élections.

Bonne journée à tous.

Bruno LEAL DE SOUSA
06.01.23.45.96

Le sam. 9 mai 2020 à 16:38, Johann  a écrit :

> Bonjour Bruno,
>
> Pour répondre un peu plus sur la partie technique, car j'imagine que
> beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
> Ou n'ont tout simplement pas le background technique suffisant (ce n'est
> pas une insulte) pour juger en profondeur de celle-ci.
>
> TECHNIQUEMENT PARLANT :
> Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui
> utiliserait la même structure de paquet et qui serait en plus
> rétrocompatible.
> Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter
> l'apocalypse. Ça c'est la promesse papier électorale.
>
> Humainement parlant, on aurait les IPv4 classiques
> [0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
> Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG
> du header IPv4 pour indiqué si c'est de l'IPv4+.
> Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une
> plage d'IP réservée est souvent difficile à utilisé dans le futur.
>
> Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de
> la technique et du déploiement.
> Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF
> (don't fragment) et MF (more fragment), qui eux sont utilisés dans nos
> réseaux  pour la gestion de la fragmentation.
> C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce
> qui est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
> Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de
> destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.
>
> Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces
> bits :
> - Le champs ToS peut être modifié sur le chemin
> - Le champs IP-ID peut être modifié sur le chemin
> - Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)
>
> Ce monsieur justifie que les bits de fragmentation sont "optional by
> design" et que si on connait la MTU, on en a en faite pas besoin.
> Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
> On ne peut pas connaitre la MTU sans MTU Path discovery, qui se base sur...
> le DF bit (et ICMP, souvent filtré d'ailleurs). Aie.
> D'ailleurs, on ne peut pas être sur que le chemin aura la même MTU dans le
> temps. Vous pouvez très bien avoir un changement de route au milieu du
> chemin qui change la MTU maximal disponible.
> Si un routeur sur le chemin passe d'un réseau à un autre avec une MTU plus
> petite, il fragmentera de lui-même les paquets si le bit DF n'est pas
> activé.
> Alors bien sur, par contre  il pense bien à créé une nouvelle méthode de
> détection de MTU pour son IPv4+, mais ça ne semble pas le déranger plus que
> cela de casser celle d'IPv4.
> Je pense que cela vient du fait qu'il ne sait simplement comment
> fonctionne la fragmentation et BGP.
>
> Bon déjà à ce moment la, on sait que c'est mort.
> Mais si on continue de lire un peu son idée de déploiement, on tombe
> littéralement de sa chaise :
> - Il suffit de réunir une table ronde avec les 5 RIR, une personne
> représentante par d'OS, et une personne de chaque équipementier. Et
> magiquement cela sera adopté par tous.
> - Il suffira de mettre à jour chaque OS via les mises à jour automatiques
> (il aime beaucoup insisté sur les mises à jour automatiques dans ses
> messages) et chaque routeur BGP (parfois automatiquement, parfois non).
> - Et hop, voila ça fonctionnera comme par magie
>
> L'argument fort serait que les LIR pourraient avoir beaucoup de nouvelles
> IPs et donc qu'ils feront pression sur leurs fournisseurs pour que IPv4+
> soit disponible sur leurs réseaux.
> On a vu ce que donnait IPv6 qui rajoute encore plus d'adresse IP, mais on
> va dire que ce n'est pas toute à fait la même chose ;-)
> Et encore plus fort, c'est que pour lui, on peut partir sur un déploiement
> en 2, 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Johann]

Bonjour Bruno,

Pour répondre un peu plus sur la partie technique, car j'imagine que
beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
Ou n'ont tout simplement pas le background technique suffisant (ce n'est
pas une insulte) pour juger en profondeur de celle-ci.

TECHNIQUEMENT PARLANT :
Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui utiliserait
la même structure de paquet et qui serait en plus rétrocompatible.
Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter
l'apocalypse. Ça c'est la promesse papier électorale.

Humainement parlant, on aurait les IPv4 classiques
[0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG
du header IPv4 pour indiqué si c'est de l'IPv4+.
Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une
plage d'IP réservée est souvent difficile à utilisé dans le futur.

Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de la
technique et du déploiement.
Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF
(don't fragment) et MF (more fragment), qui eux sont utilisés dans nos
réseaux  pour la gestion de la fragmentation.
C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce qui
est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de
destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.

Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces
bits :
- Le champs ToS peut être modifié sur le chemin
- Le champs IP-ID peut être modifié sur le chemin
- Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)

Ce monsieur justifie que les bits de fragmentation sont "optional by
design" et que si on connait la MTU, on en a en faite pas besoin.
Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
On ne peut pas connaitre la MTU sans MTU Path discovery, qui se base sur...
le DF bit (et ICMP, souvent filtré d'ailleurs). Aie.
D'ailleurs, on ne peut pas être sur que le chemin aura la même MTU dans le
temps. Vous pouvez très bien avoir un changement de route au milieu du
chemin qui change la MTU maximal disponible.
Si un routeur sur le chemin passe d'un réseau à un autre avec une MTU plus
petite, il fragmentera de lui-même les paquets si le bit DF n'est pas
activé.
Alors bien sur, par contre  il pense bien à créé une nouvelle méthode de
détection de MTU pour son IPv4+, mais ça ne semble pas le déranger plus que
cela de casser celle d'IPv4.
Je pense que cela vient du fait qu'il ne sait simplement comment fonctionne
la fragmentation et BGP.

Bon déjà à ce moment la, on sait que c'est mort.
Mais si on continue de lire un peu son idée de déploiement, on tombe
littéralement de sa chaise :
- Il suffit de réunir une table ronde avec les 5 RIR, une personne
représentante par d'OS, et une personne de chaque équipementier. Et
magiquement cela sera adopté par tous.
- Il suffira de mettre à jour chaque OS via les mises à jour automatiques
(il aime beaucoup insisté sur les mises à jour automatiques dans ses
messages) et chaque routeur BGP (parfois automatiquement, parfois non).
- Et hop, voila ça fonctionnera comme par magie

L'argument fort serait que les LIR pourraient avoir beaucoup de nouvelles
IPs et donc qu'ils feront pression sur leurs fournisseurs pour que IPv4+
soit disponible sur leurs réseaux.
On a vu ce que donnait IPv6 qui rajoute encore plus d'adresse IP, mais on
va dire que ce n'est pas toute à fait la même chose ;-)
Et encore plus fort, c'est que pour lui, on peut partir sur un déploiement
en 2, 4, allez au pire 8 semaines (!). En proposant plein d'IP d'un coup si
on déploie vite.
En effet, on aurait la mise à jour automatique des OS et seul les routeurs
BGP devrait avoir une "petite mise à jour".
Parceque ce n'est "qu'une petite modification du header".

Bon, un peu de sérieux.

Les problématiques de sa proposition :
1) Il casse la fragmentation d'IPv4
2) Il utilise un bit réservé qui posera sans doute soucis sur des vieux
équipements
3) Une table ronde, si elle avait la moindre chance d’exister un jour (ce
que je doute), ne garantie en rien le résultat d'adoption universelle. Et
un concours de muscle ne changera rien.

4) Il sous estime totalement le processus de mise à jour. Non ça ne sera
pas qu'une simple "petite mise à jour software".

Déjà parceque beaucoup d'équipements actif sur internet ne recoivent plus
de mise à jour de leur constructeur pour ce genre de chose.
On a encore de vieux OS en production qui supporte pas IPv6, alors IPv4+,
je ne parle pas des milliards d’objet IoT chinois (ou non) perdu partout
dans le monde.
Et j'ose même pas imaginer les tablettes/smartphones dans l'histoire.

4.5) La grande majorité des équipements réseaux actuels, surtout chez les
opérateurs, se basent sur des ASIC ou équivalent qui 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Johann]

Bonjour Bruno,

Ce qui me fait peur dans l'histoire, c'est que j'imagine que votre remarque
est sérieuse et à prendre au 1er degré.
Cela veut sans doute dire que des personnes LIR auprès de qui il s'amuse à
spammer via des emails trouvés et utilisés contre toute règle du RIPE (pour
lequel il se présente, je rappel...) pourrait le penser aussi et être
tenter de voter pour lui.

Je ne m'attarderais pas sur l'email spam, je pense que chaque personne un
minimum censé se sera aperçu du n'importe quoi qui le compose.
Par contre, aucune de ses propositions (pour avoir plus d'IP, lutter contre
le spam (activité qu'il pratique donc), ou contre les DDoS) n'a de réel
base technique ou même un moindre PoC.
Pour des gens du métier, par exemple ceux qui construisent des réseaux, on
s'aperçoit du non sens technique après 10 lignes sur chacune de ces
propositions.

Il ne s'est pas gêné pour spammer une mailing-list du RIPE dédiée aux
questions autour de l'adhésion. Quand on lui fait remarqué que c'est pas le
bon endroit, c'est pas triste...
D'ailleurs à chaque remarque ou simple question au sujet de ses
propositions, la réponse semble être la même à chaque fois :
- Soit on ment car on est contre lui et qu'on fait partie du complot
(lequel? Je ne comprends toujours pas son histoire)
- Bah on a qu'à continué comme cela alors (le fameux "my way or noway"),
surtout sur son "anti-DDoS magique"
- On le diffame (alors que la plus part du temps, c'est l'inverse)
- On est le gang des "proipv6" et on veut empêcher toute alternatif (oh mon
dieu...)
- C'est pas nous qui fixons les règles (sauf que lui non plus, il y a des
chartes par exemple)

Du coup, c'est compliqué de débattre sur ses propositions, vu qu'on est
face à un mur.
Mur qui d'ailleurs se présente à un poste qui demande quand même des
qualités de dialogues et d'ouverture. Bref...
Nous n'avons jamais une vrai réponse aux questions techniques.
Entre deux attaques, diffamation ou théorie du complot, on arrive parfois à
avoir quelques éléments mais peu probant techniquement.
J'ai pris beaucoup de temps à lire presque l'intégralité des échanges
disponible et c'est réellement une perte de temps.

Clairement, c'est une personne à qui il faut éviter de donner de
l'importance et ne surtout pas voter.
C'est un élément toxique pour la communauté, comme j'en ai déjà vu par le
passé.

P.S : Juste pour rappel, ce n'est pas le RIPE qui décide tout seul dans son
coin des protocoles.
Si nous voulons proposé un protocole, on passe comme tout le monde par le
chemin classique, pour que cela devienne après un long chemin une RFC.

Johann


Le ven. 8 mai 2020 à 19:24, Bruno LEAL DE SOUSA 
a écrit :

> Hello,
>
> Je ne connais pas ce fameux candidat mais au vu de la complexité d'adoption
> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
> intelligent et encourageant !
>
> A suivre...
>
> Bruno LEAL DE SOUSA
> 06.01.23.45.96
>
> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a
> écrit :
>
> >  Bonjour,
> > Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
> > est votre avis ?
> > A bon entendeur.
> > Christophe
> >
> > De : Elad Cohen 
> > Envoyé : vendredi 8 mai 2020 00:06
> > À : contact 
> > Objet : Message important concernant les élections du RIPE
> >
> > Bonjour,
> >
> > Je m'appelle Elad Cohen et je suis candidat au conseil d'administration
> du
> > RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
> >
> > J'ai créé une solution technique avec laquelle il y aura plus de 4 294
> 967
> > 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
> > RIPE, vous pouvez en savoir plus à ce sujet ici :
> >
> >
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
> >
> > Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
> > RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
> > Personne d'autre ne mettra en œuvre ma solution technique, je vous
> demande
> > votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
> > générale du RIPE, ma solution technique ci-dessus ne sera pas mise en
> œuvre.
> >
> > Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
> > utilisant le lien suivant :
> > https://www.ripe.net/s/gm-registration-may-2020
> >
> > Si vous rencontrez un problème pour vous inscrire au vote en ligne,
> > veuillez envoyer un courrier électronique à a...@ripe.net > a...@ripe.net>
> >
> > ---
> >
> > Outre la solution technique susmentionnée au problème de « l'épuisement
> de
> > l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai
> de
> > mettre en œuvre si j'ai l'honneur d'être élu :
> >
> >
> > Une solution technique au problème mondial du spam par courrier
> > électronique :
> >
> >
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
> >
> > Une solution technique au problème mondial de l'amplification de
> > l'usurpation du DDoS :
> >
> >
> 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Radu-Adrian Feurdean]

On Fri, May 8, 2020, at 19:59, Julien Escario wrote:
> Il faudrait peut être expliquer pourquoi sa proposition est une
> aberration totale ?

Raison 0 : au niveau de l'API systeme, l'IPv4 est 32 bits pas un de plus, 
*sans* le bit reserved.
=> Nouvelle implementation cote systeme, nouvelle AF, nouvelles extensions sur 
tous les protocoles, applications a modifier et recompiler, configurations a 
changer 
Bref, meme si la stack de l'OS implemente cette connerie, aucune application ne 
sera en mesure de l'utiliser sans des modifications. 

Il me semble qu'a ce sujet il y a des alternatives qui ont bien plus de 10 ans 
(plutot 20) d'avance.

Toute "extension de l'IPv4" est voue a l'echec rien que pour ce raison. Mais il 
y en a plein d'autres.


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[David Ponzone]

> Le 8 mai 2020 à 22:09, Fabien VINCENT FrNOG via frnog  a 
> écrit :
> 
> 
> La Dual Stack ca existe et ca marche. Non sans problème, mais à un moment 
> donné, t'imagines si on rénovait des 2CV depuis 80 ans ? Ca peut aussi 
> marcher ! This industry SHOULD move :)

https://www.automobile-propre.com/r-fit-quand-la-citroen-2cv-et-la-mehari-se-convertissent-a-lelectrique/
 


:)


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Stéphane Rivière]

> Je ne connais pas ce fameux candidat mais au vu de la complexité d'adoption
> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
> intelligent et encourageant !

Voila. La guerre ipv5 / ipv5.5 est repartie.
Chic, ça me rajeunit de... plus de 20 ans.

Moi, je suis nul en réseau mais je sais une chose, c'est que l'ipv4
existe et mes serveurs gèrent, l'ipv6 existe et mes serveurs peuvent
gérer, que ce message va passer dans un tunnel ipv4 dans ipv6 et qu'il
existe des équipements réseaux qui comprennent l'ipv4 et l'ipv6.

Ce qu'il propose n'est ni de l'ipv4, ni de l'ipv6 et implémenté nulle
part. C'est juste digne de tous les arrivistes politiciens (voter pour
moi, ciel bleu toute l'année) qui deviennent nos gouvernants parvenus.

Encore une fois, la démocratie participative (voter pour des promesses)
n'est pas la démocratie (les grecs le savaient déjà) et que la seule
démocratie est celle de projet (voter pour un projet pas une personne).

Ce qu'il propose est à l'image de la gestion du covid-19 : si c'était
implémenté dans de nouveaux équipements, les anciens équipements
mettraient un souk total. C'est (imho)  du bullshit stratosphérique.

Ce qui est inquiétant, c'est que ça reçoit de l'audience. On en obligé
d'en parler et d'expliquer. Perso, j'ai fais le choix de rester ipv4
jusqu'au bout et quand je devrais, je passerais ipv6 sans dual stack.

Je n'ai pas à voter, ce n'est pas mon métier, mais si je pouvais, je
suivrais simplement l'avis des colistiers qui ont de l'expérience.

C'est la vie, c'est l'évolution, what else George ? (C) Clooney

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Fabien VINCENT FrNOG via frnog]

Le 08-05-2020 20:23, Damien DUJARDIN a écrit :

Tu aurais du lire mieux (troll gratuit du vendredi)

Techniquement il utilise un bit réservé dans l'entête donc ça peut
fonctionner.


It MAY work ;) Ca me rappelle une histoire avec la réutilisation du bit 
CFI de 802.1q devenu DEI :)


Un véritable carnage dans les implémentations constructeurs (quand DEI 
est implémenté et qu'il fait des chocapic avec un vieux routeur en 
face). Les stacks réseaux, elles ont pas les durées de vie des k8s 
serverless in da cloud.


Bref, il serait peut être temps d'implémenter tout ce qu'il faut pour 
qu'IPv6 fonctionne correctement plutôt (je pense notamment aux moultes 
implémentations DNS reverse et autres). Il n'est certes pas parfait, 
mais IPv4 l'était-il ?


La Dual Stack ca existe et ca marche. Non sans problème, mais à un 
moment donné, t'imagines si on rénovait des 2CV depuis 80 ans ? Ca peut 
aussi marcher ! This industry SHOULD move :)




Par contre la modif est énorme puisque ce bit doit être pris en compte 
dans

tout ce qui manipule de l'ipv4.
C'est encore plus risqué que la transition ipv6 car le matériel non
compatible ne verra pas ce bit et routera donc vers la mauvaise cible. 
Bon

courage pour le troubleshoot.

Il relativise la modification en promettant immédiatement monts et
merveilles aux membres. Méthodes classique des politiciens.
Tous le marketing est bien rodé, il vend du rêve.
Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si 
je

suis élu"
Ça en dit tout sur le personnage.

Sinon d'après vous, on est sur quels profils du côté des votants, 
plutôt

technique ou plutôt managers politiciens ?

Pour ma part, c'est technique, et ça sera mon premier vote au RIPE

Que pensez vous des autres candidats (en dehors des iraniens bien sûr)?

Bonne soirée

Damien

Le ven. 8 mai 2020 à 20:00, Julien Escario  
a

écrit :


Il faudrait peut être expliquer pourquoi sa proposition est une
aberration totale ?

Si j'ai bien compris, le monsieur propose de jouer sur la 
représentation
de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] 
en

[0-65535].[0-65535].
Ce qui est une connerie abominable au niveau technique puisque dans un
paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est 
strictement

la même chose.

J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des 
années

lumières de la connaissance technique qu'il faut pour causer de ça. Si
même moi, avec mes quelques notions de réseau je comprends ça (tout en
ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a 
juste

rien à faire ni au RIPE, ni à proposer un draft.

Juste ou j'aurais dû lire mieux ?

Julien

Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> Est-ce que c’est un troll ?
>
> Dans le cas contraire, ce genre de propos est franchement indigne d’une
ML comme FRnOG…
>
> Hugues
> AS57199 - AS50628
>
>> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA 
wrote:
>>
>> Hello,
>>
>> Je ne connais pas ce fameux candidat mais au vu de la complexité
d'adoption
>> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
>> intelligent et encourageant !
>>
>> A suivre...
>>
>> Bruno LEAL DE SOUSA
>> 06.01.23.45.96
>>
>> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a
écrit :
>>
>>> Bonjour,
>>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
>>> est votre avis ?
>>> A bon entendeur.
>>> Christophe
>>>
>>> De : Elad Cohen 
>>> Envoyé : vendredi 8 mai 2020 00:06
>>> À : contact 
>>> Objet : Message important concernant les élections du RIPE
>>>
>>> Bonjour,
>>>
>>> Je m'appelle Elad Cohen et je suis candidat au conseil
d'administration du
>>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
>>>
>>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294
967
>>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
>>> RIPE, vous pouvez en savoir plus à ce sujet ici :
>>>
>>>
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
>>>
>>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
>>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
>>> Personne d'autre ne mettra en œuvre ma solution technique, je vous
demande
>>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
>>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en
œuvre.
>>>
>>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
>>> utilisant le lien suivant :
>>> https://www.ripe.net/s/gm-registration-may-2020
>>>
>>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
>>> veuillez envoyer un courrier électronique à a...@ripe.net>> a...@ripe.net>
>>>
>>> ---
>>>
>>> Outre la solution technique susmentionnée au problème de «
l'épuisement de
>>> l'IPv4 », il existe deux autres solutions techniques que je
m'efforcerai de
>>> mettre en œuvre si j'ai l'honneur d'être élu :
>>>
>>>
>>> Une solution technique 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Emmanuel DECAEN]

Bonsoir,

Le 08/05/2020 à 20:35, Clement Cavadore a écrit :
> En ce qui me concerne, je donnerai mon support à Christian Kauffman,
> qui se présente à sa propre succession au sein du Board. 

Je ne le connais pas, mais ce que j'ai pu lire le concernant est plutôt
positif.
Je vais également voter pour lui.

>> PS: If you don’t know for who else you wanted to vote, then please 
>> have a look at Sylvester and Maria background and motivation 
>> statements.

Je pense également voter pour Maria Häll, sa biographie est intéressante
et cela fera un peu de mixité.

https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies#maria_hall

Bon Week-End à tous.
-- 
*Emmanuel DECAEN
*

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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Clement Cavadore]

Hello,

En ce qui me concerne, je donnerai mon support à Christian Kauffman,
qui se présente à sa propre succession au sein du Board. 
Il a toute ma confiance, étant donné que c'est également un membre du
Board de France-IX, ou je siège également: J'ai pu donc constater qu'il
était très sérieux dans ce genre de contexte, et le trouve efficace
lorsqu'il anime les réunions de board aux meetings/AG du RIPE. 

Je n'ai pas (encore) d'avis objectif sur les deux autres pour qui voter
(il y a trois membres à élire). Je vous rapporte donc ses suggestions
en l'état (je l'ai sondé à ce sujet), afin que vous puissiez vous faire
votre propre avis (chose que je ferai):

> PS: If you don’t know for who else you wanted to vote, then please 
> have a look at Sylvester and Maria background and motivation 
> statements.

A vous de voir, donc. Juste, je vous conseille d'éviter Elad Cohen,
mais vous pouviez vous en douter, j'imagine.



Les candidats (ainsi que leurs bio) sont listés ici:
https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates
A noter que deux Iraniens semblent avoir retiré leur candidature (on le
voit sur la page que j'ai linkée ci-dessus).


Bon week-end !


Clément


On Fri, 2020-05-08 at 20:23 +0200, Damien DUJARDIN wrote:
> Tu aurais du lire mieux (troll gratuit du vendredi)
> 
> Techniquement il utilise un bit réservé dans l'entête donc ça peut
> fonctionner.
> 
> Par contre la modif est énorme puisque ce bit doit être pris en
> compte dans
> tout ce qui manipule de l'ipv4.
> C'est encore plus risqué que la transition ipv6 car le matériel non
> compatible ne verra pas ce bit et routera donc vers la mauvaise
> cible. Bon
> courage pour le troubleshoot.
> 
> Il relativise la modification en promettant immédiatement monts et
> merveilles aux membres. Méthodes classique des politiciens.
> Tous le marketing est bien rodé, il vend du rêve.
> Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si
> je
> suis élu"
> Ça en dit tout sur le personnage.
> 
> Sinon d'après vous, on est sur quels profils du côté des votants,
> plutôt
> technique ou plutôt managers politiciens ?
> 
> Pour ma part, c'est technique, et ça sera mon premier vote au RIPE
> 
> Que pensez vous des autres candidats (en dehors des iraniens bien
> sûr)?
> 
> Bonne soirée
> 
> Damien
> 
> Le ven. 8 mai 2020 à 20:00, Julien Escario  > a
> écrit :
> 
> > Il faudrait peut être expliquer pourquoi sa proposition est une
> > aberration totale ?
> > 
> > Si j'ai bien compris, le monsieur propose de jouer sur la
> > représentation
> > de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-
> > 255] en
> > [0-65535].[0-65535].
> > Ce qui est une connerie abominable au niveau technique puisque dans
> > un
> > paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est
> > strictement
> > la même chose.
> > 
> > J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des
> > années
> > lumières de la connaissance technique qu'il faut pour causer de ça.
> > Si
> > même moi, avec mes quelques notions de réseau je comprends ça (tout
> > en
> > ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a
> > juste
> > rien à faire ni au RIPE, ni à proposer un draft.
> > 
> > Juste ou j'aurais dû lire mieux ?
> > 
> > Julien
> > 
> > Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> > > Est-ce que c’est un troll ?
> > > 
> > > Dans le cas contraire, ce genre de propos est franchement indigne
> > > d’une
> > 
> > ML comme FRnOG…
> > > 
> > > Hugues
> > > AS57199 - AS50628
> > > 
> > > > On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA  > > > ail.com>
> > 
> > wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > Je ne connais pas ce fameux candidat mais au vu de la
> > > > complexité
> > 
> > d'adoption
> > > > de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de
> > > > solution est
> > > > intelligent et encourageant !
> > > > 
> > > > A suivre...
> > > > 
> > > > Bruno LEAL DE SOUSA
> > > > 06.01.23.45.96
> > > > 
> > > > Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  > > > fr> a
> > 
> > écrit :
> > > > 
> > > > > Bonjour,
> > > > > Avez vous reçu cette information pour augmenter le nombre
> > > > > d’ipv4 ? Quel
> > > > > est votre avis ?
> > > > > A bon entendeur.
> > > > > Christophe
> > > > > 
> > > > > De : Elad Cohen 
> > > > > Envoyé : vendredi 8 mai 2020 00:06
> > > > > À : contact 
> > > > > Objet : Message important concernant les élections du RIPE
> > > > > 
> > > > > Bonjour,
> > > > > 
> > > > > Je m'appelle Elad Cohen et je suis candidat au conseil
> > 
> > d'administration du
> > > > > RIPE lors des prochaines élections, qui auront lieu le 13 de
> > > > > ce mois.
> > > > > 
> > > > > J'ai créé une solution technique avec laquelle il y aura plus
> > > > > de 4 294
> > 
> > 967
> > > > > 296 adresses IPv4 pour les 5 registres Internet régionaux, y
> > > > > compris le
> > > > > RIPE, vous pouvez en savoir plus à ce sujet ici :
> > > > > 
> > > > > 
> > 
> > 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Julien Escario]

Le 08/05/2020 à 20:23, Damien DUJARDIN a écrit :
> Tu aurais du lire mieux (troll gratuit du vendredi)

Mais justifié ;-)

> Techniquement il utilise un bit réservé dans l'entête donc ça peut
> fonctionner.

Merci, tu viens de me faire gagner deux bonnes heures à comprendre
quelle bidouille il utilise.
C'est donc un bit flip.

Ce qui ne change rien au fait que c'est du vent mais la raison n'est
plus totalement technique.

Julien


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Hugues Voiturier]

Il me semble qu’il utilise le bit réservé *et* le bit de fragmentation, donc si 
un routeur sur le chemin doit fragmenter et changer ce bit pour une raison X ou 
Y, ton paquet est mort :)


Hugues
AS57199 - AS50628

> On 8 May 2020, at 20:23, Damien DUJARDIN  wrote:
> 
> Tu aurais du lire mieux (troll gratuit du vendredi)
> 
> Techniquement il utilise un bit réservé dans l'entête donc ça peut
> fonctionner.
> 
> Par contre la modif est énorme puisque ce bit doit être pris en compte dans
> tout ce qui manipule de l'ipv4.
> C'est encore plus risqué que la transition ipv6 car le matériel non
> compatible ne verra pas ce bit et routera donc vers la mauvaise cible. Bon
> courage pour le troubleshoot.
> 
> Il relativise la modification en promettant immédiatement monts et
> merveilles aux membres. Méthodes classique des politiciens.
> Tous le marketing est bien rodé, il vend du rêve.
> Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si je
> suis élu"
> Ça en dit tout sur le personnage.
> 
> Sinon d'après vous, on est sur quels profils du côté des votants, plutôt
> technique ou plutôt managers politiciens ?
> 
> Pour ma part, c'est technique, et ça sera mon premier vote au RIPE
> 
> Que pensez vous des autres candidats (en dehors des iraniens bien sûr)?
> 
> Bonne soirée
> 
> Damien
> 
> Le ven. 8 mai 2020 à 20:00, Julien Escario  a
> écrit :
> 
>> Il faudrait peut être expliquer pourquoi sa proposition est une
>> aberration totale ?
>> 
>> Si j'ai bien compris, le monsieur propose de jouer sur la représentation
>> de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] en
>> [0-65535].[0-65535].
>> Ce qui est une connerie abominable au niveau technique puisque dans un
>> paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est strictement
>> la même chose.
>> 
>> J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des années
>> lumières de la connaissance technique qu'il faut pour causer de ça. Si
>> même moi, avec mes quelques notions de réseau je comprends ça (tout en
>> ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a juste
>> rien à faire ni au RIPE, ni à proposer un draft.
>> 
>> Juste ou j'aurais dû lire mieux ?
>> 
>> Julien
>> 
>> Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
>>> Est-ce que c’est un troll ?
>>> 
>>> Dans le cas contraire, ce genre de propos est franchement indigne d’une
>> ML comme FRnOG…
>>> 
>>> Hugues
>>> AS57199 - AS50628
>>> 
 On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA 
>> wrote:
 
 Hello,
 
 Je ne connais pas ce fameux candidat mais au vu de la complexité
>> d'adoption
 de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
 intelligent et encourageant !
 
 A suivre...
 
 Bruno LEAL DE SOUSA
 06.01.23.45.96
 
 Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a
>> écrit :
 
> Bonjour,
> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
> est votre avis ?
> A bon entendeur.
> Christophe
> 
> De : Elad Cohen 
> Envoyé : vendredi 8 mai 2020 00:06
> À : contact 
> Objet : Message important concernant les élections du RIPE
> 
> Bonjour,
> 
> Je m'appelle Elad Cohen et je suis candidat au conseil
>> d'administration du
> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
> 
> J'ai créé une solution technique avec laquelle il y aura plus de 4 294
>> 967
> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
> RIPE, vous pouvez en savoir plus à ce sujet ici :
> 
> 
>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
> 
> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
> Personne d'autre ne mettra en œuvre ma solution technique, je vous
>> demande
> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en
>> œuvre.
> 
> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
> utilisant le lien suivant :
> https://www.ripe.net/s/gm-registration-may-2020
> 
> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
> veuillez envoyer un courrier électronique à a...@ripe.net a...@ripe.net>
> 
> ---
> 
> Outre la solution technique susmentionnée au problème de «
>> l'épuisement de
> l'IPv4 », il existe deux autres solutions techniques que je
>> m'efforcerai de
> mettre en œuvre si j'ai l'honneur d'être élu :
> 
> 
> Une solution technique au problème mondial du spam par courrier
> électronique :
> 
> 
>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
> 
> Une solution technique au problème mondial de l'amplification de
> 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Damien DUJARDIN]

Tu aurais du lire mieux (troll gratuit du vendredi)

Techniquement il utilise un bit réservé dans l'entête donc ça peut
fonctionner.

Par contre la modif est énorme puisque ce bit doit être pris en compte dans
tout ce qui manipule de l'ipv4.
C'est encore plus risqué que la transition ipv6 car le matériel non
compatible ne verra pas ce bit et routera donc vers la mauvaise cible. Bon
courage pour le troubleshoot.

Il relativise la modification en promettant immédiatement monts et
merveilles aux membres. Méthodes classique des politiciens.
Tous le marketing est bien rodé, il vend du rêve.
Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si je
suis élu"
Ça en dit tout sur le personnage.

Sinon d'après vous, on est sur quels profils du côté des votants, plutôt
technique ou plutôt managers politiciens ?

Pour ma part, c'est technique, et ça sera mon premier vote au RIPE

Que pensez vous des autres candidats (en dehors des iraniens bien sûr)?

Bonne soirée

Damien

Le ven. 8 mai 2020 à 20:00, Julien Escario  a
écrit :

> Il faudrait peut être expliquer pourquoi sa proposition est une
> aberration totale ?
>
> Si j'ai bien compris, le monsieur propose de jouer sur la représentation
> de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] en
> [0-65535].[0-65535].
> Ce qui est une connerie abominable au niveau technique puisque dans un
> paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est strictement
> la même chose.
>
> J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des années
> lumières de la connaissance technique qu'il faut pour causer de ça. Si
> même moi, avec mes quelques notions de réseau je comprends ça (tout en
> ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a juste
> rien à faire ni au RIPE, ni à proposer un draft.
>
> Juste ou j'aurais dû lire mieux ?
>
> Julien
>
> Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> > Est-ce que c’est un troll ?
> >
> > Dans le cas contraire, ce genre de propos est franchement indigne d’une
> ML comme FRnOG…
> >
> > Hugues
> > AS57199 - AS50628
> >
> >> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA 
> wrote:
> >>
> >> Hello,
> >>
> >> Je ne connais pas ce fameux candidat mais au vu de la complexité
> d'adoption
> >> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
> >> intelligent et encourageant !
> >>
> >> A suivre...
> >>
> >> Bruno LEAL DE SOUSA
> >> 06.01.23.45.96
> >>
> >> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a
> écrit :
> >>
> >>> Bonjour,
> >>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
> >>> est votre avis ?
> >>> A bon entendeur.
> >>> Christophe
> >>>
> >>> De : Elad Cohen 
> >>> Envoyé : vendredi 8 mai 2020 00:06
> >>> À : contact 
> >>> Objet : Message important concernant les élections du RIPE
> >>>
> >>> Bonjour,
> >>>
> >>> Je m'appelle Elad Cohen et je suis candidat au conseil
> d'administration du
> >>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
> >>>
> >>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294
> 967
> >>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
> >>> RIPE, vous pouvez en savoir plus à ce sujet ici :
> >>>
> >>>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
> >>>
> >>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
> >>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
> >>> Personne d'autre ne mettra en œuvre ma solution technique, je vous
> demande
> >>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
> >>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en
> œuvre.
> >>>
> >>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
> >>> utilisant le lien suivant :
> >>> https://www.ripe.net/s/gm-registration-may-2020
> >>>
> >>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
> >>> veuillez envoyer un courrier électronique à a...@ripe.net >>> a...@ripe.net>
> >>>
> >>> ---
> >>>
> >>> Outre la solution technique susmentionnée au problème de «
> l'épuisement de
> >>> l'IPv4 », il existe deux autres solutions techniques que je
> m'efforcerai de
> >>> mettre en œuvre si j'ai l'honneur d'être élu :
> >>>
> >>>
> >>> Une solution technique au problème mondial du spam par courrier
> >>> électronique :
> >>>
> >>>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
> >>>
> >>> Une solution technique au problème mondial de l'amplification de
> >>> l'usurpation du DDoS :
> >>>
> >>>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html
> >>>
> >>> ---
> >>>
> >>> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE
> >>> devienne :
> >>>
> >>> - Une organisation 100% transparente.
> >>>
> >>> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures
> pour
> >>> chaque demande d'assistance, 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Julien Escario]

Il faudrait peut être expliquer pourquoi sa proposition est une
aberration totale ?

Si j'ai bien compris, le monsieur propose de jouer sur la représentation
de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] en
[0-65535].[0-65535].
Ce qui est une connerie abominable au niveau technique puisque dans un
paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est strictement
la même chose.

J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des années
lumières de la connaissance technique qu'il faut pour causer de ça. Si
même moi, avec mes quelques notions de réseau je comprends ça (tout en
ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a juste
rien à faire ni au RIPE, ni à proposer un draft.

Juste ou j'aurais dû lire mieux ?

Julien

Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> Est-ce que c’est un troll ?
> 
> Dans le cas contraire, ce genre de propos est franchement indigne d’une ML 
> comme FRnOG…
>  
> Hugues
> AS57199 - AS50628
> 
>> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA  
>> wrote:
>>
>> Hello,
>>
>> Je ne connais pas ce fameux candidat mais au vu de la complexité d'adoption
>> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
>> intelligent et encourageant !
>>
>> A suivre...
>>
>> Bruno LEAL DE SOUSA
>> 06.01.23.45.96
>>
>> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a écrit :
>>
>>> Bonjour,
>>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
>>> est votre avis ?
>>> A bon entendeur.
>>> Christophe
>>>
>>> De : Elad Cohen 
>>> Envoyé : vendredi 8 mai 2020 00:06
>>> À : contact 
>>> Objet : Message important concernant les élections du RIPE
>>>
>>> Bonjour,
>>>
>>> Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du
>>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
>>>
>>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967
>>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
>>> RIPE, vous pouvez en savoir plus à ce sujet ici :
>>>
>>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
>>>
>>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
>>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
>>> Personne d'autre ne mettra en œuvre ma solution technique, je vous demande
>>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
>>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en œuvre.
>>>
>>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
>>> utilisant le lien suivant :
>>> https://www.ripe.net/s/gm-registration-may-2020
>>>
>>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
>>> veuillez envoyer un courrier électronique à a...@ripe.net>> a...@ripe.net>
>>>
>>> ---
>>>
>>> Outre la solution technique susmentionnée au problème de « l'épuisement de
>>> l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de
>>> mettre en œuvre si j'ai l'honneur d'être élu :
>>>
>>>
>>> Une solution technique au problème mondial du spam par courrier
>>> électronique :
>>>
>>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
>>>
>>> Une solution technique au problème mondial de l'amplification de
>>> l'usurpation du DDoS :
>>>
>>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html
>>>
>>> ---
>>>
>>> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE
>>> devienne :
>>>
>>> - Une organisation 100% transparente.
>>>
>>> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour
>>> chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la
>>> qualité du service reçu et marquer si la demande d'assistance a été résolue
>>> ou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra
>>> automatiquement la demande d'assistance). Chaque aspect du RIPE changera
>>> pour être centré sur le LIR et non sur la bureaucratie.
>>>
>>> Une organisation efficace en termes de dépenses de RIPE, je veillerai
>>> personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE
>>> soit une organisation efficace. Lorsque RIPE soit devenue une organisation
>>> efficace, les cotisations annuelles des membres de RIPE seront
>>> considérablement réduites.
>>>
>>> Je vous demande de vous inscrire pour le vote en ligne en utilisant le
>>> lien suivant :
>>> https://www.ripe.net/s/gm-registration-may-2020
>>>
>>> ---
>>>
>>> Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts,
>>> vous pouvez en voir l'exemple à travers les deux liens suivants :
>>>
>>>
>>> https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html
>>>
>>> Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration
>>> du RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de
>>> l'actuel président du conseil 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Hugues Voiturier]

Est-ce que c’est un troll ?

Dans le cas contraire, ce genre de propos est franchement indigne d’une ML 
comme FRnOG…
 
Hugues
AS57199 - AS50628

> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA  wrote:
> 
> Hello,
> 
> Je ne connais pas ce fameux candidat mais au vu de la complexité d'adoption
> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
> intelligent et encourageant !
> 
> A suivre...
> 
> Bruno LEAL DE SOUSA
> 06.01.23.45.96
> 
> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a écrit :
> 
>> Bonjour,
>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
>> est votre avis ?
>> A bon entendeur.
>> Christophe
>> 
>> De : Elad Cohen 
>> Envoyé : vendredi 8 mai 2020 00:06
>> À : contact 
>> Objet : Message important concernant les élections du RIPE
>> 
>> Bonjour,
>> 
>> Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du
>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
>> 
>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967
>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
>> RIPE, vous pouvez en savoir plus à ce sujet ici :
>> 
>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
>> 
>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
>> Personne d'autre ne mettra en œuvre ma solution technique, je vous demande
>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en œuvre.
>> 
>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
>> utilisant le lien suivant :
>> https://www.ripe.net/s/gm-registration-may-2020
>> 
>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
>> veuillez envoyer un courrier électronique à a...@ripe.net> a...@ripe.net>
>> 
>> ---
>> 
>> Outre la solution technique susmentionnée au problème de « l'épuisement de
>> l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de
>> mettre en œuvre si j'ai l'honneur d'être élu :
>> 
>> 
>> Une solution technique au problème mondial du spam par courrier
>> électronique :
>> 
>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
>> 
>> Une solution technique au problème mondial de l'amplification de
>> l'usurpation du DDoS :
>> 
>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html
>> 
>> ---
>> 
>> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE
>> devienne :
>> 
>> - Une organisation 100% transparente.
>> 
>> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour
>> chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la
>> qualité du service reçu et marquer si la demande d'assistance a été résolue
>> ou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra
>> automatiquement la demande d'assistance). Chaque aspect du RIPE changera
>> pour être centré sur le LIR et non sur la bureaucratie.
>> 
>> Une organisation efficace en termes de dépenses de RIPE, je veillerai
>> personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE
>> soit une organisation efficace. Lorsque RIPE soit devenue une organisation
>> efficace, les cotisations annuelles des membres de RIPE seront
>> considérablement réduites.
>> 
>> Je vous demande de vous inscrire pour le vote en ligne en utilisant le
>> lien suivant :
>> https://www.ripe.net/s/gm-registration-may-2020
>> 
>> ---
>> 
>> Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts,
>> vous pouvez en voir l'exemple à travers les deux liens suivants :
>> 
>> 
>> https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html
>> 
>> Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration
>> du RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de
>> l'actuel président du conseil d'administration du RIPE, Christian Kaufmann,
>> candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du
>> candidat : » vous pouvez voir que la ligne « Raison de la nomination du
>> candidat: » apparaît deux fois. Il y a une deuxième ligne « Raison de la
>> nomination du candidat : » juste après la première ligne « Raison de la
>> nomination du candidat: » parce que Maria a copié tout le paragraphe que
>> Christian lui a envoyé sur lui-même, Christian notre président du RIPE
>> trompe la communauté et il a écrit tout ce paragraphe sur lui-même et l'a
>> envoyé à Maria. Maria, notre membre actuel du Conseil d'administration, a
>> également trompé la communauté lorsqu'elle ne l'a même pas lu mais a fait
>> un copier-coller (y compris le titre) pour qu'on ait l'impression que cela
>> vient d'elle. Elle ne l'a même pas lu et n'a fait qu'un copier-coller avec
>> le titre. C'est pourquoi le titre « Raison de 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Bruno LEAL DE SOUSA]

Hello,

Je ne connais pas ce fameux candidat mais au vu de la complexité d'adoption
de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
intelligent et encourageant !

A suivre...

Bruno LEAL DE SOUSA
06.01.23.45.96

Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a écrit :

>  Bonjour,
> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
> est votre avis ?
> A bon entendeur.
> Christophe
>
> De : Elad Cohen 
> Envoyé : vendredi 8 mai 2020 00:06
> À : contact 
> Objet : Message important concernant les élections du RIPE
>
> Bonjour,
>
> Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du
> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
>
> J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967
> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
> RIPE, vous pouvez en savoir plus à ce sujet ici :
>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
>
> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
> Personne d'autre ne mettra en œuvre ma solution technique, je vous demande
> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en œuvre.
>
> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
> utilisant le lien suivant :
> https://www.ripe.net/s/gm-registration-may-2020
>
> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
> veuillez envoyer un courrier électronique à a...@ripe.net a...@ripe.net>
>
> ---
>
> Outre la solution technique susmentionnée au problème de « l'épuisement de
> l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de
> mettre en œuvre si j'ai l'honneur d'être élu :
>
>
> Une solution technique au problème mondial du spam par courrier
> électronique :
>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
>
> Une solution technique au problème mondial de l'amplification de
> l'usurpation du DDoS :
>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html
>
> ---
>
> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE
> devienne :
>
> - Une organisation 100% transparente.
>
> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour
> chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la
> qualité du service reçu et marquer si la demande d'assistance a été résolue
> ou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra
> automatiquement la demande d'assistance). Chaque aspect du RIPE changera
> pour être centré sur le LIR et non sur la bureaucratie.
>
> Une organisation efficace en termes de dépenses de RIPE, je veillerai
> personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE
> soit une organisation efficace. Lorsque RIPE soit devenue une organisation
> efficace, les cotisations annuelles des membres de RIPE seront
> considérablement réduites.
>
> Je vous demande de vous inscrire pour le vote en ligne en utilisant le
> lien suivant :
> https://www.ripe.net/s/gm-registration-may-2020
>
> ---
>
> Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts,
> vous pouvez en voir l'exemple à travers les deux liens suivants :
>
>
> https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html
>
> Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration
> du RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de
> l'actuel président du conseil d'administration du RIPE, Christian Kaufmann,
> candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du
> candidat : » vous pouvez voir que la ligne « Raison de la nomination du
> candidat: » apparaît deux fois. Il y a une deuxième ligne « Raison de la
> nomination du candidat : » juste après la première ligne « Raison de la
> nomination du candidat: » parce que Maria a copié tout le paragraphe que
> Christian lui a envoyé sur lui-même, Christian notre président du RIPE
> trompe la communauté et il a écrit tout ce paragraphe sur lui-même et l'a
> envoyé à Maria. Maria, notre membre actuel du Conseil d'administration, a
> également trompé la communauté lorsqu'elle ne l'a même pas lu mais a fait
> un copier-coller (y compris le titre) pour qu'on ait l'impression que cela
> vient d'elle. Elle ne l'a même pas lu et n'a fait qu'un copier-coller avec
> le titre. C'est pourquoi le titre « Raison de la nomination du candidat : »
> apparaît deux fois. Est-ce le genre de membres du conseil d'administration
> que vous voulez ? Voilà notre président actuel du conseil d'administration,
> Chrisitan Kaufmann, qui essaie d'être réélu et qui trompe la communauté ;
> voilà notre membre du conseil d'administration, Maria Hall, qui prend part
> à cette 

[FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[JCLB]

Il y'a des tentatives plus ou moins amusantes pour essayer d'échapper à 
l'inéluctable manque d'espace IPv4.

Ma préférée est l'EzIP 
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
On sent que le rédacteur y a mis son énergie... sans se préoccuper une seconde 
de sujets de couche 1 comme l'optimisation des ASICs pour router, quand on voit 
ce qu'il a été nécessaire de faire pour supporter VxLAN/Geneve il est facile 
d'imaginer la charge.

Par le passé il y'a eu la proposition d'utiliser la classe E IPv4 pour gagner 
du temps, 240.0.0.0/4
Ça serait le truc le plus plausible techniquement, et bien rien que ça les 
constructeurs ne sont pas chauds.
Ces mêmes constructeurs qui feraient bien de travailler à implémenter la 
rfc5838 permettant d'annoncer de l'IPv4 address family dans OSPFv3.

Ce monsieur dit "si je suis élu j'offrirais des masques, euh des IP 
gratuitement" c'est un ancien taxi ? il croit que la licence est payante, car 
les gars se la revendent entre eux ?

Je vais voir dès lundi pour faire participer au vote mon entreprise, après tout 
avec une cinquantaine de /16 il serait dommage de ne pas s'exprimer.


IP est mort, vive IP !

JC Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Christophe 
PLESSIS
Envoyé : vendredi 8 mai 2020 15:41
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les 
élections du RIPE

 Bonjour,
Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel est 
votre avis ?
A bon entendeur.
Christophe

De : Elad Cohen 
Envoyé : vendredi 8 mai 2020 00:06
À : contact 
Objet : Message important concernant les élections du RIPE

Bonjour,

Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du RIPE 
lors des prochaines élections, qui auront lieu le 13 de ce mois.

J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967 296 
adresses IPv4 pour les 5 registres Internet régionaux, y compris le RIPE, vous 
pouvez en savoir plus à ce sujet ici :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html

Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre RIPE 
recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu. Personne 
d'autre ne mettra en œuvre ma solution technique, je vous demande votre vote en 
ligne. Sans votre vote en ligne à la prochaine assemblée générale du RIPE, ma 
solution technique ci-dessus ne sera pas mise en œuvre.

Veuillez vous inscrire au vote en ligne pour les élections du RIPE en utilisant 
le lien suivant :
https://www.ripe.net/s/gm-registration-may-2020

Si vous rencontrez un problème pour vous inscrire au vote en ligne, veuillez 
envoyer un courrier électronique à a...@ripe.net<mailto:a...@ripe.net>

---

Outre la solution technique susmentionnée au problème de « l'épuisement de 
l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de 
mettre en œuvre si j'ai l'honneur d'être élu :


Une solution technique au problème mondial du spam par courrier électronique :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html

Une solution technique au problème mondial de l'amplification de l'usurpation 
du DDoS :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html

---

Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE devienne :

- Une organisation 100% transparente.

- Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour 
chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la 
qualité du service reçu et marquer si la demande d'assistance a été résolue ou 
non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra 
automatiquement la demande d'assistance). Chaque aspect du RIPE changera pour 
être centré sur le LIR et non sur la bureaucratie.

Une organisation efficace en termes de dépenses de RIPE, je veillerai 
personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE soit 
une organisation efficace. Lorsque RIPE soit devenue une organisation efficace, 
les cotisations annuelles des membres de RIPE seront considérablement réduites.

Je vous demande de vous inscrire pour le vote en ligne en utilisant le lien 
suivant :
https://www.ripe.net/s/gm-registration-may-2020

---

Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts, vous 
pouvez en voir l'exemple à travers les deux liens suivants :

https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html

Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration du 
RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de 
l'actuel président du conseil d'administration du RIPE, Christian Kaufmann, 
candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du 
candidat : » vous pouvez voir que la ligne « Raison de la nomination du 
candidat: » apparaît deux fois. Il 

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Refuznik]

Yep on connait il y a eut discussion ici
https://www.mail-archive.com/frnog@frnog.org/msg59822.html

Le ven. 8 mai 2020 à 15:53, Solarus  a écrit :

>
> Le 08/05/2020 à 15:41, Christophe PLESSIS a écrit :
> >   Bonjour,
> > Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
> est votre avis ?
> > A bon entendeur.
> > Christophe
> >
> J'en pense qu'un protocole pour augmenter le nombre d'adresses IP ça
> existe déjà et ça s'appelle IPv6.
> Bref, cette proposition est une vaste blague.
>
> Cordialement.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Solarus]

Le 08/05/2020 à 15:41, Christophe PLESSIS a écrit :

  Bonjour,
Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel est 
votre avis ?
A bon entendeur.
Christophe

J'en pense qu'un protocole pour augmenter le nombre d'adresses IP ça 
existe déjà et ça s'appelle IPv6.

Bref, cette proposition est une vaste blague.

Cordialement.


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

[FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Christophe PLESSIS]

 Bonjour,
Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel est 
votre avis ?
A bon entendeur.
Christophe

De : Elad Cohen 
Envoyé : vendredi 8 mai 2020 00:06
À : contact 
Objet : Message important concernant les élections du RIPE

Bonjour,

Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du RIPE 
lors des prochaines élections, qui auront lieu le 13 de ce mois.

J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967 296 
adresses IPv4 pour les 5 registres Internet régionaux, y compris le RIPE, vous 
pouvez en savoir plus à ce sujet ici :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html

Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre RIPE 
recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu. Personne 
d'autre ne mettra en œuvre ma solution technique, je vous demande votre vote en 
ligne. Sans votre vote en ligne à la prochaine assemblée générale du RIPE, ma 
solution technique ci-dessus ne sera pas mise en œuvre.

Veuillez vous inscrire au vote en ligne pour les élections du RIPE en utilisant 
le lien suivant :
https://www.ripe.net/s/gm-registration-may-2020

Si vous rencontrez un problème pour vous inscrire au vote en ligne, veuillez 
envoyer un courrier électronique à a...@ripe.net

---

Outre la solution technique susmentionnée au problème de « l'épuisement de 
l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de 
mettre en œuvre si j'ai l'honneur d'être élu :


Une solution technique au problème mondial du spam par courrier électronique :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html

Une solution technique au problème mondial de l'amplification de l'usurpation 
du DDoS :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html

---

Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE devienne :

- Une organisation 100% transparente.

- Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour 
chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la 
qualité du service reçu et marquer si la demande d'assistance a été résolue ou 
non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra 
automatiquement la demande d'assistance). Chaque aspect du RIPE changera pour 
être centré sur le LIR et non sur la bureaucratie.

Une organisation efficace en termes de dépenses de RIPE, je veillerai 
personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE soit 
une organisation efficace. Lorsque RIPE soit devenue une organisation efficace, 
les cotisations annuelles des membres de RIPE seront considérablement réduites.

Je vous demande de vous inscrire pour le vote en ligne en utilisant le lien 
suivant :
https://www.ripe.net/s/gm-registration-may-2020

---

Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts, vous 
pouvez en voir l'exemple à travers les deux liens suivants :

https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html

Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration du 
RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de 
l'actuel président du conseil d'administration du RIPE, Christian Kaufmann, 
candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du 
candidat : » vous pouvez voir que la ligne « Raison de la nomination du 
candidat: » apparaît deux fois. Il y a une deuxième ligne « Raison de la 
nomination du candidat : » juste après la première ligne « Raison de la 
nomination du candidat: » parce que Maria a copié tout le paragraphe que 
Christian lui a envoyé sur lui-même, Christian notre président du RIPE trompe 
la communauté et il a écrit tout ce paragraphe sur lui-même et l'a envoyé à 
Maria. Maria, notre membre actuel du Conseil d'administration, a également 
trompé la communauté lorsqu'elle ne l'a même pas lu mais a fait un 
copier-coller (y compris le titre) pour qu'on ait l'impression que cela vient 
d'elle. Elle ne l'a même pas lu et n'a fait qu'un copier-coller avec le titre. 
C'est pourquoi le titre « Raison de la nomination du candidat : » apparaît deux 
fois. Est-ce le genre de membres du conseil d'administration que vous voulez ? 
Voilà notre président actuel du conseil d'administration, Chrisitan Kaufmann, 
qui essaie d'être réélu et qui trompe la communauté ; voilà notre membre du 
conseil d'administration, Maria Hall, qui prend part à cette manipulation de la 
communauté avec lui. Ils essaient de se faire réélire de quelque manière que ce 
soit. S'ils trompent la communauté de cette manière, pouvons-nous leur faire 
confiance pour gérer les dépenses du RIPE d'environ 30 millions d'euros par an. 
Qui sait où vont ces dépenses alors que toute demande d'un membre du RIPE pour 
des informations détaillées sur les dépenses est redirigée de la direction du 
RIPE vers ces