[lacnog] Implementação do IPv6 at CERN

Vie Jul 26 16:06:56 -03 2024

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>
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> 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 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> 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>
>> 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> 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> 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> 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
>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>>
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> 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
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> 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
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> _______________________________________________
> LACNOG mailing list
> 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.
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20240726/89c0ef50/attachment-0001.htm>