<html>
<body>
<font size=3>At 11:18 a.m. 21/10/2008, Jorge Villa wrote:<br><br>
</font><blockquote type=cite class=cite cite=""><font size=2>Respecto a
la seguridad.... Es cierto que IPSec es &quot;mandatory&quot; 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 &quot;teoricamente&quot; mas seguro que IPv4.
</font></blockquote><br>
Sinceramente no entiendo esta aseveración. La unica interpretación que
hago sobre que &quot;es parte del diseño&quot; es que basicamente &quot;o
usas IPsec, o se asume que todo es inseguro&quot;. Pero esta es
exactamente la misma situación de IPv4.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=2>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 &quot;controlar&quot; 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.
</font></blockquote><br>
A eso voy. Esa es exactamente la misma situación que en IPv4.<br><br>
<br><br>
<blockquote type=cite class=cite cite=""><font size=2>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; </font></blockquote><br>
IPv4 ya no tiene mas ToS, sino que tiene diffserv.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=2>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 &quot;teoricamente&quot; para manejar los valores del
campo Traffic Class, y de ahi la potencialidad de la infraestructura IPv6
de garantizar calidad de servicio. </font></blockquote><br>
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)<br><br>
Me parece un tanto cuestionable este argumento.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=2>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&nbsp; (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 &quot;garantizar&quot; que los demas
ISP se ocupen de igual forma de QoS; pero al menos en teoria IPv6
nativamente debe dar mejores resultados que
IPv4.</font></blockquote><br>
Pregunta concreta: que mecanismo provee para el QoS que no provea
IPv4?<br><br>
<font size=3>Saludos cordiales,<br>
<x-sigsep><p></x-sigsep>
--<br>
Fernando Gont<br>
e-mail: fernando@gont.com.ar || fgont@acm.org<br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
FFF1<br><br>
<br><br>
</font></body>
</html>