[LAC-TF] Seguridad y Direccionamiento IPv6

[Erick Lobo Marín]

Slds, El rfc cubre el protocolo no la implementación, habrá que esperar en
algunos casos los dos aspectos para resolver los issues o como en la vida
madurar en lo que corresponda.

En el caso particular, de SLAAC y DHCPv6, he sondeado y existen posiciones
muy definidas por algunas productos en cuanto a lo disponible
(implementado):
-DHCPv6 preferida por no pocos, a nivel de infraestructura de red "delegan"
el role de asignación y otros encuentran un mercado extendido del DHCP
(original IPv4), aunque no “natural” del IPv6. Ajustes como la inclusión
del relay del DHCPv6 y features como la ramdorización en la asignación del
DHCP podrían ser reflejo de tal “compañerismo”. Muy orientado a la
Enterprise.
-En caso de SLAAC ahora menos apetecido por la necesidad de que los hosts
(ya operando) implementen en sí mismos los algoritmos y la necesidad de que
la infraestructura de red pueda responder adecuadamente a éstos. También
que no es que el DHCP en este caso debe estar ausente, sino que también se
incluyen funciones como el stateless DHCP. Muy orientado a los CPE.

No quisiera caer en el pragmatismo religioso pero a su vez tomar las
mejores decisiones para la implementación. Prefiero pensar en un “proceso”
de evolución que nos involcra a todos e ir avanzado en ello.

Atentamente,
Erick Lobo

lgD

El 9 de septiembre de 2014, 8:28, Fernando Gont <fernando at gont.com.ar>
escribió:

> On 09/09/2014 12:17 AM, Carlos M. Martinez wrote:
> > 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.
>
> Aca hay una cuestión de fondo que es todo lo relacionado con SLAAC vs.
> DHCPv6. -- una cuestion que, para su solución, requier mas de la
> disfribución masiva de Ibuevanol :-) que de escribir RFCs.
>
> Contamos con dos maneras de hacer autoconfiguración, y la realidad es
> que pese a ser en teoria alternativas, uno requiere de ambas.
>
>
> Ejemplo concreto de este caso: EL tipo del blog esta usando SLAAC. SLAAC
> deberia poder permitir al router especificar que es lo que se quiere
> hacer con las direciones temporales (RFC4941)... porque si no, las
> opciones son:
>
> 1) EL problema descripto en el blog, o,
> 2) Tener que morir en DHCPv6.
>
>
> Alguno podría pensar "Ok, usemos DHCPv6, ya que al fin y al cabo en v4
> utilizo DHCP"... pero resulta que por cuestiones religiosas uno no puede
> utilizar DHPCv6 para cosas tan elementales como especificar una ruta
> defecto.
>
> Resultado: para solucionar este problema, uno deberia utilizar SLAAC +
> DHCPv6... cuando en v4 con un solo protocolo alcanzaba -- lease: poor
> choice.
>
> Cada vez que hay algun intento para solucionar/mejorar esta cosas,
> reaparecen ambos bandos en un debate "religioso" (si es que se lo puede
> llamar debate)... y, lamentablemente, como dijo alguno: "You each name
> yourself king, yet the kingdom bleeds"
>
>
>
> > Y esto no es solo cierto para IPv6, es cierto para
> > cualquier feature que uno quiera habilitar.
>
> El problema principal que hay con IPv6 no es en si las cuestiones
> tecnicas que van surgiendo con el increment de su espliegue... -- esto,
> como bien decís, pasa con casi cualquier cosa que uno vaya a desplegar.
>
> El problema principal es la gran vendida de humo que rodea a IPv6.
>
> Desde que se lo intento pintar como "bonito, eficiente y barato" (en vez
> de enfocarse en solucionar lo que sea que este al alcance, para que
> funcione lo mejor posible).... a vendors que han sido "propulsores de
> IPv6" sin siquiera soportar IPv6 en sus sitios.
> La gente de estandares pretendiendo "freezar" las especificaciones para
> que la gente "piense que el protocolo esta terminado, y es estable"
> (wtf!? :-) ), y fabricantes que tienen con implementaciones con bugs
> horribles, pero que asi y todo pones excusas para no arreglarlos. etc,
> etc., etc.
>
> la conjunción es un cocktail no tan agradable para el tipo que tiene que
> desplegar IPv6 -- y lo peor es que es innecesario. Las cosas podrian
> funcionar mucho mejor, con menos sorpresas, etc., si cada uno de los
> items de arriba se hiciera un poquito mas en serio...
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20140909/c7206060/attachment.html>