[LAC-TF] FAQ: Grupo1 - Pregunta "a"

[marcelo bagnulo braun]

Hola,

estoy de acuerdo con los puntos que hace Fernando.

Creo que es un error tratar de "vender" ue IPv6 tiene mejor QoS o mejor 
seguridad.

IPv6 tiene mas direcciones. Y esto es una razon sufiente para que sea 
necesaria su adopcion.

A decir verdad, Geoff escribio un articulo muy bueno sobre esto mismo 
hace ya mucho tiempo, donde habla de IPv6 myths
Se los recomiendo, 

http://ispcolumn.isoc.org/2003-01/Waiting.html

Saludos, marcelo


Fernando Gont escribió:
> At 11:18 a.m. 21/10/2008, Jorge Villa wrote:
>
>> Respecto a la seguridad.... Es cierto que IPSec es "mandatory" en el 
>> protocolo IPv6, sin embargo eso no quiere decir que todas las 
>> implementaciones la incluyan o que este habilitado por defecto su 
>> empleo (de hecho, casi ninguna implementacion lo hace), y 
>> posiblemente muchas implementaciones de pequeño tamaño no lo 
>> incluyan. Lo que si es importante, es que IPSec es parte del diseño 
>> del protocolo, y esto promete un ambiente "teoricamente" mas seguro 
>> que IPv4. 
>
> Sinceramente no entiendo esta aseveración. La unica interpretación que 
> hago sobre que "es parte del diseño" es que basicamente "o usas IPsec, 
> o se asume que todo es inseguro". Pero esta es exactamente la misma 
> situación de IPv4.
>
>
>> En cualquier caso, con IPv6 se puede hablar de seguridad IPSec en 
>> ambientes controlados, ya que al no existir una plataforma global de 
>> llaves publicas, entonces el uso de IPSec se restringe a los 
>> ambientes en que se implementen autoridades de certificacion. Un ISP 
>> puede crear perfectamente una infraestructura de este tipo para 
>> "controlar" los equipos terminales que tiene asignados a los usuarios 
>> finales o desarrollar cualquier tipo de servicio que requiera 
>> autenticacion segura, pero nunca pensarlo como algo global, al menos 
>> en este momento. 
>
> A eso voy. Esa es exactamente la misma situación que en IPv4.
>
>
>
>> En el tema de Calidad de Servicio, hay algunas posibles mejoras 
>> respecto a IPv4. En realidad con Traffic Class puedes hacer un poco 
>> mas que el Type of Service de IPv4; 
>
> IPv4 ya no tiene mas ToS, sino que tiene diffserv.
>
>
>> aunque en principio la implementacion en ambas plataformas se basa en 
>> DiffServ. Lo que sucede es que si uno tiene una infraestructura de 
>> routers IPv6, estos deben estar preparados "teoricamente" para 
>> manejar los valores del campo Traffic Class, y de ahi la 
>> potencialidad de la infraestructura IPv6 de garantizar calidad de 
>> servicio. 
>
> El argumento es entonces que se asume que todos los routers IPv4 son 
> tan viejos que entonces singuen interpretando el campo diffserv de 
> manera obsoleta? (como habia sido definido hace 20 años atrás)
>
> Me parece un tanto cuestionable este argumento.
>
>
>> En el caso de IPv4, muchos routers no pueden trabajar con DiffServ, 
>> ya que no es parte de la arquitectura basica del protocolo. O sea, 
>> que si hablamos de una NGN  (donde es critico el uso de QoS), la 
>> implementacion basada en IPv6 debe brindar mejor trabajo en este 
>> aspecto que la implementacion basada en IPv4. Claro, cuando uno 
>> trabaja con una infraestructura propia (digase un ISP), uno puede 
>> adquirir el equipamiento que soporte DiffServ para el backbone (o 
>> emplear las herramientas de ingenieria de trafico de MPLS) para 
>> garantizar QoS. El asunto esta cuando se habla de enrutamiento inter 
>> dominios, donde uno no puede "garantizar" que los demas ISP se ocupen 
>> de igual forma de QoS; pero al menos en teoria IPv6 nativamente debe 
>> dar mejores resultados que IPv4.
>
> Pregunta concreta: que mecanismo provee para el QoS que no provea IPv4?
>
> Saludos cordiales,
>
> --
> Fernando Gont
> e-mail: fernando at gont.com.ar || fgont at acm.org
> 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
>