Auteur Sujet: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?  (Lu 6652 fois)

0 Membres et 1 Invité sur ce sujet

buddy

  • Expert
  • Client Bbox fibre FTTH
  • *
  • Messages: 11 758
  • Alpes Maritimes (06)
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #36 le: 21 janvier 2020 à 13:32:57 »
Ils font exprès non ?
pour éviter que quelqu'un ne "porte plainte" car son IP "Perso" est passé à l'écran. Car dans toutes les séries, soient ce sont des IPs Locales soit ce sont des IPs qui n'existent pas.

Optix

  • AS41114 - Expert OrneTHD
  • Client Orne THD
  • *
  • Messages: 2 130
  • Strasbourg (67)
    • OrneTHD
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #37 le: 21 janvier 2020 à 13:34:37 »
Ils font exprès non ?
pour éviter que quelqu'un ne "porte plainte" car son IP "Perso" est passé à l'écran. Car dans toutes les séries, soient ce sont des IPs Locales soit ce sont des IPs qui n'existent pas.
Bien sûr.

C'est pareil pour les numéros de téléphone, avec le fameux "555" par ex.

DamienC

  • Client Bbox fibre FTTH
  • *
  • Messages: 2 231
  • FTTH 2G - Brest (29)
    • Damien CUEFF - Portfolio
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #38 le: 21 janvier 2020 à 14:17:26 »
Dans ce cas pourquoi ne pas mettre des IP stle 192.168.x.x...??

alarig

  • AS204092 Association Grifon
  • Expert
  • *
  • Messages: 94
    • SwordArMor
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #39 le: 21 janvier 2020 à 14:33:03 »
Ou même 240/4 ? :p (pour rester dans le sujet)

vivien

  • Administrateur
  • *
  • Messages: 36 202
    • Twitter LaFibre.info
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #40 le: 10 mai 2020 à 14:57:10 »
IPv4+ modification d'IPv4 pour ne plus avoir de pénurie d'IPv4

Traduction d'une discussion au RIPE : [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world

Message écrit par Elad Cohen, le samedi 25 avril 2020.

Il me semble que c'est humoristique, mais je me trompe peut-être : son IPv4 est pas si éloigné d'IPv6, a part que tout routeur qui n'a pas encore été mis à niveau vers IPv4+ ne provoquera pas de rupture du trafic IPv4, ce qui ne me semble pas réaliste.

Bonjour à tous,

Je veux partager avec vous ma solution technique au problème «d'épuisement IPv4» (sans mettre à niveau chaque routeur existant sur Internet), en utilisant l'implémentation ci-dessous, il y aura plus de 4 294 967 296 adresses IPv4 dont le monde a tant besoin:

Actuellement dans un paquet IPv4 - l'adresse source et l'adresse de destination sont représentées chacune par quatre octets, chacun de ces quatre octets étant affiché comme: [0-255]. [0-255]. [0-255]. [ 0-255]

Mais c'est à nous de choisir comment nous voulons les afficher, par exemple: quatre octets peuvent également être affichés sous la forme [0-65535]. [0-65535] (deux chiffres et un point, les deux chiffres sont plus grands car dans au total, ils sont également représentés par quatre octets)

Il peut donc y avoir un ensemble d'adresses IPv4 4 294 967 296 (celle que nous connaissons au format d'affichage [0-255]. [0-255]. [0-255]. [0-255])

et un autre ensemble d'adresses IPv4 4 294 967 296 (avec un nouveau format de [0-65535]. [0-65535])

