IPv6 Principios tecnológicos 01/06/2000 Jordi Palet. http://consulintel.es Aquí se expone una primera aproximación a los principios fundamentales de IPv6, especialmente en lo que se refiere a sus especificaciones básicas (RFC2460), y a las cuestiones que afectan a las direcciones y los direccionamientos (RFC2373). Para facilitar su comprensión, hemos optado por adoptar un esquema de tutorial. Dada la amplitud del tema, se trata tan sólo de una primera entrega sobre los principios tecnológicos del nuevo IP. Otros aspectos irán siendo desarrollados, como artículos independientes pero relacionados, en próximos números. ESPECIFICACIONES BASICAS Veamos, en primer lugar, la descripción de la cabecera de un paquete IPv4: +---------------------------------------------------------+ | +Version |*Header |+TOS | +Total Lenght | +---------------------------------------------------------+ | *Identification |*Flag | *Fragment Offset | +---------------------------------------------------------+ | +TTL | +Protocol | *Checksum | +---------------------------------------------------------+ Como vemos, la longitud mínima de la cabecera IPv4 es de 20 bytes (cada fila de la tabla supone 4 bytes). A ello hay que añadir las opciones, que dependen de cada caso. En la tabla anterior hemos usado abreviaturas, en aquellos casos en los que son comunes. En el resto, se ha optado por nuestra “particular” traducción de la nomenclatura original anglosajona, cuya “leyenda de equivalencias” indicamos a continuación: - Version – Versión (4 bits) - Header – Cabecera (4 bits) - TOS (Type Of Service) – Tipo de Servicio (1 byte) - Total Length – Longitud Total (2 bytes) - Identification – Identificación (2 bytes) - Flag – Indicador (4 bits) - Fragment Offset – Desplazamiento de Fragmentación (12 bits – 1.5 bytes) - TTL (Time To Live) – Tiempo de Vida (1 byte) - Protocol – Protocolo (1 byte) - Checksum – Código de Verificación (2 bytes) - 32 bit Source Address – Dirección Fuente de 32 bits (4 bytes) - 32 bit Destination Address – Dirección Destino de 32 bits (4 bytes) En la tabla anterior, hemos marcado, mediante el color de fondo, los campos que van a desaparecer en IPv6, y los que son modificados, según el siguiente esquema: Campo modificado = + Campo que desaparece = * En el nuevo IP, se ha pasado de tener 12 campos, como en IPv4, a tan solo 8. El motivo fundamental por el que los campos son eliminados es la innecesaria redundancia. En IPv4 se facilita la misma información de varias formas. Un caso muy evidente es el checksum o verificación de la integridad de la cabecera, cuya función ya es realizada por otros mecanismos de encapsulado (IEEE 802 MAC, framing PPP, capa de adaptación ATM, etc.). El caso del campo de “Desplazamiento de Fragmentación”, es ligeramente diferente, dado que el mecanismo por el que se realiza la fragmentación de los paquetes se ha modificado totalmente en IPv6, lo que implica la total “inutilidad” de este campo. En IPv6 los encaminadores no fragmentan los paquetes, sino que de ser precisa, dicha fragmentación/desfragmentación se produce extremo a extremo. Algunos de los campos han adoptado otras denominaciones: - Longitud total: longitud de carga útil (payload length). Es, en definitiva, la longitud de los propios datos, y puede ser de más de 65.536 bytes. Tiene una longitud de 16 bits (2 bytes). - Protocolo: siguiente cabecera (next header). Dado que en lugar de usar cabeceras de longitud variables se emplean sucesivas cabeceras encadenadas, desaparece el campo de opciones. En muchos casos ni siquiera es procesado por los encaminadores, sino tan sólo extremo a extremo. Tiene una longitud de 8 bits (1 byte). - Tiempo de vida: límite de saltos (Hop Limit). Tiene una longitud de 8 bits (1 byte). Los nuevos campos son: - Clase de Tráfico (Traffic Class), también denominado Prioridad (Priority), o simplemente Clase (Class). Podría ser más o menos equivalente a TOS en IPv4. Tiene una longitud de 8 bits (1 byte). - Etiqueta de Flujo (Flow Label), para permitir tráficos con requisitos de tiempo real. Tiene una longitud de 20 bits. Estos dos campos, como se puede suponer, son los que nos permiten una de las características fundamentales e intrínsecas de IPv6: Calidad de Servicio (QoS), Clase de Servicio (CoS), y en definitiva un poderoso mecanismo de control de flujo, de asignación de prioridades diferenciadas según los tipos de servicios. Por tanto, en el caso de un paquete IPv6, la cabecera tendría el siguiente formato: El campo de versión, que es igual a 6, lógicamente, tiene una longitud de 4 bits. La longitud de esta cabecera es de 40 bytes, el doble que en el caso de IPv4, pero con muchas ventajas, al haberse eliminado campos redundantes. Además, como ya se ha mencionado, la longitud fija de la cabecera implica una mayor facilidad para su procesado en routers y conmutadores, incluso mediante hardware, lo que implica unas mayores prestaciones. A este fin coadyuva, como hemos indicado anteriormente, el hecho de que los campos están alineados a 64 bits, lo que permite que las nuevas generaciones de procesadores y microcontroladores, de 64 bits, puedan procesar mucho más eficazmente la cabecera IPv6. El valor del campo “siguiente cabecera”, indica cual es la siguiente cabecera y así sucesivamente. Las sucesivas cabeceras, no son examinadas en cada nodo de la ruta, sino sólo en el nodo o nodos destino finales. Hay una única excepción a esta regla: cuando el valor de este campo es cero, lo que indica opción de examinado y proceso “salto a salto” (hop-by-hop). Así tenemos, por citar algunos ejemplos, cabeceras con información de encaminado, fragmentación, opciones de destino, autenticación, encriptación, etc., que en cualquier caso, han de ser procesadas en el orden riguroso en que aparecen en el paquete. Sin entrar en más detalles, véanse a continuación los siguientes ejemplos gráficos del uso del concepto de las “cabeceras de extensión” (definidas por el campo “siguiente cabecera”), mecanismo por el que cada cabecera es “encadenada” a la siguiente y anterior (si existen): El MTU (Unidad Máxima de Transmisión) debe de ser como mínimo, de 1.280 bytes, aunque se recomiendan tamaños superiores a 1.500 bytes. Los nodos descubren el valor MTU a través de la inspección de la ruta. Se prevé así una optimización de los paquetes y del número de cabeceras, dado el continuo crecimiento de los anchos de banda disponibles, así como del incremento del propio tráfico. Dado que IPv6 no realiza verificación de errores de la cabecera en tráfico UDP, se requiere el empleo del su propio mecanismo de checksum. DIRECCIONES Y DIRECCIONAMIENTO Ya hemos dicho que IPv6 nos aporta, como principio fundamental, un espacio de direcciones de 2 elevado a 128, lo que equivale a 3,40 elevado a 38 (340.282.366. 920.938.463.463.374.607.431.768.211.456). Definición de dirección en IPv6 Las direcciones IPv6 son identificadores de 128 bits para interfaces y conjuntos de interfaces. Dichas direcciones se clasifican en tres tipos: - Unicast: Identificador para una única interfaz. Un paquete enviado a una dirección unicast es entregado sólo a la interfaz identificada con dicha dirección. Es el equivalente a las direcciones IPv4 actuales. - Anycast: Identificador para un conjunto de interfaces (típicamente pertenecen a diferentes nodos). Un paquete enviado a una dirección anycast es entregado en una (cualquiera) de las interfaces identificadas con dicha dirección (la más próxima, de acuerdo a las medidas de distancia del protocolo de routing). Nos permite crear, por ejemplo, ámbitos de redundancia, de forma que varias máquinas puedan ocuparse del mismo tráfico según una secuencia determinada (por el routing), si la primera “cae”. - Multicast: Identificador para un conjunto de interfaces (por lo general pertenecientes a diferentes nodos). Un paquete enviado a una dirección multicast es entregado a todas las interfaces identificadas por dicha dirección. La misión de este tipo de paquetes es evidente: aplicaciones de retransmisión múltiple (broadcast). Diferencias con IPv4 Hay algunas diferencias importantes en el direccionamiento de IPv6 respecto de IPv4: - No hay direcciones broadcast (su función es sustituida por direcciones multicast). - Los campos de las direcciones reciben nombres específicos; denominamos “prefijo” a la parte de la dirección hasta el nombre indicado (incluyéndolo). - Dicho prefijo nos permite conocer dónde esta conectada una determinada dirección, es decir, su ruta de encaminado. Cualquier campo puede contener sólo ceros o sólo unos, salvo que explícitamente se indique lo contrario. - Las direcciones IPv6, indistintamente de su tipo (unicast, anycast o multicast), son asignadas a interfaces, no nodos. Dado que cada interfaz pertenece a un único nodo, cualquiera de las direcciones unicast de las interfaces del nodo puede ser empleado para referirse a dicho nodo. - Todas las interfaces han de tener, al menos, una dirección unicast link -local (enlace local). - Una única interfaz puede tener también varias direcciones IPv6 de cualquier tipo (unicast, anycast o multicast) o ámbito. Una misma dirección o conjunto de direcciones unicast pueden ser asignados a múltiples interfaces físicas, siempre que la implementación trate dichas interfaces desde el punto de vista de internet, como una única, lo que permite balanceo de carga entre múltiples dispositivos. - Al igual que en IPv4, se asocia un prefijo de subred con un enlace, y se pueden asociar múltiples prefijos de subred a un mismo enlace. Reservas de espacio de direccionamiento en IPv6 A diferencia de las asignaciones de espacio de direccionamiento que se hicieron en IPv4, en IPv6, se ha reservado, que no “asignado”, algo más del 15%, tanto para permitir una fácil transición (caso del protocolo IPX) como para mecanismos requeridos por el propio protocolo. De esta forma se permite la asignación directa de direcciones de agregación, direcciones locales, y direcciones multicast, con reservas para OSI NSAP e IPX. El 85% restante queda reservado para uso futuro. Podemos distinguir las direcciones multicast de las unicast por el valor del octeto de mayor orden de la dirección (FF, o 11111111 en binario, indica multicast). En cambio, en el caso de las anycast, no hay ninguna diferencia, sintácticamente hablando, y por tanto, son tomadas del espacio de direcciones unicast. Direcciones especiales Se han definido también las direcciones para usos especiales como: - Dirección de auto-retorno o Loopback (::1) – No ha de ser asignada a una interfaz física; se trata de una interfaz “virtual”, pues son paquetes que no salen de la máquina que los emite; nos permite hacer un bucle para verificar la correcta inicialización del protocolo (dentro de una determinada máquina). - Dirección no especificada (::) – Nunca debe ser asignada a ningún nodo, ya que se emplea para indicar la ausencia de dirección; por ejemplo, cuando se halla en el campo de dirección fuente, indica que se trata de un host que esta iniciándose antes de que haya aprendido su propia dirección. Túneles dinámicos/automáticos de IPv6 sobre IPv4 (::) – Se denominan direcciones IPv6 compatibles con IPv4, y permiten la retransmisión de tráfico IPv6 sobre infraestructuras IPv4 de forma transparente. - Representación automática de direcciones IPv4 sobre IPv6 (::FFFF:) – permite que los nodos que sólo soportan IPv4, puedan seguir trabajando en redes IPv6. Se denominan “direcciones IPv6 mapeadas desde IPv4”. Representación de las direcciones IPv6 La representación de las direcciones IPv6 sigue el siguiente esquema: - x:x:x:x:x:x:x:x, donde “x” es un valor hexadecimal de 16 bits, de la porción correspondiente a la dirección IPv6. No es preciso escribir los ceros a la izquierda de cada campo. Ejemplos: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:0:8:800:200C:417A - Dado que, por el direccionamiento que se ha definido, podrán existir largas cadenas de bits “cero”, se permite la escritura de su abreviación, mediante el uso de “::”, que representa múltiples grupos consecutivos de 16 bits “cero”. Este símbolo sólo puede aparecer una vez en la dirección IPv6. Ejemplos: Las direcciones: 1080:0:0:0:8:800:200C:417A (una dirección unicast) FF01:0:0:0:0:0:0:101 (una dirección multicast) 0:0:0:0:0:0:0:1 (la dirección loopback) 0:0:0:0:0:0:0:0 (una dirección no especificada) Pueden representarse como: 1080::8:800:200C:417A (una dirección unicast) FF01::101 (una dirección multicast) ::1 (la dirección loopback) :: (una dirección no especificada) - Una forma alternativa y muy conveniente, cuando nos hallemos en un entorno mixto IPv4 e IPv6, es x:x:x:x:x:x:d:d:d:d, donde “x” representa valores hexadecimales de 16 bits (6 porciones de mayor peso), y “d” representa valores decimales de las 4 porciones de 8 bits de menor peso (representación estándar IPv4). Ejemplos: 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:FFFF:129.144.52.38 Pueden representarse como: ::13.1.68.3 ::FFFF:129.144.52.38 La representación de los prefijos IPv6 se realiza del siguiente modo: dirección IPv6/longitud-del-prefijo donde: - dirección-IPv6 = una dirección IPv6 en cualquiera de las notaciones válidas - longitud-del-prefijo = valor decimal indicando cuantos bits contiguos de la parte izquierda de la dirección componen el prefijo Por ejemplo, las representaciones válidas del prefijo de 60 bits 12AB00000000CD3, son: 12AB:0000:0000:CD30:0000:0000:0000:0000/60 12AB::CD30:0:0:0:0/60 12AB:0:0:CD30::/60 Por tanto, para escribir una dirección completa, indicando la subred, podríamos hacerlo como: 12AB:0:0:CD30:123:4567:89AB:CDEF/60 Direcciones unicast locales Las direcciones unicast son agregables con máscaras de bits contiguos, similares al caso de IPv4, con CIDR (Class-less Interdomain Routing). Como hemos visto, hay varias formas de asignación de direcciones unicast, y otras pueden ser definidas en el futuro. Los nodos IPv6 pueden no tener ningún conocimiento o mínimo de la estructura interna de las direcciones IPv6, dependiendo de su misión en la red (por ejemplo, host frente a router). Pero como mínimo, un nodo debe considerar que las direcciones unicast (incluyendo la propia), no tienen estructura: Un host algo más sofisticado conocería el prefijo de la subred del enlace al que esta conectado: Dispositivos más sofisticados pueden tener un conocimiento más amplio de la jerarquía de la red, sus límites, etc., en ocasiones dependiendo de la posición misma que el dispositivo o host/router, ocupa en la propia red. El “identificador de interfaz” se emplea, por tanto, para identificar interfaces en un enlace, y deben de ser únicos en dicho enlace. En muchos casos también serán únicos en un ámbito más amplio. Por lo general, el identificador de interfaz coincidirá con la dirección de la capa de enlace de dicha interfaz. El mismo identificador de interfaz puede ser empleado en múltiples interfaces del mismo nodo, sin afectar a su exclusividad global en el ámbito IPv6. Se han definido dos tipos de direcciones unicast de uso local: Local de Enlace (Link-Local) y Local de Sitio (Site-Local). Las direcciones locales de enlace han sido diseñadas para direccionar un único enlace para propósitos de autoconfiguración (mediante identificadores de interfaz), descubrimiento del vecindario, o situaciones en las que no hay routers. Por tanto, los encaminadores no pueden retransmitir ningún paquete con direcciones fuente o destino que sean locales de enlace (su ámbito esta limitado a la red local). Tienen el siguiente formato: Se trata de direcciones FE80::/10. Las direcciones locales de sitio permiten direccionar dentro de un “sitio” local u organización, sin la necesidad de un prefijo global. Se configuran mediante un identificador de subred, de 16 bits. Los encaminadores no deben de retransmitir fuera del sitio ningún paquete cuya dirección fuente o destino sea “local de sitio” (su ámbito esta limitado a la red local o de la organización). Se trata de direcciones FEC0:::/10. Direcciones anycast Tal y como hemos indicado antes, las direcciones anycast tienen el mismo rango de direcciones que las unicast. Cuando una dirección unicast es asignada a más de una interfaz, convirtiéndose en una dirección anycast, los nodos a los que dicha dirección ha sido asignada deben ser explícitamente configurados para que reconozcan que se trata de una dirección anycast. Existe una dirección anycast, requerida para cada subred, que se denomina “dirección anycast del router de la subred” (subnet-router anycast address). Su sintaxis es equivalente al prefijo que especifica el enlace correspondiente de la dirección unicast, siendo el indicador de interfaz igual a cero: Todos los routers han de soportar esta dirección para las subredes a las que están conectados. Los paquetes enviados a la “dirección anycast del router de la subred”, serán enviados a un router de la subred. Una aplicación evidente de esta característica, además de la tolerancia a fallos, es la movilidad. Imaginemos nodos que necesitan comunicarse con un router entre el conjunto de los disponibles en su subred. Dentro de cada subred, los 128 valores superiores de identificadores de interfaz están reservados para su asignación como direcciones anycast de la subred. La construcción de una dirección reservada de anycast de subred depende del tipo de direcciones IPv6 usadas dentro de la subred. Las direcciones cuyos tres primeros bits (prefijo de formato) tienen valores entre 001 y 111 (excepto las de multicast, 1111 1111), indican con el bit “universal/local” igual a cero, que el identificador de interfaz tiene 64 bits, y por tanto no es globalmente único (es local). En este caso, las direcciones reservadas anycast de subred se construyen del siguiente modo: En el resto de los casos, el identificador de interfaz puede tener una longitud diferente de 64 bits, por lo que la construcción se realiza según el siguiente esquema: Direcciones multicast Una dirección multicast en IPv6 puede definirse como un identificador para un grupo de nodos. Un nodo puede pertenecer a uno o varios grupos multicast. Las direcciones multicast tienen el siguiente formato: El bit “T” indica, si su valor es cero, una dirección multicast permanente, asignada únicamente por la autoridad de numeración global de Internet. En caso contrario, si su valor es uno, se trata de direcciones multicast temporales. Los 4 bits que le preceden, que por el momento están fijados a cero, están reservados para futuras actualizaciones. Los bits “ámbito” tienen los siguientes significados: El “Identificador de Grupo”, identifica, como cabe esperar, el grupo de multicast concreto al que nos referimos, bien sea permanente o temporal, dentro de un determinado ámbito. Por ejemplo, si asignamos una dirección multicast permanente, con el identificador de grupo 101 (hexadecimal), al grupo de los servidores de tiempo (NTS), entonces: - FF01::101 significa todos los NTS en el mismo nodo que el paquete origen - FF02::101 significa todos los NTS en el mismo enlace que el paquete origen - FF05::101 significa todos los NTS en el mismo sitio que el paquete origen - FF0E::101 significa todos los NTS en Internet Las direcciones multicast no permanentes sólo tienen sentido en su propio ámbito. Por ejemplo, un grupo identificado por la dirección temporal multicast local de sitio FF15::101, no tiene ninguna relación con un grupo usando la misma dirección en otro sitio, ni con otro grupo temporal que use el mismo identificador de grupo (en otro ámbito), ni con un grupo permanente con el mismo identificador de grupo. Las direcciones multicast no deben ser usadas como dirección fuente en un paquete IPv6, ni aparecer en ninguna cabecera de encaminado. Las principales direcciones multicast reservadas son las incluidas en el rango FF0x:0:0:0:0:0:0:0. Algunos ejemplos útiles de direcciones multicast, según su ámbito, serían: - FF01:0:0:0:0:0:0:1 – todos los nodos (ámbito local) - FF02:0:0:0:0:0:0:1 – todos los nodos (ámbito de enlace) FF01:0:0:0:0:0:0:2 – todos los routers (ámbito local) - FF02:0:0:0:0:0:0:2 – todos los routers (ámbito de enlace) - FF05:0:0:0:0:0:0:2 – todos los routers (ámbito de sitio) La dirección FF02:0:0:0:0:1:FFxx:xxxx, denominada “Solicited Node Address”, o dirección de nodo solicitada, permite calcular la dirección multicast a partir de la unicast o anycast de un determinado nodo. Para ello, se sustituyen los 24 bits de menor peso (“x”) por los mismos bits de la dirección original. Así, la dirección 4037::01:800:200E:8C6C se convertiría en FF02::1:FF0E:8C6C. Cada nodo debe de calcular y unirse a todas las direcciones multicast que le corresponden para cada dirección unicast y anycast que tiene asignada. Direcciones Requeridas para cualquier nodo Todos los nodos, en el proceso de identificación, al unirse a la red, deben de reconocer como mínimo, las siguientes direcciones: - Sus direcciones locales de enlace para cada interfaz Las direcciones unicast asignadas - La dirección de loopback - Las direcciones multicast de todos los nodos - Las direcciones multicast solicitadas para cada dirección unicast o anycast asignadas - Las direcciones multicast de todos los grupos a los que dicho host pertenece Además, en el caso de los routers, tienen que reconocer también: - La dirección anycast del router de la subnet, para las interfaces en las que esta configurado para actuar como router - Todas las direcciones anycast con las que el router ha sido configurado - Las direcciones multicast de todos los routers - Las direcciones multicast de todos los grupos a los que el router pertenece Además, todos los dispositivos con IPv6, deben de tener predefinidos los prefijos siguientes: - Dirección no especificada - Dirección de loopback Prefijo de multicast (FF) - Prefijos de uso local (local de enlace y local de sitio) - Direcciones multicast predefinidas - Prefijos compatibles IPv4 Se debe de asumir que todas las demás direcciones son unicast a no ser que sean específicamente configuradas (por ejemplo las direcciones anycast). Direcciones unicast globales agregables Dado que uno de los problemas que IPv6 resuelve es la mejor organización jerárquica del routing en las redes públicas (globales), es indispensable el concepto de direccionamiento “agregable”. En la actualidad ya se emplea este tipo de direcciones, basadas en la agregación por parte de los proveedores del troncal Internet, y los mecanismos adoptados para IPv6, permiten su continuidad. Pero además, se incorpora un mecanismo de agregación basado en “intercambios”. La combinación de ambos es la que permite un encaminamiento mucho más eficiente, dando dos opciones de conectividad a unas u otras entidades de agregación. Se trata de una organización basada en tres niveles: - Topología Pública: conjunto de proveedores e “intercambiadores” que proporcionan servicios públicos de tránsito Internet. - Topología de Sitio: redes de organizaciones que no proporcionan servicios públicos de tránsito a nodos fuera de su propio “sitio”. - Identificador de Interfaz: identifican interfaces de enlaces. En la figura adjunta, el formato de direcciones agregables ha sido diseñado para soportar proveedores de larga distancia (identificados como Proveedor 1-4), intercambiadores (Intercambiador 1 y 2), proveedores de niveles inferiores (podrían ser ISP’s, identificados como Proveedor 5 y 6), y Clientes (Cliente A F). A diferencia de lo que ocurre actualmente, los intercambiadores también proporcionarán direcciones públicas IPv6. Las organizaciones conectadas a dichos intercambiadores también recibirán servicios de conectividad directos, indirectamente a través del intercambiador, de uno o varios proveedores de larga distancia. De esta forma, su direccionamiento es independiente de los proveedores de tráfico de larga distancia, y pueden, por tanto, cambiar de proveedor sin necesidad de renumerar su organización. Este es uno de los objetivos de IPv6. Además, una organización puede estar suscrita a múltiples proveedores (multi-homing o “multi-localización”), a través de un intercambiador, sin necesidad de tener prefijos de direcciones de cada uno de los proveedores. Estructura de direcciones unicast globales agregables El formato de las direcciones unicast globales agregables es el siguiente: Donde: El campo Reservado permitirá, en el futuro, ampliaciones “organizadas” del protocolo, como, por ejemplo ampliar el número de bits de los campos TLA y NLA. Por el momento contiene ceros. Identificador de Agregación de Nivel Superior Se trata del nivel superior en la estructura jerárquica de enrutado. Los routers situados en este nivel tienen, en la tabla de encaminado, una entrada para cada TLA ID activo, y probablemente entradas adicionales relativas al propio TLA ID donde están físicamente situados. Podrían tener otras entradas para su optimización, dependiendo de su topología, pero siempre pensando en que se minimice la tabla. Esta estructura de direccionamiento permite 8.192 (2 elevado a 13) identificadores de TLA. Se prevé su crecimiento haciendo que este campo crezca hacia la derecha en el espacio reservado para el futuro, o usando este mismo formato/estructura para prefijos de formato (FP) adicionales. Identificador de Agregación de Siguiente Nivel Es empleado por organizaciones a las que se ha asignado un TLA para crear una estructura jerárquica de direccionamiento, acorde con su propia red, y para identificar los “sitios” u organizaciones que de ella dependen. Pueden reservar los bits superiores para la diferenciación de la estructura de su red, en función a sus propias necesidades. Dado que cada organización que recibe un TLA dispone de 24 bits de espacio NLA, permite proporcionar servicio aproximadamente al número total de direcciones IPv4 soportadas actualmente. Las organizaciones que reciben un TLA pueden soportar varios NLA en su propio espacio de direccionamiento (Site ID). Esto permite que sirvan tanto a clientes directos (suscriptores) como a otras organizaciones proveedoras de servicios públicos de tránsito. Y así sucesivamente, como se muestra en la siguiente figura: El diseño del espacio NLA de cada organización es libre para cada TLA asignado, y así sucesivamente con los niveles inferiores. Sin embargo, se recomienda seguir los procedimientos del RFC2050. En cualquier caso es fundamental apreciar el balance entre eficacia de encaminado agregable y flexibilidad. Las estructuras más jerárquicas permiten una mejor agregación, y por tanto reducen las tablas de encaminado. Por el contrario, asignaciones más planas del espacio NLA proporcionan mejor flexibilidad en la conexión (crecimientos no previstos en un determinado espacio), resultando en tablas de encaminado mayores, y por tanto menos eficaces. Identificador de Agregación de Nivel de Sitio El SLA es usado por organizaciones “finales” para crear su propia estructura jerárquica de direcciones e identificar sus subredes. Es equivalente al concepto de subred en IPv4, con la muy apreciable diferencia de que cada corporación tiene un mayor número de subredes (16 bits proporcionan capacidad para 65.535). Del mismo modo que en el caso del NLA, se puede escoger entre una estructura “plana”, o crear varios niveles, según la figura adjunta: n16-n bits64 bitsSLA1SubredInterfaz IDm16-n-m bits64 bitsSLA2SubredInterfaz IDUna gran compañía podría necesitar varios identificadores SLA. Como es lógico, cada caso dependerá de cómo están conectadas sus diversas delegaciones. Formato para la representación en URL Cuando navegamos, continuamente aludimos a URL, en muchas ocasiones sin conocer el significado precios de esta abreviatura. La especificación original (RFC2396), que data del año 1.988, nos dice que Uniform Resource Locator (Localizador de Recurso Uniforme) es un medio simple y extensible para identificar un recurso a través de su localización en la red. Una vez aclarado esto, y de la misma forma que en ocasiones usamos direcciones en formato IPv4 para escribir un URL, se han descrito unas normas para realizar la representación literal de direcciones IPv6 cuando se usan herramientas de navegación WWW. El motivo por el que ha sido preciso realizar esta definición es bien simple. Con la anterior especificación no estaba permitido emplear el carácter “:” en una dirección, sino como separador de “puerto”. Por tanto, si se desea facilitar operaciones tipo “cortar y pegar” (cut and paste) de forma rápida para trasladar direcciones entre diferentes aplicaciones era preciso buscar una solución que evitase la edición manual de las direcciones IPv6. La solución es bien sencilla: el empleo de los corchetes (“[”,“]”) para encerrar la dirección IPv6, dentro de la estructura habitual del URL. Veamos algunos ejemplos. Las direcciones siguientes: - FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 - 1080:0:0:0:8:800:200C:4171 - 3ffe:2a00:100:7031::1 - 1080::8:800:200C:417A ::192.9.5.5 - ::FFFF:129.144.52.38 - 2010:836B:4179::836B:4179 serían representadas como: http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html http://[1080:0:0:0:8:800:200C:417A]/index.html - http://[3ffe:2a00:100:7031::1] - http://[1080::8:800:200C:417A]/foo - http://[::192.9.5.5]/ipng http://[::FFFF:129.144.52.38]:80/index.html - http://[2010:836B:4179::836B:4179] Hemos añadido alguna “complicación”, para que el propio lector descubra el uso del separador de puertos. Conclusiones Aunque puede parecer un esquema muy complejo, en realidad es muy simple y sobre todo, muy eficiente. Los resultados de este esquema son: - Las direcciones siguen siendo asignadas por el proveedor, pero al cambiar de proveedor, sólo cambia el prefijo, y la red se “renumera” automáticamente (routers, sitios y nodos finales – dispositivos – servidores). - Las interfaces pueden tener múltiples direcciones. - Las direcciones tienen ámbito (Global, Sitio, Enlace). - Las direcciones, al estar compuestas por un prefijo y un identificador de interfaz, nos permiten separar “quién es” de “donde esta conectado”: - Además, las direcciones tienen un período de vida (de validez). El RFC2450 propone las reglas para la administración de los TLA’s y NLA’s. Además, en http://www.arin.net/regserv/ipv6/IPv6.txt. podemos encontrar más información al respecto de las normas para registros IPv6, del mismo modo que en http://www.ripe.net/ripencc/about/regional/maps/ipv6policy-draft-090699.html. o en http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html. En todos los casos, la máxima autoridad competente es IANA (Internet Assigned Numbers Authority).