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

[Carlos M. Martinez]

Personalmente estoy 10.000% de acuerdo con Fernando y el seguimiento de
Marcelo.

Hoy por hoy, tanto IPSec como Multicast o QoS para IPv4 estan
disponibles en casi cualquier caja (Cisco u otros fabricantes de
routers, Linux, FreeBSD).

Estoy de acuerdo (parcialmente) que el hecho de que estas
funcionalidades esten incluidas nativamente en el protocolo puede
presentar algunas ventajas, pero realmente creo que son marginales y
difícilmente van a ser drivers para la adopcion de IPv6 (ver un par de
comentarios mas abajo  :-)  )

Creo que en IPv6, tal como estamos hoy tenemos dos puntos fundamentales
a rescatar y reafirmar:

- Recuperar la naturaleza end-to-end de Internet, al menos en parte
(Geoff opina que ya es tarde para recuperarlo completamente). Esto es lo
que en el futuro va a permitir el desarrollo de nuevas aplicaciones.

- Ampliar el espacio de direccionamiento de tal forma que el crecimiento
esté garantizado

Como punto adicionales si creo que la potencial compactación de las
tablas de enrutamiento a nivel de backbone en Internet va a ser un
alivio para los operadores (yendo a cuales son las ventajas para un
operador) y ademas este hecho puede llegar a permitir el uso mas
generalizado de la tabla de enrutamiento completa a niveles mas bajos y
perifericos de internet, reduciendo problemas asociados al enrutamiento
asimétrico.

Hasta acá con el IPv6

(los comentarios van en otro mensaje, perdon!)

slds

Carlos


marcelo bagnulo braun wrote:
> 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
>>   
> 
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf