“IPv10” est-il une blague ou un projet sérieux de RFC?

Spécification du protocole Internet version 10 (IPv10)

Le nom est amusant (IPv4 + IPv6 == IPv10), mais la proposition actuelle semble étrange (un format de paquet supplémentaire pour lutter contre l'incompatibilité entre les formats de paquets).

Est-ce une proposition normale qui présente un équilibre entre le pour et le contre ou un document peu viable pour se moquer de "IPv10" avec un visage sérieux?

Si c'est grave, veuillez le décrire de façon "tl; dr". Pourquoi cela et pas une autre technologie de transition comme nat64 / teredo?

Comme Ron l'a dit, n'importe qui peut écrire une proposition. J'ai du mal à prendre au sérieux les propositions de quelqu'un qui suggère d' interconnecter des satellites avec de la fibre optique , cependant.

De plus, je ne peux pas imaginer que cette proposition actuelle gagne du terrain, en particulier à cause de cette remarque:

Tous les hôtes connectés à Internet doivent être des hôtes IPv10 pour pouvoir communiquer quelle que soit la version IP utilisée, et le processus de déploiement IPv10 peut être réalisé par TOUTES les entreprises technologiques développant des systèmes d'exploitation pour les périphériques de sécurité et de réseau des hôtes.

Donc, pour résoudre le problème des hôtes uniquement IPv4 ne pouvant pas communiquer avec des hôtes uniquement IPv6 (et vice versa), vous devez implémenter un autre protocole: IPv10. Alors, pourquoi s'embêter avec cela et ne pas simplement mettre en œuvre IPv6 sur cet hôte uniquement IPv4 et en finir avec lui.

De plus, comme on peut le lire dans la RFC7059 , il existe déjà suffisamment de mécanismes de tunnel disponibles qui peuvent être utilisés pour résoudre en partie ce problème.

Pour être honnête, je pense que l'auteur espère avoir un certain succès commercial en revendiquant le droit d'auteur, comme on peut le lire dans ces tweets :

ANNONCE: Protéger le droit d'auteur, les protocoles de routage # IPv10 et KHALED (#KRP ou #RRP) sont développés par le PDG de @The_Road_Series.

Ils NE DOIVENT PAS être représentés ni publiés par aucune organisation sans l'approbation de leur développeur, @Eng_Khaled_Omar.

Aujourd'hui 26 mai 2017, une deuxième demande a été envoyée à l'ietf pour supprimer les brouillons # IPv10 #KRP (#RRP) de leur référentiel.

N'oubliez pas que n'importe qui peut soumettre des propositions à l'IETF et qu'elles sont prises au sérieux jusqu'à leur adoption ou leur décès par manque d'intérêt.

Cette proposition particulière a expiré et a été renouvelée par l'auteur à plusieurs reprises. Il ne semble pas y avoir beaucoup, voire pas du tout de soutien, et il n’a même pas de statut RFC proposé, par exemple Standards Track. L'auteur est probablement sérieux au sujet de sa proposition, mais il ne semble pas avoir recueilli un soutien sérieux pour cette proposition.

Il y a une proposition visant à IPv4 coucher du soleil qui est grave, et il a un groupe de travail complet derrière, mais il a une longue route difficile devant lui à l' adoption plénière. Il a pour objectif de résoudre les problèmes inhérents au passage d’IPv4 à IPv6.

“IPv10” est-il une blague ou un projet sérieux de RFC?

Tous les deux. Je suppose que ce type est sérieux et qu'il ne comprend pas les stratagèmes ridicules qu'il propose. La blague est sur lui.

La proposition de satellite à fibre est encore plus ridicule, car elle néglige les longueurs de fibre requises et ignore totalement la mécanique orbitale.

L’IETF devrait l’empêcher de traîner.

C'est une tentative sérieuse de résoudre un problème réel. Que la solution soit bonne ou mauvaise (c'est probablement de la foutaise), l'énoncé du problème est correct: la stratégie actuelle consistant à essayer de mettre en œuvre IPv6 a jusqu'à présent échoué. Comme l'indique son introduction, IPv6 a 19 ans et nous ne voyons toujours pas comment nous sommes passés d'une manière significative à la transition.

Comme il est mentionné, nous avons déjà des solutions de pontage telles que NAT64 (il en mentionne d'autres aussi). Celles-ci sont bonnes et bonnes mais ne permettent toujours pas une transition complète vers IPv6 - elles supposent que les hôtes publics uniquement IPv4 sont là pour rester.

Cela dit, je suis sceptique quant à l’utilité de cette spécification, étant donné que je vois des problèmes fondamentaux liés à la transition vers IPv6. Je n’ai pas passé beaucoup de temps à essayer de comprendre comment il essayait de le faire, et c’est peut-être plus sage que moi (bien que le consensus entre les autres réponses donne à penser que j’ai raison), mais il semble que le même problème de démarrage que celui d’IPv6 ait été rencontré. première place.

Pour répondre à la question, il s'agit toujours d'une tentative sérieuse de résolution du problème.

La mise en œuvre d'un nouveau protocole présente un certain intérêt. Le protocole de traduction actuel est NAT64.

NAT64 est un mécanisme de transition IPv6 qui facilite la communication entre les hôtes IPv6 et IPv4 en utilisant une forme de traduction d'adresse réseau (NAT). La passerelle NAT64 est un traducteur entre les protocoles IPv4 et IPv6 1 , fonction pour laquelle elle nécessite au moins une adresse IPv4 et un segment de réseau IPv6 comprenant un espace adresse de 32 bits. Un client IPv6 incorpore l’adresse IPv4 avec laquelle il souhaite communiquer en utilisant la partie hôte du segment de réseau IPv6, ce qui donne des adresses IPv6 intégrées à IPv4 (d’où l’espace adresse de 32 bits du segment de réseau IPv6) et envoie des paquets à l'adresse résultante. La passerelle NAT64 crée un mappage entre les adresses IPv6 et IPv4, qui peut être configuré manuellement ou déterminé automatiquement.

La source

L'idée principale pour IPv10 serait l'élimination de NAT64. A proprement parler, le NAT a toujours été un goulot d'étranglement.