Suponga que existen máquinas del tiempo. Viajas a 1977 a Stanford, California. ¿Qué mejora de TCP / IP le propondría a su grupo de investigación de redes para mejorar el futuro despliegue y rendimiento de TCP / IP?

Creo que el diseño modular de IPv6 es una muy buena idea, así que eso es lo que habría sugerido si pudiera viajar en el tiempo. En retrospectiva, sabiendo lo rápido que cambió la tecnología a lo largo de los años, propondría un diseño aún más modular para adaptarse fácilmente a las mejoras en los requisitos subyacentes de hardware y software.

Propondría un encabezado de dirección de origen y destino de IP modular, forzándolo a ser el segundo encabezado para fines de velocidad. Dentro de este encabezado podríamos tener bits de versión para poder comenzar con direcciones de 32 bits y luego avanzar hacia direcciones más largas sin perder la compatibilidad con versiones anteriores.

Incluso podríamos tener los TOS, las opciones y la fragmentación como encabezados opcionales, reduciendo la cantidad de bytes necesarios para los datagramas que no los necesitan.

Tomaría esta idea más allá para hacer algo similar a lo que la familia IP-Sec está haciendo para los datagramas IP pero para TCP. También podríamos tener un campo de “siguiente encabezado” en el encabezado TCP, siguiendo el principio de la cadena de encabezados que utiliza IPv6. De esta manera, agregar cosas como la seguridad (SSL) o la funcionalidad del protocolo de paquete (utilizado en DTN) sería mucho más fácil. También proporcionaríamos la infraestructura en caso de que queramos agregar cosas nuevas y elegantes en el futuro.

He estado leyendo todas las respuestas, y la mayoría de nosotros cree que esta pregunta es fácil de responder, considerando que muchos genios han estado trabajando con TCP / IP durante estas últimas cuatro décadas y han propuesto un montón de soluciones. El problema es que algunas soluciones no son factibles en el hardware de los años 70. Por lo tanto, debemos tener esto en mente, por ejemplo, se descartan las direcciones más largas o la criptografía compleja.

La primera idea que se me ocurrió es combinar un protocolo IP más simple con la posibilidad de opciones extendidas, con un potencial ilimitado. Si disminuimos la longitud del encabezado y lo establecemos constante, podemos mejorar el procesamiento de paquetes, como lo hace IPv6. Básicamente, tendríamos una IP simple con longitud de encabezado constante, datos y el siguiente campo de encabezado. Por lo tanto, no necesitaríamos el campo Longitud del encabezado. También podemos olvidarnos de la fragmentación (y su campo) utilizando un protocolo para administrar las MTU entre redes. Finalmente, podríamos pasar la verificación de integridad a las capas superiores y eliminar el campo de suma de verificación.
Para resumir, podríamos usar unidades de datos extremadamente simples, como las celdas de los cajeros automáticos, para aumentar el rendimiento de la red y reducir la congestión. Luego, para aquellos que necesitaban más funcionalidades, podían usar extensiones. Por ejemplo, podríamos usar una extensión de dirección adicional para aumentar el número de direcciones IP o podríamos usar IPSec fácilmente :).

Pero definitivamente, el equipo de investigación de TCP / IP hizo un gran trabajo, como sugirió Stan Hanks. ¡Todavía está en uso después de más de 30 años!

Como dice Stan Hanks, la idea de algo sobre las direcciones de 32 bits habría sido imposible debido a las limitaciones de hardware. Pero, ¿qué hay de dividir las direcciones IP en dos o más direcciones de 32 bits? El resultado sería algo similar a tener un Internet completo usando IPv4 para cada IP (y esto no tendría problemas de escalabilidad, ya que de hecho estamos usando direcciones de 32 bits, podríamos concatenar tantas direcciones como queramos). ¡No hay problema en el número de direcciones ahora!

Propondría, como lo hace IPv6, un encabezado de longitud fija para mejorar el rendimiento y el mecanismo que utiliza con los encabezados opcionales para tener una base para mejoras en el futuro, para agregar más funcionalidad al protocolo, como seguridad, cuando el hardware nos permita Haz eso.

