-- Leo's gemini proxy
-- Connecting to elpamplina.duckdns.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
por elpamplinadecai@gmail.com
El protocolo IP más extendido (en el momento de escribir este tutorial) es el que originariamente se desarrolló como IP versión 4 (en forma abreviada IPv4) a finales de la década de los 1970, y publicado en 1980 como RFC 760. La fortaleza de su diseño ha hecho que durante décadas siga siendo la base de prácticamente todas las comunicaciones no sólo en Internet, sino incluso en redes locales e intranets. Pocos desarrollos tecnológicos en la historia han sido tan exitosos y se han mantenido sin cambios por tanto tiempo.
Sin embargo, su punto débil (y el que va a precipitar su final) es el espacio de direcciones. Cuando se desarrolló IPv4, el escenario era el de unos pocos miles de mainframes (grandes computadoras) en redes universitarias y de investigación. Los ordenadores personales eran casi inexistentes. En aquel momento, la idea de que llegaría un momento en que cada persona necesitaría, no una, sino varias direcciones IP era algo descabellado. Por tanto, se definió un esquema de direcciones IP de 32 bits. Con más de cuatro mil millones de combinaciones (232), pareció más que suficiente.
Con el paso de los años, el desarrollo de ordenadores personales y todo tipo de dispositivos que requieren direcciones IP (teléfonos móviles, etc.) hace que cada vez más sean necesarias más de una dirección IP por persona. A principios de 2011 se liberan los últimos bloques de direcciones y se constata que el agotamiento sería definitivo para 2012.
Mucho antes, a finales del siglo XX, la IETF se puso a trabajar en una nueva versión de IP. Se llamó IPv6 porque el número de versión 5 ya se había usado para un protocolo orientado a conexión, complementario de IPv4, que no llegó a cuajar.
Hay que tener claro que la adopción de IPv6 es la única solución que va a permitir a Internet seguir desarrollandose. Por tanto, su uso generalizado solo es cuestión de tiempo, a pesar de la lentitud y poco entusiasmo con los que ha ido siendo adoptado por los proveedores de Internet (ISP).
El espacio de direcciones que introduce IPv6 es de 128 bits. La cantidad de direcciones posibles que surge de esta longitud no sólo es suficiente para cualquier uso futuro, sino que resulta inimaginable para la mente humana. Sólo decir que en este espacio hay varios miles de cuatrillones de direcciones para cada persona del planeta.
Esta enorme extensión en el espacio de direcciones no es arbitraria, sino que ha sido pensada más alla de evitar el simple agotamiento. La idea es que, usando este espacio tan amplio, sea posible desarrollar mecanismos de rutado mucho más eficientes. Las técnicas de agregación de rutas permitirán que diferentes partes de Internet puedan usar prefijos comunes de manera estructurada.
Lógicamente, al aumentar tanto de tamaño, la forma de representar los dígitos de las direcciones debe cambiar con respecto a IPv4. Concretamente, la representación común es de números hexadecimales de 16 bits cada uno, separados por el signo de dos puntos (:). Se forman, por tanto, ocho grupos con cuatro dígitos hexadecimales cada uno. Por ejemplo:
3ffe:1900:4545:3:200:f8ff:fe21:67cf
Los ceros a la izquierda en cada grupo no se escriben. Las letras hexadecimales se escriben en minúsculas por convención.
Dado que esta notación aún es incómoda de usar por su longitud, se permite abreviarla usando ciertas convenciones:
Los grupos de ceros consecutivos se pueden omitir colocando dos veces los dos puntos en su lugar:
fe80:0:0:0:200:f8ff:fe21:67cf
se puede abreviar a
fe80::200:f8ff:fe21:67cf
Si hay más de una secuencia de ceros, se abreviará la más larga de ellas, pero nunca más de una. Esto es para evitar representaciones ambiguas:
fe80:0:0:0:200:0:0:67cf
se abrevia a
fe80::200:0:0:67cf
pero NO se puede escribir
fe80::200::67cf
Si las secuencias de ceros a abreviar son de igual longitud, se elige la que está más a la izquierda:
fe80:0:0:1:200:0:0:67cf
se abrevia a
fe80::1:200:0:0:67cf
Usando este tipo de notación, es muy simple escribir las típicas direcciones de loopback (::1 por 0:0:0:0:0:0:1) e inespecificada (:: por 0:0:0:0:0:0:0:0).
Sin embargo, surgen problemas para integrar las direcciones en protocolos preexistentes, que usan los dos puntos para otros fines. Concretamente, para las URL (localizador universal de recurso) e URI (identificador universal de recurso), es necesario usar corchetes para delimitar la dirección IPv6. Por ejemplo:
http://[3ffe:1900:4545:3:200:f8ff:fe21:67cf]/index.html
En los localizadores de tipo UNC (convención uniforme de nombres), propio de los protocolos de Microsoft, la solución adoptada es usar un dominio DNS específico (ipv6-literal.net), cambiando además los símbolos de dos puntos (: y ::) por guiones (- y --). Por ejemplo;
3ffe-1900--f8ff-fe21-67cf.ipv6-literal.net
Aunque éste es un dominio real registrado por Microsoft, las direcciones normalmente son resueltas por el propio software sin necesidad de llamadas a los servidores DNS.
Aparte de la ampliación del espacio de direcciones, el nuevo protocolo lógicamente incorpora nuevas funcionalidades, así como correcciones de problemas que se han ido detectando en su antecesor:
En IPv6 se redefine el funcionamiento del multicast (envío de paquetes a varios nodos) y el broadcast (envío de paquetes a todos los nodos). En realidad se unifican ambos conceptos, los cuales tenían en IPv4 diferentes mecanismos. En IPv6 se solucionan muchas de las dificultades que había para implementar emisiones multicast. Por ejemplo, la adaptación entre las direcciones de unicast (punto a punto) y multicast es automática por el diseño, sin necesidad de los complejos mecanismos de IPv4. Cualquier dirección IPv6 tiene asignada por sí misma, sin configuración adicional, un conjunto amplio de direcciones multicast usables globalmente.
Una de esas direcciones multicast predefinidas es precisamente la de "todos los nodos" (ff02::1), equivalente a la tradicional dirección de broadcast (255.255.255.255).
Aparte de las tradicionales configuraciones manuales o dinámicas (DHCPv6), los nodos pueden autoconfigurarse usando un mecanismo más avanzado basado en el protocolo ICMPv6. En él, los propios encaminadores de la red informan en todo momento de los parámetros de la red y enrutado disponible, mediante la llamada autoconfiguración de direcciones sin estados (SLAAC).
Los protocolos de encriptación y autenticación IPsec, opcionales en IPv4, están ahora implementados obligatoriamente.
Las cabeceras de los paquetes IPv6 están rediseñadas para acelerar el procesamiento en los enrutadores. Esto se consigue aún cuando el tamaño de las cabeceras sea que las de IPv4, mediante un diseño más eficiente:
Los campos que se usan raramente se mueven a extensiones opcionales de la cabecera.
No se admite la fragmentación de paquetes en ruta. Los paquetes sólo se pueden fragmentar de extremo a extremo, usando una técnica de descubrimiento del tamaño máximo del camino (PMTU discovery).
Se elimina la redundancia en el control de errores (checksum). La integridad es competencia de las otras capas de red (enlace y/o transporte). Es innecesario que la capa IP tenga que calcular también el checksum.
El concepto de TTL (tiempo de vida) se rediseña a uno más lógico de límite de saltos (hop limit).
Se incorpora el concepto de jumbogramas (paquetes de hasta 4 gigabytes de tamaño) para aplicaciones específicas.
El rediseño de las cabeceras y de las propias direcciones hacen incompatibles los protocolos IPv4 y IPv6. Los nodos que implementen distintas versiones no pueden comunicarse directamente entre ellos. Para paliar este problema se han previsto distintas técnicas y adaptaciones transitorias:
Cada dirección IPv4 tiene una dirección IPv6 equivalente, convertible fácilmente. El prefijo ::ffff: indica una dirección IPv4 traducida a IPv6. Los últimos 32 bits (que serían dos grupos hexadecimales) corresponden a la propia dirección IPv4. Para mayor comodidad, se acepta la notación híbrida, dejando la dirección IPv4 en su formato original, como en el siguiente ejemplo:
150.200.1.10
se traduce en
::ffff:150.200.1.10
También existe la transcripción inversa (dirección IPv6 a IPv4), pero lógicamente no puede hacerse de uno a uno, al ser mayor el espacio de direcciones IPv6. Ciertos bloques de direcciones IPv4 se han reservado para mapear direcciones IPv6 (ver sección 6to4).
Los nodos que soportan IPv6 lo hacen normalmente mediante una doble pila o una pila híbrida, de manera que puedan manejar paquetes de ambos protocolos. Todos los sistemas operativos modernos lo incorporan por defecto para facilitar la transición.
Hay que tener en cuenta que, aunque el sistema operativo soporte IPv6, no siempre el software de aplicación puede hacer uso de él. Será necesario en ese caso actualizar ese software a una versión superior que sí lo soporte.
Cuando un nodo o red IPv6 tiene que atravesar otra red que sólo soporta IPv4 para alcanzar sus destinos se les llama nodo o red aislados. En este caso, han de usarse técnicas de tunneling (encapsulado de paquetes) para atravesar la ruta. En este caso IPv4 (o incluso UDP) funciona como una especie de capa de enlace entre nodos IPv6. Las técnicas son variadas según los fabricantes.
También existe el tunneling de IPv4 dentro de IPv6, para equipos que no soportan doble pila, pero se usa mucho menos.
En contraposición al tunneling usado para atravesar otras redes, los mecanismos de tunneling automático proveen un mecanismo de transición para conectividad entre nodos IPv4 e IPv6. Se han desarrollado varias técnicas, de las cuales las más extendidas son:
6to4: Es el método recomendado por el RFC 3056. Se determinan los extremos del túnel mapeando ciertas direcciones IPv4 llamadas anycast (direcciones que representan a determinados nodos dentro de cualquier red, es decir, obvian la parte netid de la dirección).
Teredo: En este caso se utiliza UDP como medio de encapsulamiento. Tiene la ventaja sobre 6to4 de poder atravesar enrutadores que estén usando NAT (un mecanismo de traducción de direcciones entre redes de uso muy extendido).
Los equipos Windows (a partir de Vista) incluyen ambas técnicas por defecto. Los equipos Linux sólo incorporan 6to4 por defecto y Teredo se puede instalar aparte.
Se pueden usar servidores específicos a nivel de aplicación (proxies) para dar acceso a los nodos que sólo soportan IPv6 a servidores remotos que sólo soportan IPv4. Esto se puede hacer mediante mecanismos específicos denominados NAT64 y DNS64.
@ElPamplina@masto.es
elpamplinadecai@gmail.com
-- Response ended
-- Page fetched on Thu May 9 15:28:33 2024