[LAC-TF] Seguridad y Direccionamiento IPv6

[Carlos M. Martinez]

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
>