[lacnog] Problemas con conexiones entrantes de IPv6 en CPEs
Fernando Frediani
fhfrediani en gmail.com
Dom Sep 15 13:03:56 -03 2019
Hola a todos
Terminé no enviando una actualización sobre este tema, así que lo envío
a continuación.
Realicé algunas pruebas con respecto a los 2 puntos mencionados con
diferentes tipos de CPE a los que tuve acceso.
- Además de OpenWrt, que previamente había realizado la prueba al
liberar manualmente las conexiones entrantes con destino a IP en la
configuración del firewall, traté de simular el proceso de abrir estos
puertos IPv6 de manera 'automatizada' usando miniupnpc (cliente UPnP -
http://miniupnp.free.fr/) para hacer la solicitud y funcionó como se
esperaba, pero solo para OpenWrt 18.06 y superior.
- Para OpenWrt 17.01, aunque existe un soporte IPv6 bastante completo,
el daemon miniupnpd aparentemente no viene por defecto compilado con la
opción --igd2 que proporciona soporte completo para ACL IPv6 y PinHoles
(la funcionalidad utilizada para manejar este tipo de solicitud en IPv6).
- Para algunos CPE de TP-Link probados a pesar de haber el soporte de
navegación IPv6 no funcionaba automáticamente para UPnP / PCP y ni
siquiera había una opción en el menú para agregar reglas entrantes para
IPv6 en la LAN.Envié estas solicitudes de funciones al equipo que
desarrolla el firmware para los CPEs TP-Link y me respondieron diciendo
que agregarían soporte para ambos, pero sin ningún compromiso ni fecha
límite.
- En un RouterOS con UPnP habilitado tampoco funcionó. Preguntado
Mikrotik confirmó que no funciona y no le importó el problema. Jugó como
una posibilidad para la versión 7 como todo lo que le falta a RouterOS
(¡ríe!)
- También se probaron dos ONUs Vivo Fibra, una MitraStar GPT-2731GN2A4P
y una Mirastar GPT-2541GNAC-N1 con UPnP habilitado y tampoco funcionó.
Sin embargo, en este caso, la parte de Firewall funcionó para agregar
reglas específicas en IPv6 correctamente permitiendo el tráfico
destinado a alguna dirección IPv6 en LAN. Dependiendo del daemon UPnP
que utilicen en el firmware, solo es cuestión de actualizar la versión o
compilar con PCP y/o compatibilidad con IGD2.
Por lo tanto, parece que en algunos casos existe incluso un soporte
parcial y la falta de soporte para PCP puede ser un problema mayor a
medida que las aplicaciones se vuelven más compatibles con IPv6. Aunque
es posible liberarlo manualmente en algunos casos, esto dificulta onde
el prefijo delegado sea dinámico e onde el PCP se resolvería.
Fernando Frediani
On 31/07/2019 19:20, Fernando Frediani wrote:
> Hola jordi
> Gracias por la respuesta.
> Contestaré en línea sobre cada tema.
>
> XPTO es solo un nombre genérico para ejemplificar un dispositivo como
> Acme, Foo o Bob ;-)
>
> On 31/07/2019 18:55, JORDI PALET MARTINEZ via LACNOG wrote:
>> Hola Fernando,
>>
>> No entiendo muy bien que es XPTO, pero lo voy a contestar de forma
>> genérica.
>>
>> Con IPv6 no tiene sentido que los prefijos sean no-persistentes. En
>> IPv4 se hizo por una única razón: direcciones dinámicas porque no
>> había suficientes y se podían compartir (al principio los módems no
>> estaban permanentemente conectados).
> Personalmente, también me gusta la idea de distribuir prefijos fijos a
> los usuarios, pero hay varias razones técnicas y no técnicas que no
> siempre permiten que se haga de esa manera. Desde mi experiencia con
> los ISP en general, veo que la mayoría entrega lo PD de forma
> dinámica. No creo que eso cambie pronto.
>>
>> Si un ISP no cambia su forma de pensar, mejor que no despliegue IPv6,
>> porque NO le aporta valor, y que los clientes elijan un ISP que lo
>> haga correctamente. Que tampoco despliegue CGN, le sale mucho mas
>> barato comprar direcciones y seguir con el sistema de NAT tradicional.
>>
>> Es lo que siempre insisto del cambio de "chip" y creo que los
>> clientes son cada vez mas "expertos" como para saber lo que les
>> conviene.
>>
>> Recomiendo la lectura del RIPE690.
>>
>> Si el ISP despliega correctamente IPv6, con prefijos persistentes, se
>> abre la puerta a si mismo y a terceros (que pueden cooperar con el
>> ISP) para desarrollar y ofrecer servicios de forma sencilla, sin
>> complejidades de NAT, IP y DNS dinámico.
> Aunque lo ISP entrega los prefijos de PD de manera fija eso elimina
> solo el problema de las reglas de firewall estático, y la necesidad de
> usar DNS dinámico, pero el problema de PCP persiste para aplicaciones
> y CPE.
>>
>> Todas las soluciones que queramos inventar, son técnicamente
>> complejas e innecesarias, y solo harían que encarecer el precio de
>> todos los servicios. Si eso es lo que queremos, mejor nos quedamos
>> con IPv4. Espero que no desaprovechemos la oportunidad!
>>
>> Generalmente los CPEs tienen lo que los ISPs "piden". Los CPEs con
>> IPv4, originalmente no tenían firewall (configurable), y poco a poco
>> se fueron incorporando. No es algo complejo, especialmente porque la
>> mayoría de los fabricantes de CPEs usan OpenWRT como base (dado que
>> los fabricantes de SoC, los semiconductores de los CPEs también
>> desarrollan sus versiones basadas en OpenWRT, es algo publico y
>> conocido).
> Si el CPE no tiene al menos una configuración básica de firewall o
> UPnP/PCP funcionando correctamente, entonces tenemos un gran problema
> que restringe las conexiones IPv6 solo para la navegación a Internet
> sin cualquier posibilidad de conexiones entrantes.
>>
>> Así que, si un fabricante de CPE quiere incorporar el GUI al
>> firewall, es algo que *YA* esta hecho, no hace falta desarrollarlo,
>> como tu mismo has confirmado con OpenWRT.
>>
>> Es el mismo problema que hemos tenido con el soporte de IPv6-only e
>> IPv4aaS, que finalmente hemos resuelto con el RFC8585, donde también
>> hablamos de uPnP, PCP, firewall y todo lo que tu estas pidiendo.
>>
>> Ahora bien, si los ISPs, no lo piden, no servirá de nada.
> Por eso me interesa conocer la experiencia de las personas con estas
> situaciones con los usuarios. Si el ISP ya no tiene mas la capacidad
> de entregar IPv4 pública al usuario y recomienda al cliente el uso de
> IPv6, debe funcionar correctamente, es decir, también para las
> conexiones entrantes, ya sea a través de la configuración manual del
> firewall o automáticamente a través de un mecanismo como PCP...
>>
>> Yo diría incluso que los reguladores, como Anatel en tu caso,
>> deberían exigir que se vendan CPEs con soporte de determinados RFCs
>> (concretamente el RFC8585, que además obliga al soporte del RFC7084),
>> porque es su obligación *proteger* a los consumidores y evitar que se
>> les suministren (por parte de los ISPs) o vendan (por parte de la
>> cadena de distribución) equipos que, básicamente, no sirven, y mas
>> aún cuando no hay un incremento en el precio.
> Sí, desde hace algún tiempo, Anatel requiere que los fabricantes de
> dichos equipos tengan soporte IPv6 para ser aprobados y
> comercializados. Pero, ¿qué se entiende por soporte IPv6? ¿Solo
> navegación o también la posibilidad de conexiones entrantes? Esta es
> la discusión que estoy tratando de plantear.
>>
>> Saludos,
>> Jordi
>> @jordipalet
>>
>> El 31/7/19 19:28, "LACNOG en nombre de Fernando Frediani"
>> <lacnog-bounces en lacnic.net en nombre de fhfrediani en gmail.com> escribió:
>>
>> Hola a todos.
>> Le escribo para preguntarle algo sobre el uso de IPv6 en los
>> CPEs más
>> comunes que se encuentran en el mercado.
>> Un problema común con la transición a IPv6 en el mercado de
>> banda ancha
>> y el uso de CGNAT en conexiones de doble pila es que algunos
>> usuarios
>> solicitan que se les devuelva a IPv4 público porque tienen un
>> servicio o
>> dispositivo XPTO particular dentro de su casa o negocio y necesitan
>> acceder a ellos (DVR/NVR sin opción de cloud, SOHO Server,
>> sistema de
>> alarma, etc.). Sin embargo, esto no siempre es posible o el
>> usuario no
>> está dispuesto a pagar por el servicio y la única recomendación
>> posible
>> es verificar si el dispositivo que utilizan es compatible con
>> IPv6. Algo
>> que lo hace un poco más fácil es que la red móvil se está
>> volviendo más
>> compatible con IPv6 para que se pueda acceder desde dispositivos
>> móviles
>> Sin embargo, noté algunos problemas comunes que creo que los
>> fabricantes
>> de CPE y de dispositivos aún necesitan ajustar y me gustaría
>> preguntar
>> si otras personas han observado este compartimento en sus
>> escenarios.
>> 1) El dispositivo XPTO tiene soporte para IPv6 pero no
>> tiene soporte
>> para DNS Dinámico en IPv6 para actualizar la dirección recibida
>> del ISP
>> . Este también es un problema cultural que se volverá muy común
>> porque
>> los usuarios siempre se hayan acostumbrado a configurar DNS
>> Dinámico
>> solo en CPE y hacer que IPv4 NAT Port Forward e en IPv6 vayan
>> directamente al dispositivo al que se accede.
>> 2) Noté que muchos CPEs comunes en el mercado tienen bueno
>> soporte de
>> navegación IPv6 (conexiones salientes) pero no tienen un área de
>> configuración de Firewall IPv6 para permitir conexiones de paso a
>> dispositivos de red para que puedan recibir estas conexiones
>> entrantes
>> directamente.
>> Aunque tienen esta posibilidad de configuración, hay otra
>> cuestión que
>> deberia funcionar bien: ¿cómo vincular IPv6 da LAN en lo
>> dispositivo que
>> puede cambiar con el tiempo o con lo reboot del CPE con reglas de
>> firewall estáticas cuando el ISP no entrega un IPV6-PD fijo?
>> Una forma es que podría vincularse a una entrada DHCPv6 para el
>> hostname
>> del dispositivo, pero en este caso, ¿cómo asegurarse de que el
>> dispositivo que utiliza DNS dinámico envíe el IPv6 recibido de
>> DHCPv6 y
>> no de RA? También es posible liberar un puerto específico para
>> toda la
>> LAN, pero en este caso tendríamos problemas de seguridad.
>> 3) Para hacer este problema mucho más fácil, los
>> dispositivos y
>> aplicaciones que necesitan conexiones entrantes pueden enviar
>> señales a
>> CPE que lo necesitan a través del Port Control Protocol (PCP) si se
>> admiten que tanto CPE como las aplicaciones tienen este soporte.
>> ¿Alguien sabe si el soporte actual para UPnP contenido en las
>> CPEs ya
>> incluye este tipo de funcionalidad PCP para IPv6?
>> Realicé pruebas usando OpenWrt como firmware en CPE y
>> liberando los
>> puertos para lo IPv6 del dispositivo y funciona como se
>> esperaba, pero
>> como sabemos, la mayoría de los usuarios no tienen CPE de
>> OpenWrt. Me
>> gustaría conocer su experiencia en estos 3 escenarios.
>> Saludos cordiales
>> Fernando Frediani
>> _______________________________________________
>> 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
Más información sobre la lista de distribución LACNOG