1. IPV6 BÁSICO 1
1.1. DISTRIBUCIÓN DE DIRECCIONES IPV4 1
1.2. EVOLUCIÓN DE LA NECESIDAD DE DIRECCIONES 3
1.3. INCONVENIENTES TÉCNICOS DE IPV4 3
1.4. LA SOLUCIÓN:IPV6 5
1.5. HISTORIA DE IPV6 7
2. CABECERA, DIRECCIONAMIENTO Y CONFIGURACIÓN BÁSICA. 9
2.1. LA NUEVA CABECERA 10
2.1.1. LIMPIEZA EN IPV4 10
2.1.2. LOS CAMPOS BIT A BIT 12
2.1.3. LAS CABECERAS DE EXTENSIÓN 15
2.2. DIRECCIONAMIENTO 19
2.2.1. LOS PREFIJOS 21
2.2.2. DIRECCIÓN NO ESPECIFICADA Y DIRECCIÓN DE LOOPBACK 22
2.2.3. DIRECCIONES UNICAST GLOBALES 23
2.2.4. DIRECCIÓN UNICAST DE ENLACE LOCAL 25
2.2.5. DIRECCIÓN UNICAST LOCAL ÚNICA 27
2.2.6. DIRECCIONES ANYCAST 28
2.2.7. DIRECCIONES MULTICAST 30
2.2.8. DIRECCIONES DE CADA NODO 33
2.2.9. SELECCIÓN DE DIRECCIONES POR DEFECTO 33
2.3. INSTALACIÓN Y TIPOS DE CONFIGURACIÓN DE IPV6 36
2.3.1. INSTALACIÓN Y CONFIGURACIÓN BÁSICA DE IPV6: 36
2.3.2. CONFIGURACIÓN AVANZADA DE IPV6: 48
2.4. ORDENES BÁSICAS EN GNU/LINUX Y WINDOWS 50
2.4.1. ORDENES BÁSICAS EN UBUNTU-LINUX 50
2.4.2. ORDENES BÁSICAS EN WINDOWS 55
2.5. PRUEBAS DE CONECTIVIDAD EN LAN(PING6) 60
3. CONFIGURACIÓN AVANZADA. 64
3.1. ICMPV6. 64
3.1.1. LOS MENSAJES 65
3.1.2. NEIGHBOR DISCOVERY 71
3.1.3. OTRAS POSIBILIDADES DE ICMPV6 78
3.2. CONFIGURACIÓN STATELESS. 84
3.2.1. INTRODUCCIÓN 84
3.2.2. DESCRIPCIÓN 84
3.2.3. AUTOCONFIGURACIÓN DE DIRECCIONES GLOBALES 85
3.2.4. OBTENCIÓN DE DIRECCIONES DE AUTOCONFIGURACIÓN 87
3.2.5. ALGORITMOS DE GENERACIÓN DE DIRECCIONES GLOBALES 88
3.3. DHCPV6. 94 3.3.1. DHCPV6UBUNTU 9.10SERVER 95 3.3.2. DHCPV6WINDOWS 2008SERVER 97 3.3.3. DHCPV6CLIENTE UBUNTU 9.10 104 3.3.4. DHCPV6CLIENTE WINDOWS XP 107 3.3.5. DHCPV6CLIENTE WINDOWS 7 113 3.4. CONFIGURACIÓN MANUAL. 115
3.4.1. CONFIGURACIÓN MANUAL EN UBUNTU-LINUX 115
3.4.2. CONFIGURACIÓN MANUAL EN WINDOWS 121
3.5. PLANIFICACIÓN DE UNA RED IPV6 130
4. MECANISMOS DE TRASICIÓN PARA CONSEGUIR CONECTIVIDAD. 132
4.1. IPV6 IN IPV4 133
4.2. IPV6 TO IPV4 136
4.3. TEREDO. 139
5. EJEMPLOS DE TUNELES: TUNNEL BROKER Y TEREDO 142
5.1. CREACIÓN DE TÚNEL EN UN HOST CON WINDOWS CON FREENET6. 142 5.2. CREACIÓN DE TÚNEL DE UN FIREWALL DE BEBIAN CON HURRICANE. 152
5.3. CREACIÓN DE TÚNEL TEREDO 160
6. INYECCIÓN Y CAPTURA DE PAQUETES. 164
6.1. WIRESHARK 164
7. NUEVAS AMENAZAS CON IPV6 170
7.1. COMUNICACIONES A TRAVÉS DE IPV6 170
7.2. ATAQUES CONTRA LA AUTOCONFIGURACIÓN IPV6 170
7.3. VULNERABILIDADES CON TEREDO 171
7.3.1. PUERTA ABIERTA A INTERNET 171
7.3.2. SUPLANTACIÓN DE IDENTIDADES 172
7.3.3. ATAQUES DE DENEGACIÓN DE SERVICIOS 172
7.4. VULNERABILIDADES CON 6TO4 173
7.4.1. PUERTA ABIERTA A INTERNET 173
7.4.2. SUPLANTACIÓN DE IDENTIDADES 173
1.
IPv6 Básico
A pesar de no tener dueño y de dar la sensación de ser un mundo incontrolable, desde el punto de vista técnico, Internet está totalmente regulada.
Ejemplos:
Todos los equipos del mundo que se conectan a Internet, están identificados de forma unívoca por medio de una especie de matrícula digital: la dirección IP.
Todos los datos que circulan por la red van empaquetados y tienen su origen y destino perfectamente identificados, así como cuál es la aplicación que les espera.
Las comunicaciones que se establecen entre equipos, tanto vía Internet como en nuestras redes locales, se rigen por una serie de protocolos estándar totalmente definidos.
Todos los protocolos empleados conviven en la llamada pila de protocolos TCP/IP. El nombre de la pila es en "honor" a sus protocolos más famosos, aunque no son los únicos.
El IP (Internet Protocol) que aparece en el nombre de la pila hace referencia al protocolo IPv4, que es el que se ha utilizado hasta ahora para cuestiones de enrutamiento, esto es, para decidir por donde irán los datos del origen al destino en función de las direcciones IP que llevan "grabadas".
1.1.
Distribución de direcciones IPv4
Debido a la longitud de la direcciones IPv4, que es de 32 bits, hay un total de 2³² = 4.294.967.296 direcciones disponibles.
Estas direcciones se representan en 4 grupos de 8 bits, con notación decimal y separados por puntos. Cada grupo de 8 bits puede tomar en total 256 valores (2⁸) entre 0 y 255.
Las direcciones están organizadas por rangos de modo que hay direcciones públicas y direcciones privadas.
Las privadas se pueden utilizar en cualquier tipo de red local sin mayores problemas, ya que son direcciones que no se enrutan hacia Internet y por lo tanto no pueden provocar conflictos. Los rangos de las direcciones privadas son:
10.0.0.0 a 10.255.255.255 (10.0.0.0/8) 172.16.0.0 a 172.31.255.255 (172.16.0.0/12) 192.168.0.0 a 192.168.255.255 (192.168.0.0/16)
Las públicas son las que nos identifican en Internet y deben ser únicas para cada equipo. Precisamente por su carácter global es necesario que existan mecanismos de control para organizar el reparto de las mismas.
La jerarquía para el reparto se ilustra en la siguiente figura:
Puede parecer que más de 4.000 millones de direcciones deberían ser suficientes para abastecer de direcciones a todo el planeta, pero como vamos a ver, no es así.
El total de las direcciones disponibles se organiza en 256 bloques de 16.777.216 direcciones. Actualmente la situación en cuanto al reparto de estos bloques es el siguiente:
En este enlace se pueden ver estadísticas diarias de la progresión del reparto de direcciones IPv4 que nos lleva a la extinción del espacio disponible. Incluso se prevé cuál será la fecha del día "X" (en el momento de escribir este documento -marzo de 2010- se hablaba de finales de 2011.
Un problema adicional al agotamiento de las direcciones es lo descompensado que está el reparto de las mismas. Que un estado como El Vaticano, con algo menos de 1000 habitantes, tenga algo más de 8 direcciones IPv4 por cabeza no parece demasiado problemático. Pero que un país como Estados Unidos, con más de 300 millones de habitantes, tenga casi 5 direcciones por habitante, da que pensar, especialmente cuando en el otro extremo del baremo países como Nigeria disponen de una IP para más de 5000 habitantes.
Por ello, el achacar el problema del agotamiento a las economías emergentes como China (1 dirección IPv4 para cada 5 habitantes) o India (1 dirección IPv4 para cada 50 habitantes) no es muy riguroso. El verdadero problema es que hay pocas direcciones y están mal repartidas.
1.2.
Evolución de la necesidad de direcciones
En septiembre de 1981 se publicó la RFC 791 "Internet Protocol". Desde entonces el crecimiento de la necesidad de este protocolo ha sido imparable e impredecible.
Por un lado, como se ha comentado en el punto anterior, las economías emergentes
exigen su parte del pastel de las direcciones.
Por otro lado, el número de dispositivos que se pueden conectar a Internet es cada vez mayor: PDAs, móviles, consolas, sistemas de seguridad (alarmas, cámaras), televisores y hasta frigoríficos...
Las previsiones indican que en un futuro cercano elementos como los contadores de agua, gas o electricidad estarán también online y lo mismo ocurrirá con los coches..
Además, las soluciones para monitorización remota de todo tipo de máquinas serán cada vez más frecuentes.
Todo esto nos lleva a un escenario "Always-on" en el que el usuario no solo dispondrá siempre de acceso a Internet, sino que además, estará siempre localizable.
1.3.
Inconvenientes técnicos de IPv4
La evolución de las necesidades de Internet ha supuesto un reto para IPv4.
Cuando fue diseñado, a finales de los años 70, no había preocupación por hacer frente a la saturación de los medios disponibles debido al alto número de equipos conectados ni era una prioridad la seguridad.
Por ello, a parte del ya comentado problema del agotamiento del rango de direcciones, IPv4 presenta otros inconvenientes que se repasan a continuación.
Problemas de rendimiento:
Los problemas de rendimiento vienen ocasionados por: El mal uso de los medios disponibles.
La manipulación a que son sometidos los datos.
El resultado final es la acumulación de retardos que producen fallos en aplicaciones sensibles a los mismos, como por ejemplo VoIP.
Por ejemplo, en IPv4 existe la posibilidad de generar tráfico de broadcast. Esto son paquetes de datos que parten de un equipo con la pretensión de llegar a todos los equipos que estén a "tiro de PING", es decir, a todos los equipos que se encuentran en el mismo dominio de difusión.
El uso indiscriminado de este tipo de tráfico, incluso por algunos de los protocolos incluidos en TCP/IP, provoca el colapso de las redes debido a las colisiones que tienen lugar. Colisiones que se solucionan con la retransmisión de los datos después de esperar cierto tiempo. Ya tenemos un retardo.
Otra situación que desemboca en retardos es el procesamiento a que son sometidos los paquetes de información.
Cada vez que un paquete viaja de un equipo al siguiente que le acerca a su destino se dice que ha realizado un salto (hop). En cada salto se analiza la información recibida para determinar si el paquete se queda en la red a la que acaba de llegar o si hay que enviarlo a otra red diferente. Aquí surgen nuevos retardos.
Por último, los routers que reciben la información, después de analizarla y decidir que tienen que reenviarla, tienen que aplicar algoritmos de selección de rutas para que la elección sea la óptima. En la aplicación de estos algoritmos aparecen nuevos retardos.
Problemas de IPv4 relacionados con seguridad
En el diseño de IPv4 se pensó en garantizar la conectividad. El tema de la seguridad quedó al margen y esto se refleja en que no hay ningún tipo de control de seguridad en su estructura.
El aplicar estas técnicas implica una carga adicional para el procesamiento de los datos (nuevos retardos) y por lo tanto, una nueva reducción del rendimiento.
Problemas de la utilización de NAT (Network Address Translation)
Ante la necesidad de dosificar las direcciones IP públicas disponibles se ha ideado el NAT, cuyo objetivo es hacer posible que una red privada al completo pueda acceder a Internet a través de una única dirección IP pública.
Algunas de las consecuencias de la utilización de NAT son las siguientes: Rompe el modelo end-to-end.
Debido a NAT se pierde la "transparencia" original de Internet, cuando había un esquema de direccionamiento único y universal y los paquetes podían fluir del origen al destino sin alteraciones intermedias.
Afecta a protocolos y aplicaciones.
Proporciona una falsa sensación de seguridad.
Hay varios documentos que explican los motivos de la no conveniencia del NAT: RFC 2775 "Internet transparency"
RFC 3027 "Protocol Complication with the IP Network Address Translator" RFC 2993 "Architectural Implications of NAT"
1.4.
La solución: IPv6
Efectivamente, la solución a los problemas comentados se logra mediante IPv6 En relación a la escasez de direcciones:
En IPv6 el número de bits para direccionamiento pasa de los 32 de IPv4 a 128. Para hacernos a la idea de la cantidad de direcciones disponibles en IPv6 se suele recurrir a varios ejemplos típicos como los millones de millones de direcciones que podríamos asignar a cada m² del planeta Tierra. Pero quizás sea más significativo pensar que con IPv6 podríamos dar una dirección a cada grano de arena que hay en la Tierra. La cantidad de direcciones es tan grande que parece imposible que se puedan agotar, independientemente de que la gestión de las mismas sea más o menos acertada.
En relación a los retardos:
En IPv6 el formato de las cabeceras de los paquetes se ha simplificado. Tienen un tamaño fijo y no hay información redundante. Todo esto hace que sea más sencillo su procesamiento y por lo tanto se reducen los retardos del mismo.
En IPv6 no existe tráfico de broadcast. Cada paquete de información tiene un origen y un destino.
No hay reconstrucción de tramas en cada salto. Esa reconstrucción la hará únicamente el equipo final.
Los campos de carga útil tienen un tamaño de 64Kb, para que sean más fácilmente "digeridos" por los micros de 64bits.
Las tablas de los routers se descongestionan, y necesitan menos tiempo para decidir cuál será el siguiente salto.
Todo esto hace que mejore el rendimiento de la red. En relación a la seguridad:
IPsec está integrado en IPv6, de modo que se reduce el procesamiento externo para implementarlo y se consigue por un lado mejorar la seguridad y por otro reducir los retardos.
Hay nuevos campos en la cabecera cuyo objetivo es mejorar la seguridad: AH = Authentication Header y ESP = Encapsulating Security Payload. Estos campos permiten que la seguridad se base en la encriptación de la información transmitida. Para garantizar la autenticación de las entidades se recurre a los certificados digitales.
En relación a los problemas de NAT, la implantación de IPv6 supone la vuelta al modelo end-to-end, con lo que los problemas que sufrían las protocolos y las aplicaciones desaparecen.
Otras ventajas de IPv6:
El control del tráfico es más efectivo, ya que hay reservados campos para QoS (Quality of Service) y CoS (Class of Service), con los que se puede regular el tráfico en función de su sensibilidad al retardo de red.
Como se puede ver, IPv6 ha aprendido de las carencias de su antecesor y ofrece un amplio abanico de mejoras que solo están esperando a ser aprovechadas por los servicios y programas que están por desarrollar.
Lo que no va a ser posible es establecer una fecha para realizar una transición total de IPv4 a IPv6. En otras palabras, de momento no va a producirse un "Apagón IP".
La situación requiere una transición gradual en la que los dos protocolos convivan, cosa que se ilustra en la siguiente figura.
1.5.
Historia de IPv6
El organismo encargado del desarrollo del nuevo protocolo fue el IETF (Internet Engineering Task Force).
En el año 1991 comienza a trabajar sobre el problema de expandir el número de direcciones de Internet.
Puesto que la IP es uno de los datos incluidos en la cabecera del protocolo, el hecho de ampliar el rango de direcciones implicaba un rediseño de la cabecera, esto es, había que desarrollar una versión nueva de IP.
Los objetivos inicialmente planteados fueron: Gran número de direcciones disponibles.
Soportar un esquema de direccionamiento jerárquico.
Seguridad embebida (tanto encriptación como autenticación). Autoconfiguración “plug and play”.
Mejoras a la Calidad de Servicio. Movilidad IP.
Las alternativas barajadas inicialmente fueron las siguientes:
CATNIT (Common Architecture for the Internet): este era un protocolo compatible con IP, IPX y OSI que aportaba un largo de direcciones variable.
SIPP (Simple Internet Protocol Plus): este era una evolución de IPv4, con encabezado más simple y 64 bits para direccionamiento.
TUBA (TCP and UDP with Bigger Addresses): este era la propuesta usando direcciones de red OSI (CLNP).
Finalmente, a partir de SIPP se diseñó el IPng (Internet Protocol next generation), que fue rebautizado posteriormente con el nombre de IPv6.
El motivo por el que saltaron de IPv4 a IPv6 omitiendo IPv5 fue que dicho nombre ya había sido utilizado para un protocolo experimental descrito la RFC 1819 (Internet Stream Protocol Version 2).
La especificación general de IPv6 se describe en la RFC 2460 (en sustitución a la RFC 1883), y su estructura de direccionamiento en la RFC 4291 (en sustitución a la RFC 3513).
A partir de ahí se han ido creando distintos grupos para fomentar la implantación de IPv6. Entre los más destacables tendríamos el IPv6 Forum.También se pusieron en marcha proyectos como 6bone (1996-2006) mediante el que se fomentaba la experimentación sobre una red mundial IPv6.
A día de hoy, aunque el protocolo es completamente operativo, no se puede decir que se haya terminado su desarrollo. De hecho, se sigue trabajando en guías operativas, en la adaptación de IPv6 - WiMAX, en algunos detalles de las cabeceras de extensión...
2.
Cabecera, direccionamiento y configuración básica.
En esta sección se hará, en primer lugar, una incursión en la nueva cabecera de IPv6, comentando su estructura y el funcionamiento de las nuevas cabeceras de extensión.
Por otro lado se hablará del direccionamiento en IPv6, repasando los distintos tipos de direcciones existentes y explicando su utilidad.
Por último se mostrará como realizar la instalación y configuración básicas en algunos de los sistemas operativos más usuales.
Antes de continuar conviene repasar algunos conceptos habituales. Las siguientes definiciones suelen aparecer al comienzo de muchas RFCs.
Nodo: es un dispositivo que utiliza el protocolo en estudio (IP, IPv6...)
Router: es un nodo que reenvía paquetes actuando como intermediario en una comunicación entre dos nodos.
Host: cualquier otro nodo que no sea un router.
Upper Layer o Capa Superior: cuando se habla de protocolos de la capa superior se hace referencia a la capa que está justo por encima de la capa de IP, por lo que los mencionados protocolos serán TCP, UDP, ICMP, etc.
Link o Enlace: un medio sobre el que los nodos se pueden comunicar en la capa de enlace, es decir, la capa que está justo debajo de IP. Un ejemplo de enlace sería Ethernet, X.25, Frame Relay...
Interface o Interfaz: es la conexión de un nodo a un enlace.
Neighbors o Vecinos: son los nodos conectados a un mismo enlace.
Dirección: es un identificador de la capa IP para una interfaz o un conjunto de interfaces.
Paquete: es la cabecera IP junto al payload, es decir, junto a los datos a enviar.
Link MTU(Maximum Transmission Unit): es el tamaño máximo de los paquetes que pueden ser manejados en un enlace.
Path MTU: el path es la ruta que siguen los datos desde el host de origen al de destino y el Path MTU es el valor de MTU que se puede utilizar a lo largo de dicha ruta. Para no tener problemas en ningún punto, el valor a adoptar debería ser el más pequeño de los MTU que aparezcan en el path.
2.1.
La nueva cabecera
Entender la estructura de la cabecera de un protocolo y el tipo de información que se puede transportar con la misma es el mejor camino para aprender a trabajar con un protocolo.
Este conocimiento ayuda a identificar cómo se puede configurar el protocolo de la mejor manera posible y qué opciones ofrece.
También ayuda a identificar posibles fuentes de problemas y soluciones de problemas.
La estructura de la cabecera de un paquete IPv6 está especificada en la RFC 2460 Durante el diseño de IPv6 se ha analizado la cabecera IPv4, simplificándola y eliminado aquello que era superfluo.
En la siguiente imagen se pueden comparar los campos de las dos cabeceras.
Como se puede ver, la cabecera IPv6 es mucho más simple que la de IPv4 y esto acelera el procesamiento de los datos.
La cabecera IPv6 tiene una longitud fija de 40 bytes, organizados en dos grupos de 16 bytes para las direcciones de Origen y Destino y solo 8 bytes más para información general.
En el siguiente punto se explican los motivos por los que se han eliminado ciertos campos de la cabecera IPv4.
A continuación se analizarán los distintos campos de la cabecera IPv6.
Por último nos centraremos en el funcionamiento de las nuevas cabeceras de extensión.
A continuación se explican los motivos por los han desaparecido. Longitud de la cabecera
En IPv4, la mínima longitud de cabecera es de 20 bytes, pero si se añaden opciones, puede crecer en incrementos de 4 bytes hasta los 60 bytes. Por lo tanto, con IPv4 sí es importante la información sobre la longitud de la cabecera.
En IPv6 las cabeceras tienen una longitud fija de 40 bytes, por lo tanto el campo "Longitud de la cabecera" no tiene sentido.
El tema de las opciones se resuelve en IPv6 por medio de las cabeceras de Extensión.
Identificación, Flags y Fragment Offset
Estos campos permiten gestionar la fragmentación de un paquete en IPv4.
La fragmentación tiene lugar cuando un paquete grande tiene que ser transmitido en una red que sólo soporta paquetes más pequeños.
En ese caso, el router IPv4 trocea el paquete original en otros más pequeños y los envía.
El host de destino los recoge y recompone el mensaje original.
Si se detecta que falta algún fragmento (aunque solo sea uno), hay que volver a retransmitirlos todos.
Esta forma de actuar es muy poco eficiente.
Ya en IPv6, el host emisor utiliza un proceso llamado "Path MTU Discovery" para saber el cuál es el mayor tamaño de paquete que se puede gestionar en el camino que seguirán los datos desde el origen hasta el destino, esto es, en el Path. Esa información es lo que se llama "Path MTU" (Maximum Transmission Unit).
Con esta información, el host emisor decide si hay que fragmentar el paquete o no. En caso de tener que hacerlo utiliza la cabecera de Extensión correspondiente.
Debido a esto, no es necesario que los routers IPv6 proporcionen fragmentación como se hacía en IPv4.
También por eso no hacen falta los campos de Identificación, Flags y Fragment Offset en la cabecera IPv6. En caso de necesitar la fragmentación estos campos serán insertados por el host origen en la correspondiente cabecera de Extensión.
Checksum de cabecera
Cuando se desarrolló IPv4, no era habitual el checksum a nivel de acceso al medio (capa de enlace de datos), por lo que tenía sentido el campo de checksum en la cabecera de IPv4.
Hoy en día, el riesgo de que lleguen a nivel de IP errores no detectados y paquetes mal enrutados es mínimo.
En IPv6 se ha considerado que la responsabilidad de comprobar la integridad de los datos debe recaer en las capas superiores.
Así, si subimos de la capa de red a la capa de transporte y nos fijamos en el protocolo UDP, nos encontramos que el checksum que era opcional trabajando con IPv4 es obligatorio al trabajar con IPv6.
Al eliminar la comprobación del checksum en la capa de red, los routers no tienen ya que comprobarlos ni actualizarlos y, de nuevo, se mejora la gestión de los paquetes.
Opciones
En IPv6 las opciones se manejan por medio de las ya mencionadas cabeceras de Extensión, por lo que no son tratadas como un campo al uso.
2.1.2. Los campos bit a bit
Como se ha dicho antes, entender la función de los campos de la cabecera de un protocolo, es fundamental para comprenderlo.
Este campo de 4 bits contiene la versión del protocolo. Para IPv6 su valor es 6.
Traffic Class = Clase de Tráfico (1 Byte)
Este campo sustituye al "Type of Service" de IPv4. no obstante, su función es la misma en los dos protocolos. De hecho la RFC que regula su funcionamiento es la misma: RFC2474 ("Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"). En dicha RFC se usa el término “DS Field” (Differentiated Services Field) para hacer referencia tanto al campo "Type of Service" de IPv4 como al de “Traffic Class” de IPv6.
Por medio de este campo ("Traffic Class) los equipos que envían los paquetes y los routers pueden identificar y distinguir distintas clases o prioridades de paquetes IPv6. Gracias a este campo, algunos datos que requieran un tratamiento especial se pueden manejar, en tiempo real, con mayor facilidad.
Flow Label = Etiqueta de flujo (20 Bits)
Este campo sirve para marcar paquetes que requieren un mismo tratamiento, de forma que se facilita su manipulación en tiempo real.
El equipo emisor puede etiquetar secuencias de paquetes con un conjunto de opciones.
Los routers pueden mantener bajo control los flujos y pueden procesar los paquetes pertenecientes al mismo flujo de forma más eficiente porque no tienen que reprocesar cada cabecera de paquete.
La “etiqueta de flujo” y la dirección de la fuente identifican el flujo de forma única. A los nodos que no soportan las funciones del campo “Flow Label” se les pide que no toquen dicho campo cuando reenvían un paquete y que lo ignoren cuando lo reciben. Todos los paquetes pertenecientes al mismo flujo deben tener las mismas direcciones de Origen y Destino.
La RFC3697 es la "IPv6 Flow Label Specification".
Payload Length = Longitud de carga útil (2 Bytes)
El PAYLOAD son los datos enviados después de la cabecera. En el campo "Payload Length" se indica qué cantidad de datos están siendo enviados.
La forma de medir esta carga es distinta en IPv6 y en Ipv4.
En IPv4 el campo “Longitud” incluye la longitud de la cabecera IPv4, mientras que el “Payload Length” de IPv6 contiene solo los datos que siguen a la cabecera IPv6. Las cabeceras de Extensión también se consideran parte del Payload.
El hecho de que la longitud de este campo sea de 2 bytes, limita el tamaño máximo del payload a 64KBytes. (2¹⁶ = 65536 Bytes = 64KB)
Los paquetes de tamaños mayores son soportados por IPv6 por medio de la cabecera de Extensión "Jumbograma".
Los Jumbogramas se especifican en la RFC 2675 y cobran importancia sólo cuando los nodos IPv6 están asociados a enlaces que tienen un enlace MTU mayor que 64KB.
Next Header = Siguiente cabecera (1 Byte)
En IPv4 este campo se llama “Protocol Type”. En IPv6 se ha renombrado porque ahora la forma de organizar los paquetes es distinta, ya que se utilizan las llamadas Cabeceras de Extensión que son explicadas en la siguiente sección.
Si la siguiente cabecera es UDP o TCP, este campo contendrá los mismos números de protocolo que en IPv4 (TCP = 6, UDP = 17...)
En caso de que usen las cabeceras de Extensión de IPv6, este campo contiene el tipo de la siguiente cabecera de Extensión.
Estas cabeceras de Extensión están localizadas entre las cabecera IP y la cabecera TCP o UDP.
En la página www.iana.org/assignments/protocol-numbers se puede encontrar un listado actualizado de los números asignados a los protocolos.
Hop Limit = Límite de Saltos (1 Byte)
Este campo es análogo al campo TTL (Time-To-Live) de IPv4. El campo TTL contiene un número de segundos que indican cuánto tiempo puede permanecer un paquete en la red antes de ser destruido. En IPv4, la mayoría de los routers simplemente decrementan este valor en uno con cada salto.
En IPv6, este campo ha pasado a llamarse "Hop Limit". Su valor representa ahora el número de saltos en lugar del número de segundos. Cada nodo retransmisor decrementa este valor en uno. Si un router recibe un paquete con “Hop Limit” = 1, lo decrementa a 0, descarta el paquete, y envía al equipo emisor original el mensaje ICMPv6 “Hop Limit exceeded in transit”.
Source Address =Dirección Origen (16 Bytes)
Este campo contiene la dirección IP del equipo que generó el paquete
2.1.3. Las cabeceras de Extensión
En la cabecera de IPv4, después de los campos de información general y de las direcciones de origen y destino, y antes de los datos, se coloca en campo de "Opciones". Estas "Opciones" ocupan un máximo de 40 bytes y dan indicaciones a los nodos que se encuentran en el camino (o path) que va del equipo origen al destino, acerca de cuestiones relacionadas con seguridad, enrutamiento, timestamping, etc. Concretamente, las opciones disponibles en IPv4 son: Crear un registro de la ruta.
En el datagrama se van guardando las direcciones IP de los routers visitados. Cada router intenta poner su dirección al final de la lista existente. Si la lista está llena y no puede hacerlo, simplemente reenvía el datagrama sin añadir su dirección.
Marcas de tiempo (Timestamp).
Seguridad básica del Departamento de Defensa.
Permite asegurar que el origen del datagrama tiene autorización para ser transmitido. Son opciones usadas por la NSA, la CIA...
Seguridad extendida del Departamento de Defensa.
Es una opción que permite a los departamentos antes mencionados hacer configuraciones de seguridad específicas según sus necesidades.
Sin operación (No Operation).
Se usa como relleno entre opciones, para alinear la siguiente opción en un marco de 16 o 32 bits.
Fin de la lista de opciones.
En este caso se pretende rellenar el final del campo de opción para que el tamaño total sea múltiplo de 32 bits.
En IPv4 no suelen utilizarse estas opciones porque ralentizan la transmisión.
En IPv6 las opciones se manejan por medio de las llamadas Cabeceras de Extensión (Extension Headers). Estas cabeceras se insertan en el paquete solo si las opciones son necesarias.
En la siguiente figura se pueden ver varios casos de utilización de cabeceras IPv6 y cabeceras de Extensión.
En el primer paquete hay una única cabecera IPv6 que precede a los datos de la capa superior de transporte.
En el segundo paquete se ha insertado una tercera cabecera entre las dos anteriores. Ahora, la cabecera IPv6 indica que la siguiente cabecera es una cabecera de Extensión del tipo Routing, cuyo código identificativo es el 43 y que se utiliza para dar una lista de uno o más nodos que deben estar en la ruta seguida por un paquete.
En el campo Next Header de esa cabecera de Routing se indica ya que a continuación van los datos de TCP.
En el tercer paquete se ha insertado una cabecera más. En este caso es una cabecera de Extensión de Fragmento, cuyo código es el 44.
Como se puede ver los campos Next Header de las distintas cabeceras mantienen la lógica explicada.
Podemos enumerar ya algunas cuestiones generales relativas a las cabeceras de Extensión:
En un paquete IPv6 puede haber cero, una o más cabeceras de Extensión. Estas cabeceras se sitúan entre la cabecera IPv6 y la cabecera del protocolo de la capa superior (capa de transporte).
Las cabeceras existentes deben ser procesadas en el orden exacto en que aparecen en la cabecera del paquete.
o Si la cabecera de Extensión es del tipo Opciones Hop-by-Hop, la información que lleva debe ser examinada y procesada por cada uno de los nodos que se encuentran en la ruta del paquete.
o Este tipo de cabecera debe seguir inmediatamente a la cabecera IPv6 y su valor de "Next Header" es 0.
Si en el campo "Dirección de destino" hay una dirección multicast, las cabeceras de Extensión serán examinadas y procesadas por todos los nodos que pertenezcan al grupo multicast.
La longitud de cada cabecera de Extensión es un múltiplo de 8 bytes de forma que, independientemente del número de ellas que se utilicen, siempre quedan alineadas.
Tipos de cabecera
Los 6 tipos de cabeceras de Extensión que se definen en la RFC 2460 son: De opción Hop-by-Hop (RFC 2460).
La información de esta cabecera debe ser examinada Salto-a-Salto, es decir, en cada uno de los nodos de la ruta que ha de seguir el paquete.
De enrutado (RFC 2460). Se utiliza para dar una lista de uno o más nodos que deben estar en la ruta seguida por un paquete.
De fragmento (RFC 2460). Un host IPv6 que quiere enviar un paquete a un destino IPv6 utiliza el llamado “Path MTU discovery” para determinar el tamaño máximo de paquete que se puede utilizar en el path hasta ese destino. Si el paquete que hay que enviar es más grande que el MTU soportado, el host origen fragmenta el paquete. Gracias a esta forma de actuar, la fragmentación se gestiona de extremo a extremo, liberando a los routers del path de este trabajo. En caso de que el "Path MTU discovery" falle, se usará el valor mínimo de "Path MTU" en IPv6, 1280 bytes. El valor máximo es de 65536 bytes, en los cuales se incluye la carga o payload del datagrama y los 40 bytes de la cabecera.
De opciones de destino (RFC 2460). Estas cabeceras llevan información que será procesada, exclusivamente, por el nodo de destino.
De autenticación (AH) (RFC 4302). Proporciona integridad y autenticación (que no confidencialidad) para todos los paquetes de datos IP. Soporta distintos mecanismos de autenticación.
De carga útil de seguridad encriptada (Encrypted Security Payload =ESP) (RFC 4303). Proporciona integridad, confidencialidad, autenticacion de datos y otras funciones para todos los paquetes de datos IP.
La flexibilidad de esta arquitectura permitirá el desarrollo de nuevas cabeceras de Extensión en el futuro, a medida que sean necesarias. Lo bueno de este sistema es que las nuevas cabeceras de Extensión se pueden definir y usar sin cambiar la cabecera IPv6.
Orden de ejecución
Si se le pide a un nodo que procese la siguiente cabecera pero no identifica el valor del campo “Next Header”, descartará el paquete y enviará un mensaje “ICMPv6 Parameter Problem” al equipo origen del paquete.
Según la RFC 2460, si en un paquete se usa más de una cabecera de Extensión, se debería respetar el siguiente orden:
1. Cabecera IPv6.
2. Cabecera de Opciones Hop-by-Hop
3. Cabecera de opciones de destino (para opciones que tienen que ser procesadas por el primer destino que aparece en el campo de dirección de destino, además de los destinos posteriores enumerados en la cabecera de Routing).
4. Cabecera de enrutamiento (Routing) 5. Cabecera de Fragmento.
6. Cabecera de autenticación (Authentication header).
7. Cabecera de carga útil de seguridad encapsulada (Encapsulating Security Payload)
8. Cabecera de Opciones de Destino (para opciones a ser procesadas solo por el destino final del paquete)
2.2.
Direccionamiento
Una vez analizados y aclarados los problemas de IPv4 en relación a la gestión de direcciones y a la disponibilidad de las mismas, nos centraremos en el direccionamiento de IPv6.
Capacidad de direccionamiento IPv6
Las direcciones utilizadas son de 128 bits, por lo que la capacidad de direccionamiento es de 2¹²⁸.
Para entender de qué cantidad estamos hablando, un ejemplo:
Teniendo en cuenta que la superficie terrestre es de 510.065.284,702 x 10⁶ m²... ... con 2¹²⁸ direcciones podríamos asignar 667.134.927.874.467.426.204.012 direcciones IPv6 por m².
Parece suficiente para hacer frente a cualquier necesidad presente y futura. Tipos de direcciones IPv6
El documento base que regula las direcciones y el direccionamiento es la RFC 4291. Hay tres tipos principales de direcciones: las unicast, multicast y anycast.
Unicast: dirección para un único dispositivo. El paquete enviado a una dirección unicast es recibido sólo por el propietario de la dirección.
Multicast: este es el sustituto del broadcast de IPv4. La diferencia entre broadcast y multicast es que en el broadcast se envían paquetes a todos los equipos que se encuentran en la misma subred y en multicast se envían paquetes solo a los equipos que tienen la misma dirección multicast. Es una especie de broadcast controlado.
Anycast: es una dirección para varios dispositivos. Cuando se envía un paquete a una dirección Anycast, se entregará al equipo más cercano que sea propietario de dicha dirección.
Cuando trabajamos con IPv4 estamos acostumbrados a tener que asignar una dirección IP del estilo 192.168.0.10 a la tarjeta de red de nuestro ordenador, y solo en situaciones concretas tenemos varias direcciones IPv4 asignadas a nuestra interfaz de red. Esto último ocurre, por ejemplo, cuando usamos "interfaces de red virtuales", las cuales permiten, entre otras cosas, ofrecer distintos servicios de red en cada una de las direcciones empleadas.
En IPv6 lo normal es que una tarjeta de red tenga varias direcciones asignadas. En la RFC 4291 "IP Version 6 Addressing Architecture" se especifica cuáles son las direcciones IPv6 que tiene que tener cada host.
Su dirección de enlace local para para cada interfaz. Todas las direcciones unicast y anycast asignadas. La dirección de loopback.
La dirección multicast All-nodes.
La dirección multicast Solicited-node para cada una de sus direcciones unicast y anycast.
Las direcciones multicast de todos los grupos a los que pertenezca el host. En apartados posteriores se analizarán las peculiaridades de los tipos y subtipos mencionados.
Representación de las direcciones
Tienen una longitud de 128 bits y para su representación se organizan en 8 grupos de 4 dígitos hexadecimales (8grupos x 4dígitosHex x 4bits = 128 bits).
Los grupos se separan con dos puntos (:). Esto serían ejemplos de dirección IPv6:
ABFE:CD67:2143:6574:AFDE:DB87:6543:2109 2191:0:0:7:0:900:300B:528B
Si hay varias cadenas de 4 ceros hexadecimales, es decir, 16 ceros (...:0000:....), se pueden sustituir por ::
Esta sustitución solo puede hacerse una vez en cada dirección. Por ejemplo:
2191:6:0:0:0:700:311B:528D = 2191:6::700:311B:528D FF01:0:0:0:0:0:0:101 = FF01::101
0:0:0:0:0:0:0:1 = ::1
0:0:0:0:0:0:0:0 = ::
En entornos mixtos en los que hay nodos IPv4 e IPv6 hay también un formato válido que permite representar una dirección IPv4 como IPv6. Esto se hace poniendo 0:0:0:0:0:0 y a continuación la dirección IPv4. Hay que tener en cuenta que la representación se puede hacer expresando la dirección IPv4 en decimal o en hexadecimal y que también se puede emplear la notación abreviada. Teniendo todo esto en cuenta, las siguientes notaciones son equivalentes:
0:0:0:0:0:0:192.168.44.1 ::192.168.44.1
0:0:0:0:0:0:C0A8:2C01 ::C0A8:2C01
2.2.1. Los prefijos
Notación de los prefijos
Esta notación está descrita en la RFC 4291 "IP Version 6 Addressing Architecture". Un prefijo es un conjunto de bits (en la zona de mayor peso) en una dirección IPv6, que se utiliza para identificar subredes o el tipo de dirección.
El nombre exacto que reciben estos bits es “prefijo de enrutado global”.
La notación de prefijo es muy similar a la forma en que se escriben las direcciones IPv4 en notación CIDR (Classless Interdomain Routing), indicando detrás de la dirección IP el número de bits que determinan el ID de la red (192.168.0.10/24 equivale a una máscara 255.255.255.0):
En IPv6 tenemos:
El campo “Longitud del prefijo” especifica cuantos bits de la parte izquierda de la dirección forman el prefijo.
Gracias al prefijo, los routers saben como dirigir los paquetes que les llegan hacia su destino correcto en una subred determinada.
Un ejemplo, en la siguiente dirección IPv6, puesto que cada carácter hexadecimal consta de 4 bits, el prefijo es la parte marcada en azul (10 caracteres hexadecimales):
2E78:DA53:1200::/40
La notación abreviada (sustitución de ceros con un doble “:”) se puede aplicar también a la representación del prefijo, siguiendo las reglas ya explicadas.
Prefijos de enrutado global
En este enlace se puede ver cómo organiza la IANA los prefijos reservados y las direcciones especiales (direcciones de enlace local, multicast...).
Vamos a comentar algunos de estos prefijos:
0000::/8 → Las direcciones que empiezan con 8 ceros están reservadas para la IETF. 2000::/3 → Direcciones Unicast Globales. Estas serán todas aquellas direcciones cuyos 3 primeros dígitos binarios (los de mayor peso) sean 001. Estas son las direcciones Unicast que gestiona la IANA. A efectos prácticos serían como las direcciones públicas que venimos usando con IPv4.
FC00::/7 → Dirección Unicast Local Única (ULA = Unique Local Unicast Address). Son direcciones cuyos 7 bits de mayor peso son 1111 110.
FE80::/10 → Dirección Unicast de Enlace Local. Aquellas cuyos primeros 10 bits son 1111 1110 10.
FF00::/8 →Direcciones Multicast. Aquellas cuyos 8 primeros bits son 1.
En cuanto a las direcciones Anycast, se toman del rango de direcciones Unicast, por lo tanto, no es posible saber si una dirección es Anycast tan solo con mirar su prefijo.
Es la dirección 0:0:0:0:0:0:0:0 y también se le llama la dirección de “todo ceros” (all-zeros address)
Se puede representar en notación abreviada como ::
Su función es la misma que la de la dirección 0.0.0.0 de IPv4: actuar como dirección de origen cuando se solicita una configuración de arranque en un momento en que el equipo solicitante no tiene una dirección válida. Esto ocurre, por ejemplo, cuando se buscan servidores DHCP o BOOTP para pedirles la configuración de la interfaz de red.
Dirección de Loopback
Es la dirección 0:0:0:0:0:0:0:1, que en notación abreviada queda en ::1
Su función es la misma que la dirección 127.0.0.1 de IPv4: hacer referencia a la interfaz de red local y permite hacer pruebas para determinar el buen funcionamiento de la misma o de algún servicio ubicado en el equipo local.
2.2.3. Direcciones Unicast Globales
Estas son las direcciones que se reconocen a nivel global, por lo que, a efectos prácticos, juegan el papel de las direcciones públicas IPv4.
Puesto que van a ser direcciones válidas a nivel global es lógico pensar que deben estar controladas como lo están las IPs públicas de IPv4. En seguida veremos que es así. Todas las Direcciones Unicast Globales tienen 001 en sus tres bits de mayor peso, por lo que el prefijo es 2000::/3. Esto indica que si la dirección empieza tanto por 0010 (0x2) como por 0011(0x3), estaremos ante una dirección unicast global.
En la RFC 4291 se define el formato de estas direcciones.
Como se puede ver en la imagen, los 128 bits se descomponen en tres campos: Prefijo de enrutado global (n bits).
Para redes de tamaño pequeño y medio suele constar de 48 bits y es gestionado por los servicios de registro internacionales y los ISPs.
La IANA (Internet Assigned Numbers Authority) es el organismo responsable de la coordinación, a nivel mundial, del direccionamiento.
El reparto de direcciones se realiza de forma jerárquica y hay una entidad responsable para cada región del mundo.
En la imagen se pueden ver los nombres de dichas entidades.
Fuente: http://www.iana.org/numbers
Aunque el prefijo para las direcciones unicast globales es 2000::/3, IANA solo permite el uso de ciertos rangos. En este enlace se puede ver cuál es el reparto actual.
Todo el espacio de direcciones del bloque 2000::/3 no listado en la tabla anterior está reservado por la IANA para una futura asignación.
Aparte de la asignación para cada uno de los servicios de registro internacionales, hay también un rango reservado para la propia IANA.
Por ejemplo, el prefijo 2001::/23, que incluye el prefijo 2001:0000::/32 utilizado en
Teredo (RFC 4380: Tunneling IPv6 sobre UDP a través de NAT).
Igualmente aparece el prefijo 2002:0000::/16, utilizado para 6to4 (RFC 3056: Connection of IPv6 Domains via IPv4 Clouds).
Identificador de Subred ((64 - n) bits).
El ID de Subred identifica un enlace dentro de un sitio. Puesto que normalmente n = 48 bits, quedan un total de 16 bits para hacer subredes en la organización. Es decir,
En caso de que la organización sea muy grande, puede solicitar un prefijo de enrutado global de menos de 48 bits, de modo que pueda disponer de más espacio para crear subredes.
Identificador de Interfaz (64 bits).
El Identificador de Interfaz identifica una interfaz en una subred y debe ser único dentro de esa subred. Este identificador se puede configurar de varias maneras.
Configuración estática (Manual).
Autoconfiguración (Identificador de Interfaz basado en EUI-64). Configuración dinámica (DHCPv6).
Identificador de Interfaz Pseudo-Aleatorio. Identificador generado criptográficamente.
En el caso de la autoconfiguraciónEUI-64 (EUI = Extended Unique Identifier), se consigue un identificador de interfaz único que se basa en la dirección MAC de la propia interfaz (de ahí su exclusividad).
El procedimiento a aplicar para conseguir el identificador es sencillo. Se parte de la MAC que tiene 48 bits y hay que agregarle 16 bits para alcanzar los 64 bits del identificador de interfaz. Esto se hace dividiendo la MAC por el centro e insertando los dígitos hexadecimales 0xff-fe.
00– 03 – cd – 39 – 2b – 42
00 – 03 – cd – ff – fe – 39 –2b – 42
Para terminar hay que complementar el bit universal/local, que es el segundo bit de menor peso en el primer byte (el de mayor peso). En este ejemplo el primer byte es
0000 0000, y complementando el bit marcado en rojo se convierte en 0000 0010, es decir, 0x02. Por lo tanto el identificador de interfaz obtenido mediante autoconfiguración es:
02 – 03 – cd – ff – fe – 39 –2b – 42
2.2.4. Dirección Unicast de Enlace Local
En IPv4 las organizaciones utilizan direcciones IP privadas (RFC 1918) para identificar a los nodos de sus redes.
Estas direcciones privadas no se utilizan nunca fuera de la organización, por lo que para salir de la misma hace falta un mecanismo para mapear las direcciones IPv4
privadas con la dirección IPv4 pública disponible. Ese mecanismo es el NAT (Network Address Translation).
Ya en IPv6, tenemos la "Dirección de Enlace Local" (Local-Link Address) que funciona como una dirección IPv4 privada asignada automáticamente. Por ello, por ser una dirección privada, no se enruta nunca, o lo que es lo mismo, no se envía a Internet.
En IPv4, cuando un equipo configurado para obtener su dirección de un servidor DHCP no encuentra al servidor, toma una dirección del rango 169.254.0.0/16. Las Direcciones de Enlace Local serían el equivalente a las direcciones IPv4 de la red 169.254.0.0/16. Estas Direcciones de Enlace Local se pueden utilizar en Autoconfiguración, para Neighbor Discovery, en redes sin routers y para crear redes temporales (por ejemplo, cuando se conectan dos equipos mediante un cable cruzado).
Por ser de uso privado, no necesitan un "prefijo de enrutado global", de hecho, en su lugar se coloca el "prefijo de enlace local" FE80::/10. Por eso, todas las direcciones de enlace local empiezan por FE80.
En la siguiente imagen, se puede ver dónde aparece la Dirección de enlace local en un equipo con Ubuntu y en otro con Windows XP.
Como se puede ver en la captura de Ubuntu, hay una relación directa entre la MAC de la tarjeta de red y la dirección de enlace local. El procedimiento mediante el que se crea el Identificador de Interfaz a partir de la dirección MAC ha sido ya explicado al
2.2.5. Dirección Unicast Local Única
Cuando se definió la Dirección de Enlace Local se hizo lo propio con la llamada "Dirección de Sitio Local".
Con el tiempo, ese último término fue sustituido por el de "Dirección Unicast Local Única" o simplemente "Dirección IPv6 Local". En inglés se suele usar el término ULA
(Unique Local Unicast Address).
En la RFC 4193 "Unique Local IPv6 Unicast Addresses" se puede encontrar la descripción original de este tipo de dirección.
A pesar de que estas direcciones son únicas a nivel global, no deben ser enrutadas, es decir, no deben ser utilizadas en comunicaciones fuera de los límites de la red corporativa. Están diseñadas para ser usadas en local (dentro de sitios corporativos o conjuntos de redes).
Las características de las Direcciones Unicast Locales Únicas son las siguientes: Tienen un prefijo global único que facilita el filtrado en los límites de la red.
Permiten la interconexión de redes privadas sin que haya riesgo de que surjan conflictos por direcciones duplicadas, lo cual implicaría la renumeración de una de las redes.
No dependen de los ISPs.
Se pueden usar en comunicaciones internas sin conexión a Internet.
Si se enrutan accidentalmente a Internet, no surgen conflictos de direcciones
Pueden ser utilizadas por las aplicaciones del mismo modo que utilizan las direcciones unicast globales.
El formato de estas direcciones se muestra en la siguiente figura:
El bit L puesto a 1 indica que la administración del prefijo es local.
Y esto está relacionado con el siguiente bloque de 40 bits, el IDENTIFICADOR GLOBAL. Cuando la administración es local, este Identificador Global se crea aplicando un algoritmo pseudo-aleatorio, que garantiza con una probabilidad altísima su exclusividad.
Se parte de la hora y fecha del día en formato NTP (Network Time Protocol) de 64bits. NTP es un protocolo que permite sincronizar los relojes de equipos conectados a Internet.
Se obtiene un identificador EUI - 64 a partir de la MAC. Se concatenan los resultados obtenidos en (1) y (2).
Aplicar el algoritmo SHA-1 al resultado de (3) y tomar los 40 bits menos significativos como Identificador Global.
2.2.6. Direcciones Anycast
En networking hay ocasiones en las que un servicio se ofrece por medio de varios hosts o routers.
De este modo se consigue:
Redundancia: el servicio no depende de un único servidor, de modo que si un equipo falla, los demás asumen sus funciones y el servicio sigue disponible.
Balanceo de carga: los distintos servidores se reparten el trabajo de modo que no haya un equipo sobrecargado (con la consiguiente merma de rendimiento) y otro inactivo.
Cuando un usuario, aplicación o host quiere acceder al servicio, no le importa cuál de los múltiples servidores que lo ofrecen le está atendiendo.
Las direcciones Anycast permiten esta forma de funcionamiento. Cuando un host envía un datagrama a una dirección anycast, la infraestructura de red buscará el camino más corto hasta uno, y preferiblemente solo uno, de los equipos que aceptan datagramas dirigidos a la dirección anycast utilizada.
La gran ventaja del "Anycasting" es que simplifica la búsqueda del servidor más apropiado (que suele ser el más cercano).
múltiples interfaces. Esto es lo que se usa, por ejemplo, en los servidores DNS raíz en Internet.
Dentro de una red donde un grupo de routers puede proporcionar acceso a un dominio de enrutamiento común, se puede asignar una dirección única a todos los routers y cuando un cliente envía un paquete a esta dirección, será enviado al siguiente router disponible.
Esto se utiliza en 6to4 (RFC 3068) y en Mobile IPv6.
También hay que ser conscientes de que al utilizar direcciones anycast, el emisor no tiene control sobre cuál será la interfaz a la que se entregará el paquete, ya que esta decisión se toma sobre el nivel del protocolo de enrutamiento.
Debido a esto pueden darse errores si un emisor envía varios paquetes a una dirección anycast y los paquetes llegan a diferentes destinos. Lo mismo ocurre si hay que establecer un diálogo con una serie de peticiones y respuestas o si hay que fragmentar el paquete.
Como extensión a lo explicado, y ya en IPv6, la dirección anycast es una dirección que se asigna a más de una interfaz (normalmente pertenecientes a distintos nodos).
Se sigue manteniendo que un paquete enviado a una dirección anycast es enrutado a la interfaz más cercana con esa dirección anycast. La distancia es medida por los protocolos de enrutado.
Las direcciones anycast están dentro del espacio de las direcciones unicast, por lo que, sintacticamente, no se puede distinguir una dirección anycast de una unicast.
Cuando se convierte una dirección unicast en dirección anycast, asignando la dirección unicast a más de una interfaz, los nodos que han recibido la dirección deben ser configurados de modo que reconozcan la dirección anycast.
A modo de ejemplo, se muestra el formato de la "dirección anycast del router de la subred" (subnet-router anycast address), que está predefinido y tiene el aspecto indicado en la siguiente figura:
El "prefijo de subred" en una dirección anycast es el prefijo que identifica un enlace específico.
Esta dirección anycast es sintácticamente igual que cualquier otra dirección unicast de una interfaz del enlace, con el identificador de interfaz a cero.
Los paquetes enviados a la "dirección anycast del router de la subred" serán entregados a un router de la subred.
Todos los routers están obligados a soportar las "direcciones anycast del router de la subred" de todas las subredes en las que tiene conectada una interfaz.
2.2.7. Direcciones Multicast
Se las identifica fácilmente porque son direcciones que empiezan por 0xFF (es decir, por 1111 1111, en binario).
Los nodos que se configuran con una dirección multicast determinada forman lo que se llama un GRUPO DE MULTIDIFUSIÓN.
Un nodo puede pertenecer a varios grupos de multidifusión.
Cuando un paquete es enviado a una dirección de multidifusión, todos los miembros del grupo procesan el paquete
En la siguiente figura se muestra el formato de las direcciones multicast:
Los primeros 8 bits (puestos a 1) identifican la dirección como multicast. Los siguientes 4 bits se utilizan como flags y se definen así:
El primer bit (O) debe ser cero y está reservado para un uso futuro.
El segundo bit (R) indica si esta dirección de multidifusión incluye el llamado Rendezvous Point (Punto de Encuentro).
Esto está relacionado con un problema detectado al realizar multicasting entre dominios, y es que el protocolo utilizado (PIM - SM) no tiene forma de dar a conocer a otros dominios de multidifusión cuáles son las fuentes de multidifusión disponibles.
En la RFC 3956 se define cómo codificar la dirección del Rendezvous Point (RP) en una dirección de grupo multicast y el bit que estamos tratando indica si la dirección
direcciones multicast y se explica más adelante. Cuando no se envía información sobre el prefijo, este bit se pone a 0.
El último bit del campo de Flags indica si la dirección está asignada de forma permanente, esto es, si es una de las direcciones de multidifusión llamadas "Well-known" (bien conocidas), por estar asignadas por la IANA (bit a 0). O se trata de una dirección de multidifusión de carácter temporal (bit a "1"). La lista actualizada de dirección multicast asignadas está en este enlace
El campo “Scope” (= ámbito de aplicación) se utiliza para limitar el alcance de una dirección de multidifusión. En función del valor asignado el ámbito puede ser de interfaz local, de enlace local, de sitio local, global...
1 = nodo local 2 = link local 5 = site local
14 = global (Internet)
Por último, el campo "Identificador de grupo" sirve para delimitar el grupo objetivo de los paquetes multicast enviados.
1 = all nodes (Scope = 1 ó 2). Con un valor de Scope = 2 nos permitiría enviar un mensaje a todos los nodos del enlace local.
2 = all routers (Scope = 1, 2 ó 5)
Con todo lo dicho, podríamos utilizar, por ejemplo, la dirección FF02::1. Esta es la dirección "Link Local All Nodes", con la cual podríamos enviar un paquete a todos los nodos del enlace local. Esta dirección es la equivalente a la 255.255.255.255 de IPv4.
Otra dirección multicast que suele aparecer es la FF02::2, que es la dirección "Link Local All Routers" y que nos permite comunicarnos con todos los routers que se encuentran en el enlace local. Esto se usa, por ejemplo, cuando un nodo necesita encontrar un router (mensajes "Router Solicitation" de ICMPv6) que le pueda informar de cuál es la configuración de red que debe tomar.
Dirección multicast de "nodo solicitado" (Solicited-Node)
Es ésta una dirección que todos los nodos tienen que agregar para cada una de sus direcciones unicast y anycast. Se usa en Neighbor Discovery y se describe en la RFC 4291.
En IPv4, las peticiones ARP se utilizan para encontrar la MAC del nodo con el que nos queremos comunicar, a partir de la dirección IP del mismo. La búsqueda se hace
mediante mensajes de broadcast, que son examinados por todas las hosts del enlace. Esto genera mucho tráfico y es una de las cuestiones que se hecha en cara a IPv4.
En IPv6, la resolución de la dirección MAC de una interfaz se realiza mediante el envío de un mensaje Neighbor Solicitation a la dirección multicast de "nodo solicitado". De este modo, sólo el nodo que tiene en propiedad esa dirección de multidifusión examinará el paquete.
Esta dirección se forma tomando los 24 bits menos significativos de una dirección IPv6 (la última parte del host ID) y añadiendo estos bits al prefijo Well-known
FF02:0:0:0:0:1:FF00:: / 104. Por lo tanto, el rango para direcciones multicast de nodo solicitado va de FF02:0:0:0:0:1:FF00:0000 a FF02:0:0:0:0:1:FFFF:FFFF.
Por ejemplo, si un host tiene la dirección MAC 00-18-F8-29-F1-D7 y la dirección IPv6 FE80::218:F8FF:FE29:F1D7, su dirección multicast de nodo solicitado será FF02::1:FF29:F1D7.
Si este host tiene otras direcciones IPv6 unicast o anycast, cada una podría tener asociada su propia dirección multicast de nodo solicitado.
Asignación dinámica de direcciones Multicast
La RFC 3306 extiende la arquitectura de la dirección multicast para hacer posible la propagación de los prefijos unicast por medio de dichas direcciones.
Se basa en un formato modificado la dirección multicast que contiene información de prefijo.
El objetivo de esta especificación es reducir el número de protocolos necesarios para la asignación de direcciones multicast
El campo de Scope tiene la misma función que en el caso anterior y el campo Reservado vale 0 cuando P = 1.
Los siguientes 8 bits (PLen) especifican la longitud del prefijo en el campo de prefijo.Si la longitud de prefijo es menor de 64 bits, los bits no utilizados en dicho campo se pondrán a 0.
2.2.8. Direcciones de cada nodo
Aunque ya se comentó en la introducción al tema, es el momento de repasar las distintas direcciones que nos podemos encontrar tanto en los hosts como en los routers.
Respecto a los hosts, podemos tener las siguientes:
Su dirección de enlace local para para cada interfaz. Todas las direcciones unicast y anycast asignadas. La dirección de loopback.
La dirección multicast de todos los nodos (all-nodes).
La dirección multicast Solicited-node para cada una de sus direcciones unicast y anycast.
Las direcciones multicast de todos los grupos a los que pertenezca el host. En cuanto a los routers, tienen que reconocer todas las direcciones anteriores, y las siguientes:
La dirección de anycast de subred-router para las interfaces para las que está configurado para actuar como un router en cada enlace.
Todas las direcciones anycast con las que el router ha sido configurado. La dirección multicast de todos los routers.
Las direcciones multicast de todos los demás grupos a los que pertenece el router.
2.2.9. Selección de direcciones por defecto
Como venimos comentando, la arquitectura de IPv6 permite asignar varias direcciones de distinto tipo a una interfaz.
Cada vez más, será frecuente que los hosts soporten tanto IPv4 como IPv6.
Por todo ello, en las comunicaciones entre equipos de doble pila habrá que decidir entre utilizar IPv4 o IPv6 e incluso, cuál de las direcciones IPv6 será la elegida.
Supongamos una situación en la que un cliente envía una petición DNS para un servicio externo y recibe una dirección IPv6 global y una dirección IPv4 pública como respuesta. Si este cliente tiene una dirección IPv4 privada y una dirección IPv6 global, puede tener sentido utilizar IPv6 para acceder a este servicio externo. Pero si el cliente tiene una dirección IPv6 de enlace local y una dirección IPv4 pública, elegirá la dirección IPv4 para la conexión al servicio.
Estos son las situaciones y decisiones que tendrán que ser manejadas en un escenario de redes mixtas con redes sólo-IPv4, redes sólo-IPv6 y redes con doble pila.
La forma en que se trata depende de la programación de la aplicación que están usando el protocolo.
Los desarrolladores tienen que ser conscientes de ello y tratar de establecer mecanismos para que sus aplicaciones se comportan de manera óptima en todos los ambientes posibles.
La RFC 3484 "Default Address Selection for IPv6", define dos algoritmos generales, uno para la selección de la dirección de origen y el otra para la selección de la dirección de destino. Esta RFC debe ser soportada por todos los nodos IPv6, es decir, tanto por host como por routers.
Los algoritmos especifican el comportamiento por defecto para los nodos IPv6, pero no anulan las decisiones tomadas por las aplicaciones o protocolos de la capa superior.
Antes de enumerar las principales reglas hay que saber que las direcciones asociadas a las interfaces tienen un tiempo de vida que indica hasta cuándo está dicha dirección asociada a la interface. Mientras ese tiempo no haya expirado, la dirección se considera "preferida". Una vez agotado el tiempo, y hasta que se libera totalmente la dirección, se la considera "obsoleta" (deprecated) y se puede seguir utilizando, aunque no se recomienda.
He aquí un resumen de las reglas más importantes:
Son preferibles pares de direcciones del mismo ámbito o tipo (link-local, global).
Es preferible un ámbito pequeño para la dirección de destino(utilizar el ámbito más pequeño posible).
Para la dirección de origen, se prefiere un dirección global a una dirección temporal.
En situaciones de Mobile IP, se prefieren las direcciones “home” antes que las “care-of”.
Las normas de la RFC 3484 se aplicarán cuando no haya otros criterios específicos. La especificación también permite la configuración de una política que puede reemplazar estos valores por defecto con combinaciones preferidas de direcciones de origen y de destino.
2.3.
Instalación y tipos de configuración de IPv6
La instalación de IPv6 establece una configuración básica en los adaptadores de red de nuestro sistema operativo.
Para comprender mejor la instalación y configuración de IPv6 vamos a analizarlo en dos apartados:
Instalación y configuración básica de IPv6. Configuración avanzada de IPv6.
Estudiemos cada caso:
2.3.1. Instalación y configuración básica de IPv6:
La configuración de los interfaces de red es completamente automática. Aunque por supuesto pueden existir, no es necesario ningún elemento externo como puede ser un router, un servidor de direcciones o una configuración manual por parte del usuario. En principio el adaptador de red intenta descubrir en la red “alguien” que pueda suministrarle una dirección. Aunque nadie responda, la dirección local de enlace se construye utilizando un algoritmo. Al igual que ocurría en IPv4 con las direcciones del tipo. 169.254.X.X. En aquel caso, si la interfaz estaba configurada para obtener una IP automaticamente pero no existía ningún servidor DHCP la interfaz obtenía una IP del tipo 169.254.X.X. En IPv6 la dirección inicial configurada empezará siempre por FE80::
Para entender mejor los conceptos teóricos vamos a realizar la instalación y configuración básica de IPv6 utilizando los sistemas operativos más comunes (Ubuntu-Linux, Windows XP, y Windows 7).
Veamos como se realiza la instalación en cada sistema operativo y analizemos la configuración básica resultante con un ejemplo:
Instalación y configuración básica de IPv6 en Ubuntu-Linux (9.10) Instalación y configuración básica de IPv6 en Windows XP (SP3) Instalación y configuración básica de IPv6 en Windows 7
En general la configuración en otros sistemas operativos como Solaris o en otras distribuciones de linux como Suse o Debian, es muy parecida.
adelante contemplaremos la instalación de elementos que posibiliten los distintos tipos de configuración, por ejemplo "stateful" (DHCPv6).
Tal y como veremos la dirección link-local en la configuración stateless sin router se obtiene aplicando un algoritmo a la dirección física o MAC de cada interface.
En Ubuntu-Linux IPv6 está integrado y activo por defecto en el sistema operativo. Por tanto sin hacer nada, si desde la terminal de comandos, ejecutamos el comando ip addr show . El comando ip sustituye entre otros comandos a ifconfig que ha quedado obsoleto. Veamos la respuesta que obtenemos en ambos casos:
En ausencia de un router, observamos que se instalan 2 interfaces.
Interfaz Local Loopback o lo: Es la dirección local, ::1 , similar a 127.0.0.1 en IPv4. Interfaz eth0 : fe80::213:d4ff:fe27:4680 Dirección Link-Local preferida. Es la dirección preferida en nuestro caso. Se obtiene usando el prefijo fe80 (predeterminado
para direcciones locales de enlace), y a continuación, se aplica un algoritmo (especificado en RFC 4291) a la dirección MAC 00:13:D4:27:46:80 de nuestro adaptador. Veamos el algoritmo aplicado en nuestro caso de forma gráfica:
Como sabemos de la teoría, el algoritmo consiste en introducir FFFE entre el tercer y cuarto byte y complementar el bit universal.
Una vez analizados los interfaces instalados automaticamente para determinar el correcto funcionamiento podemos utilizar el comando ping6 a las siguientes direcciones.
ping6 ::1 ping6 al link-local
En el segundo caso, cuando se trata de hacer ping utilizando IPv6 a direcciones locales de enlace, es necesario utilizar la opción -I para especificar el interface a utilizar.
Los resultados obtenidos son satisfactorios.
2.3.1.2. Instalación y configuración básica de IPv6 en Windows XP:
Antes de nada al contrario de lo que sucede en las últimas versiones de Ubuntu-Linux o en Windows 7, en Windows XP el protocolo IPv6 no es nativo y primero deberemos instalarlo.
Instalación de ipv6 en Windows XP, SP3:
Para la instalación se ha venido utilizado el comando "ipv6.exe" desde la consola de comandos.
Para desinstalar:
Sin embargo, desde hace unos años y para el uso y configuración del entorno y conexiones de red Microsoft aconseja el uso del comando "netsh" dentro de la consola de comandos.
Cada opción de ipv6 es sustituida por otra en netsh, profundizaremos en el uso de netsh más adelante.
Por tanto, para realizar la instalación en lugar de ipv6.exe install, se recomienda:
La instalación también puede hacerse utilizando el modo gráfico.
Inicio--> Mis sitios de red --> Ver conexiones de red--> Configuración de area local -->Botón derecho --> Propiedades