[lacnog] [LAC-TF] Seguridad y Direccionamiento IPv6
Carlos M. Martinez
carlosm3011 en gmail.com
Mar Sep 9 10:02:11 BRT 2014
100% de acuerdo Ale :-)
Como datapoint, cuando armamos la red de los eventos de LACNIC, el IPv6
casi nunca genera problemas. Sufrimos mucho mas con los WLAN
Controllers, el firmware de los access points y los cableados de pésima
calidad de los hoteles que con el IPv6.
s2
C.
On 9/9/14 1:20 AM, Alejandro Acosta wrote:
> Hola,
> Como dice Carlos este caso creo que lo sacaron de proporcion.
> Estuve siguiendo el thread que hablaba sobre
> http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week
> en nanog y luego lo pasaron a la IETF.
> Trabaje cerca de 18 anos en operadores de red y perfectamente pude
> haber escrito cientos de cosas similares en redes IPv4, podia hasta
> decir que se consumieron mi semana, mi mes y hasta varios meses.
> Tambien llame a los vendors y me pusieron ingenieros en sitio, tuve
> conferencias telefónicas, tele-presencias, asistencia remotas, cambios
> de hardware, de software y mucho mas. Puedo decir con certeza que tuve
> problemas en casi todas las tecnologias adyacentes o en las tangentes
> a IP: en routing (basico, medio y avanzado), en ARP, en STP, en SIP,
> h323, QinQ, DNS, QoS, SNMP, http, smtp, etc, etc.... bueno, bueno,
> tampoco me voy a quedar guindado en esto, seguro todos han pasado por
> cosas parecidas.
> Ahora, regresando al articulo me parece que esta muy completo pero
> aun asi queria saber mas, tener mas informacion, tener trazas,
> topologia, configuraciones que es evidente que nunca las veremos.
>
> Mis comentarios los enmarco en:
>
> - No siempre es el vendor
> - No todo se arregla con patchs.
> - No todos los problemas son bugs (jajaja, esta es la mas facil, como
> lo dicen por alli)
> - La red no es solo capa 3, en el mismo articulo hablan mucho sobre
> Spanning Tree (uff, mi profundo respeto a STP!!), loops de bridge y
> esas cosas
> - Recuerden que a veces es capa 8 los problemas.
>
> Abrazos,
>
> Alejandro,
> P.D Reconozco que una vez estuve con un importante cliente que tenia
> una red mediana, Routers y Firewalls de ultima generacion, HSRP,
> protocolo de enrutamiento dinamico, todos los periquitos
> espectaculares pero unos Lan Switch 3com de hace mas de 15 anos,
> compro unas super impresoras ultimo modelo que tenian IPv6 por default
> y tumbaba la red constantemente. Se quito IPv6 en las impresoras y
> voila. Esto fue en Feb del 2013.
>
>
> 2014-09-08 22:47 GMT-04:30 Carlos M. Martinez <carlosm3011 en gmail.com>:
>> Comparto lo que dice Fernando, pero tambien es cierto que me parece que
>> la persona que escribe eso saca los problemas de proporcion.
>>
>> Uno tiene que ser consciente del hardware que tiene y de sus
>> limitaciones. Y esto no es solo cierto para IPv6, es cierto para
>> cualquier feature que uno quiera habilitar.
>>
>> Siempre van a haber redes o personas que tengan mas o menos problemas.
>>
>> s2
>>
>> -Carlos
>>
>> On 9/8/2014 6:00 PM, Erick Lobo Marín wrote:
>>> Fernando, me inquieta
>>> <http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/>
>>> tanto el problema como la solución de eliminar IPv6...
>>> Varios de los problemas indicados son "neighbor discovery", el mecanismo
>>> de privacidad IPv6 en "comunión" con una implementación "raw" del código
>>> IPv6.
>>> En este caso particular crees que una de las soluciones propuestas de
>>> utilizar DHCPv6 en lugar de SLAAC (y el mecanismo asociado de
>>> privacidad) hubiera sido un "work around" y mantener extendido el uso de
>>> IPv6?
>>>
>>>
>>>
>>> Atentamente,
>>> Erick Lobo
>>>
>>> lgD
>>>
>>> El 8 de septiembre de 2014, 2:47, Fernando Gont <fgont en si6networks.com
>>> <mailto:fgont en si6networks.com>> escribió:
>>>
>>> Estimados,
>>>
>>> [para quienes solo estén interesados en la parte de ops, saltar a lo
>>> marcado con asteriscos más abajo]
>>>
>>> El pasado 5 de septiembre, en el contexto de IEAR 2014
>>> <http://43jaiio.sadio.org.ar/?q=IEAR>, realicé la siguiente presentación
>>> <http://www.si6networks.com/presentations/iear2014/fgont-iear2014-ipv6-addressing.pdf>
>>> (slide 9 solo para "endendidos" ;-) ).
>>>
>>>
>>> Al final de la presentación se planteó una discusión con dos Directores
>>> de Area de IETF, en la cual básicamente se argumentaba que la solución a
>>> los problemas mencionados era utilizar RFC4941 (direcciones temporales),
>>> haciendo que las mismas *nunca se vuelvan invalidas* si hay alguna
>>> conexion TCP utilizandolas. Tal como lo mencioné en su momento,
>>> personalmente creo que eso es equivocado (conceptualmente) asi como
>>> también impracticable -- y el blog post de abajo, parece ser un
>>> datapoint interesante en este aspecto...
>>>
>>>
>>> **** Cuestiones Operacionales ****
>>>
>>> Irónicamente, acabo de recibir el siguiente enlace:
>>> <http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/>
>>>
>>>
>>>
>>> Algunos datos interesantes:
>>>
>>> * RFC7217 -- que basicamente es lo que uno usaria para mitigar
>>> cuestiones de seguridad/privacidad, incluso deshabilitando RFC4941 --
>>> fue bastante doloroso de publicar...
>>>
>>> *
>>> <http://tools.ietf.org/id/draft-gont-6man-managing-privacy-extensions-01.txt>
>>> podría haberse utilizado para solucionar este problema sin necesidad de
>>> configuración manual, ni deshabilitar IPv6... pero tuvo oposición de
>>> algun fabricante por ahí.
>>>
>>>
>>> Me embriague hasta el vacio
>>> con tu miel venenosa
>>> fuiste mia
>>> y el hastio
>>> nos llevo al desengaño
>>> y eso paso
>>> Fue
>>>
>>> (<https://www.youtube.com/watch?v=3qW9ygULVbc>)
>>>
>>> Saludos cordiales,
>>> --
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: fgont en si6networks.com <mailto:fgont en si6networks.com>
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF en lacnic.net <mailto:LACTF en lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>>> <mailto:lactf-unsubscribe en lacnic.net>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>
>
>
Más información sobre la lista de distribución LACNOG