[lacnog] Implementação do IPv6 at CERN

Vie Jul 26 15:25:23 -03 2024

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 <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
> 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/71d5ccae/attachment-0001.htm>