<div dir="ltr">A todos muchas gracias, sus comentarios me han bendecido porque me permiten desarrollar mejor el proyecto de transición IPv6 en la enterprise en donde laboro, además del conocimiento como tal.<div class="gmail_extra">
<br clear="all"><div><div dir="ltr">Atentamente,</div><div>Costa Rica</div><div dir="ltr"><div>Erick Lobo</div><div><br></div><div>lgD</div></div></div>
<br><br><div class="gmail_quote">El 15 de mayo de 2014, 5:07, Fernando Gont <span dir="ltr"><<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/14/2014 09:43 AM, Erick Lobo Marín wrote:<br>
><br>
>>Para poder hacer correlación en tales escenarios, necesitarías algo<br>
>>como: <<a href="http://www.si6networks.com/tools/ipv6mon/" target="_blank">http://www.si6networks.com/tools/ipv6mon/</a>>, que en IPv4<br>
>>generalmente NO es necesario.<br>
><br>
> En relación con tu comentario se me ocurre que en IPv4 no eran<br>
> necesarios los mecanismos comentados (RFC4941 y RFC7217), porque en<br>
> general en la Enterprise se manejaba el NAT en combinación con políticas<br>
> de Firewall, y de alguna forma se deba el ocultamiento de la dirección<br>
> final y el tracking era más difícil de hacer.<br>
<br>
Herramientas como ipv6mon se utilizan para mantener una tabla con los<br>
mapeos IP <-> MAC address. En IPv4, dichos mapeos han sido (en la<br>
practica) tipicamente estables... entonces no hacia falta mantener un<br>
registro de que IP addres se correspondia con que dirección MAC.<br>
<br>
En IPv6, RFC4941 tiene el objetivo explicito de que dichos mapeos varien<br>
en el tiempo, por lo cual se hace necesario mantener tal registro.<br>
<br>
<br>
En lo que respecta a las cuestiones de privacidad, ciertamente en IPv4<br>
el tema ha sido "solucionado" por el NAT.<br>
<br>
<br>
<br>
> Con IPv6, por sus<br>
> características (tales como: autoconfiguración stateless y suficiente<br>
> direccionamiento) ya no aplica el NAT<br>
<br>
Personalmente prefieron no entrar en la discusión sobre "aplica vs. no<br>
aplica", porque termina en discusiones relegiosas, y en ocasiones medio<br>
fundamentalistas. :-)<br>
<br>
Personalmente, soy de la idea de que uno debe comprender que<br>
caracteristicas aporta una teconologia, y cuales son sus contras. Y<br>
luego evaluar para cada caso si su utilizacion tiene sentido. -- Está<br>
claro que en IPv6 habrá tambien NAT (y no solo el lamado NPT)... mas<br>
allá de las opiniones puristas de algunos.<br>
<br>
<br>
> (o por lo menos no tienen mucho<br>
> sentido el usarlo) lo cual produce que no se disponga el ocultamiento y<br>
> el tracking, requiriendo considerar estas opciones.<br>
<br>
Respecto al tracking (rastreo de sistemas a traves de redes), el<br>
problema no es la falta de NAT, sino el hecho de poner lo que<br>
basicamente es un "serial number" 8la MAC address), en un identificador<br>
visible globalmente (una direccion IPv6).<br>
<br>
Ver, por ejemplo:<br>
<<a href="http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-01" target="_blank">http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-01</a>>.<br>
<br>
Saludos cordiales,<br>
--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a><br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
LACTF mailing list<br>
<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lactf" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br>
</blockquote></div><br></div></div>