Como sabemos, las redes ahora son más confiables que antes y, en la mayoría de los casos, estaríamos bien sin los TCP ACK, eliminarlos reduciría considerablemente el impacto en el tráfico de Internet, por lo que sugeriría que permitieran las capas superiores para asumir la responsabilidad de los paquetes perdidos, en otras palabras, sugeriría que solo usen UDP, pero tal vez con algunos campos más.

Con la posibilidad de retroceder en el tiempo y proponer cualquier tipo de información al grupo de investigación, me gustaría presentarles una de las funcionalidades que ofrece IPsec, la capacidad de cifrar el mensaje.

Para que eso no otorgue una alta prioridad a estos problemas y les permita evolucionar, una de las posibilidades que veo más razonables sería introducir un identificador en el encabezado. Ese identificador diría el tipo de cifrado de datos, con indicadores y valores para la negociación de claves. Y también, podríamos introducir la posibilidad de indicar el tipo de compresión en el mensaje como se discutió anteriormente.

¿Y dónde pondríamos este identificador?

Como se menciona en otras respuestas, una posibilidad es sugerir el paso de IPv4 a IPv6 al grupo de investigación. IPv6 elimina completamente la suma de comprobación del encabezado IP, dejando esa función en las capas inferiores. Creo que si eliminan la suma de comprobación de IPv4, podríamos usar sus 16 bits para ingresar el identificador discutido anteriormente.

Aunque esto sería solo una pequeña sugerencia en comparación con las posibilidades que ofrece IPsec en ese momento.

En primer lugar, propondría las mejoras de IPv6 pero excluiría la parte de las direcciones IP de 128 bits porque, como dijo Stan Hanks, incluso la IP de 64 bits habría sido imposible debido a los límites tecnológicos. Una de estas mejoras a las que me refiero es la reducción del encabezado base a 16 bytes constantes (el encabezado IPv6 tiene 40 bytes pero, con IP de 32 bits en lugar de 128 bits, su longitud se reduce a 16 bytes), lo que también significa que algunos campos de encabezado IPv4, como la Longitud del encabezado de Internet (IHL) o el desplazamiento de fragmentos, serían eliminados u opcionales (tenga en cuenta que en 2007 solo el 0.06% del tráfico estaba fragmentado [consulte El estado del tráfico de red empresarial en 2012] ) Esto habría resultado en una mayor eficiencia, ya que cada datagrama habría tenido 4 bytes de encabezado menos, y en el ancho de banda de los 80 (56 Kbit / s aprox.) Esto habría hecho una diferencia.

Además, IPv6 hace que los datagramas sean más fáciles de procesar porque su encabezado tiene una longitud constante y los enrutadores no necesitan fragmentar ningún datagrama. Entonces, como resultado de estos requisitos más bajos, podrían haberse utilizado infraestructuras de red más baratas.

En segundo lugar, dado que el Síndrome de Windows tonto fue un problema en las primeras implementaciones de TCP, lo advertiría y sugeriría una solución temprana a este problema (algoritmo de Nagle). Además, propondría la idea de sellar los segmentos TCP con el fin de obtener inequívocamente el RTT de un segmento después de que se haya realizado una retransmisión.

La compensación dura en cualquier momento dado es la potencia informática disponible en el hardware de la época en comparación con lo que desea hacer con él. Es sorprendente que algunas personas tengan tanta visión de futuro que su investigación anticipa la tecnología por décadas, por ejemplo, la tesis de doctorado del Dr. Ivan Sutherland fue sobre gráficos interactivos por computadora …

… en 1963!

TCP / IP fue un tramo para las Minicomputadoras de la década de 1970: recuerdo haber visto la codificación y las acrobacias de MMU que se introdujeron en el PDP-11/70 en 2.9 BSD Unix. Fue esa clase de máquina la que aprendí a usar y programar Unix en UCB en 1981. La memoria de acceso aleatorio (RAM) era muy limitada (64K para las instrucciones de su programa, 64K para sus datos, si tiene suerte de tener un computadora I / D dividida), costosa y, por lo tanto, preciosa: se requería la eficiencia del tamaño del programa para que su aplicación (y el Kernel (sistema operativo)) incluso funcionara.

Para otro contexto: 1977 tiene 38 años en el pasado y, por lo tanto, han pasado 19 turnos de la Ley de Moore desde entonces, es decir, las computadoras ahora son 524,288 veces más potentes . Ver también la Ley de Moore está muerta, viva la Ley de Moore.

