#83 Todos los dispositivos con IPv6 tienen también una dirección IPv4.
No necesariamente. Son dos protocolos diferentes y hay que mantener y configurar los dos por separado si quieres. Se suele hacer así pero en mi opinión ha sido la causa del fracaso de IPV6: si no te queda otra que tener los dos, ¿para qué molestarse en poner el nuevo?
Y si no tienen, pueden usar 464XLAT
No lo había visto nombrar. He encontrado un post sobre esto en mikrotik:
#81Un dispositivo con IP 10.0.0.1 no puede conectarse a un dispositivo con IP 2222.10.0.0.1, sin una capa de traducción. Exactamente igual que IPv6.
Claro, pero puedes conectarlo a la red IPV8 (cosa que con IPV6 no se puede) y seguirá pudiendo acceder a lo mismo que accedía antes. Eso te permite hacer que toda red nueva tenga el protocolo nuevo sin afectar a lo que antes funcionaba. Y si en la red local elijes el juego de IPV8 adecuado, se mantendría la conectividad con dispositivos IPV4 sin problema.
#79Todo lo que estamos diciendo ya se puede hacer y se hizo con IPv6.
No, porque los equipos no vienen con IPV6 exclusivamente. Ha sido necesario mantener los dos protocolos. IPV6 no es un reemplazo directo a IPV4 porque si lo conectas a una red IPV4 no funciona. Lo que se busca es que un dispositivo que solamente tenga IPV8 pueda conectarse a una red IPV4 y siga funcionando.
Por otro lado, si tienes un dispositivo que sólo soporta IPV4 no puede conectarse a una red IPV6. Sin embargo sí podría conectarse a una red IPV8.
Imagina que en tu trabajo tienes que montar una red nueva. La montas con IPV8 y listo. Cuando venga el técnico de la alarma y te ponga una alarma que funciona con IPV4 no tienes que hacer nada, funciona de forma transparente. Mientras tanto tus ordenadores con Linux que seguramente sería el primero en soportarlo, funcionarán con IPV8, los windows tendrán IPV4 como siempre hasta que salga la siguiente versión, y aunque tengas algunos con uno y otros con otro, podrían comunicarse entre ellos.
Puedo acceder a mi red local desde cualquier sitio sin VPN ni nada, con conexión directa a los contenedores Docker, y no tengo que preocuparme de abrir puertos.
Sí, esa es una gran ventaja de IPV6, aunque hay que tener cuidado en el firewall.
Y no fue mucho más difícil que montar IPv4.
Bueno, no tiene por qué ser más difícil. Pero ya te digo que he leído de problemas por muchas partes.
#77Y, como IPv8 no trae nada nuevo, pues no va a tener más éxito.
Tal como lo plantean, sería un reemplazo de todo el stack IP. O sea que si se adoptara, los dispositivos empezarían a venir sólo con IPV8. A medida que quedaran obsoletos los equipos antiguos la red terminaría compuesta totalmente por dispositivos IPV8.
Lo que están diciendo es que cada red IPv8 tiene que tener una capa de traducción para conectarse al Internet IPv4.
Más bien es un encapsulado. Si tienes que mandar un paquete y el otro extremo sólo soporta IPV4, lo encapsula y lo envía. Si el siguiente salto soporta IPV8 lo desencapsula y continúa como si nada. Tal vez esté confundido pero me pareció entender eso.
Entonces IPv8 no es compatible con IPv4: un dispositivo con solo IPv4 no puede entender un paquete IPv8
Claro que no. Pero el dispositivo IPV8 se da cuenta de que el otro equipo sólo soporta V4 y encapsula el paquete para que pueda continuar viaje.
Lo mires por donde lo mires, esta chapuza de protocolo no tiene ningún sentido. Y me preocupa lo convencida que está la gente en los comentarios.
Yo no es que estoy convencido... más bien estoy "esperanzado". Es que si 30 años después estamos como estamos, queda claro que IPV6 es un caso perdido. Desde que salió hace tantos años cada vez que he configurado una red me he planteado probar con IPV6, y cada vez lo he descartado por ser una complicación que no da ninguna ventaja. Incluso me he planteado probarlo en mi casa que puedo trastear todo lo que quiera. En casa tengo un router mikrotik que es mucho más avanzado que cualquier router que pongan las operadoras pero he terminado por descartar la idea.
¿Tu usas IPV6 en alguna red? ¿Qué experiencia puedes contarme?
#75Por que la gente no quiere cambiar lo que funciona, e IPv4 con parches, por ahora funciona.
Es que no me refiero a equipos que estén ahí desde hace 30 años. Me refiero a que por ejemplo si hoy mismo, en plena segunda década del siglo 21, se monta una nueva red digamos para una empresa, lo más seguro es que se monte sobre IPV4.
O que si compras novedosos dispositivos IOT para tu "hogar inteligente", es muy probable que sólo funcionen en IPV4. De hecho he leído de gente que ha tenido muchos problemas con dispositivos Tuya y Home Assistant si la red es IPV6.
ARP no cruza las fronteras de la red local.
Por lo que leí, justamente esa es la idea: cada tramo local funciona como puede y se las arregla de forma transparente. No te importa si el siguiente dispositivo soporta o no el nuevo standard: el protocolo se arregla solito para que el tráfico llegue.
Entonces estamos de acuerdo en que no son compatibles.
No se si hablamos de lo mismo: lo que pretende esta gente con el nuevo protocolo es que incluso si la red no es compatible, funcione igual.
#71No, hay un montón de tecnologías para permitir la retrocompatibilidad: 6rd, NAT64, 464XLAT, 6to4, etc
Entonces explícame por qué 30 años después menos de la mitad del tráfico es IPV6.
ARP aquí no pinta nada
El ARP se usa para determinar si el destinatario soporta o no el protocolo extendido. Si no lo soporta, se encapsula el tráfico en IPV4 automáticamente.
Un dispositivo que solo conozca IPv4 no puede leer un paquete IPv8.
Claro, por eso hay un mecanismo para detectarlo automáticamente.
#67un dispositivo con solo IPv4, no puede enviar paquetes a un servidor IPvX sin una capa que traduzca las direcciones
Por lo que leo, la propuesta es justamente que el dispositivo IPV8 pueda recibir sin problemas IPV4. Incluso se prevé una forma de que el tráfico IPV8 pase por redes IPV4 sin tener que configurar nada especial.
Te puedo asegurar que cualquier idea que se te ocurra ya se ha aplicado en IPv6.
A mi me parece que habrán discutido alternativas y al final decidieron que para no complicarlo, sería mejor crear IPV6 sin retrocompatibilidad haciendo que los dispositivos tengan doble stack, que es lo que tenemos hoy.
Exactamente lo mismo que pasa con este supuesto IPv8.
Pero en este caso la selección es totalmente automática y transparente: los dispositivos determinan automáticamente lo que soporta su interlocutor en el momento de hacer el ARP,
O sea, que se elimina la necesidad de mantener dos protocolos incompatibles. El nuevo protocolo sabría responder al antiguo si es necesario y el nuevo protocolo puede usar las redes antiguas cuando no hay otra alternativa.
#62Es que lo que hay que cambiar primero es la red del cliente. El servidor es lo último que cambias.
Claro. Y lo que ha ocurrido es exactamente lo contrario: han pasado los años y los clientes se han mantenido en IPV4 mientras que de a poco se iba poniendo servidores con IPV6.
Yo incluso hace años hice la prueba de instalar un túnel de los que te dan IPV6 gratis. Funcionó pero resulta que el ordenador daba preferencia al conectar por IPV6. Eso parece una buena idea, pero ese túnel me daba mucha menos velocidad que la salida directa de mi proveedor. Lo quité y listo.
#61Por que es imposible. En IPv4 no puedes tener más de 32 bits de dirección.
Al parecer es la idea de este nuevo protocolo que proponen. Se me ocurren ideas pero bueno. El hecho es que IPV6 se pensó como un protocolo totalmente nuevo sin retrocompatibilidad. Si tu dispositivo funciona con IPV6 solamente y recibe un paquete IPV4 no tiene manera de procesarlo, lo cual obliga a que todo dispositivo soporte los dos. Eso hizo que IPV4 sea totalmente obligatorio hasta que no quede en internet ningún dispositivo que solo soporte IPV4. Cosa que por lo visto no va a ocurrir nunca.
#114 Bueno, hacer una distro nueva no es nada tan complicado. De ahí a que realmente termine reemplazando a los windows, no sabemos. Siempre habrá quejas. Si de hecho cuesta que la gente pase de un windows a la siguiente versión, imagina si les pides que pasen a otro sistema con algunas diferencias. Y mucho peor si les dicen que no tendrán su amado Microsoft Office.
#17 La que tiene más alcance y mejor propagación es la onda media que van a quitar. Y encima los receptores son más simples y consumen menos baterías, son ideales para emergencias, llevan funcionando perfectamente desde hace décadas y los putos subnormales lo van a desmantelar y encima poco después de un apagón histórico que ha dejado el país entero a oscuras
#17 puede ser, pero con visión directa entre el receptor y del emisor. Al transmitir en una frecuencia muy superior (alrededor de los 200mhzb frente al 88-108 de la FM) es mucho más susceptible a los accidentes geográficos y se producen zonas de sombra. Incluso en la ciudad cerca de la antena, detrás de una colina o entre calles puedes perder la cobertura fácilmente. Basta con ver el mapa de cobertura de #29, en las zonas de costa se adentra en el mar porque no hay ningún obstáculo, y en Bilbao que es un valle apenas sigue la línea del río.
#13 no, yo también he escuchado, esa misma vez que digo a reino unido, francia y rusia, a parte de las de china. fue el año pasado y no creo que hayan dejado de emitir
#16 Falso... hoy en día con C++ moderno (C++11, C++14, C++17, C++20) no tienes que tener mayor carga mental que con otros lenguajes de alto nivel actuales. y los compiladores actuales son muchisimo mejores y si te avisa de muchisimas cosas...
#130 Se quedan "guardados" en su entorno/memoria. Luego puedes convertirlos en archivos al darle a "guardar", si quieres, pero si pones algo, ahí se queda, como si fuera un archivo, y puede estar varios años que ahí sigue
#180 Lo que decían que había hecho y dejado de hacer ya se sabía de hace tiempo a poco que hubieras leído las noticias en su momento y seguido el juicio mínimamente.
Segundo, he leído otro artículo sobre lo mismo, no necesito leer este en concreto.
No necesariamente. Son dos protocolos diferentes y hay que mantener y configurar los dos por separado si quieres. Se suele hacer así pero en mi opinión ha sido la causa del fracaso de IPV6: si no te queda otra que tener los dos, ¿para qué molestarse en poner el nuevo?
Y si no tienen, pueden usar 464XLAT
No lo había visto nombrar. He encontrado un post sobre esto en mikrotik:
forum.mikrotik.com/t/nat64-and-464xlat-on-ros-how-to/267046
Por lo que veo es complicada la cosa. Incluso mete una máquina viertual con un linux para resolverlo.