BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 👇 este 📰 artículo ⏎
  • 🔍 en 💬 foros ⏎
Regístrate Regístrate Identifícate Identifícate
  • 📰 Artículos

Movistar iniciará pilotos IPv6 en ADSL y móvil tras el 8 de junio

Joshua Llorach

El IPv6 World Day que se celebra el 8 de junio, servirá para que los proveedores de contenidos comprueben que son capaces de trabajar con IPv6. Para entonces, los clientes de Movistar aún no navegarán con las nuevas direcciones. Será después de esa fecha cuando las pruebas que Telefónica está realizando a nivel interno, se abrirán a los primeros clientes dentro de experiencias piloto que se realizarán tanto en la red fija como en la móvil.

Telefónica está llevando a cabo desde abril una primera prueba a nivel interno dentro del centro de Telefónica I+D en Walqa (Huesca), la que según afirman, es la primera red corporativa que trabaja al completo con el nuevo protocolo de Internet. Un entorno real donde los empleados se conectan por IPv6.

Carlos Ralli, responsable de estándares de Internet y experto en IPv6 en Telefónica I+D ha respondido a las preguntas de los usuarios durante un encuentro en Twitter. Asegura que tras el IPv6 World Day, que servirá para "depurar sistemas operativos y navegadores", se iniciará la migración de usuarios, de forma "progresiva".

Primero hay que solucionar fallos de contenidos en dual-stack (propósito del World Day del 8 de Junio). A partir de ahí se han planificado pilotos en distintas fases (fijo y móvil). Las fechas concretas se están definiendo.

Para ello es necesario que el usuario, el router, el ISP y el servidor al que accede estén actualizados. La red del operador está preparada y "los routers se irán actualizando", asegura.

Los usuarios migrados utilizarán doble pila, de modo que podrán navegar simultáneamente mediante IPv4 e IPv6. La parte IPv4, como ya adelantamos hace unas semanas, se realizará mediante CGNAT (NAT a nivel de ISP) de forma que varios usuarios compartirán una misma IP. Aunque Carlos Ralli ha evitado dar una fecha, fuentes cercanas a Telefónica nos aseguran que la fecha prevista sería el mes de agosto.

La extensión de IPv6 a toda la red de Internet será lenta al principio, aunque se irá acelerando conforme pase el tiempo. "Llegar al primer 20% de v6 llevará tiempo, luego se llegará rápido a un 90% y quedará v4 residual durante años", explica.

Zyxel tiene listos nuevos firmwares con IPv6

Zyxel, uno de los principales fabricantes de routers ADSL y VDSL empleados por Telefónica, ya está proporcionando a los ISP, firmwares compatibles con IPv6. Telefónica y otros operadores tendrán la posibilidad de hacer actualizaciones remotas de los dispositivos ya instalados, aunque lo lógico es que también ofrezcan de forma general los archivos para su descarga, que serán útiles sobre todo para los usuarios que han bloqueado la administración remota de su router.

💬 Comentarios

BocaDePez
BocaDePez

Menos mal que empieza a verse algo de movimiento...

🗨️ 11
heffeque

En éste caso un bravo por Telefónica, algo que no se da muy a menudo que digamos.

🗨️ 10
txuspe
2

No podemos felicitar a una compañía que va a montar un CGNAT para sus clientes.

🗨️ 9
BocaDePez
BocaDePez
-2

¿Sabes cuantos operadores NO van a montar CGNAT con IPv6? No lo busques, te lo digo yo. Dos, en todo el mundo.

🗨️ 1
BocaDePez
BocaDePez
1

Referencias, por favor.

heffeque
1

Ostras, no había visto/leído esa parte. Dios mío, qué marrón.

El CGNAT romperá programas de VoIP, videoconferencia, servidores caseros, P2P, juegos online... bueno, y ni decir tiene que a los usuarios de MegaUpload no les va a hacer ni pizca de gracia cuando vean que en su IP ya se ha agotado el cupo sin haber descargado ni un sólo mega.

Que el diablo nos pille confesaos.

Edit: aunque pensándolo bien, si el IPv4 consiguen que funcione mal mal es posible que así se acelere el uso de IPv6 xDDD

🗨️ 6
Khyros

pero.. ¿si implementan el ipv6 por qué ponen un nat?

no entiendo… en todo caso un NAT por parte del operador tendría sentido si siguieran con ipv4 no?

🗨️ 2
Mocho
BocaDePez
BocaDePez
Mocho

Supongo que si tu conexión ya soporta IPV6 y por ejemplo la de tu proveedor VoIP también la comunicación será por IPV6 y te dará igual el CGNAT.

🗨️ 2
heffeque
🗨️ 1
Mocho
vukits

¿Eso del video es el departamenteo I+D ?

Yo creía que lo tienen en un sotano. :-/