Nous devons avoir une marque, un drapeau, dans l'en-tête du paquet ip - afin de savoir si l'adresse source est de l'ancien formatage (IPv4) ou du nouveau formatage (appelons-le IPv4+), pour cette marque, le 'réservé bit 'dans l'en-tête ip peut être utilisé, donc dans le cas où l'adresse source est IPv4+ ou dans le cas où l'adresse destination est IPv4+ (ou dans le cas où les adresses source et destination sont IPv4+), alors le bit réservé dans le l'en-tête ip sera défini sur 1, nous devons également savoir exactement si l'adresse source est IPv4+ ou non (signification IPv4) et si l'adresse de destination est IPv4+ ou non (signification IPv4) - cela peut être fait par marquer le drapeau DF si l'adresse source est IPv4+ (et ne pas marquer le drapeau DF si l'adresse source est IPv4) et marquer le drapeau MF si l'adresse de destination est IPv4+ (et ne pas marquer le drapeau MF si l'adresse de destination est de IPv4), en utilisant les bits DF et MF qui sont liés à la fragmentation (chaque fois que le bit réservé est mis à «1») nous perdons la fonctionnalité de fragmentation ip pour tout trafic avec une adresse IPv4+ (pour le trafic entre deux adresses IPv4, le bit réservé n'est pas défini sur «1» et donc la fonctionnalité facultative de fragment ip est inchangée)

Nous devons connaître le MTU avant qu'un paquet IPv4+ soit envoyé, car aucune fragmentation ne pourra être effectuée avec IPv4+, le "Path MTU Discovery" actuel (RFC 1191) n'est pas bon dans ce cas car il utilise le bit DF que nous utilisons également (et dans le trafic IPv4+, un indicateur DF défini sur 1 indique que l'adresse source est IPv4+), et le protocole ICMP peut également être bloqué par des routeurs dans le chemin de routage, la solution consiste à envoyer plusieurs demandes udp (avec des tailles MTU fixes connues) à l'adresse de destination (appelons-la IPv4+ poignée de main) - l'adresse de destination peut ou non les recevoir (dans le cas où un routeur dans le chemin de routage a plusieurs amonts et n'a pas été mis à niveau vers une version supérieure qui prend en charge IPv4+, il ne reconnaîtra pas le bit réservé et les bits DF et MF qui lui sont associés, il ne reconnaîtra pas les nouvelles adresses IPv4+ et même si le bit réservé est défini sur «1» et l'indicateur MF est défini sur «1» dans le paquet ip - il sera acheminé vers l'adresse de destination comme s'il s'agissait d'un I Adresse Pv4 et non adresse IPv4+, ce qui signifie une adresse de destination complètement différente) - dans le cas où l'adresse de destination a effectivement reçu les paquets IPv4+ - elle renverra les demandes udp à l'adresse source aux mêmes tailles exactes (avec l'indicateur de bit réservé défini à '1' et avec les drapeaux DF et MF définis en conséquence) - lorsque l'adresse source les recevra - l'adresse source saura que l'adresse de destination prend en charge IPv4+, que les paquets ip avec un nouveau format IPv4+ atteindront la destination et la source l'adresse saura quelle est la plus grande taille de la demande udp qui a été reçue - et ce sera le MTU pour cette connexion spécifique entre la source et les adresses de destination (la prise de contact IPv4+ sera refaite s'il n'y a pas de réponse de la destination après la prise de contact initiale udp s'est déjà terminée avec succès).

La négociation udp entre une adresse source et une adresse de destination (que l'une d'entre elles ou les deux est une adresse IPv4+) utilisera un port udp spécifique, un port non attribué disponible entre 0 et 1023, une pile de mise en réseau du système d'exploitation (qui a été mise à jour pour IPv4+ avec le système de mise à jour automatique du système d'exploitation) saura exactement à quoi sert ce port udp - et réagira en conséquence, la pile de mise en réseau du système d'exploitation mise à niveau vérifiera également que l'adresse de destination (dans le format IPv4 ou IPv4+) est définie localement dans le système d'exploitation, avant de renvoyer les demandes udp à l'adresse source (sinon, le paquet ip sera abandonné par la pile de mise en réseau du système d'exploitation mise à niveau). Tout système d'exploitation qui n'a pas été mis à niveau pour prendre en charge IPv4+ - supprimera simplement ce type de demandes udp.

IPv4+ est entièrement rétrocompatible avec IPv4 (et tout routeur qui n'a pas encore été mis à niveau vers IPv4+ ne provoquera pas de rupture du trafic IPv4), il n'ajoute pas non plus de nouveaux champs aux paquets IP ou n'utilise pas de nouveaux champs, IPv4+ n'entraînera aucune surcharge de performances pour tout routeur pris en charge.

La raison pour laquelle les bits MF et DF sont utilisés pour IPv4+ et non les ToS / IP-ID / Options dans l'en-tête ip sont utilisés parce que nous ne pouvons pas être sûrs à 100% que le ToS / IP-ID / Options dans l'en-tête ip ne sera pas modifié ou abandonné par un rouer dans le chemin de routage qui n'a pas été mis à niveau vers IPv4+ (et nous ne voulons pas mettre à niveau un routeur dans le monde car c'est une mission impossible) - dans l'en-tête ip ToS est effacé par certains routeurs - L'ID IP peut être modifié par les routeurs NAT - Le champ Options est supprimé par de nombreux routeurs, nous pouvons être sûrs que les drapeaux DF et MF ne seront pas modifiés dans le chemin de routage par des routeurs qui n'ont pas été mis à niveau vers IPv4+.

Pour la solution ci-dessus, tous les appareils Internet dans le monde n'ont pas besoin d'être corrigés / mis à niveau pour prendre en charge IPv4+, ce qui est une mission impossible, les systèmes d'exploitation des utilisateurs finaux doivent être mis à niveau (mais cela peut être fait simplement en utilisant leur système de mise à jour automatique), Les routeurs BGP (et tout routeur avec plusieurs chemins de routage physiques) devront avoir son firmware mis à niveau pour prendre en charge IPv4+, tout routeur NAT qui voudra utiliser une adresse IPv4+ externe devra avoir son firmware mis à niveau (tout routeur NAT qui utilisera un L'adresse IPv4 externe n'aura pas besoin d'avoir son micrologiciel mis à niveau, seuls les appareils Internet dans le LAN du routeur NAT devront avoir une seule mise à jour du système d'exploitation pour pouvoir accéder aux adresses IPv4+ sur Internet), tout routeur domestique (pas NAT) ou modem domestique n'auront pas besoin de mise à niveau du firmware et la fonctionnalité IPv4+ leur sera transparente.

Le déploiement d'IPv4+ peut être assez facile et très rapide, une table ronde d'une personne de chacun des 5 RIR et de chacun des fournisseurs de systèmes d'exploitation et de chacun des fournisseurs de fabricants de routeurs. Même si IPv4+ sera déployé au fil du temps, il ne provoquera pas de rupture d'Internet (les appareils qui doivent être mis à niveau vers IPv4+ et qui ne fonctionnent pas encore exactement comme ils le sont maintenant avec IPv4, ils ne prendront tout simplement pas encore en charge IPv4+).

Ce qui précède résoudra le problème de «l'épuisement IPv4» et apportera à chacun des 5 RIR près de 900 000 000 de nouvelles adresses IPv4+ qui pourront être fournies aux LIR dans le monde entier, si vous avez des questions, faites-le moi savoir.

Avec respect,
Elad


Source : RIPE Membership Mailing Lists

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 8 360
  • Paris (19ème)
    • Twitter
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #41 le: 10 mai 2020 à 15:09:17 »
Vivien,

Elad est très sérieux dans son raisonnement, il agresse tous ceux qui sont contre lui, et il est *candidat* au Board du RIPE.
Je vais copier coller la réponse de Johann sur FRnOG parce qu'il est hors de question de laisser ce genre de bêtises sur ce forum sans débunk :


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à parce-que beaucoup d'équipements actif sur internet ne reçoivent 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 sont construit pour IPv4 et IPv6.
La moindre modification demanderait de réécrire le firmware hardware, voir un changement d'ASIC (dur de s'avancer sans la vision constructeur).

5) En plus, il occulte totalement la partie intégration des ces "nouvelles IPs" dans la table de routage. Aucun volet technique n'est présent à ce sujet.
Comment l'équipement doit le gérer? Ça a une influence sur la RIB et la FIB de chaque routeur et donc le comportement des ASIC.
Pourtant, un paquet sont but c'est d'être forwarder vers son destinataire, oublier cette partie est un peu étonnant.

