[lacnog] Implementação do IPv6 at CERN

Vie Jul 26 16:59:01 -03 2024

Hola Tomas,

No diría que sea “egoísta" lograr que en todas las redes haya mas tráfico IPv6, empezando por la de cada uno, ya que es bueno para la comunidad!

Es cierto que los mayores “contribuyentes” al tráfico IPv6 global son los grandes proveedores de contenidos, y es 100% normal, porque son los “grandes” proveedores de contenidos de forma global, nada de magia, solo estadística. Y por eso cuando se habilita IPv6 en una red residencial donde el tráfico mayoritarios es para esos proveedores de contenidos, el tráfico mayoritario pasará a ser IPv6 en la misma proporción - salvo que tengamos por ejemplo smartTVs antiguos que sean solo IPv4.

No son solo unos pocos AAAA o dominios, hay muchos. Quizás Meta (por ejemplo), solo tiene “uno grande”, pero Google tiene muchos, y aparte tenemos a varios proveedores de video, clouds, etc., etc.

Para que en nuestras redes tengamos un % mayor de tráfico IPv6, se tiene que dar el caso que, ademas de estar bien desplegado (los puntos que antes mencioné), y por tanto sea accesible desde IPv6 sin penalización o menor digamos que de 100-150ms (puede variar en función de la implementación de HE en el cliente) respecto de IPv4, desde donde estén ubicados los clientes.

Un detalle que tb puede ser importante (para HEv2) es si las consultas DNS penalizan de algún modo (caches o algo mal configurado), a los tiempos de respuesta para un AAAA respecto del A correspondiente (de nuevo tiene que ser mucho mas de x ms).

En tu caso concreto, no se cuanto tráfico llega desde redes móviles que ya tienen IPv6 (y si esas redes móviles están funcionando bien con IPv6), y en la mismas condiciones cuanto desde redes fijas, si hay proveedores de tránsito involucrados extremo-a-extremo diferentes del “infame” con el que nadie quiere hacer peering …, cuales son las aplicaciones (tienen por defecto preferencia por IPv6 o hay que configurar un flag, o HE nos la esta “jugando” y no vemos el problema), hay CDNs involucradas y tienen activo IPv6, el routing es igual para IPv4 que para IPv6, etc. ...

Creo que no estoy diciendo nada “nuevo”, solo un paso a paso para verificar donde esta el problema y como he repetido muchas veces, HE nos ayuda a “esconderlo”, desafortunadamente.

Ahora nos ponemos en marcha tras muchos años que llevo insistiendo en IETF (https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-he-reporting/00/), para arreglarlo … pero llevara 1-2 años mas, junto con la v3 de HE que ya no solo tendrá en cuenta IPv4/IPv6, sino también HTTP3/QUIC (https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-v3/01/).

Saludos,
Jordi

@jordipalet