🗨️ 4
BocaDePez
BocaDePez
4

I+D Movistar = ¿ha probado a apagar y encender de nuevo su enrutadora de la internet?

jimmyyuyu

lo tenian en un sotano pero para que el video quede mas guay han dejado a los esclavos en el sotano y han subido los trastos a una zona con ventanas

🗨️ 2
BocaDePez
BocaDePez

Yo duré allí 10 semanas sin ver la luz del sol antes de mandarles a la mierda.

En esas 10 semanas no conseguí tener ni silla ni ordenador propio. Si esa es la créme de la créme del I+D en España...

🗨️ 1
BocaDePez
BocaDePez

Empleo tipical spanish...

BocaDePez
BocaDePez
1

A punto de finalizar portabilidad a Vodafone. Adiós Timofónica, métete tu CGNAT donde te quepa

🗨️ 6
BocaDePez
BocaDePez
0

si ahora preparate tu, y el soporte tecnico de Vodafone, vete diciendoles hola hola jajajaja

🗨️ 4
BocaDePez
BocaDePez
1

¿Ah que el de Telefónica es una maravilla? Cuando llamas y te atienden de Perú o a saber.... Es una porquería como la de todos los operadores

🗨️ 3
BocaDePez
BocaDePez
-1

El servicio técnico de la timo puede que sea un asco, pero es que las demás ni tan solo te atienden, como tengas una averia que requiera la presencia de un técnico lo vas a tener claro, antes prefieren perder el cliente que solucionar el problema.

🗨️ 2
BocaDePez
BocaDePez
1

Si te has creído que los problemas que he tenido con Telefónica son sólo por el servicio técnico, estás apañado. Son unos mangantes, los más caros y los que ofrecen unas velocidades más absurdas. Aquí ni siquiera se molestaron en ofrecernos una promoción por la baja , por no decir los problemas de línea que he tenido con estos impresentables, que son una larga lista. Que me voy con ganas joder, que estoy harto de que me roben todos los meses

BocaDePez
BocaDePez
1

No lo diras por ONO, porque en 10 años 3 veces he tenido problemas de cortes de conexion, 3 veces me cambiaron el modem al dia siguiente solucionando el problema.

BocaDePez
BocaDePez

Ninguno va a implementar IPv6 a corto plazo, ambos son operadores desastrosos en todos los aspectos.

BocaDePez
BocaDePez
5

Al final tanto quejarse del proxy-caché y van a poner algo similar por pelotas. Esta compañía es para mandarla 1000 veces a la mierda, su política principal consiste en joder a sus propios usuarios

🗨️ 9
NetSpot

Lo que harán será una especie de 6to4 a nivel de compañía. Es algo parecido al servicio de Microsoft que puedes utilizar para ello:

6to4.ipv6.microsoft.com

((link roto)

Eso es lo que creo, claro, porque una cosa es saber todo esto del IPv6 y otra es ver cómo está evolucionando y cómo hay que ir adaptándolo...

🗨️ 8
Mocho
1

El 6to4 es una chapuza de tal calibre que los técnicos de RIPE en sus informes llegan a decir que si un operador lo implementa perderá clientes por el mal servicio y que la única altenativa viable es el dual stack.

If the access provider has not upgraded to dual-stack yet, its IPv4-only customers will have to use a technology like 6to4, and face breakage. This may cause customers to switch provider (which paradoxically will help IPv6 deployment).

Moral of the story: Go dual-stack. Now.

labs.ripe.net/Members/emileaben/6to4-how…is-it-really

🗨️ 7
NetSpot

Ya se verá, ya se verá. Que esto, según va pasando el tiempo, se va abriendo paso a su manera ;)

Razón no te falta.

Si acaban usando un proxy, un proxy 6to4, o lo que sea, sólo al final ellos lo saben.

Que llegue el día 8 y así veremos más claro el camino :)

🗨️ 6
Mocho
1

Parece ser que el camino que van a tomar, salvo raras excepciones como la francesa free, es el dual stack, aunque lo correcto es decir doble pila ;)

Los usuarios migrados utilizarán doble pila, de modo que podrán navegar simultáneamente mediante IPv4 e IPv6

🗨️ 5
BocaDePez
BocaDePez
🗨️ 3
Mocho
🗨️ 2
BocaDePez
BocaDePez
🗨️ 1
Mocho
BocaDePez
BocaDePez
-1
NetSpot

A mí hay 2 cosas que realmente me molestan:

1.- que en el transcurso del cambio, los que tengamos router no podremos hacer 6to4 para ir avanzando, ya que se necesita IP pública asignada al equipo, o sea, un módem,

2.- que mis routers D-Link 524T y 3Com812, que funcionan/funcionaban de perlas, no tienen visos de ver actualizados sus firmwares por estas y que me veré obligado a usar routers que no me gustan, o a comprar otro.