6) On ne parle pas non plus de l'intégration de ces nouvelles IPs dans le protocole BGP. J'imagine qu'il faudra une nouvelle AFI?
Puis comment on les forwards sur les interconnexions? Il faudra sans doute rajouter une IPv4+ sur les intercos opérateurs?
Ou ca sera "compatible" via IPv4 classique?  La encore, aucune information, aucune étude et aucun PoC...

D'ailleurs, si un paquet IPv4+ passe par un routeur IPv4 non mis à jour, il sera router vers la mauvaise adresses IP legacy correspondante.
Ça sera assez cocasse quand même, surtout avec de l'UDP. Ça va donner de nouvelle manière de DDoS intéressante :-)

6.5) On ne parle pas du toute de l'intégration de BGP, mais pas non plus des IGP. Quid de OSPF, ISIS, EIGRP? Ce sont des protocoles indépendants et qui devront aussi recevoir une mise à jour, sinon ca ne marchera pas.
Et je ne suis pas certain que beaucoup soit chaud pour pousser en production un patch "tout frais" de leur IGP, au risque de vautré leur réseau.

7) Il n'a aucune idée de commence marche un process de mise à jour d'un opérateur Ce n'est pas une mise à jour automatique avec deux clique dans une UI. On choisi une version cible, on la test en lab, on la valide, on peut faire des bugfix avec le constructeur.
Une fois la validation effectuée, on déploie la nouvelle version progressivement sur l'ensemble du backbone, souvent sur plusieurs long mois. Chez un opérateur, on évite de faire des mises à jours tout les mois de nos équipements.

8 ) Il faudra que l'ensemble des OS, de systèmes de sécurités et box opérateurs soient mise à jour (en oubliant volontairement la partie opérateur)
Si un seul équipement actif (NAT, comme sur une box domestique) ou l'OS n'est pas à jour, ca ne marchera pas correctement. D'ailleurs, il faudra aussi que l'ensemble des équipements de sécurité, type firewall, IDS et IPS soit mise à jour.

9) Il oublie totalement la partie logiciel qui utilise internet C'est bien beau de mettre à jour l'OS... mais il oublie qu'il faut que les applications soient mise à jour pour être rendu compatible. On ne rend pas compatible une application en mettant à jour l'OS. Il faut la rendre compatible avec le nouveau format d'IP et tout ce que cela implique.