> El 26 jul 2024, a las 12:06, Tomas Lynch <tomas.lynch en gmail.com> escribió:
> 
> Jordi,
> 
> Muchas gracias por la respuesta. Quería poner la discusión en la lista porque tengo un motivo muy egocéntrico: el tráfico IPv6 en mi red totalmente Dual Stack no llega al 10% y quiero saber que estoy haciendo "mal". Por otra parte, cuando vemos estadísticas sobre "el tráfico IPv6 llega al 50% mundialmente!!!" en realidad debería decir "el tráfico IPv6 (de las CDNs más importantes del mundo que tienen 4 o 5 dominios con sus correspondientes AAAA) llega al 50% mundialmente!!!"
> 
> Saludos,
> 
> Tomás
> 
> 
> On Fri, Jul 26, 2024 at 2:25 PM jordi.palet--- vía LACNOG <lacnog en lacnic.net <mailto:lacnog en lacnic.net>> wrote:
>> Hola Tomas,
>> 
>> Si, yo doy por sentados los siguientes pasos (asumiendo que IPv4 ya existe y funciona entre un determinado cliente y un servidor):
>> 1) El servidor tiene que tener buena conectividad IPv6.
>> 2) El servidor tiene que tener sus correspondientes RR AAAA.
>> 3) El cliente tiene que tener soporte de IPv6 y buena conectividad IPv6.
>> 4) El transito entre el cliente y el servidor tiene que permitir “buena conectividad” IPv6, por ejemplo no puede estar filtrado PMTUD. En caso de estar filtrado PMTUD, no solo podría no funcionar IPv6, sino no permitir hacer fall-back a IPv4 - he visto muchos casos de esto.
>> 
>> Si todo esto se cumple, y la aplicación que usemos para alcanzar a esos AAAA tiene soporte IPv6, hay varios posibles escenarios:
>> a) Que la aplicación tenga un flag para usar solo IPv6 siempre, o darle preferencia a IPv6 salvo caso extremo (y puede que haga o no fall-back a IPv4).
>> b) Que la aplicación o el SO use HE y en caso de un determinado mayor retardo de IPv6 frente a IPv4, haga fall-back a IPv4.
>> 
>> Para que haya mas tráfico IPv6, en el caso a, creo que es obvio que va a ser lo habitual, salvo que el mecanismo de fall-back determine que el retardo es inaceptable (o que ni siquiera llega).
>> 
>> En el caso b es un poco mas complicado, y precisamente por eso en el IETF estamos trabajando en un WG especifico de Happy Eyeballs, porque hay casos de fall-back, por razones diversas (tanto en el lado del cliente, como del servidor, como del transito), que hacen que haya fall-back a IPv4 y no hay ningún reporte para que la parte “culpable” lo sepa y pueda resolverlo. Hace años que yo tengo varios drafts precisamente para hacer reporting de “HE-failures”.
>> 
>> En la redes académicas, como las que usa CERN, donde hay anchos de banda muy grandes, es realmente extraño que IPv6 no funcione bien, y por lo tanto si las apps permiten IPv6 (y/o se les configura como preferido, que es lo que cabe esperar atendiendo a la definición de como funciona doble-pila), es fácil que IPv6 sea el tráfico mayoritario.
>> 
>> En redes “normales” (las que todos usamos de Internet), a veces las apps, o los CDNs (las propias CDNs ven problemas de “calidad” en la red IPv6 y desconfiguran los AAAAs), no están correctamente configurados para permitir que IPv6 sea preferido, y sobretodo, actúa HE y nos hace fall-back sin que nadie tenga reporte de eso.
>> 
>> Ejemplo real: El tráfico de India, en muchos casos prefiere IPv4, porque el routing esta tan mal configurado que suele ir a través de UK para IPv6 (y es mas director para IPv4), y por tanto es mas lento que IPv4, por lo que HE determina que así debe ser.
>> 
>> Uno de los problemas que mas a menudo encuentro en despliegues de IPv6 es que, básicamente no están bien hechos, y sobretodo, no está monitorizándose bien los enlaces o el tráfico IPv6 (aunque sean los mismos porque sean doble-pila), y puede incluso haberse caído IPv6, nadie se da cuenta o lo reporta, porque HE lo esconde.
>> 
>> Hubo un caso en un país de Centroamérica hace pocos años, en que uno de los upstreams providers del proveedor dominante tenia la parte IPv6 caída desde hacia 2 años, y no lo sabia (no se monitorizaba) … Así que parte del tráfico que debería ir con IPv6, se bajaba a IPv4.
>> 
>> RESUMEN: No basta con desplegar IPv6, hay que hacerlo BIEN (no como lo hacemos con IPv4, porque no son lo mismo - Para aprender IPv6 hay que desaprender IPv4), y hay que monitorizar *en todos los aspectos* que IPv6 este funcionando bien en todas nuestras redes, al igual que lo hacemos con IPv4.
>> 
>> Saludos,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 26 jul 2024, a las 10:42, Tomas Lynch <tomas.lynch en gmail.com <mailto:tomas.lynch en gmail.com>> escribió:
>>> 
>>> Henri y Jordi,
>>> 
>>> Me parece que me estoy expresando mal. Lo que quiero decir es que no alcanza con ponerle IPv6 a una máquina para que haya más tráfico IPv6. Obviamente es el primer paso pero tiene que venir acompañado de DNS: agregar los AAAA en el DNS. Si yo tengo www.alfajorlittlegeorge.com <http://www.alfajorlittlegeorge.com/> y lo único que tengo es una entrada A, ese servidor por más IPv6 que tenga nunca va a recibir tráfico.
>>> 
>>> Por ahí es una obviedad lo que digo, pero no sé si todo el mundo lo sabe o si configurar AAAA es lo único que tengo que hacer para que haya más tráfico IPv6. Quiero saber en su experiencia cuáles son los otros pasos a seguir para que haya más tráfico IPv6 que IPv4 en una red dual stack.
>>> 
>>> Saludos,
>>> 
>>> Tomás
>>> 
>>> 
>>> 
>>> On Fri, Jul 26, 2024 at 11:03 AM Henri Alves de Godoy <henri.godoy en fca.unicamp.br <mailto:henri.godoy en fca.unicamp.br>> wrote:
>>>> 
>>>> A partir do momento que se torna dual-stack, apesar de ainda estar com IPv4, a preferência é do IPv6, principalmente quando você configura como default, na maioria dos serviços.
>>>> 
>>>> A grande medição foi com relação a transferência de dados de pesquisa e seu mega sistema de storage dCache que passou a trafegar preferencialmente em IPv6.
>>>> 
>>>> O CERN não fez nada de mais que todos devemos fazer, e demonstrou o aumento do tráfego IPv6 latente.
>>>> 
>>>> Por aí percebemos que mudanças mínimas que muitos resistem em fazer em seus sistemas operacionais e aplicações, podem aumentar muito o tráfego em IPv6, pois mais da metade de todo tráfego global fala e ouve IPv6  :-)
>>>> 
>>>> Abraços !
>>>> 
>>>> 
>>>> 
>>>> Em sex., 26 de jul. de 2024 às 11:47, Tomas Lynch <tomas.lynch en gmail.com <mailto:tomas.lynch en gmail.com>> escreveu:
>>>>> Henri,
>>>>> 
>>>>> Uno puede tener una red dual stack completa: todos los elementos de red con una dirección IPv4 y una IPv6, happy eyeballs, etc. Pero eso no alcanza para que el tráfico IPv6 sea mayor que el de IPv4. Obviamente que si lo único que tienes es IPv6, entonces el tráfico será mayor. Pero en un ambiente como el CERN, que según entiendo es Dual Stack, ¿qué es lo que asegura que el tráfico IPv6 sea mayor que el de IPv4? ¿O simplemente CERN migró muchos de sus servicios a IPv6-only?
>>>>> 
>>>>> Saludos,
>>>>> 
>>>>> Tomás
>>>>> 
>>>>> On Fri, Jul 26, 2024 at 10:41 AM Henri Alves de Godoy <henri.godoy en fca.unicamp.br <mailto:henri.godoy en fca.unicamp.br>> wrote:
>>>>>> Tomas,
>>>>>> 
>>>>>> Na apresentação realizada ontem, o CERN tem realizado muitas ações nos últimos 5 anos, evitando ao máximo o NAT, habilitando dual-stacks em vários serviços, dando preferência para o IPv6 em muitas configurações default, como aplicações, sistemas operacionais.
>>>>>> 
>>>>>> Após essas mudanças, principalmente na transferência de dados, houve um nítido aumento do tráfego em IPv6.
>>>>>> 
>>>>>> Com isso a redução do tráfego IPv4 está sendo notado e vemos um grande avanço e as vantagens para a pesquisa na transferência de dados.
>>>>>> 
>>>>>> Abraços !
>>>>>> Henri
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Em sex., 26 de jul. de 2024 às 11:27, Tomas Lynch <tomas.lynch en gmail.com <mailto:tomas.lynch en gmail.com>> escreveu:
>>>>>>> Henri,
>>>>>>> 
>>>>>>> ¿Cuál es la causa de que sea superior? Justamente en LACNOG, si es aceptado, voy a presentar una análisis de tráfico IPv6 y cuál es la causa de que sea tan bajo a pesar de tener IPv6 desplegado en la red.
>>>>>>> 
>>>>>>> Saludos,
>>>>>>> 
>>>>>>> Tomás
>>>>>>> 
>>>>>>> On Fri, Jul 26, 2024 at 7:27 AM Henri Alves de Godoy <henri.godoy en fca.unicamp.br <mailto:henri.godoy en fca.unicamp.br>> wrote:
>>>>>>>> 
>>>>>>>> Bom dia a todos.
>>>>>>>> 
>>>>>>>> Compartilho a apresentação dos avanços e desafios da implantação do IPv6 no CERN.
>>>>>>>> 
>>>>>>>> Feliz em saber que o tráfego IPv6 tem sido muito superior que o IPv4.
>>>>>>>> 
>>>>>>>> Saludos !
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> LACNOG mailing list
>>>>>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>>> _______________________________________________
>>>>>>> LACNOG mailing list
>>>>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> _______________________________________________
>>>>>> LACNOG mailing list
>>>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>> 
>>>> 
>>>> --
>>>> 
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com <http://www.theipv6company.com/>
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>> 
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20240726/f3586925/attachment-0001.htm>