Banda Ancha EU

Información independiente
sobre fibra, móvil y ADSL

hosting en interdominios

294

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

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.

Los comentarios más recientes se muestran primero. Haz click sobre un comentario para desplegar/plegar.
  • BocaDePez BocaDePez
    12

    MTU y MSS para que veais que perdemos velocidad de transferencia. Perdemos velocidad!

    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

    • BocaDePez BocaDePez
      6

      20 bytes es el tamaño mínimo de la cabecera IPv4, pero puede…

      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.

      • Lo que no ha tenido en cuenta es el hecho de que en IPv6 no…

        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.

        • Me uno al comentario del Bocadepez de arriba. La MTU mínima…

          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
          6
          Yo tenia entendido que exigia segun la RFC un mtu minimo…

          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

  • A mí hay 2 cosas que realmente me molestan: 1.- que en el…

    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.

    • Para varios Dlink, hay varios firmwares.. alguno te irá…

      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

        • el dsl54t al no lleva wifi, así que la funcionalidad que te…

          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"
    • BocaDePez BocaDePez
      6

      Chico, estás bastante desfasado. El 3Com OCR 812 no tiene…

      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.

      • Er.... para los que vivimos donde vivimos y que los 10Mb son…

        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.

        • Pocos se acuerdan de que hay zonas de España en donde las…

          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.

  • 6

    Si queréis tocarle los cojones al señor responsable de…

    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.

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

          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

            • Iluso de mi que pensaba que tendrían suficientes direcciones…

              Iluso de mi que pensaba que tendrían suficientes direcciones IPv4 como para aguantar el tirón durante la transición, de ahí mi sorpresa, pero veo que no, que van a tener que tirar den NAT en las IPv4. Sé que la transición será larga pero... joer, si ya se están planteando meter NAT, mal vamos (o de repente se han vuelto previsores, algo que si fuera verdad ya habrían empezado la transición a IPv6 hace años como ha hecho Free.fr por poner un ejemplo).

              • Free no es que lo haya hecho con más tiempo, lo ha hecho con…

                Free no es que lo haya hecho con más tiempo, lo ha hecho con una variante del 6to4 que por ejemplo Cogent desechó después de varios meses de pruebas y que ningún otro va a usar, supongo que por algo será.

            • BocaDePez BocaDePez
              6
              El NAT para IPv4 será necesario mientra existan aplicaciones…

              El NAT para IPv4 será necesario mientra existan aplicaciones no adaptadas a IPv6. Si quieres usar P2P, VoIP, etc tendrás que hacerlo sobre IPv6, ya hay unas cuantos programas de estos con soporte de IPv6. Quizas el mayor problema lo tengan los que juegan online, ya que es más difícil adaptar los juegos y servidores de estos.

            • El problema es que durante un tiempo todavía por definir pero…

              El problema es que durante un tiempo todavía por definir pero que no será corto van a convivir IPV4 y IPV6 con dual stack después de comprobar el fracaso de sistemas como el 6to4.

  • BocaDePez BocaDePez
    36

    Al final tanto quejarse del proxy-caché y van a poner algo…

    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

    • Lo que harán será una especie de 6to4 a nivel de compañía. Es…

      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

      (http://msdn.microsoft.com/en-us/library/ms737598(v=vs.85).aspx)

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

      • 12

        El 6to4 es una chapuza de tal calibre que los técnicos de…

        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

        • Ya se verá, ya se verá. Que esto, según va pasando el tiempo,…

          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 :)

    • BocaDePez BocaDePez
      6

      Ninguno va a implementar IPv6 a corto plazo, ambos son…

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

      • BocaDePez BocaDePez
        12

        ¿Ah que el de Telefónica es una maravilla? Cuando llamas y te…

        ¿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

        • BocaDePez BocaDePez
          0
          El servicio técnico de la timo puede que sea un asco, pero es…

          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.

          • BocaDePez BocaDePez
            12
            No lo diras por ONO, porque en 10 años 3 veces he tenido…

            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
            12
            Si te has creído que los problemas que he tenido con…

            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
    6

    ¿Seguro que pueden permitirselo? Yo creo que habra que echar…

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

  • BocaDePez BocaDePez
    6

    Nada hombre , todos a echar una manita a Telefónica... daros…

    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

1