10) Il oublie totalement la partie "3rd"/dépendance J'imagine qu'on voudra mettre des nom de domaine sur ces nouvelles IPs. Du coup, il faudra aussi mettre à jour les serveurs DNS pour les prendre en charge avec un nouveau type d'enregistrement. Cela rajoute une couche et un délai.

10) Il oublie totalement la partie humain Je ne crois pas une seconde que tout les DSI/RSI du monde seront d'accord sans la moindre question ou étude avant

11) Ca va encore ralentir l'adaptation d'IPv6 bordel de merde.

Et j'imagine que j'oublie sans doute des choses.

Je suis désolé pour ceux qui ont vu la belle promesse électorale de Elad. Mais clairement, l'idée aurait été intéressante il y a 20 ou 25 ans, maintenant on a IPv6 qui a passé l'ensemble des points bloquants.

Et contrairement à ce Elad raconte, non IPv6 n'est pas <5-10% des connexions, cela augmente chaque année et d'après Google 30% des connexions seraient compatible. D'après les courbes de Google, cela grossit de 5% par année. Donc si la tendance se poursuit, on dépassera les 50% avant 2025.


kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 7 370
  • FTTH 1Gb/s sur Paris (75)
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #42 le: 10 mai 2020 à 15:20:31 »
C'est pas lui qui était impliqué dans une histoire de fraude/vol de blocks d'IPv4 a une époque ?
Et je crois que son sujet 'IPv4+' est tag spam sur la ML du Ripe.

la meilleur réponse: https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003732.html

Citer
Elad, this is your avenue: you need to demonstrate two working and
interoperating implementations for two host stacks and two router stacks.

Just claming "it is easy" is not sufficient.


et il se fait allumer ici: https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003733.html

Citer
There is no talking sense into this person. He is oblivious to how the internet works and how hardware and software upgrades are implemented and deployed. Obviously pointing out his flaws means I have an illegal interest somehow.

I think Elad has already tried following Trump's recent advice and we are seeing the consequences…

Time to move on…
Sander

vivien

  • Administrateur
  • *
  • Messages: 36 202
    • Twitter LaFibre.info
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #43 le: 10 mai 2020 à 15:20:39 »
Donc c'est vraiment écrit sérieusement où c'est un message humoristique (genre 1er avril en retard) ?

Il semble évident qu'une petite mise à jour automatique sur des équipements réseaux critique, c'est impossible.

lechercheur123

  • Client Orange Fibre
  • *
  • Messages: 1 066
  • Montauban (82)
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #44 le: 10 mai 2020 à 15:44:10 »
Donc c'est vraiment écrit sérieusement où c'est un message humoristique (genre 1er avril en retard) ?

Le mec est très sérieux :

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

On peut le voir raconter les mêmes idioties histoires dans sa candidature pour le board du RIPE

vivien

  • Administrateur
  • *
  • Messages: 36 202
    • Twitter LaFibre.info
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #45 le: 10 mai 2020 à 17:17:03 »
C'est chaud que cela soit à ce niveau.

Cela me rappelle une présentation que j'ai fait sur l'IPv6, dans une entreprise ou le busness de base est l'IPv4 (je reste flou volontairement pour que l'on ne puisse pas identifier l'entreprise en question). Dés le début, le plus haut dirigeant, m'interrompt et me demande : "mais au fait c'est quoi une adresse IP ?" (Tout de suite son staff technique a volé à son secours, mais cela m'a fait drôle)

Steph

  • Client K-Net
  • *
  • Messages: 1 934
  • La Balme de Sillingy 74
    • Uptime K-net
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #46 le: 10 mai 2020 à 17:22:02 »
Cela me rappelle une présentation que j'ai fait sur l'IPv6, dans une entreprise ou le busness de base est l'IPv4 (je reste flou volontairement pour que l'on ne puisse pas identifier l'entreprise en question). Dés le début, le plus haut dirigeant, m'interrompt et me demande : "mais au fait c'est quoi une adresse IP ?" (Tout de suite son staff technique a volé à son secours, mais cela m'a fait drôle)
Avec l'hopital public en France, on a la même blague en remplaçant "adresse IP" par "masque"...

alarig

  • AS204092 Association Grifon
  • Expert
  • *
  • Messages: 94
    • SwordArMor
Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
« Réponse #47 le: 10 mai 2020 à 23:46:06 »
Donc c'est vraiment écrit sérieusement où c'est un message humoristique (genre 1er avril en retard) ?

Il semble évident qu'une petite mise à jour automatique sur des équipements réseaux critique, c'est impossible.

Oui oui oui, il spamme même les LIRs en promettant monts et merveilles pour recevoir des votes.

 

Mobile View