La otra cosa que es injusta sobre esta pregunta se expresa en el aforismo “la retrospectiva siempre es 20/20” (aunque “siempre” tampoco es del todo cierto, mucha gente malinterpreta la historia). Sabemos cómo la informática y las redes han evolucionado durante las décadas intermedias.

Con todo eso como trasfondo, el problema arquitectónico al que volvería a atacar es la sobrecarga de las direcciones IP con muchas funciones más allá de su uso previsto, por ejemplo, Autenticación (seguridad informática). ¿Cómo propondría abordar el problema? Haga que las direcciones IP sean mucho más dinámicas desde el primer momento, para que no pueda sobrecargarlas con nada más de lo que pretendía ser: un identificador de enrutamiento, porque cambia con demasiada frecuencia, demasiado rápido.

Ah, e insisto en que la seguridad IP con cifrado (ESP) sea una parte necesaria de la especificación y la implementación, a pesar de la relativa imposibilidad de eso (como se señala en la respuesta de Stan Hanks). [Expletivo eliminado] la NSA y el FBI.

[En realidad, estaba en la Universidad de Stanford para una sesión de la escuela de verano cuando era estudiante de secundaria en el verano de 1978, ahí fue cuando aprendí a usar TOPS-20 y Emacs, y allí obtuve mi primer vistazo al ARPANET]

Señalaría algunos de los cambios importantes que hoy en día la comunidad de Internet está tratando de implementar con IPv6. El tamaño fijo del encabezado con extensiones opcionales y hacer de la fragmentación un problema de extremo a extremo serían mis dos primeras sugerencias. Esto facilitará la complejidad y aumentará el rendimiento temprano en la vida de Internet.
Será necesario un mayor rango de IP pero, como ya se ha señalado, las máquinas de la época ya tenían dificultades para calcular las direcciones IP de 32 bits. Por lo tanto, propondré usar la extensión opcional para agregar otro datagrama de IP que se dirigirá a una Internet interna dentro de cada dirección pública. Esta implementación tiene las ventajas de tener un rango casi infinito de direcciones IP que crecerá junto con el aumento de hosts en Internet.

Algo más que me gustaría sugerir es implementar mecanismos a nivel de infraestructura. Para poder abordar el problema de DDoS reflexivo, que necesita utilizar direcciones IP de origen falsificadas para amplificar un ataque utilizando servicios públicos como DNS o NTP (protocolo de tiempo de red). Mi propuesta será utilizar el filtrado de ingreso a la red descrito en el RFC 2827 para mitigar el DDoS utilizando técnicas de reflexión.

Bueno, propondría agregar una marca de tiempo al encabezado TCP, que simultáneamente lograría dos cosas:
– Resuelva el problema de la ambigüedad de los números de secuencia: cuando un número de secuencia TCP alcanza el número máximo permitido (2 ^ 32) y se reinicia desde 0, el otro host no puede estar seguro de que el segmento que tiene un número de secuencia más bajo persiga El anterior. La marca de tiempo permitiría la identificación de segmentos continuos cuando eso ocurra.

– Permita un cálculo más fácil del tiempo de ida y vuelta (RTT), verificando las marcas de tiempo, de los últimos dos segmentos ACK y haciendo cálculos matemáticos simples.
Una buena idea sería implementar esto como se define en RFC # 1323, incorporándolo en las Opciones del encabezado TCP sin la necesidad de agregar campos adicionales.

También sugeriría que el mecanismo Keep-alive sea un estándar para todas las conexiones TCP, funcionando de manera similar a como se describe en RFC_ # 1122. Enviaría un segmento vacío después de dos horas de inactividad y si no se recibe el ACK después de X intentos, la conexión se corta. Siempre estaría activo pero podría desactivarse, y el tiempo podría ser configurable, manteniendo las dos horas como mínimo.

Creo que ambas opciones, sin costar mucho esfuerzo, serían beneficiosas, y si se planificaran en ese momento (incluso si la tecnología no estuviera disponible), creo que TCP sería un poco mejor hoy, con un rendimiento mejorado.