🗨️ 7
BocaDePez
BocaDePez

Chico, estás bastante desfasado. El 3Com OCR 812 no tiene soporte ADSL2 (su velocidad máxima admitida es 8 Mbps) a lo que se añade que sus puertos son de 10 Mbps por lo que transferir archivos de cierto peso entre equipos conectados a sus puertos se hace eterno. Para solventarlo puede comprarse un switch de 1 Gbps pero ya hay que realizar un gasto adicional.

Ciertamente era muy buen producto en su momento pero hace algunos años que está obsoleto.

🗨️ 2
NetSpot

Er.... para los que vivimos donde vivimos y que los 10Mb son como un deseo vacío... (ergo, ADSL2, algún día llegará...) sigue siendo más que útil.

El resto te lo podrías guardar, que ya se sabe.

🗨️ 1
heffeque

Pocos se acuerdan de que hay zonas de España en donde las conexiones son más bien tercermundistas (sin ánimo de ofender) y que un aparato nuevo va a tener el mismo rendimiento que uno antiguo.

vukits

Para varios Dlink, hay varios firmwares.. alguno te irá bien.. ya sea Openwrt, que va de perlas, excepto en el tema del wifi, o Routertech.. que tiene el kernel un poco antiguo

🗨️ 3
NetSpot

¿Que lleve soporte IPv6?

🗨️ 2
vukits

el dsl54t al no lleva wifi, así que la funcionalidad que te da Openwrt es completa ;)

OpenWRT soporta ya ipv6

sección de /etc/config referente a adsl (mirar instrucciones adicionales de openwrt para establlcer modo adsl... o dejarlo a multimode, en firm oficial, antes de flashear con Openwrt).. ah.. y dejar el bootloder adam2 .. no cambiarlo por pspboot ;)

## Example for ATM bridging.
## Useful for PPPoE or IP over ATM. Will create 'nas${unit}'
#
 config atm-bridge
#  option unit     0
  option encaps   llc
        option vpi      8
  option vci      35
#        option payload  bridged # some ISPs need this set to 'routed'

 config interface wan
##        PPPoE:
     option ifname   nas0
       option proto    pppoe

##       PPPoA:
#    option ifname   atm0
#      option proto    pppoa
#     option encaps   llc
#       option vpi      8
# option vci      35

##  Both:
      option username "my_username"
      option password "my_password"
🗨️ 1
vukits

jopé..

es /etc/config/network ..

BocaDePez
BocaDePez

Nada hombre , todos a echar una manita a Telefónica... daros de baja todos los que podáis y así no les faltarán ip's. Que se las metan por el orto

BocaDePez
BocaDePez
0

¿Seguro que pueden permitirselo? Yo creo que habra que echar a mas gente para esto.

BocaDePez
BocaDePez
1

MTU es el tamaño total de un paquete(incluyendo header) a enviar suponiendo que por el camino no se parte o se haga mas pequeño, lo normal es 1492.

MSS en cambio es el tamaño maximo de datos en un paquete (sin incluir el header).

Ahora que pasa si dejamos el MTU igual (que es lo que pasará) y pasamos a iupv6? como todos sabemops ipv6 tiene cabeceras de 80bytes vs 20 bytes de ip v4.

Esto quiere decir que por cada paquete en ipv4 podiamos enviar 1492(MTU)-20=1472Bytes (MSS).

en cambio en ipv6 1492-80=1412Bytes

Bien ahora suponemos un fichero de 600MB.

600*1024=614400KB*1024=629145600 bytes

Un adsl de 6Mbits=60000000bits /s significa que si lo dividimos entre 8 nos da 750KB/S pico = 768000bytes/s

IPV4 dividimos los 600MB en el tamaño de segmento de ipv4 (MSS) para saber el numero de segmentos necesarios.

629145600/1472=427408,69 segmentos

Ahora calculamos esos nº de segmentos el tamaño real incluyendo cabeceras ipv4:427408,69*1492=637693773,9

En realidad transferimos unos 608MB los cuales en ipv4 se han consumido 8MB en cabeceras

Por lo que el adsl tardaria 637693773,9/768000=830,33=13,83 min en condiciones imaginarias pico.

ahora veremos ipv6

600MB entre el tamaño de segmento de ipv6:629145600/1412=445570,54 segmentos

Tamaño real a transferir=445570,54*1492=664791245,68bytes=634MB

En ipv6 se necesitan 34MB mas por las cabeceras vs 8MB en ipv4!!!!

Ahora calculamos el tiempo 664791245,68/768000=865,62seg=14,427min

En resumen

IPV4 transfiere 608MB reales los cuales 8Mb en cabeceras tarda 13,83min

IPV6 transfiere 634MB los cuales 34MB en cabeceras tarda 14,427min

