[LAC-TF] Fwd: RFC 7217 on A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

[Carlos M. Martinez]

Igual, no creo que deshabilitar sea una buena recomendación, ya que el 
stack esta ahí y no es cierto que los administradores controlen el 100% del 
hardware que se.conecta a sus redes, mas en una epoca donde el BYOD cobra 
cada vez mas adeptos.

S2

Carlos

Sent with AquaMail for Android
http://www.aqua-mail.com


On May 12, 2014 7:04:23 PM Arturo Servin <arturo.servin at gmail.com> wrote:

> Para evitar que en una infraestructura de solo IPv4 te metan un "gol"
> usando IPv6. Sin embargo contrario a la opinion del autor :)  mi
> preferencia es que en lugar de deshabilitar la gente se ponga las pilas e
> implemente IPv6 como se debe.
>
> Pero en gustos se rompen generos.
>
> Slds
> as
>
>
>
> 2014-05-12 7:53 GMT-07:00 Erick Lobo Marín <erick.lobo at cgr.go.cr>:
>
> > Buenos días, ¿por qué se deshabilita en la Enterprise?, será para que los
> > sistemas perimetrales (firewall, ids...) de seguridad tengan más "certeza"
> > al aplicar las políticas de seguridad sobre éstas?
> >
> > Atentamente,
> > Costa Rica
> > Erick Lobo
> >
> > lgD
> >
> >
> > El 11 de mayo de 2014, 13:19, Cristian F. Perez Monte 
> <cdlt23 at gmail.com>escribió:
> >
> >
> >>
> >>
> >> 2014-05-11 1:35 GMT-03:00 Fernando Gont <fernando at gont.com.ar>:
> >>
> >>> Hola, Erick,
> >>>
> >>> On 05/09/2014 05:01 PM, Erick Lobo Marín wrote:
> >>> > Fernando: ¿Qué tan aceptado es el método que ha implementado Microsoft
> >>> > en sus sistemas operativos Windows de generación aleatoria de la
> >>> > dirección IPv6 sobre el tiempo?
> >>>
> >>> Supongo que te referis a lo especificado en RFC 4941. En tal caso, te
> >>> diría que con el correr del tiempo ha sido mas y mas aceptado por
> >>> distintas plataformas -- aunque no todas ellas habilitan dichas
> >>> direcciones por defecto. Las que recuerdo (de memoria) que implementan
> >>> RFC 4941 son:
> >>>
> >>> * Windows
> >>> * FreeBSD
> >>> * OpenBSD
> >>> * Linux
> >>>
> >>>
> >>> Windows las habilita por defecto. FreeBSD no. Y el resto no recuerdo...
> >>>
> >>
> >> En linux dependiendo de distribución y versión de kernel, he visto con y
> >> sin habilitación de lo especificado en el RFC 4941.
> >> En el caso de NetBSD no estaría tan seguro que no lo implementa, creería
> >> que si, sucede que por defecto viene todo desactivado.
> >>
> >>>
> >>> Mas alla de la habilitacion por defecto, es de notar que al menos en
> >>> ambientes tipo Enterprise, este feature suele ser deshabilitado.
> >>>
> >>>
> >>>
> >>> > Considerando entre las razones de su uso el evitar el tracking de la
> >>> > dirección IP.
> >>>
> >>> RFC 4941 no evita, per se, el tracking, sino que lo ahce mas dificil.
> >>>
> >>> Cuando RFC4941 esta habilitado, se utilizan direcciones aleatorias para
> >>> las conexiones salientes... pero las direcciones "tradicionales"
> >>> (no-temporales) siguen ahí... por lo cual el tracking sigue siendo
> >>> posible (ni hablar del escaneo, etc.).
> >>>
> >>> Saludos, y gracias!
> >>> --
> >>> Fernando Gont
> >>> e-mail: fernando at gont.com.ar || fgont at si6networks.com
> >>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > _______________________________________________
> > LACTF mailing list
> > LACTF at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lactf
> > Cancelar suscripcion: lactf-unsubscribe at lacnic.net
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20140512/b9688ef0/attachment.html>