A principios de 1977, TCP se utilizaba para servir como un protocolo de extremo a extremo a nivel de host y para servir como un protocolo de enrutamiento y empaquetado de Internet, como dijo Jon Posel:
“Estamos arruinando nuestro diseño de protocolos de internet al violar el principio de estratificación. Específicamente, estamos tratando de usar TCP para hacer dos cosas: servir como un protocolo de extremo a extremo a nivel de host y servir como un protocolo de enrutamiento y empaquetado de Internet. Estas dos cosas deben proporcionarse de forma modular y en capas. Sugiero que se necesita un nuevo protocolo de red distinto, y que TCP se use estrictamente como un protocolo de extremo a extremo de nivel de host “.
Por lo tanto, si hubiera estado allí, habría propuesto dividir la arquitectura TCP / IP dividiendo TCP en la capa de transporte e IP en la capa de red.
Además de esto, teniendo en cuenta que IPv4 se implementó en 1980 y la experiencia actual de que las direcciones IPv4 se agotaron, propondría directamente las direcciones IPv6. Las direcciones IPv6 son mejores para tener una medida de encabezado fija (40 bytes) por tal motivo no es necesario agregar la longitud del encabezado de Internet (IHL), lo que implica una mayor facilidad y velocidad de procesamiento en enrutadores y conmutadores, además de otras mejoras.
Sin embargo, el problema de proponer IPv6 en 1977 es que las tecnologías de esa época no permitieron esta implementación. Por esa razón, realmente tendría que proponer una dirección de implementación menor que IPv6 (y mayor que IPv4), para que sean compatibles con las limitaciones tecnológicas.

En primer lugar hola a todos,

Según comentamos Stan Hanks, en la era en que todo (1977) retrocedió fue muy difícil mejorar la tecnología ya implementada en ese momento, así que creo que eso fue lo que fue. Mientras estuvo allí, un mejor control de seguridad hubiera sido perfecto, porque en ese momento era “fácil” interceptar un datagrama y atacarlo. Mucha gente habla sobre lo que había implementado IPv6 o al menos su diseño modular, pero como mencioné anteriormente, técnicamente es muy difícil de implementar por falta de recursos. Sin embargo, si pudiera (una vez más tecnológicamente hablando) una de las mejoras que hubiera intentado implementar en el tamaño del encabezado y aumentar la seguridad, como mencioné anteriormente.

También podríamos hablar de congestión, ya que es uno de los principales problemas que tenemos hoy, como si se hubiera implementado mejor en su día, tal vez ahora este problema sería más avanzado, especialmente porque creo que ya han comentado y no había capacidad como la hay ahora (este problema podemos relacionarlo con el algoritmo Van Jacobson) Software antes.

En realidad, hay muchas mejoras que podrían implementarse … Pero realmente es cierto que en ese momento tal vez no podría hacer nada más, aunque algunos creen que siempre hay más por hacer.

¡Un saludo!

Teniendo en cuenta todo lo que ha publicado, no puedo ver una mejora significativa si nos mudamos a 1977 para reinventar TCP / IP.

El aumento del uso de direcciones de 128 bits habría evitado la colisión de direcciones IP y protocolos como NAT o VPN habrían sido innecesarios. Pero usar 128 bits en 1977 era imposible como dice Stan Hanks.

Realizar la fragmentación en el proceso de enrutamiento, es algo maravilloso, pero consume recursos limitados. Hoy en día tal vez sea totalmente innecesario (porque las rutas varían mucho tiempo), pero no sé exactamente cómo eran las redes en 1977. Lo que sí sé es que la tasa de error fue mucho mayor y la transmisión fue mucho peor que real, por lo que la MTU de las redes podría cambiar o las rutas probablemente estarían cambiando mucho más que ahora y el hecho de pedirle al remitente que reenvíe toda la información fue un costo que justificó la necesidad de implementar el protocolo. Probablemente en 1977 sea necesario.

Estoy de acuerdo con Eduardo Martínez Rojo, no veo la necesidad de introducir una suma de verificación en el datagrama de IP, aunque la tasa de error fue mucho mayor que en este momento. ¿No es suficiente vincular la suma de comprobación de la capa?

