¿Es “IPv10” una broma o un borrador serio de RFC?

Protocolo de Internet versión 10 (IPv10) Especificación

El nombre es divertido (IPv4 + IPv6 == IPv10), pero la propuesta real parece extraña (un formato de paquete más para combatir la incompatibilidad entre formatos de paquete).

¿Es una propuesta normal que tiene ventajas y desventajas equilibradas o simplemente un documento mínimamente viable para burlarse de "IPv10" con una cara seria?

Si es grave, descríbalo de forma "tl; dr". ¿Por qué esta y no otra tecnología de transición como nat64 / teredo?

Como dijo Ron, cualquiera puede escribir una propuesta. Sin embargo, me cuesta tomar en serio las propuestas de alguien que sugiere interconectar satélites con fibra óptica .

Además, no puedo imaginar que esta propuesta real gane impulso, especialmente debido a esta nota:

Todos los hosts conectados a Internet deben ser hosts IPv10 para poder comunicarse independientemente de la versión de IP utilizada, y TODAS las empresas de tecnología que desarrollan sistemas operativos para hosts de redes y dispositivos de seguridad pueden realizar el proceso de implementación de IPv10.

Por lo tanto, para resolver el problema de que los hosts solo IPv4 no puedan hablar con hosts solo IPv6 (y viceversa) necesita implementar otro protocolo: IPv10. Entonces, ¿por qué molestarse con eso y no solo implementar IPv6 en ese host solo IPv4 y terminar con eso?

Además, como se puede leer en RFC7059 , ya hay más que suficientes mecanismos de túnel disponibles que se pueden utilizar para resolver partes de este problema.

Para ser honesto, creo que el autor espera algún éxito comercial al reclamar derechos de autor, como se puede leer en estos tweets :

ANUNCIO: La protección del Copyright, el # IPv10 y el Protocolo de enrutamiento KHALED (#KRP o #RRP) son desarrollados por el CEO de @The_Road_Series.

NO DEBEN ser representados o publicados por ninguna organización sin la aprobación de su desarrollador @Eng_Khaled_Omar

Hoy, 26 de mayo de 2017, se envió una segunda solicitud a la ietf para eliminar borradores # IPv10 #KRP (#RRP) de su repositorio.

Debe recordar que cualquiera puede presentar propuestas al IETF, y se toman en serio, hasta que sean adoptadas o mueran por falta de interés.

Esta propuesta particular ha expirado y ha sido renovada por el autor varias veces. No parece tener mucho, si es que tiene alguno, soporte, y ni siquiera tiene un estado RFC propuesto, por ejemplo, Normas Track. El autor probablemente toma en serio su propuesta, pero no parece haber obtenido ningún apoyo serio para la propuesta.

Hay una propuesta para poner fin a IPv4 que es seria, y tiene un grupo de trabajo completo detrás de ella, pero tiene un largo y difícil camino por delante para su plena adopción. Tiene la intención de abordar los problemas inherentes a la transición de IPv4 a IPv6.

¿Es “IPv10” una broma o un borrador serio de RFC?

Ambos. Supongo que ese tipo es serio y no entiende los esquemas ridículos que propone. El chiste es sobre él.

La propuesta del satélite de fibra es aún más absurda, ya que descuida las longitudes de fibra requeridas e ignora totalmente la mecánica orbital.

IETF debería bloquearlo por trolling.

Es un intento serio de resolver un problema real. Ya sea que la solución sea buena o mala (probablemente sea basura), su planteamiento del problema es correcto: la estrategia actual de tratar de implementar IPv6 ha fallado hasta ahora. Como dice su introducción, 19 años de IPv6 y todavía no hay forma de que podamos vernos en una transición significativa.

Como se menciona, ya tenemos algunas soluciones puente como NAT64 (también menciona otras). Estos son buenos y buenos, pero aún así no permiten una transición completa a IPv6: suponen que los hosts públicos solo IPv4 están aquí para quedarse.

Dicho esto, soy escéptico sobre cómo ayudaría esta especificación dado que lo que veo son problemas fundamentales con la transición a IPv6. No he pasado mucho tiempo tratando de entender cómo lo intenta, y tal vez sea más sabio que yo (aunque el consenso entre las otras respuestas sugiere que estoy en lo cierto), pero parece sufrir el mismo problema de arranque que IPv6 tiene en el primer lugar.

Para responder a la pregunta Pero todavía es un intento serio de resolver el problema.

Hay cierta validez con la implementación de un nuevo protocolo. El protocolo de traducción actual es NAT64.

NAT64 es un mecanismo de transición de IPv6 que facilita la comunicación entre los hosts IPv6 e IPv4 mediante el uso de una forma de traducción de direcciones de red (NAT). La puerta de enlace NAT64 es un traductor entre los protocolos IPv4 e IPv6, 1 para cuya función necesita al menos una dirección IPv4 y un segmento de red IPv6 que comprende un espacio de direcciones de 32 bits. Un cliente IPv6 incrusta la dirección IPv4 con la que desea comunicarse utilizando la parte del host del segmento de red IPv6, lo que da como resultado direcciones IPv6 incrustadas en IPv4 (de ahí el espacio de direcciones de 32 bits en el segmento de red IPv6) y envía paquetes al dirección resultante La puerta de enlace NAT64 crea una asignación entre las direcciones IPv6 e IPv4, que pueden configurarse manualmente o determinarse automáticamente.

Fuente

La idea principal para IPv10 sería la eliminación de NAT64. Estrictamente hablando, NAT siempre ha sido un cuello de botella.