Hola Ismael,<div><br></div><div>Primero decir que porsupuesto que estoy a favor del despliegue de UPv6 y muchos saben que milito desde hace tiempo (mucho tiempo) en esa línea.</div><div><br></div><div>Pero en escencia la solucion de IPv6 no es tanto para el usuario final como lo es para el proveedor, creo yo, por una muy simple razon: continuidad operativa y del negocio.</div>
<div><br></div><div>Algunos centarios entre lineas sobre tu ultimo correo.<br><br>El domingo, 13 de julio de 2014, Ismael Luceno <<a href="mailto:ismael.luceno@gmail.com">ismael.luceno@gmail.com</a>> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 24 Jun 2014 15:54:48 +0100<br>
"Carlos M. Martinez" <<a href="javascript:;" onclick="_e(event, 'cvml', 'carlosmarcelomartinez@gmail.com')">carlosmarcelomartinez@gmail.com</a>> wrote:<br>
> Se agotaba el pool de IANA y efectivamente se agotó. Te recomiendo<br>
> este artículo para que leas, en particular la sección 'The<br>
> relationship between IANA and the RIRs':<br>
><br>
> <a href="http://en.wikipedia.org/wiki/Regional_Internet_registry" target="_blank">http://en.wikipedia.org/wiki/Regional_Internet_registry</a><br>
><br>
> Lo que se agotó ahora es el stock de LACNIC. Es posible que los ISPs<br>
> tengan stocks propios, que eventualmente se irán acabando en lo que<br>
> queda del año.<br>
><br>
> Sobre tus otros puntos:<br>
><br>
> - no hay ninguna forma de esconder 2^32 usuarios atras de un NAT. A lo<br>
> sumo podes esconder 2^16, si le das un puerto a cada uno. Te aseguro<br>
> que como usuario NO queres estár atrás de un NAT que te permita solo<br>
> una conexión TCP a la vez :-)<br>
><br>
> - Justamente IPv6 te permite mantener el end-to-end. Lo que tu<br>
> propones, que es colocar cajas que mantienen estado de conexión en el<br>
> medio de la red, *eso* es un cambio estructural en la red.<br>
> Literalmente, estás creando una función de la red que antes no<br>
> existía.<br>
><br>
> - Que la performance de IPv6 es mejor que la de IPv4 es un mito que la<br>
> verdad, no se de donde salió. De hecho, la buena noticia del articulo<br>
> de Emil Aben que mencionas es que la performance es comparable, y es<br>
> como debería ser.<br>
<br>
IPv6 debería ser más eficiente, si no lo es, se debe a que en<br>
muchos casos los el software y hardware provee malas<br>
implementaciones.</blockquote><div><br></div>No creamos que IPv6 es la mejor implementacion que pudo hacerse... Despues de todo, solo es unos pocos años mas nueva que la de IPv4.<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
En primer lugar, la cabecera es más simple de procesar y re-escribir<br>
de ser necesario, lo que implica un gran impacto para los routers.<br>
<br></blockquote><div>No olvidar que hay que matener dual stack... El procesamiento de paquetes v6 se agrega al de v4.</div><div>Que es mas simple es cierto.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Segundo, se elimina completamente la fragmentación en la red, con<br>
el consiguiente aumento general del rendimiento.</blockquote><div><br></div><div> Fragmentacion en origen en IPv6... Creo que es RFC2460 en la seccion 4 o 5 si mal no recuerdo.</div><div>El Path MTU Discovery tiene algunos problemas tambien y puede hasta ser poco eficiente en algunos casos...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Tercero, se pueden usar paquetes de más de 64KB, lo que permite<br>
aprovechar mejor los enlaces.</blockquote><div><br></div><div>Conoces alguna implementacion que envie paquetes de mas de digamos 10KB (por decir un disparate de paquete)...??? Recordemos que aprox 1500B es lo tipico y que dado el funcionamiento de TCP, retransmisones siempre vamos a tener por lo que perder paquetes de tamaño dinosaurio tampoco es muy costo-efectivo...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Y en cuarto lugar, el soporte multicast simplificado implica que<br>
se puede aprovechar mucho mejor la infraestructura en general.</blockquote><div><br></div><div>Multicast inter proveedores... Otra hermosa expresión  de deseo!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Además tiene todas las ventajas de auto-configuración y movilidad, que<br>
se extienden a los routers también, cosa que no es nada sencillo<br>
conseguir en IPv4. Reconfigurar una red al vuelo y hacer cambios<br>
complejos en poco tiempo se hace posible.<br>
</blockquote><div><br></div><div>Autoconfiguracion entre routers: para un ISP es una demencia.</div><div>Autoconfiguracion para el usuario final: concuerdo con vos que es una ganacia a considerar!</div></div><div>Movilidad en IPvX: otra linda expresion de deseo... si bien es cierto que como las direcciones v6 son de 128b se pueden hacer dibujos raros que pueden llegar a facilitar ciertos protocolos de movilidad pero por ahora son todos Draft en IETF; o implementaciones que presentan otros problemas a resolver.</div>
<div><br></div><div>Saludos,</div><div>Nico<span></span></div><div><br></div><div><br></div>