En el encabezado TCP tenemos el campo de secuencia que controla el flujo de transmisión de datos, el problema es que eventualmente podemos girar alrededor del contador (aunque tenemos el campo opcional para aumentar). Pero si prestamos atención a una conexión TCP / IP, el número de secuencia aumenta con el tamaño de la ventana del receptor. Porque no usamos la información ofrecida por la ventana del receptor para aumentar el número de secuencia. La ventana del receptor en sí nos permitiría aumentar de forma no lineal la secuencia y los números de reconocimiento, lo que permite que las conexiones que envían más información, su número de secuencia aumente más lentamente, que las conexiones que envían mucha menos información (lo que aumentaría por byte). Además, esto complicaría aún más la suplantación de identidad, porque un ataque de “El hombre en el medio” que intercepta solo datagramas del remitente no conocería la ventana del receptor y la predicción de los números de secuencia sería mucho más complicada al no confiar solo de la longitud del paquete. Podría ser una forma inteligente de aumentar el número de secuencia sin uso opcional.

La respuesta de Stan Hanks es muy esclarecedora, gracias por la lectura.

También me gustan las propuestas de Quora User y Dani Gámez Franco. IPv4 podría haber utilizado algunas de las mejoras que IPv6 trae a la mesa, la parte más interesante es la forma en que se manejan los encabezados de extensión.

Además de eliminar la longitud del encabezado de Internet, habría sugerido que también eliminara la suma de comprobación, ya que otras capas pueden hacer ese proceso. Dicho esto, teniendo en cuenta el bajo ancho de banda disponible en ese momento, no estoy completamente seguro de cuán grande habría sido el impacto de un paquete dañado que viaja por su camino completo, en lugar de ser descartado en algún lugar a lo largo del camino.

La idea de usar encabezados de extensión como una forma de extender el espacio de direcciones IP también parece interesante. De la forma en que lo imagino, el campo de protocolo (o siguiente encabezado) se etiquetaría como “dirección”, lo que haría que el dispositivo de enrutamiento verifique el siguiente encabezado y cree una dirección completa fusionando ambos campos de dirección. Esto habría hecho que el protocolo fuera escalable a costa de cierta eficiencia (ya que se usarían bits adicionales para lo que podría ser un solo campo IP).

En general, cuanto más pienso en mejorar TCP / IP en ese momento, mejor entiendo la última línea de Stan Hank en su comentario.

Y ahora mi respuesta no seria … Si asumiera que existen máquinas del tiempo, habría viajado con una copia del IPv6 RFC (2460) y algunos datos sobre las tecnologías y redes actuales. Les mostraría a las grandes mentes en ese tiempo que comenzó todo, para que supieran qué mejoras necesitaría el futuro. Estoy seguro de que sus mejoras en TCP / IP serían mejores que cualquier cosa que pudiera proponer. 😛

Sin embargo, hay una cosa más que hubiera hecho antes de ir a 1977 con mi máquina del tiempo. Habría viajado al futuro primero, para agarrar un hoverboard para lucir genial cuando apareciera en Standford.

Probablemente sugeriría usar SCTP y DCCP en lugar de TCP y UDP. El hardware necesario para implementarlos no es significativamente diferente y TCP ha presentado todo tipo de problemas a lo largo de los años debido a dónde se colocó la confiabilidad.

La especificación IPv6 original esencialmente tenía la dirección como tres fragmentos distintos: algo para identificar qué tipo de tráfico era (por ejemplo: enlace local, unidifusión, multidifusión, etc.), algo que decir dónde estaba una máquina de destino con respecto a la red troncal, y algo para identificar la máquina de destino en sí. Entiendo que esto se basa en el protocolo TUBA propuesto, donde la diferencia clave es que TUBA era de longitud variable y las direcciones IPv6 son de longitud fija. Las direcciones de longitud variable no funcionaron bien con los proveedores de hardware, pero la noción de un prefijo de enrutamiento parece haber atraído.

IPv6 también permite encabezados extendidos, fragmentos de encabezado adicionales que pueden proporcionar información adicional.

Este sistema es extremadamente flexible, pero limita la profundidad del árbol y causa algunos otros dolores de cabeza. DHCPv6 lo hace aún peor. La dirección también es demasiado larga para el hardware antiguo.

Pero, ¿qué pasaría si IPv4 hubiera utilizado encabezados de direcciones de longitud fija apilables, cada uno marcado para el nivel de Internet al que se aplicaba? No hay una imposición seria en el hardware, está trabajando con una dirección de 32 bits que tiene un desplazamiento constante para todos los paquetes que lo alcanzan. No hay complejidad adicional y, cuando Internet era muy pequeño, no hay gastos generales. Nunca necesita una capa para un nivel al que nunca va. (Lo que significa que las direcciones siguen siendo pequeñas para el tráfico local, sin importar cuán grande sea Internet).

