La Fibre

Télécom => Réseau => reseau IPv6 => Discussion démarrée par: vivien le 06 avril 2018 à 13:59:08

Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 06 avril 2018 à 13:59:08
On parle de l'arrivé de nouvelles IPv4 : 240.0.0.0/4

C'est un bloc de 268 435 456 IPv4 (de 240.0.0.0 a 255.255.255.255)

Poisson d'avril ? Cela me semble arriver tardivement. Cela fait un petit moment que les réserves d'IPv4 sont vides chez certains RIR (Regional Internet Registries).


La RFC6890 (https://tools.ietf.org/html/rfc6890) définit le pool 240.0.0.0/4 :
                 +----------------------+----------------------+
                 | Attribute            | Value                |
                 +----------------------+----------------------+
                 | Address Block        | 240.0.0.0/4          |
                 | Name                 | Reserved             |
                 | RFC                  | [RFC1112], Section 4 |
                 | Allocation Date      | August 1989          |
                 | Termination Date     | N/A                  |
                 | Source               | False                |
                 | Destination          | False                |
                 | Forwardable          | False                |
                 | Global               | False                |
                 | Reserved-by-Protocol | True                 |
                 +----------------------+----------------------+


Il y aurait donc de nombreux équipements qui bloquent ces plages IP...

Source : Twitter @Solarus0

Sinon vous avez la liste fort bien les plages IP réservées : https://en.wikipedia.org/wiki/Reserved_IP_addresses
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: doctorrock le 06 avril 2018 à 14:39:00
Ce sent le poisson non ?
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: turold le 06 avril 2018 à 16:57:06
Ce sent le poisson non ?
Je ne sais pas.
C'est pour ça que je suis contre tout changement un 1er avril, dans ce monde qui ne croit plus en grand chose.
Il y en a beaucoup qui pensent que le cloudfare DNS est un poisson... pourtant non.

Pour revenir au rfc6890, il est mise à jour (mais ne remplace pas) par la rfc8190: https://tools.ietf.org/html/rfc8190
rfc6890 ne s'occupe plus que du block 192.0.0.0/24 ...Voir dans le lien du rfc dans le 1er message du sujet.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 07 avril 2018 à 15:28:19
Bon, c'était une blague...

Oh mon dieu c'était une blague, je suis désolé que tu l'ait pris au sérieux. ;)

L'attribution du 240.0.0.0/4 n'est pas impossible mais elle est très compliquée, notamment parce ce que TOUS les Windows bloquent cette plage en dur dans leur code.


