<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Fernando, en realidad la pregunta puedes verla
desde varios puntos de vista, pues a un ISP en realidad lo que mas le interesa
es su caso de negocios (o sea, aumentar sus ingresos), y por supuesto, si su
operacion es mas eficiente, ello implicara menos costos y el caso de negocio
tendra mucho mas sentido. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>En IPv6, el tema de agregación eficiente es
relativo, quizas menos traumatico que con IPv4 porque la administracion del
espacio IPv6 cuenta desde su inicio con los RIRs, quienes generan
politicas para su conservacion, empleo y asignacion (y esto si es una gran
diferencia respecto a la historia de IPv4). Sin embargo al existir
asignaciones para usuarios finales ya la agregacion se comienza a reducir como
posibilidad. Tampoco con IPv6 se elimina "multihoming", que es otro de los
factores que inciden en el tema de enrutamiento (y que es algo que se refleja en
el material que recomiendas). Por el tamaño del espacio de direcciones, si
se elimina en gran medida la probabilidad de asignaciones discontiguas a
una misma organizacion, que es algo que IPv4 no puede garantizar del todo cuando
se trata de grandes bloques. Tambien puede ser interesante considerar que los
protocolos de enrutamiento son en escencia los mismos de IPv4, por tanto la
eficiencia no esta en los algoritmos, sino en la manera de administrar el
espacio.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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. 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. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial 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; 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. 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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Saludos,</FONT></DIV>
<DIV><FONT face=Arial size=2>Jorge</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=fernando@gont.com.ar href="mailto:fernando@gont.com.ar">Fernando
Gont</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=lactf@lac.ipv6tf.org
href="mailto:lactf@lac.ipv6tf.org">lactf@lac.ipv6tf.org</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, October 20, 2008 9:30
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [LAC-TF] FAQ: Grupo1 -
Pregunta "a"</DIV>
<DIV><BR></DIV><FONT size=3>Estiamdo Carlos,<BR><BR>Mis respuestas van entre
lineas....<BR><BR>
<BLOCKQUOTE class=cite cite="" type="cite">Las ventajas técnicas son las
siguientes: <BR><BR>- Cálculo de rutas y agregación más eficiente, menos
redirecciones, menos re-enrutamiento, </BLOCKQUOTE><BR>Creo que es interesante
considerar el siguiente enlace: <A
href="http://www.iab.org/about/workshops/routingandaddressing/vaf-iab-raws.pdf"
eudora="autourl">http://www.iab.org/about/workshops/routingandaddressing/vaf-iab-raws.pdf<BR><BR><BR></A>
<BLOCKQUOTE class=cite cite="" type="cite">- Seguridad nativa y
obligatoria.</BLOCKQUOTE><BR>Este punto debe ser aclarado. E incluso si la
*implementacion* de IPsec es mandatoria, esto no quiere decir que
necesariamente se pueda utilizar. Los problemas principales para la
utilizacion de IPv6 (por e.j., establecimiento de SAs) siguen siendo
exactamente los mismos.<BR><BR><BR><BR>
<BLOCKQUOTE class=cite cite="" type="cite">- Habilita el desarrollo de la
próxima generación de aplicaciones, permitiendo: <BR> *
Priorización de paquetes <BR> * Aseguramiento real de que el
tráfico marcado como prioritario no será interrumpido por datos menos
crÃticos </BLOCKQUOTE><BR>Personalmente me gustaria alguna justificacion
para estos dos puntos.<BR><BR>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><BR>-- <BR>Este mensaje ha sido analizado por <A
href="http://www.mailscanner.info/"><B>MailScanner</B></A> <BR>en busca de
virus y otros contenidos peligrosos, <BR>y se considera que está limpio.
<BR>MailScanner agradece a <A href="http://www.transtec.co.uk/">transtec
Computers</A> por su apoyo.
<P>
<HR>
<P></P>_______________________________________________<BR>LACTF mailing
list<BR>LACTF@lacnic.net<BR>https://mail.lacnic.net/mailman/listinfo/lactf<BR></BLOCKQUOTE></BODY><br />--
<br />Este mensaje ha sido analizado por
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>
<br />en busca de virus y otros contenidos peligrosos,
<br />y se considera que está limpio.
<br />MailScanner agradece a <a href="http://www.transtec.co.uk/">transtec Computers</a> por su apoyo.
</HTML>