La multidifusión probablemente está fuera. IGMP es demasiado complejo para sistemas livianos.

Una mejor apuesta podría haber sido colocar algo en las bebidas de los comités del CCITT responsables de X.25, X.400 y X.500. Si se tratara de estándares totalmente abiertos, gratuitos para que cualquiera pueda acceder e implementarlos, muchos de los problemas de seguridad que afectan a Internet hoy en día nunca habrían sucedido. Además, existen ambigüedades en las especificaciones para la pila TCP / IP. Si más IETF hubiera estado expuesto a un mayor número de estándares mucho más rigurosos, podrían haber solucionado esas ambigüedades. Menos ambigüedades significan menos estrés en el sistema y un mayor determinismo en el procesamiento de paquetes. Todas las cosas buenas.

Actualmente, llamado IPv4, el sistema de direcciones IP que en la mayoría de las redes están conectadas a Internet, este protocolo fue creado en 1981, y se decía que era el sistema perfecto para abordar las capas. El sistema se basa en direcciones de 32 bits, de modo que se logran sucesivas variaciones 4,294,967,296 (2 ^ 32). Si no hubiera sido por tecnologías como NAT o DHCP, las direcciones IPv4 serían mucho más largas, por lo que IPv6 ha aparecido antes. ¿Quién podría imaginar que esta situación había evolucionado tan rápidamente en el mundo de las redes?
Si viajo a 1977, explicaría el gran problema de las limitaciones de IPv4 asumidas actualmente en el siglo XXI. Una posible propuesta que haría que este grupo de investigadores pudiera adaptar el tamaño de 32 a 128 bits, para 2 ^ 128, aproximadamente 340 sextillones de combinaciones para ser exactos. Con esta solución, evitaríamos la falta de asignación de IPv4 para un futuro más lejano, además de obtener más campos para garantizar la seguridad, integridad y privacidad de los datos.
Por supuesto, la implementación de IPv6 en 1977 habría sido una inversión muy grande y costosa en ese momento, además de la falta de tecnología que no había logrado implementar el protocolo y que era compatible. Es por eso que, desde el futuro, hemos explicado una posible solución para abordar esta compatibilidad encapsulando IPv6 en IPv4, como explica RFC 4213 y RFC3056.

Si tiene una máquina del tiempo, debe ser capaz de bloquear el período de tiempo que dejó de los efectos de causalidad, efectuándolo.

Imagina si la máquina del tiempo que tuvieras pudiera mover cosas del pasado, del futuro.

Mueva un quark fuera de lugar en un átomo en un grano de arena, en una playa hace 1000 años.

Algo tan pequeño como esto es suficiente para cambiar toda la historia de la tierra a partir de ese momento.

Si miras videos sobre la paradoja del abuelo, es un error pensar que puedes tener tiempo suficiente para pararte frente a él y apretar el gatillo, y mucho menos tener una conversación con él.

No puedes retroceder en el tiempo y obtener los números de lotería ganadores, no puedes matar a Hitler, detener el ataque de Pearl Harbor, no puedes salvar a JFK o detener el 11 de septiembre.

Solo puede cambiar estas cosas si la máquina del tiempo puede bloquear los efectos de causalidad (mantenga el período de tiempo del que provino de los efectos de causalidad que lo afectan)

Pero los cambios nunca contarían en realidad de donde vienes, solo la otra dimensión a la que volviste y en la que te metiste.

Si una máquina puede hacer algo tan asombroso como recrear el pasado, entonces bloquear la causalidad no debería ser un problema para la máquina del tiempo.

Tal vez las personas del futuro vayan al pasado en la técnica que describí anteriormente, o tengan la tecnología para ver el pasado desde el futuro en un monitor de televisión, sin causar ningún efecto causal.

Estas son las dos únicas formas en que puedo pensar que no afectan la causalidad.

A menos que los extraterrestres tengan una máquina del tiempo, pero no van a compartir, porque se trata de dinero, avaricia, excitar nuestros neurotransmisores y poder, y no se puede confiar, incluso si podemos entender la tecnología de la máquina del tiempo que crearon, si se explica a nosotros por ellos.