Esto en un fichero de 600MB si descargas gigas la diferencia no sera de 1 min y algo teoricamente.

ahora lo peor viene aqui, la mayoria de equipos intermedios trabajan con mtu's mas pequeños que 1492, asi que los paquetes se parten en mas pequeños.

Entonces si en el camino se parten en paquetes ipv6 mas pequeños el tamaño incrementa en 1/3 parte mas o incluso en ficheros grandes (hablamos de 20GB) puede hasta duplicarse.

Pues para cada trocito pequeño se le genera una nueva cabecera ipv6 asi que seria un efecto multiplicativo de transportar 60bytes menos en cada paquete /s en cada subdivision que se hace, y estaos por seguro que se parten en varios es raro que haya un mtu constante entre dos extremos.

ahora el proveedor nos da la velocidad en mbits por lo que es un problema porque no cuentan cabeceras asi que ahora perdemos.

Saludos

🗨️ 5
Josh

Muy interesante tu reflexión.

🗨️ 3
heffeque
1

Lo que no ha tenido en cuenta es el hecho de que en IPv6 no es siempre necesario volver a enviar la cabecera (Jumbograms), que los routers intermedios nunca fragmentan los paquetes a trozos más pequeños que 1280 bytes (o sea que su presunción anterior no sirve) y que, de nuevo, los routers intermedios dejan de tener que hacer numerosos cálculos que frenan la velocidad de transmisión de los paquetes, tanto en ancho de banda como en latencia, o sea se, que el uso de la CPU desciende muchísimo en los routers intermedios, ya que dejan de tener que calcular el TTL en cada uno de los saltos (se sustituye por el Hop Limit que es un simple sumador), no necesitan calcular el checksum de cada una de las cabeceras de los paquetes y admás el hecho de que muchos de los atributos "poco utilizados" se han movido de la cabecera a un campo auxiliar opcional.

Vamos, que lo que pierdes por tener algo más de cabecera, lo ganas por ser más eficiente.

🗨️ 2
BocaDePez
BocaDePez

Yo tenia entendido que exigia segun la RFC un mtu minimo parecido al del ipv4 de 500 y algo.

Sobre lo de la fragmentación es cierto, pero antes el cliente debe descubrir el mtu y si cambia el mtu del camino se rechaza el paquete porque los router no lo fragmentarán ya se fragmenta en origen.

Como todos sabemos las rutas son muy dinamicas y hasta que no se use a fondo ipv6 con rutas con mtu bastante similares habra una cantidad de paquetes rechazados que vamos a flipar.

Entonces almenos al principio ira fatal.

Saludos

Albaceteman2

Me uno al comentario del Bocadepez de arriba. La MTU mínima en IPv6 es de 1280 octetos, como tú dices, pero no hay fragmentación en los routers intermedios. Si un paquete supera la MTU en algún punto de la red, se devuelve un mensaje de error y es la estación que originó el paquete la que debe fragmentar el paquete en origen para cumplir con la MTU del camino (PATH MTU), pero no puede haber fragmentación en routers intermedios precisamente por agilizar el forwarding en IP, ya que de otra forma les supone una carga adicional a los routers intermedios.

No obstante, no creo que les dé por bajar la MTU de unos 1500 octetos, ya que medio mundo tiene Ethernet y sería un pelín fastidio.

BocaDePez
BocaDePez

20 bytes es el tamaño mínimo de la cabecera IPv4, pero puede tener un máximo de 60 bytes (es variable).

El tamaño de cabecera fija de IPv6 es de 40 bytes, y puede llevar cabeceras opcionales adicionales de tamaño variable y que añaden funcionalidad no presente en IPv4.

Hopo

Si queréis tocarle los cojones al señor responsable de Telefónica -I-D ... twitter.com/#!/telefonicaid

Según el RFC1631 (El del NAT) :

3.3 Header Manipulations

In addition to modifying the IP address, NAT must modify the IP checksum and the TCP checksum. Remember, TCP's checksum also covers a pseudo header which contains the source and destination address. NAT must also look out for ICMP and FTP and modify the places where the IP address appears. There are undoubtedly other places, where modifications must be done. Hopefully, most such applications will be discovered during experimentation with NAT.

.... vamos que a simple vista nos aumentará el ping.

The negative characteristics are:

1. It requires a sparse end-to-end traffic matrix. Otherwise, the NAT tables will be large, thus giving lower performance. While the expectation is that end-to-end traffic matrices are indeed sparse, experience with NAT will determine whether or not they are. In any event, future applications may require a rich traffic matrix (for instance, distributed resource discovery), thus making long-term use of NAT unattractive.

2. It increases the probability of mis-addressing.

3. It breaks certain applications (or at least makes them more difficult to run).

4. It hides the identity of hosts. While this has the benefit of privacy, it is generally a negative effect.

5. Problems with SNMP, DNS, ... you name it.