[LAC-TF] Seguridad y Direccionamiento IPv6

Tue 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 at 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 at si6networks.com
>>> <mailto:fgont at 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 at si6networks.com <mailto:fgont at si6networks.com>
>>>     PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     LACTF mailing list
>>>     LACTF at lacnic.net <mailto:LACTF at lacnic.net>
>>>     https://mail.lacnic.net/mailman/listinfo/lactf
>>>     Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>     <mailto:lactf-unsubscribe at lacnic.net>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> 
> 
> 