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


72

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?


9
En suivant initialement le lien, je m'attendais à voir le "1er avril".
Vi.


4
Bien que la proposition puisse être une blague, le nom ne l’est pas. IPv4 à IPv9 sont déjà réservés (bien que seuls IPv4 et IPv6 soient utilisés). IPv10 est la prochaine version disponible non attribuée.
user4556274

5
Fait intéressant, l'auteur propose d'utiliser 16 bits pour le champ ASN, alors que les ASN 32 bits sont déjà une pratique courante
Hagen von Eitzen

4
Il existe une belle tradition de RFC légers, traditionnellement publiés le 1er avril. en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments est un bon point de départ.
Dominic Cronin

Réponses:


84

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.


15
Eh bien, vous savez ce qu’ils disent - vous pouvez résoudre tous les problèmes avec une autre couche d’abstraction, à l’exception du problème de trop de couches d’abstraction!
revoir

13
ROFL aux satellites reliés par fibre. Cela semble aussi raisonnable qu'IPoAC.
Reirab

14
Il n'a pas de chance avec le droit d'auteur. Il a déjà cédé les droits d’auteur à l’IETF en s’engageant dans le processus RFC, indépendamment de ce que l’on pourrait dire dans le texte du document, ce qui n’est pas conforme aux politiques de l’IETF .
user207421

14
Il est temps de réentraîner mon cerveau pour ne pas implicitement faire confiance à tout ce que je lis au format RFC.
Matt

6
Tweet lien en ma journée (/ semaine / mois)
Scientifique en échec

27

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.



1

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.


1
Tout est prêt pour IPv6 depuis des années. L'adoption effective peut sembler lente, et la raison en est que IPv4 "fonctionne toujours". Cependant, le trafic IPv6 est d'environ 20% et croît assez rapidement. En 2017, un service Internet ne fournissant pas d'IPv6 devrait vraiment reconsidérer sa position. Ce dont nous n’avons vraiment pas besoin maintenant, c’est encore un autre mécanisme de transition.
ch7kor

Tout vrai. Mais j’ai le sentiment qu’IPv6 n’atteindra jamais une pénétration significative (les premiers 20% sont supposés être les plus faciles, les derniers 20% devraient être beaucoup plus difficiles) et un jour, les gens choisiront une autre voie. Le problème des technologies destinées à faciliter la transition est qu’une fois qu’elles sont présentes assez longtemps, vous réalisez qu’elles sont devenues le nouvel Internet.
thomasrutter

3
En fait, on pourrait affirmer que les 20% restants seront les plus faciles, car lorsque IPv6 dispose de 80% du trafic Internet, la proposition de suppression du trafic IPv4 sera probablement la norme et la plupart des FAI arrêteront de router le trafic IPv4. La situation sera inversée dès la création d’IPv6, de sorte que le trafic IPv4 doit être tunnelisé sur l’Internet (IPv6).
Ron Maupin

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.