[LAC-TF] FAQ: Grupo1 - Pregunta "a"
marcelo bagnulo braun
marcelo at it.uc3m.es
Tue Oct 21 15:18:11 BRST 2008
Hola Jorge,
Yo creo que las razones por las que no se despliegan los protocolos que
mecnionas no tienen nada que ver con IPv4 o IPv6 o el soporte nativo.
Creo que no se depliegan porque el modelo que uso o de despliegue esta
simplemente mal y quienes tiene que desplegarlo no lo encuentran atractivo.
tomemos el ejemplo de multicast. Cuando decis que IPv6 soporta multicast
nativo y es necesrio para su funcionamiento me imagino que te referis a
que ND usa multicast en vez de broadcast. El uso de multicast es a nivel
de enlace local. Esto segun yo entiendo no fomenta para nada que se
depliegie multicast a nivel de intradominio mas alla del nivel del
enlace, y mucho menos a nivel interdomino (notese que los operadores que
ofrece TV sobre IP ya han desplegado multicast en IPv4 en su
intradominio, por lo que falta por deplegar es multicast a nivel
interdominio, y en esto IPv6 no te va a ayudar ni un poquito, creo yo)
Como eso podemos hablar de muchas otras cosas, como IPSec, movilidad,
calidad de servicio.
My principal problema es que estamos tratando de hacer marketing the
IPv6 usando argumentos que no se sostienen cuando viene alguien con
preguntas tecnicas serias como las que hace Fernando.
El resultado creo que es contraproducente, porque al final, la unica
resupesta es "si, se puede con v4, pero es un pelin mejor con IPv6" y
eso contrasta con las grandilocuentes afirmaciones inciiales del tipo
"con IPv6 tendremos QoS y multicast y movilidad y seguridad"
Con IPv6 tendremos direcciones, que con IPv4 no tenemos casi
Con esas direcciones podremos dejar de usar los NATs (si queremos), y mi
bittorrent me funcionara sin necesidad de usar upnp y en redes donde no
tengo directamente conectado el nat al ordenador donde tengo el
bittorrent. Ademas no voy a tener que usar ni ice, ni stun, ni turn ni
nada de esas cosas raras. Ademas my skype no me dira que tiene que
encaminar mi trafico de voz por la casa de otro para poder llegar al
destino (esperemos).
creo que con esto deberia bastar para entender que IPv6 vale la pena
Saludos, marcelo
Jorge Villa escribió:
> 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
>>
>>
>>
>
>
>
More information about the LACTF
mailing list