[lacnog] Implementação do IPv6 at CERN
Tomas Lynch
tomas.lynch en gmail.com
Sab Jul 27 18:29:54 -03 2024
Jordi, Henri y Uesley,
Les agradezco sus respuestas ya que ustedes son excelentes referentes de
IPv6: no solamente por lo que saben sino por lo que han implementado. Mis
puntos son exactamente los que han comentado y quería poner en discusión en
la lista. No quiero adelantar los temas del próximo LACNIC/LACNOG pero muy
probablemente hablemos más de implementación que de teoría.
Saludos,
Tomás
On Fri, Jul 26, 2024 at 3:59 PM jordi.palet--- vía LACNOG <lacnog en lacnic.net>
wrote:
> 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> 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
>>
>
>
> **********************************************
> 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/20240727/fab797bc/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG