[uylug-varios] IPv6 en ADSL Antel

[Nicolas Antoniello]

Hola Ismael,

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.

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.

Algunos centarios entre lineas sobre tu ultimo correo.

El domingo, 13 de julio de 2014, Ismael Luceno <ismael.luceno at gmail.com>
escribió:

> On Tue, 24 Jun 2014 15:54:48 +0100
> "Carlos M. Martinez" <carlosmarcelomartinez at gmail.com <javascript:;>>
> wrote:
> > Se agotaba el pool de IANA y efectivamente se agotó. Te recomiendo
> > este artículo para que leas, en particular la sección 'The
> > relationship between IANA and the RIRs':
> >
> > http://en.wikipedia.org/wiki/Regional_Internet_registry
> >
> > Lo que se agotó ahora es el stock de LACNIC. Es posible que los ISPs
> > tengan stocks propios, que eventualmente se irán acabando en lo que
> > queda del año.
> >
> > Sobre tus otros puntos:
> >
> > - no hay ninguna forma de esconder 2^32 usuarios atras de un NAT. A lo
> > sumo podes esconder 2^16, si le das un puerto a cada uno. Te aseguro
> > que como usuario NO queres estár atrás de un NAT que te permita solo
> > una conexión TCP a la vez :-)
> >
> > - Justamente IPv6 te permite mantener el end-to-end. Lo que tu
> > propones, que es colocar cajas que mantienen estado de conexión en el
> > medio de la red, *eso* es un cambio estructural en la red.
> > Literalmente, estás creando una función de la red que antes no
> > existía.
> >
> > - Que la performance de IPv6 es mejor que la de IPv4 es un mito que la
> > verdad, no se de donde salió. De hecho, la buena noticia del articulo
> > de Emil Aben que mencionas es que la performance es comparable, y es
> > como debería ser.
>
> IPv6 debería ser más eficiente, si no lo es, se debe a que en
> muchos casos los el software y hardware provee malas
> implementaciones.


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.


>
> En primer lugar, la cabecera es más simple de procesar y re-escribir
> de ser necesario, lo que implica un gran impacto para los routers.
>
> No olvidar que hay que matener dual stack... El procesamiento de paquetes
v6 se agrega al de v4.
Que es mas simple es cierto.


> Segundo, se elimina completamente la fragmentación en la red, con
> el consiguiente aumento general del rendimiento.


 Fragmentacion en origen en IPv6... Creo que es RFC2460 en la seccion 4 o 5
si mal no recuerdo.
El Path MTU Discovery tiene algunos problemas tambien y puede hasta ser
poco eficiente en algunos casos...


>
> Tercero, se pueden usar paquetes de más de 64KB, lo que permite
> aprovechar mejor los enlaces.


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...


>
> Y en cuarto lugar, el soporte multicast simplificado implica que
> se puede aprovechar mucho mejor la infraestructura en general.


Multicast inter proveedores... Otra hermosa expresión  de deseo!


>
> Además tiene todas las ventajas de auto-configuración y movilidad, que
> se extienden a los routers también, cosa que no es nada sencillo
> conseguir en IPv4. Reconfigurar una red al vuelo y hacer cambios
> complejos en poco tiempo se hace posible.
>

Autoconfiguracion entre routers: para un ISP es una demencia.
Autoconfiguracion para el usuario final: concuerdo con vos que es una
ganacia a considerar!
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.

Saludos,
Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20140713/426956ed/attachment-0002.htm>