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


72

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?


9
Cuando inicialmente seguía el enlace allí, esperaba ver "1 de abril".
Vi.


44
Si bien la propuesta puede ser una broma, el nombre no lo es. IPv4 a IPv9 ya están reservados (aunque solo se usan IPv4 e IPv6). IPv10 es la próxima versión disponible sin asignar.
user4556274

55
Curiosamente, el autor propone utilizar 16 bits para el campo ASN, cuando los ASN de 32 bits ya son una práctica común
Hagen von Eitzen

44
Existe una buena tradición de RFC alegres, tradicionalmente publicados el 1 de abril. en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments es un buen lugar para comenzar.
Dominic Cronin

Respuestas:


84

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.


15
Bueno, ya sabes lo que dicen: ¡puedes resolver todos los problemas con otra capa de abstracción, excepto el problema de demasiadas capas de abstracción!
Adiós

13
ROFL en los satélites unidos por fibra. Suena tan razonable como IPoAC.
reirab

14
No tiene suerte con los derechos de autor. Ya ha asignado los derechos de autor al IETF al participar en el proceso de RFC, independientemente de lo que pueda decir en el texto del documento, que no se ajusta a las políticas del IETF .
user207421

14
Es hora de volver a entrenar mi cerebro para no confiar implícitamente en nada de lo que leo en el formato RFC.
Matt

66
Tweet link hizo mi día (/ semana / mes)
Falló el científico el

27

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.



1

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.


1
Todo está listo para IPv6 durante años. La adopción real puede parecer lenta, y la razón es solo porque IPv4 todavía "funciona". Sin embargo, el tráfico IPv6 es aproximadamente del 20% y crece bastante rápido. En 2017, un servicio de Internet que no proporciona IPv6 debería reconsiderar su posición. Lo que realmente no necesitamos ahora es otro mecanismo de transición.
ch7kor

Todo cierto. Pero siento que IPv6 nunca alcanzará una penetración significativa (se supone que el primer 20% es el más fácil, el último 20% debería ser mucho más difícil) y un día la gente decidirá algún otro camino a seguir. Lo que pasa con las tecnologías destinadas a facilitar la transición es que una vez que están disponibles durante el tiempo suficiente, te das cuenta de que se han convertido en el nuevo Internet.
thomasrutter

3
En realidad, se podría argumentar que el último 20% será el más fácil porque cuando IPv6 tiene el 80% del tráfico de Internet, la propuesta de la puesta de sol IPv4 probablemente será el estándar, y la mayoría de los ISP dejarán de enrutar el tráfico IPv4. La situación se revertirá desde el inicio de IPv6, de modo que el tráfico de IPv4 se debe canalizar a través de Internet (IPv6).
Ron Maupin

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.