Extraterrestres que nos explican cómo funciona su máquina del tiempo, podría ser como explicar el cálculo a un mono. Quizás no somos lo suficientemente inteligentes como para entenderlo.

El lugar más visitado por un viajero en el tiempo, si es posible, sería el depósito de la librería donde Lee Harvey Oswald le disparó a JFK, o el período de los dinosaurios.

Mire la máquina del tiempo de Ronald Mallet en YouTube, pero solo puede enviar información al punto cuando se encendió.

Hoy en día, el principal problema es que las direcciones IP están casi todas asignadas como muchos de ustedes dijeron. En este contexto, se está introduciendo IPv6.
En 1977, los investigadores no podían imaginar la tecnología actual y la interconectividad de nuestro mundo.

La información que necesitan ahora es sobre nuestra tecnología actual y futura: (1) Cada hogar debe tener al menos una computadora personal. (2) Todos deberían tener un teléfono inalámbrico con conexión a Internet llamado teléfono inteligente. (3) Todos los electrodomésticos de una casa deben tener la posibilidad de conectarse.

Esta información puede dar a los investigadores una visión de nuestro presente y crear direcciones de 128 bits como IPv6.

Otro tema importante es la seguridad. En la década de 1990 nació la primera banca electrónica. Esta información sería útil para crear un protocolo de seguridad como IPSec (nacido más o menos en 1995) integrado en TCP / IP.

En conclusión, es imposible predecir el futuro. Probablemente, en 40 años, si podemos viajar a 1977 en otro momento, la información que proporcionamos a los investigadores será absolutamente diferente. Esta es la razón por la que creo que necesitamos desarrollar nuevos protocolos en lugar de solucionar los problemas actuales de TCP / IP.
¿Por qué no desarrollar un TCP / IP 2?

Para mejorar la seguridad de TCP, hablaría sobre el ataque de número de secuencia que Morris descubrió ocho años después.

En realidad, la solución adecuada para estos ataques es la autenticación criptográfica [RFC4301] [RFC4120] [RFC4251].

Como han señalado Stan Hanks y Erik Fair, en ese momento había muchas limitaciones de lo que se podía hacer con la tecnología disponible.

Como Tony Li sugirió, habría sugerido extender la longitud del campo de IP, pero aparte de las limitaciones tecnológicas, me surge otra pregunta: ¿serían suficientes 64 bits de todos modos?

Lo que habría propuesto sería diseñar algo similar a los encabezados de extensión en IPv6 pero solo para los campos de IP. Tal vez de esa manera podríamos haber comenzado a usar IP de 32 bits y, a medida que la Ley de Moore entra en juego, pasar a direcciones más largas sin rediseñar el protocolo IP y mantener la compatibilidad con versiones anteriores.

En TCP hubiera sido genial tener algún tipo de mecanismo para que se comportara de manera diferente en las redes de tuberías con fugas , tal vez solo sea un poco tolerante con la pérdida de paquetes antes de activar mecanismos para evitar la congestión o usar gradientes de retraso en lugar de la pérdida de paquetes, pero creo que el esto último no habría sido posible para ese momento. Además, la coexistencia de mecanismos para evitar la congestión basados ​​en pérdidas y demoras podría haber sido un problema (ver http://caia.swin.edu.au/cv/dahay …).

Si pudiera viajar a 1977, me concentraría en explicar la importante restricción (agotamiento de la dirección) que se sufre hoy en día con IPv4 (motivo de preocupación desde los años 80). La respuesta que le propondría a este gran problema es la implementación de IPv6. El uso de esta extensión conservadora IPv4 aumenta la capacidad extendida de direccionamiento para resolver este problema, pero con esta solución no se pudo llevar a cabo debido a la tecnología de ese tiempo (la longitud de las direcciones IPv6 es de 128 bits y solo 32 bits están disponibles). Podríamos centrarnos en la solución de modificar / eliminar algunos campos teniendo en cuenta la tecnología de ese año para aumentar la longitud de bits para direcciones o explicar tecnologías como NAT (Network Address Translation), que es una herramienta destinada a retener las asignaciones de espacio de direcciones globales contra IPv4 abordar el agotamiento y poder usar estas herramientas correctamente.