Source : Twitter de Solarus0 (https://twitter.com/Solarus0/status/982545083286343680)


Cette arrivée de centaines de milliers d'IPv4 aurait été un message bien négatif pour la migration vers IPv6, permettant a ceux qui sont sceptique sur une pénurie d'IPv4 de reprendre de la vigueur.
Il est vrai que plus les années passent, plus on arrive a économiser les IP...

Il est loin le temps où les PC en entreprise avaient directement une IPv4 publique...
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:17:27
A quoi reconnaît-on la pénurie d'IPv4 ?
Aux idées loufoques pour en créer de nouvelles.


On reparle d'utiliser les IPv4 240.0.0.0/4 : (présentation à la Netdevconf, le 21 mars 2019)

(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions_5.png)

Et pas que 240.0.0.0/4, mais aussi tout ce qui est réservé :


(https://lafibre.info/images/ipv6/201909_ipv4_reducing_127.png)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:18:43
Un hurluberlu de plus ?

Cette fois ci ce n'est plus un poisson !


Le noyau Linux 5.3 vient de sortir et il y a du nouveau pour IPv4 :

Quelques millions de nouvelles adresses IPv4

Cette version contient un changement trivial, mais impactant: la plage 0.0.0.0/8 IPv4 sera acceptée par Linux (bien qu'elle ne soit pas déclarée comme telle dans les normes) en tant que plage d'adresses valides, autorisant 16 millions de nouvelles adresses IPv4.

L'espace d'adressage IPv4 comprend des centaines de millions d'adresses réservées pour des raisons obscures, obsolètes ou pour une "utilisation future". Au lieu de laisser ces adresses IP inutilisées, un projet de nettoyage IPv4 (https://github.com/dtaht/unicast-extensions) a été lancé pour les rendre utilisables, de manière générale. Pour plus de détails, voir cette discussion sur les extensions potentielles de IPv4 Unicast (https://netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions).


Source : Note de version de Linux 5.3 (https://kernelnewbies.org/Linux_5.3) (que j'ai traduit rapidement)

(https://lafibre.info/images/ipv6/201909_ipv4_accept_0.png)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:19:45
La présentation à la Netdevconf, le 21 mars 2019 :

https://www.youtube.com/watch?v=92aNK3ftz6M

Les slides : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions.png) (https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions.pdf)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:23:58
Je ne suis pas du tout en phase : avec le premier slide.

On déploie IPv6 par pour mettre un nouveau protocole à coté d'IPv4, pour tout superviser en double, pour tout configurer en double.

Non, on déploie IPv6 pour remplacer IPv4 !

Pendant encore 15 à 20 ans IPv4 restera présent, mais on va finir par éteindre complètement IPv4, tout comme on a tué SSL 2.0 et SSL 3.0 (et bientôt TLS 1.0 et TLS 1.1).

Le premier slide :
(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions_1.png)

Le second :

(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions_2.png)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:24:35
Les propositions :

(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions_4.png)

(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions_5.png)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:28:47
Pourquoi c'est irréaliste comme proposition ?

Tout simplement car il faut tout mettre à jour pour ces modifications : Sur les slides il suffit de 5-7 ans pour que tous les PC aient un système d'exploitation compatible, que les logiciels et les routeurs soient compatibles.

Je rappelle qu'à la sortie d'IPv6, on pensais que tout serait réglé en 3-4ans.
Le meilleur moyen d'avoir plus d'IP, c'est de passer à IPv6, pas de patcher IPv4. Il est évident que dans 20 ans il y aura encore des équipements non compatibles avec ces patch IPv4, tout comme c'est le cas aujourd'hui pour IPv6, alors que cela fait plus de 20 ans qu'IPv6 est pris en charge par Linux.


(https://lafibre.info/images/ipv6/201903_netdevconf_ipv4_unicast_extensions_3.png)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: renaud07 le 17 septembre 2019 à 21:33:48
Tout va très bien madame la marquise  ;D

 :o

Citer
Le meilleur moyen d'avoir plus d'IP, c'est de passer à IPv6, pas de patcher IPv4.

Pour le coup je suis entièrement d'accord, au lieu de s’acharner sur ipv4 autant consacrer cette énergie à déployer l'ipv6 pour de bon. Ça en finira jamais sinon.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:37:37
Aller, je fouille mes archives, ou plutôt celles de l'Arcep :

Combien d'année pour terminer la transition d'IPv4 vers IPv6, selon l'Idate ? (document de juin 2002)

Bref, je vois que l'Idate a les mêmes prévisions en nombre d'années que le M. pour ses patch IPv4 qu'il propose en 2019.

(https://lafibre.info/images/ipv6/200206_idate_etude_ipv6_1.png)

Le document de 155 pages de 2002, commandé par l'ART, aujourd'hui Arcep :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ipv6/200206_idate_etude_ipv6.png) (https://lafibre.info/images/ipv6/200206_idate_etude_ipv6.pdf)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 17 septembre 2019 à 21:44:33
Je vais citer Pierre Beyssac (@pbeyssac (https://twitter.com/pbeyssac/)) :
- Des gens ont un poil dans la main tellement énorme pour ne pas passer à #IPv6 qu'ils proposent d'utiliser en adresses publiques des morceaux de 127.0.0.0/8
- totalement impraticable. Revient à tenter de boucher la voie d'eau sur le Titanic.

Bref, il est encore un peu tôt pour en parler, ce sont des choses que l'on évoque plus quand 80% de connexions Internet et 80% des sites web seront en IPv6 : pour finir la transition et éteindre IPv4, il va être nécessaire de frapper du point sur la table.

Ce sera Google ?
Le BEREC ?

Il y a plusieurs possibilités, mais ce sera nécessaire.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: thenico le 17 septembre 2019 à 22:28:45
Ce n'est pas irréaliste d'imaginer avoir 3/4 d'Internet patché d'ici 4-5 ans.
Qu'est-ce qui est concerné par ces patchs: les clients (ordinateurs, smartphone, tablet) et les routeurs.

La plupart des routeurs auront été au minimum patché et plus probablement remplacé d'ici 5 ans.
Pour les clients:
* Windows est en mode SaaS depuis Windows 10; 6 mois pour un nouveau kernel; 3 ans plus tard une LTSB sort.
* macOS et iOS bouge encore plus vite
* Android sera mis à jour par le remplacement des terminaux

Il restera 1/4 d'Internet non patché qui patcherons quand ils seront bloqué quelque part.
C'est la même chose qui tue actuellement les Windows 2008 R2 et SQL Server 2008 chez les avocats :)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: xillibit le 17 septembre 2019 à 22:46:59
ça serait marrant de bloquer dans les pare-feux les adresses de la class e
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 18 septembre 2019 à 08:08:40
Je rappelle que la Freebox v5 a été lancée le 19 avril 2006 et elle est toujours en vente aujourd'hui en 2019 (sous le nom Freebox Crystal)

Ok il suffit d'une mise à jour, mais cette box comme de nombreuses box sur la marché ne sont plus maintenues...

Vous pensez qu'un entreprise remplace ses pare-feux et autres équipements réseau tous les 5 ans ? Non !

Bref, la difficulté est presque comme pour IPv6.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: tomfibre le 18 septembre 2019 à 08:17:32
Mais je me pose une question, pourquoi cette plage d'ip réservée n'avait jamais été attribuée? Pourquoi ne pas les avoir utilisée comme ip depuis le début comme les autres?
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: buddy le 18 septembre 2019 à 08:27:58
Même si l'on met à jour tous les équipements (disons dans 5 ans) au final on aura vécu pendant 5 ans sans ip v4 disponibles.. Donc on pourrait aussi vivre 10 ou 100 ans sans nouvelles ip v4 dispo non ?
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Optix le 18 septembre 2019 à 08:51:08
En même temps qui veut des plages IP dont la moitié du globe ne pourra pas joindre ?

Déjà qu'il y a encore pas mal de bestiaux qui ont du mal avec 1.1.1.1...
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: renaud07 le 18 septembre 2019 à 16:22:40
Déjà qu'il y a encore pas mal de bestiaux qui ont du mal avec 1.1.1.1...

#Livebox  ;D
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Thornhill le 18 septembre 2019 à 16:43:38
Mais je me pose une question, pourquoi cette plage d'ip réservée n'avait jamais été attribuée? Pourquoi ne pas les avoir utilisée comme ip depuis le début comme les autres?

Dans tous les protocoles IETF, il y a toujours un espace 'reserved for future use'.
Ca fait partie des bonnes pratiques de prévoir des bits/octets pour des usages/fonctions auxquels on n'a pas encore pensé.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 18 septembre 2019 à 17:57:38
Il est difficile d'utiliser les plages réservées ou de changer la destination d'une plage déjà attribuée (comme par exemple 127.0.0.0/8 ou les pages multticast) car les équipements sont configurées par défaut pour les rejeter pour un usage unicast.

Il faut donc changer tous les logiciels, comme ce que viens de faire Linux pou la plage 0.0.0.0/8.

La problématique, c'est que cela va mettre plus de 15 ans pour avoir 99% du parc qui supporte la fonction.

Si un jour la plage 0.0.0.0/8 sera utilisée pour des IP publique, on va être confronté à des entreprises qui l'utilisent comme une plage IP privée en complèment de 10.0.0.0/8 qui est saturé chez de nombreuses entreprises, car si Linux le support maintenant, ils ne demandent pas de ne pas l'utiliser pour la réserver pour des IP publiques.

Bref, je ne crois pas qu'il y aura un jour des IP publiques en 0.0.0.0/8, mais cela probablement utilisé comme IP privées sur un réseau maitrisé (pas pour les clients d'un FAI)

Récapitulatif des plages d'IP privées :
- 10.0.0.0/8 (10.0.0.0 – 10.255.255.255) - RFC 1918
- 100.64.0.0/10 (100.64.0.0 - 100.127.255.255) -  RFC 6598
- 172.16.0.0/12 (172.16.0.0 – 172.31.255.255) - RFC 1918
- 192.168.0.0/16 (192.168.0.0 – 192.168.255.255) - RFC 1918
- fd00::/8  - RFC 4193

Plages IP pour le Link-local :
- 169.254.0.0/16 sans le premier et dernier /24 (169.254.1.0 to 169.254.254.255) -  RFC 6890 et RFC 3927
- fe80::/10 - RFC 4862
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Ilyazam le 21 septembre 2019 à 11:00:41
Ça serait plus de boulot de réutiliser des plages réservées en mettant tout à jour plutôt que de déployer IPv6  :)
Et les plages réutilisables ne sont  pas normalisés contrairement à IPv6 donc on risque d'avoir pas mal de problèmes d'intéropérabilité.
Un peu comme à l'époque de la suppression des classes A/B/C avec le découpage de longueur variable (la commande  ip subnet-zero chez cisco)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 21 septembre 2019 à 11:05:12
Ilyazam, je pense que tu as tout à fait raison.

Il est possible de normaliser ces plages, mais comme pour la normalisation d'IPv6, cela met du temps à être mis en place dans tous les équipements.

Donc je pense plus crédible que ces plages seront utilisées comme IP privées sur un parc maîtrisé ou on sait que tous les équipements sont compatibles.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: raf le 21 septembre 2019 à 11:54:17
La plupart des routeurs auront été au minimum patché et plus probablement remplacé d'ici 5 ans.
Non. Les routeurs (les vrais, ceux dans les reseaux operateur et entreprise, pas le petits CPE) font partie des equipements les moins mises a jour. Le "dump and forget" (installe et oublie a tout jamais) est plus ou moins la regle avec les equipements reseau. Il y en a d'ailleurs encore qui utilisent du 7200VXR ou Cat6500, les deux avec du IOS 12 (non, pas celui d'Apple, celui du Cisco, qui est a la retraite depuis au moins 7 ans).

Pour les CPE (les "routeurs domestiques"), ca peut etre un peu different. Mais un client qui a son acces depuis 5 ans sana avoir rien demande, le FAI ne va pas lui changer le box juste pour le fun.

Il restera 1/4 d'Internet non patché qui patcherons quand ils seront bloqué quelque part.
Cet 1/4 de l'internet va justement etre la partie qui fait que l'internet existe (la partie "backbone", habituellement pas tres visible). Si cette partie ne se met pas totalement a jour, il n'y aura pas des nouveaux blocs d'IP publiques.

Le chose le plus probable avec ces blocs sera leur utilisation en tant qu'adresses prives, en complement de RFC1918 (peut-etre meme du RFC6598). Mais ca ne risque pas d'aller plus loin que ca.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: alarig le 27 septembre 2019 à 23:46:38
Il est possible de normaliser ces plages, mais comme pour la normalisation d'IPv6, cela met du temps à être mis en place dans tous les équipements.

Donc je pense plus crédible que ces plages seront utilisées comme IP privées sur un parc maîtrisé ou on sait que tous les équipements sont compatibles.

Actuellement, la tendance est plus à freezer toute évolution de l’IPv4 : https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00 (bon, c’est toujours un draft depuis 2 ans, certes…)
Mais du coup, je pense que la normalisation de nouveaux ranges IPv4 va prendre beaucoup de temps, en effet.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Paul le 28 septembre 2019 à 04:05:05
Ça ne sert tellement à rien, en supposant que toutes les IPv4 deviennent utilisables, ça ne fera toujours que 4,3 milliards d'adresses disponibles, or ça fait des années et des années qu'on en a besoin de bien plus.

En gros, même si on libère quelques addresses, ça ne permettra jamais de bénéficier de LA killer feature d'IPv6, à savoir supprimer le besoin de NAT. Et on rame tellement pour héberger des trucs chez soi que plus vite IPv4 se casse, mieux c'est.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: JCLB le 30 septembre 2019 à 11:35:56
Pour avoir fait poser la question à 2 BU Cisco par des collègues la semaine dernière
Réponse:
Citer
C'est une plage réservée, nous ne la supportons pas
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 09 janvier 2020 à 21:30:05
Autre solution pour garder plus longtemps des IPv4 (extrait d'un film) :

(https://lafibre.info/images/ipv6/202001_nouvelles_ipv4.png)

Il suffit de quelques patches... et de quelques dizaines d'années le temps que tous les équipements implémentent ces patchs.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: hoyohoyo le 10 janvier 2020 à 10:57:57
Je me suis toujours posé la question, pourquoi ne pas voir fait un V4.1  ;D   pour dépasser 255.255.255.255 du genre un 999.999.999.999, car c'est bien beau l'ipv6, mais bon c bien bien simple faire un 10.10.10.2 que faire un 2001:610:240:22::c100:68b ^^ 
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: FloBaoti le 10 janvier 2020 à 11:07:17
Je me suis toujours posé la question, pourquoi ne pas voir fait un V4.1  ;D   pour dépasser 255.255.255.255 du genre un 999.999.999.999, car c'est bien beau l'ipv6, mais bon c bien bien simple faire un 10.10.10.2 que faire un 2001:610:240:22::c100:68b ^^
Avec ta version tu passes d'une adresse sur 32 bits à une adresse sur 40 bits. Ce n'est pas vraiment utile, tu ne repousse pas vraiment la limite. Autant passer à beaucoup plus (128 bits en IPv6).
Et donc on opte pour une notation en base 16 plutôt que base 10 pour écrire moins d'éléments.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Johannol le 10 janvier 2020 à 11:27:31
Il y aurait eu rupture dans tous les cas (ton 255, c'est un octet, si tu montes à 999, tu passes à autre chose). Donc c'était dans tous les cas un ipv6 avec rupture.

Par contre, les gas qui ont pondu IPv6 ont largement surestimé la capacité de changement du reste du monde en pondant un truc totalement différent et avec un planning de 10ans avant suppression totale d'IPv4. La lenteur de (non) adoption d'IPv6 est un symptôme, les fonctionnalités d'IPv6 toujours mal implémenté dans équipements une autre, et la masse d'informaticien qui n'y comprennent toujours rien en 2020 encore une autre.

Je crois qu'on aurait eu un IPv6 calqué sur IPv4 avec juste un gros changement de longueur d'adresse, avec reprise/mapping des adresses IPV4, et la suppression des NAT, on n'aurait pas évité  la dual-stack temporaire, mais y serait peut-être déjà.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 10 janvier 2020 à 14:13:29
Oui, il y a de grosses erreurs dans l'informatique (on pourrait citer la limitation à 640Ko de mémoire sous DOS qui demandait une usine a gaz pour être légèrement contourné) et l'IPv6 fait parti des choses qui n'ont pas été bien mises en place. Le RIPE aurait pu imposer d'avoir un IPv6 en prod et activé pour distribuer des IPv4 quand il en avait par exemple.

Ce qui est compliqué, c'est que dans la plupart des pays, il n'y personne de légitime pour pousser IPv6 ou faire des statistiques sur le déploiement. Cela rentre dans le champ de l'Arcep, mais pas des autres régulateurs européens.

Maintenant on peut être positif et quand on voit comment se passe les interconnexions voix avec des facturation de demi-connexion, heureusement que Internet a échappé à ça. On a aussi échappé a un internet propriétaire. En 1993, beaucoup de sociétés voulaient remplacer Internet par leur intranet (AOL, MSN,...). On a ensuite échappé à un web qui ne respecte aucune norme et qui ne fonctionne que dans des logiciels propriétaire (coucou Internet Explorer).

Aujourd'hui beaucoup de choses sont ouvertes, mais cela pourrait être propriétaire (un monde a la Apple avec quelques concurrents et rien qui ne fonctionne entre deux marques).
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: FloBaoti le 11 janvier 2020 à 11:43:13
Il y aurait eu rupture dans tous les cas (ton 255, c'est un octet, si tu montes à 999, tu passes à autre chose). Donc c'était dans tous les cas un ipv6 avec rupture.

Par contre, les gas qui ont pondu IPv6 ont largement surestimé la capacité de changement du reste du monde en pondant un truc totalement différent et avec un planning de 10ans avant suppression totale d'IPv4. La lenteur de (non) adoption d'IPv6 est un symptôme, les fonctionnalités d'IPv6 toujours mal implémenté dans équipements une autre, et la masse d'informaticien qui n'y comprennent toujours rien en 2020 encore une autre.

Je crois qu'on aurait eu un IPv6 calqué sur IPv4 avec juste un gros changement de longueur d'adresse, avec reprise/mapping des adresses IPV4, et la suppression des NAT, on n'aurait pas évité  la dual-stack temporaire, mais y serait peut-être déjà.

Planning de 10 ans ? C'est écrit où ça ? IPv6 c'est 1998.
Quand on y comprend rien, on se forme. Un informaticien qui a débuté sa carrière il y a 15 ans ne connaissait pas la virtualisation, aujourd'hui on ne peut plus s'en passer, etc...

Calqué sur IPv4 c'est à dire ? Ca reste du réseau, les principes sont exactement les mêmes. IPv6 simplifie énormement de choses par rapport à IPv4. La plupart des gens ont "peur" de la notation en hexa, faites exactement la même adresse en notation décimale, vous verrez si c'est plus simple à gérer. ::)

Tous mes étudiants sont effrayés par IPv6 en début de module... à la fin du module ils me demandent si on ne peut pas faire le TP en IPv6 plutôt qu'en IPv4 car c'est plus simple à mettre en place...
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 11 janvier 2020 à 14:40:50
Peut-être le document de juin 2002 de l'Arcep (enfin à l’époque c'était l'ART)

(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ipv6/200206_idate_etude_ipv6.png) (https://lafibre.info/images/ipv6/200206_idate_etude_ipv6.pdf)

Ce document est vraiment amusant à lire... Le gros point noir pour la transition à l'époque, c'est Windows 95, car si Microsoft propose de l'IPv6 acec Windows NT4 et Windows 2000, pas d'IPv6 avec Windows 95 !
(https://lafibre.info/images/ipv6/200206_idate_etude_ipv6_1.png)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien le 21 janvier 2020 à 13:16:55
Autre solution pour garder plus longtemps des IPv4 (extrait d'un film) :

(https://lafibre.info/images/ipv6/202001_nouvelles_ipv4.png)

Il suffit de quelques patches... et de quelques dizaines d'années le temps que tous les équipements implémentent ces patchs.

Série Netflix :
(https://lafibre.info/images/ipv6/202001_nouvelles_ipv4.jpg)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: buddy 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.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Optix 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.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: DamienC le 21 janvier 2020 à 14:17:26
Dans ce cas pourquoi ne pas mettre des IP stle 192.168.x.x...??
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: alarig le 21 janvier 2020 à 14:33:03
Ou même 240/4 ? :p (pour rester dans le sujet)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien 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 (https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Hugues 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.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: kgersen 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
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien 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.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: lechercheur123 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
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: vivien 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)
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: Steph 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"...
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: alarig 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.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: lechercheur123 le 10 mai 2020 à 23:51:03
Oui oui oui, il spamme même les LIRs en promettant monts et merveilles pour recevoir des votes.

J’ai même reçu un mail en Français de sa part sur mon mail RIPE
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: cali le 11 mai 2020 à 01:46:56
J’ai même reçu un mail en Français de sa part sur mon mail RIPE

Ouais il envoie du spam à abuse@ en disant qu'il sait comment mettre fin à Spamhaus si on vote pour lui.

Voilà un bon moyen d'atteindre l'objectif contraire.
Titre: Arrivée de nouvelles IPv4 avec 240.0.0.0/4 ?
Posté par: mirtouf le 11 mai 2020 à 11:22:51
ptramo atrouvé son sucesseur !  ;D