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

Tue Oct 21 15:35:08 BRST 2008

Hola!

Un par de comentarios muy personales sobre la situacion del IPv4 y
Multicast/QoS/IPsec (cosas "no nativas")

- Multicast no se hizo mas popular por problemas de implementación sino
porque los operadores nunca enrutaron multicast en Internet, por lo que
esta tecnologia quedo para siempre reducida a usos de muy pequeña escala.

- IPSec no se hizo mas popular no porque no sea nativo al IPv4 sino
porque las implementaciones demoraron en aparecer y por el engorro que
es configurarlo y hacerlo funcionar bien. De todas formas, es algo que
ha ido mejorando mucho con el tiempo y que estoy seguro en IPv6 ya esta
pulido, pero creo que esto se debe mas al tiempo de maduracion que al
hecho de ser nativo o no.

- Algo similar con QoS: hasta que los carriers no permitan end-to-end
QoS en Internet, el uso de QoS / diffserv y todo ese andamiaje teorico
precioso que hemos construido es poco mas que un juguete de laboratorio.
De nuevo, el problema de que no es nativo, poco tiene que ver.

Resumiendo

slds

Carlos

Jorge Villa wrote:
> Marcelo, como estas? Tiempo sin "verte" por aca.
> 
> Mira, yo creo que IPv6 es un protocolo "potencialmente ventajoso" a IPv4, y 
> no solo en la cantidad de direcciones (en lo cual es verdaderamente 
> ventajoso). Aun cuando hay muchas cosas que se mantienen iguales a IPv4 
> (como el mismo caso de IPSec), el simple hecho de que sean temas que se 
> incluyen "nativamente" significan que desde que uno empieza a hablar de IPv6 
> los va a incluir de alguna manera, y esto puede lograr un mayor impacto en 
> las personas y organizaciones, y por supuesto que eso repercutira en la 
> industria. Aspiro a que de alguna forma, los routers baratos con IPv6 
> tambien tengan alguna posibilidad de QoS o de manejar IPSec, que es algo que 
> muchos no hacen con IPv4.
> 
> No se si recuerdas los trainings de IETF o ISOC hace algunos años, donde se 
> hablaba mucho de direccionamiento, subnetting, enrutamiento, dns y demas, 
> pero IPSec nunca era parte de la pelicula basica, y QoS mucho menos. Algo 
> similar sucedio con Multicasting. El gran publico IP se concentra en lo 
> basico. De hecho, sin temor a equivocarme, puedo asegurar que (en nuestra 
> region) hay montones de administradores de redes que llevan años usando IPv4 
> y jamas se han estudiado algo de IPSec o DiffServ, y mucho menos lo han 
> implementado.
> 
> Incluir tecnologias de forma nativa en el protocolo lo puede hacer 
> "potencialmente ventajoso". Por ejemplo, tomando en cuenta el tema de ancho 
> de banda, los servicios de streaming son mas eficientes sobre Multicast que 
> sobre Unicast, pero sin embargo con IPv4, Multicast no se convirtio en un 
> estandar global, y luego de mas de 25 años de IPv4 sigue sin serlo. IPv6 
> depende de Multicast en buena medida para su funcionamiento, y por tanto los 
> nodos IPv6 soportan multicast de alguna manera. Acaso eso quiere decir que 
> Multicast IPv6 se va a desplegar a nivel global para servicios de streaming 
> como el estandar de facto? No se puede afirmar, pero al menos potencialmente 
> IPv6 puede motivar a que asi sea, porque ahora todos los que trabajen con 
> IPv6 estan obligados a echarle un vistazo a Multicast, ademas de la 
> capacidad que tienen que poseer todos los nodos IPv6 para manejarlo.
> 
> A mi me parece que al enfocar estos temas desde el inicio, se puede lograr 
> que una vez que IPv6 tenga un despliegue importante, tambien haya un trabajo 
> importante (al menos desde el punto de vista de conocimiento) en IPSec, QoS, 
> Multicasting, etc; porque con seguridad la red va a ser completamente 
> diferente en unos años (sobre todo con el boom de la movilidad y los objetos 
> inteligentes), y este tipo de tecnologias seran necesarias para muchos 
> desarrollos.
> 
> Saludos,
> Jorge
> 
> ----- Original Message ----- 
> From: "marcelo bagnulo braun" <marcelo at it.uc3m.es>
> To: <lactf at lac.ipv6tf.org>
> Sent: Tuesday, October 21, 2008 9:50 AM
> Subject: Re: [LAC-TF] FAQ: Grupo1 - Pregunta "a"
> 
> 
>> 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
>>
>> -- 
>> Este mensaje ha sido analizado por MailScanner
>> en busca de virus y otros contenidos peligrosos,
>> y se considera que está limpio.
>> For all your IT requirements visit: http://www.transtec.co.uk
>>
>>
> 
> 