1. IPV6 BÁSICO 1 2. CABECERA, DIRECCIONAMIENTO Y CONFIGURACIÓN BÁSICA. 9

Transcripción

1 1. IPV6 BÁSICO DISTRIBUCIÓN DE DIRECCIONES IPV EVOLUCIÓN DE LA NECESIDAD DE DIRECCIONES INCONVENIENTES TÉCNICOS DE IPV LA SOLUCIÓN: IPV HISTORIA DE IPV CABECERA, DIRECCIONAMIENTO Y CONFIGURACIÓN BÁSICA LA NUEVA CABECERA LIMPIEZA EN IPV LOS CAMPOS BIT A BIT LAS CABECERAS DE EXTENSIÓN DIRECCIONAMIENTO LOS PREFIJOS DIRECCIÓN NO ESPECIFICADA Y DIRECCIÓN DE LOOPBACK DIRECCIONES UNICAST GLOBALES DIRECCIÓN UNICAST DE ENLACE LOCAL DIRECCIÓN UNICAST LOCAL ÚNICA DIRECCIONES ANYCAST DIRECCIONES MULTICAST DIRECCIONES DE CADA NODO SELECCIÓN DE DIRECCIONES POR DEFECTO INSTALACIÓN Y TIPOS DE CONFIGURACIÓN DE IPV INSTALACIÓN Y CONFIGURACIÓN BÁSICA DE IPV6: CONFIGURACIÓN AVANZADA DE IPV6: ORDENES BÁSICAS EN GNU/LINUX Y WINDOWS ORDENES BÁSICAS EN UBUNTU-LINUX ORDENES BÁSICAS EN WINDOWS PRUEBAS DE CONECTIVIDAD EN LAN (PING6) CONFIGURACIÓN AVANZADA ICMPV LOS MENSAJES NEIGHBOR DISCOVERY OTRAS POSIBILIDADES DE ICMPV CONFIGURACIÓN STATELESS INTRODUCCIÓN DESCRIPCIÓN AUTOCONFIGURACIÓN DE DIRECCIONES GLOBALES OBTENCIÓN DE DIRECCIONES DE AUTOCONFIGURACIÓN ALGORITMOS DE GENERACIÓN DE DIRECCIONES GLOBALES ROUTER IPV6 89 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL:

2 3.3. DHCPV DHCPV6 UBUNTU 9.10 SERVER DHCPV6 WINDOWS 2008 SERVER DHCPV6 CLIENTE UBUNTU DHCPV6 CLIENTE WINDOWS XP DHCPV6 CLIENTE WINDOWS CONFIGURACIÓN MANUAL CONFIGURACIÓN MANUAL EN UBUNTU-LINUX CONFIGURACIÓN MANUAL EN WINDOWS PLANIFICACIÓN DE UNA RED IPV MECANISMOS DE TRASICIÓN PARA CONSEGUIR CONECTIVIDAD IPV6 IN IPV IPV6 TO IPV TEREDO EJEMPLOS DE TUNELES: TUNNEL BROKER Y TEREDO CREACIÓN DE TÚNEL EN UN HOST CON WINDOWS CON FREENET CREACIÓN DE TÚNEL DE UN FIREWALL DE BEBIAN CON HURRICANE CREACIÓN DE TÚNEL TEREDO INYECCIÓN Y CAPTURA DE PAQUETES WIRESHARK NUEVAS AMENAZAS CON IPV COMUNICACIONES A TRAVÉS DE IPV ATAQUES CONTRA LA AUTOCONFIGURACIÓN IPV VULNERABILIDADES CON TEREDO PUERTA ABIERTA A INTERNET SUPLANTACIÓN DE IDENTIDADES ATAQUES DE DENEGACIÓN DE SERVICIOS VULNERABILIDADES CON 6TO PUERTA ABIERTA A INTERNET SUPLANTACIÓN DE IDENTIDADES ATAQUES DE DENEGACIÓN DE SERVICIOS USOS DE IPV6 CON FINES MALICIOSOS ASPECTOS DE SEGURIDAD MEJORADOS CON IPV ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL:

3 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" Distribución de direcciones IPv4 Debido a la longitud de la direcciones IPv4, que es de 32 bits, hay un total de 2³² = 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: a ( /8) a ( /12) a ( /16) ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 1

4 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 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 direcciones. Actualmente la situación en cuanto al reparto de estos bloques es el siguiente: Fuente: Como puede verse, quedan tan solo 26 bloques /8 de los 256 teóricamente disponibles, esto es, poco más de un 10%. Incluso aunque las direcciones no disponibles (por estar preasignadas o reservadas) se agregaran a las direcciones disponibles, se ve claro que, con la tendencia actual, en cuestión de unos pocos años no habría direcciones IPv4 que repartir. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 2

5 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 se hablaba de finales de 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 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 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 3

6 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. Con el paso de los años empezaron a surgir diversas técnicas que aprovechaban estas debilidades y que hacían las delicias de los aficionados a la "seguridad" informática (hackers). Actualmente la seguridad en IPv4 se garantiza por medio de dos parches: SSL (Secure Socket Layer) e IPsec (encriptación a nivel de red). ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 4

7 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 5

8 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. Las VPNs se soportan de forma nativa, y por ello resulta más barato implementarlas pues no es necesario adquirir productos de terceros. Además se facilitan ciertas tareas administrativas con nuevas funcionalidades: autoconfiguración, renumeración, movilidad IP... ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 6

9 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 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 7

10 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 ( ) 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... ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 8

11 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 9

12 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 Limpieza en IPv4 Los 6 campos de IPv4 eliminados en IPv6 son: Longitud de la cabecera, Identificación, Flags, Fragment Offset, Checksum de cabecera y Opciones. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 10

13 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 11

14 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 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. Version (4 bits) ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 12

15 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¹⁶ = Bytes = 64KB) ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 13

16 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 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 Destination Address = Dirección Destino (16 Bytes) Este campo contiene la dirección IP del destino del paquete. Esta dirección puede ser la del destino final. En caso de estar presente una cabecera de Enrutado, puede ser la dirección del siguiente router. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 14

17 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 15

18 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. Cada cabecera de Extensión es identificada por el campo Next Header de la cabecera precedente. Las cabeceras de Extensión son examinadas o procesadas solo por el nodo identificado en el campo dirección de Destino de la cabecera IPv con una única excepción: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 16

19 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 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 17

20 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) 9. Cabecera de capa superior. Cuando se encapsula IPv6 en IPv4, la cabecera de capa superior puede ser otra cabecera IPv6 y puede contener cabeceras de Extensión que tienen que seguir las reglas mencionadas. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 18

21 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 ,702 x 10⁶ m² con 2¹²⁸ direcciones podríamos asignar 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 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 19

22 Cuando trabajamos con IPv4 estamos acostumbrados a tener que asignar una dirección IP del estilo 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: :0:0:7:0:900:300B:528B Como se puede ver, en la segunda dirección no aparecen 4 dígitos hexadecimales en todos los casos. Esto es debido a que no hace falta representar los ceros que aparecen más a la izquierda. Pero el trato especial que reciben los ceros no termina aquí, de hecho, existe incluso una "Notación abreviada para los ceros": ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 20

23 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: :: :0:0:0:0:0:C0A8:2C01 ::C0A8:2C 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 ( /24 equivale a una máscara ): En IPv6 tenemos: Dirección IPv6 / Longitud del prefijo ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 21

24 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 FE80::/10 Dirección Unicast de Enlace Local. Aquellas cuyos primeros 10 bits son 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 Dirección No Especificada y Dirección de Loopback Vemos a continuación dos direcciones que se podrían catalogar como direcciones especiales: Dirección no especificada (Unspecified address) ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 22

25 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 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 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 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). Este prefijo limita el rango de direcciones asignado al sitio. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 23

26 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: 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, una vez obtenido el prefijo de enrutado global, la organización puede descomponerse en subredes. Lógicamente, la gestión de este identificador es responsabilidad del administrador local. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 24

27 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ón EUI-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 cd 39 2b 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 , y complementando el bit marcado en rojo se convierte en , es decir, 0x02. Por lo tanto el identificador de interfaz obtenido mediante autoconfiguración es: cd ff fe 39 2b 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 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 25

28 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 /16. Las Direcciones de Enlace Local serían el equivalente a las direcciones IPv4 de la red /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 hablar de las Direcciones Unicast Globales. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 26

29 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. Por ello, siempre que la administración sea local, el prefijo será FD::/8 ( ). ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 27

30 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 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). Realmente Anycast se planteó en la RFC 1546 (1993) como especificación experimental para IPv4 y estaba destinado a ser utilizado para servicios tales como DNS y HTTP. Una forma de implementar el Anycast es usando el método llamado "Dirección Unicast Compartida", que consiste en asignar direcciones unicast normales a ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 28

31 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 29

32 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 Direcciones Multicast Se las identifica fácilmente porque son direcciones que empiezan por 0xFF (es decir, por , 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 lleva, o no, insertado el "Rendezvous Point". En los usos más habituales, esto no será así y el bit valdrá 0. El tercer bit (P) indica si esta dirección de multidifusión incluye información acerca del prefijo (RFC 3306). Esto se utiliza para realizar la asignación dinámica de ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 30

33 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 "Wellknown" (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 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 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 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 31

34 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 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 nuevo formato es el indicado a continuación: En la especificación original, se utiliza el flag "T" para especificar si la dirección de multidifusión es Well-known o temporal En el formato extendido el flag "P" indica si la dirección muticast contiene un prefijo (P = 1) o no (P = 0). En caso de que P = 1, el flag T también se pondrá a 1, indicando que se trata de una dirección multidifusión temporal y no de una dirección Well-known. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 32

35 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 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 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 33

36 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). Es preferible una dirección preferida a una obsoleta. Las direcciones de transición (por ejemplo, direcciones ISATAP o 6to4) no se utilizan si hay direcciones IPv6 nativas disponibles. Si todos los criterios son similares, son preferibles los pares de direcciones con el prefijo común más largo. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 34

37 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 35

38 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: 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 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 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 Instalación y configuración básica de IPv6 en Ubuntu-Linux: Aunque lo más normal en una red es poseer un servidor de direcciones o router, para comenzar no contemplaremos ningún elemento externo, por tanto la configuración inicial de las direcciones será automática (stateless) sin router ni sernvidor, y más ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 36

39 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 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 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 37

40 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 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 38

41 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 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. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 39

42 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 Pulsamos Instalar ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 40

43 Marcamos TCP/IP versión 6 y pulsamos aceptar. Cada vez que instalamos y desinstalamos en XP conviene reiniciar el ordenador. Una vez concluida la instalación, para obtener la información, podemos usar: ipconfig ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 41

44 o ipconfig /all ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 42

45 o podemos usar el entorno netsh y sus comandos, por ejemplo, para ver la información IPv4: La dirección IPv4 y la puerta de enlace han sido establecidas manualmente. En el caso de IPv6 que estamos analizando: En nuestro caso observamos que se instalan 4 interfaces: Interfaz 1 o Loopback: Es la dirección local, ::1, similar a en IPv4. La interfaz 2 y 4 corresponden a mecanismos de transición que están siendo adaptados y en algunos casos quedan obsoletos y su implementación depende del creador de cada sistema operativo, en el caso de Microsoft para XP se usa la tunelización automática y Teredo. Se instalan para permitir el uso de IPv4 e IPv6 en la misma red. Interfaz 2 de Tunelización automática: fe80::5efe: utilizada para garantizar la compatibilidad de IPv4 e IPv6. Se compone de un prefijo fe80 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 43

46 (especificado para direcciones locales de enlace) efe determina (corresponde al protocolo ISATAP) que a continuación se utilizará una IPv4 privada. Interfaz 4 Tunel Teredo: fe80::ffff:ffff:fffd es utilizado como mecanismo de transición entre IPv4 e IPv6 cuando se utiliza NAT. Interfaz 5 : fe80::205:1cff:fe13:a63c 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 de nuestro adaptador. Veamos el algoritmo aplicado en nuestro caso de forma gráfica: Como hemos podido observar al hacer ipconfig /all la dirección MAC de nuestro adaptador es: C-13-A6-3C. A continuación detallamos de forma gráfica el algoritmo utilizado: 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 entendida la instalación de IPv6 y su resultado en XP para determinar el correcto funcionamiento podemos utilizar el comando ping a las siguientes direcciones. ping ::1 ping al link-local ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 44

47 o ping6 ::1 Para terminar también podríamos hacer ping6 a la dirección local configurada con el siguiente formatu: ping6 direcciónipv6local%interfaceautilizar en nuestro caso escribiríamos en la interfaz de comandos: La interfaz responderá satisfactoriamente. ping6 fe80::205:1cff:fe13:a63c%5 De esta forma tan sencilla, hemos incorporado IPv6 a nuestra red local usando Windows XP Instalación y configuración básica de IPv6 en Windows 7 : En Windows 7 ipv6 está integrado y activo por defecto en el sistema operativo. Microsoft desaconseja desactivar ipv6 pues esto podría acarrear el mal funcionamiento de algunas aplicaciones. Por tanto sin hacer nada, si desde la interfaz de comandos, ejecutamos ipconfig observaremos la configuración existente: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 45

48 o ipconfig /all Utilizando netsh podemos ver los interfaces ipv6 instalados por defecto: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 46

49 En nuestro caso observamos que se instalan 4 interfaces: Interfaz 1 o Loopback: Es la dirección local, ::1, similar a en IPv4. La interfaz 12 y 13 corresponden a mecanismos de transición que están siendo adaptados y en algunos casos quedan obsoletos y su implementación depende del creador de cada sistema operativo, en el caso de Microsoft para Windows 7 se usan Isatap y Teredo. Se instalan para permitir el uso de IPv4 e IPv6 en la misma red. Interfaz 12 de Tunelización automática: fe80::5efe: utilizada para garantizar la compatibilidad de IPv4 e IPv6. Se compone de un prefijo fe80 (especificado para direcciones locales de enlace) efe determina (corresponde al protocolo ISATAP) que a continuación se utilizará una IPv4 privada. Interfaz 13 Tunel Teredo: fe80::100:7f:fffe es utilizado como mecanismo de transición entre IPv4 e IPv6. Esta ACTIVO y conectado a internet puede obtener una dirección global del tipo 2001::/32 Interfaz 11 : Conexión de área local: fe80::e8e0:544c:1875:1c4 Dirección Link- Local preferida. Es la dirección preferida construida por Windows 7 en nuestro caso. Una de las controversias en Windows Vista, Server 2008 y Windows 7 es la utilización del algoritmo de creación de direcciones elegido por Microsoft. Como vimos anteriormente en Windows XP el algortimo utilizado dependía de la dirección MAC del adaptador de red. La creación de dicha dirección IPv6 viene determinada en los RFC 2373 y RFC Posteriormente, para garantizar la privacidad del usuario se definió RFC Windows 7 por defecto NO utiliza EUI-64 para formar la dirección. Microsoft se ha desmarcado y por defecto utiliza un algoritmo aleatorio para la creación de direcciones. Por supuesto, Microsoft permite activar o desactivar el uso de dicho algoritmo especial mediante los siguientes comandos: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 47

50 netsh interface ipv6 set global randomizeidentifiers=disabled netsh interface ipv6 set global randomizeidentifiers=enabled Una vez entendida la instalación de IPv6 y su resultado en W7 para determinar el correcto funcionamiento podemos utilizar el comando ping a las siguientes direcciones. En Windows 7 el comando ping viene preparado para usarse con IPv6. Si analizamos la ayuda del comando ping mediante ping /? incluso podemos forzar el uso de IPv6 con la opción -6 ping ::1 ping al link-local Como hemos visto en Windows XP, podemos hacer ping a la dirección local de enlace, indicando el número de interface tras el símbolo % Configuración avanzada de IPv6: La configuración avanzada requiere de un elemento configurador ( router y/o servidor ) de direcciones o de la intervención manual del usuario en la configuración. Será analizada con mayor profundidad más adelante. Básicamente puede analizarse estudiando tres técnicas que resumimos a continuación: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 48

51 Configuración Stateless con router: El PC IPv6 construye su dirección IPv6 basándose en el paquete Router Advertisement que envía el router IPv6 conectado al mismo segmento de red donde está conectado el PC. Por ejemplo el router puede estar configurado para establecer un prefijo a las direcciones IPv Configuración automática DHCPv6: Con DHCPv6 un PC IPv6 puede recibir una dirección IPv6 además de otros parámetros de configuración. Esta opción puede establecerse utilizando un servidor o un router que pueda ejercer de tal. Un uso común de DHCPv6 para PCs es recibir y configurar automáticamente la dirección IPv6 de los servidores DNS, los cuales no se reciben a través del paquete Router Advertisement que envían los routers IPv6 de la red. El paquete Router Advertisement que recibe un PC durante la fase del descubrimiento de routers contiene un campo que indica si se va a utilizar también DHCPv6 para configurar la dirección IPv Configuración manual de la dirección: Un PC IPv6 típico no necesita configurar manualmente su dirección IPv6. Este método está orientado a servidores y/o routers IPv6. Sin embargo en caso necesario, la configuración manual es muy sencilla y como es habitual en los sistemas operativos puede hacerse de forma gráfica o mediante la interfaz de comandos. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 49

52 2.4. Ordenes básicas en GNU/Linux y Windows El desarrollo del protocolo IPv6 requiere la adecuación de los comandos que utilizamos para la configuración y gestión de nuestras redes TCP/IP. Los comandos ping o traceroute han sido adecuados no sabemos si temporal o definitivamente para el uso de IPv6, pudiendo usar además de ping, ping6 o traceroute6 como alternativa de traceroute, indicando en ambos casos que las direcciones utilizadas pertenecen a IPv6. Además, el aumento de posibilidades a la hora de ver, administrar, modificar y diagnosticar nuestras redes han requerido la administración más centralizada de dichas posibilidades. Durante mucho tiempo hemos venido utilizando comandos, como ifconfig (en Linux) o ipconfig (en Windows). Aunque en la mayoría de distribuciones y versiones dichos comandos siguen siendo válidos, poco a poco muchas de las funciones están siendo incorporadas dentro del comando ip (en Linux) o de netsh (en windows). Tanto ip como netsh permiten una administración más centralizada de las diferentes opciones en la configuración de nuestras redes. Aunque el estudio de las diferentes posibilidades de dichos comandos debe analizarse en un contexto más amplio, en está sección vamos a analizar algunas de sus opciones básicas, siempre dentro del contexto de direccionamiento IPv6 que estamos estudiando. La adecuación al nuevo direccionamiento IPv6 puede valernos para de paso, sustituir el uso de los anteriores comandos por las nuevas opciones. Vamos a analizar algunas de dichas opciones tanto en Ubuntu-Linux como en Windows: Ordenes básicas en Ubuntu-Linux Ordenes básicas en Windows Para un estudio más profundo de iproute2 o netsh es necesario acudir a las diferentes manuales de ayuda Ordenes básicas en Ubuntu-Linux Para el uso de IPv6 en Linux algunos comandos han sido adecuados. Veamos: ping6: Para el controlar el estado de la conexión de dispositivos IPv6 se utiliza el comando ping6 que sustituye al comando ping utilizado para IPv4. Ping6 contiene las siguientes opciones: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 50

53 traceroute6: Es la versión IPv6 para traceroute. Su sintaxis es: Nuevas utilidades dentro de iproute2: El paquete utilizado en Ubuntu-Linux para el control de TCP y UDP en redes IP se llama iproute o iproute2. Muchos manuales de configuración de redes todavía se refieren a comandos incluidos anteriormente en las denominadas net-tools de Unix, como ifconfig y route y aunque hoy en día dichos comandos funcionan en la mayoría de distribuciones su uso está siendo sustituido por nuevos comandos. iproute2 es un paquete de utilidades desarrollado por Alexey Kuznetsov. Viene incorporado en las versiones de núcleo posteriores a la 2.2. Contiene un conjunto de herramientas muy potentes para administrar interfaces de red y conexiones en sistemas Linux. iproute2 contiene principalmente dos nuevos comandos: ip : Controla la configuración de IPv4 e IPv6. tc (traffic control): Controla el tráfico. Comando ip: Algunos ejemplos de las nuevas opciones son: DESCRIPCIÓN Configuración de direcciones y enlaces COMANDO ANTERIOR ifconfig NUEVO COMANDO ip addr ip link Tablas de rutas route ip route Vecinos o Neighbors arp ip neigh Tuneles iptunnel ip tunnel Multicast ipmaddr ip maddr Observamos que iproute2 unifica la sintaxis de los comandos. La nueva sintaxis es más simple y más consistente. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 51

54 Para facilitar el uso, los comandos pueden también ejecutarse sin introducir un espacio a continuación del comando ip, es decir: # iproute (lo que sea) En lugar de : # ip route (lo que sea) En definitiva, la sintaxis del comando ip sería: ip [ OPCIONES ] OBJETO [ COMANDO [ ARGUMENTOS ]] Graficamente: Donde cada objeto viene definido como: Objeto link addr route rule neigh tunnel maddr mroute monitor y rtmon Descripción Maneja toda la información asociada con la interfaz: si está levantado o caído, direcciones MAC locales, soporte de multicast, si está en modo promiscuo o no, MTU, nombre de las interfaces, etc Maneja la asignación de direcciones IP a las interfaces. Maneja las tablas de rutas del sistema Permite las definición de reglas en tablas para su uso por el sistema de rutado. Maneja las tablas ARP del sistema Maneja la creación de túneles entre sistemas Maneja las direcciones multicast Maneja el caché de rutado multicast del sistema Monitorizar diversos objetos del sistema ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 52

55 Veamos algunos EJEMPLOS aplicables a IPv4 o IPv6: DESCRIPCIÓN Para ver la información sobre los interfaces y direcciones IP COMANDO ANTERIOR ifconfig a NUEVO COMANDO ip link show ip addr show Ver la tablas de rutas route o netstat -nr ip route show Ver la tabla arp arp na ip neigh ls Activar dispositivos de red ifconfig eth0 up ip link set dev eth0 up Comando tc: El comando tc (traffic control) forma parte del nucleo o kernel y se utiliza para controlar el tráfico. Al formar parte del núcleo no es solamente un analizador de puertos. Permite un control total. Permite definir diferentes objetos y su sintaxis es bastante compleja. Por ejemplo podríamos querer gestionar el ancho de banda de un acceso corporativo. Para ello definiríamos clases dentro de un objeto ( por ejemplo anchos de banda de 1 Mbps, 256Kbps y 24Kbps ) y luego aplicaríamos filtros de uso. El objeto de estos apuntes es introducir el uso del comando tc en el entorno de direccionamiento IPv6 y no profundizar en su uso, por tanto, ahora simplemente indicaremos su sintaxis y algún ejemplo. Si se tiene interes en un estudio más completo existe documentación y ejemplos en internet. Por ejemplo en Traffic Control HOW To de Martín A. Brown. Debido a la complejidad de su sintaxis, existe un comando denominado tcng (traffic control next generation) que incorpora toda la potencialidad de tc pero con una sintaxis más sencilla. En definitiva, la sintaxis del comando tc sería: tc [ OPCIONES ] OBJETO { COMANDO AYUDA } Graficamente: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 53

56 Donde cada objeto viene definido como: Objeto qdisc class filter action monitor Descripción Queueing discipine, generalmente define una especie de caja negra que es capaz de encolar y desencolar paquetes. Sólo existe dentro de qdisc, y se utiliza para determinar sus características, (HTB, CBQ) Es el elemento más complejo del control de tráfico, su uso más habitual es clasificar los paquetes. Permite definir diferentes acciones. Permite monitorizar el tráfico. Veamos algunos EJEMPLOS: DESCRIPCIÓN Para listar las reglas existentes Agregarle 20ms de espera al dispositivo de retorno (para hacer pruebas) Quitar la espera agregada antes. Para borrar todas las reglas COMANDO tc -s qdisc ls dev eth0 tc qdisc add dev lo root handle 1:0 netem delay 20msec tc qdisc del dev lo root tc qdisc del dev eth1 root Podríamos comprobar el retardo haciendo ping6 a la interfaz antes y después de la aplicación de la regla de tráfico. Veamos un segundo ejemplo más completo para la gestión del ancho de banda: Obviamente esto es válido para direcciones IPv4 e IPv6. En el caso de IPv6 en el paso 4 podríamos utilizar iptables6 en lugar de iptables. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 54

57 DESCRIPCIÓN COMANDO # /sbin/tc qdisc del dev eth1 root (Borramos todas la reglas para eth1) #/sbin/tc qdisc add dev eth1 root handle 1:0 htb default 10 (Defininimos la disciplina) Vamos a crear una regla para el control del tráfico de salida HTTP para la interfaz eth1. Permitimos un ancho de banda de 512Kbytes y un máximo de 640Kbytes para el puerto 80 # /sbin/tc class add dev eth1 parent 1:0 classid 1:10 htb rate 512kbps ceil 640kbps prio 0 (Definimos características de la clase) # /sbin/iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark 10 (Asignamos el puerto a la clase) # /sbin/service iptables save (guardamos iptables) # tc filter add dev eth1 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10 (Asignamos el filtro al qdisc) Ordenes básicas en Windows Aunque en Windows prevalezca la configuración desde el entorno gráfico (En Windows 7 las opciones de IPv6 pueden configurarse graficamente), vamos a analizar algunas ordenes básicas en windows Los comandos en windows para IPv6 varían en función de la versión de Windows que usemos. ping: Para IPv6 en Windows XP se utiliza el comando ping6. Sin embargo, en posteriores versiones de Windows, por ejemplo en Windows 7 el comando ping incorpora opciones para IPv4 o IPv6. Veamos un ejemplo: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 55

58 Observamos como existe una opción -6 para forzar el uso de IPv6. Tracert: Ocurre lo mismo. Windows XP incorpora tracert6 mientras que Windows 7 incluye las opciones para IPv6 dentro del mismo comando. Veamos la ayuda en Windows 7: Además, para Windows XP mucha de la documentación existente se refiere al uso del comando IPv6 definido en el ejecutable IPv6.exe. Por ejemplo para instalar IPv6 en XP: Ipv6.exe install Sin embargo, para facilitar la administración y gestión de redes, al igual que ocurre con el comando ip en Linux, Microsoft ha desarrollado un entorno para la configuración de redes englobado dentro del comando netsh (net shell o entorno para redes). Netsh engloba características tanto para IPv4 como para IPv6. Sin embargo, al profundizar en ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 56

59 el estudio de IPv6 podemos de paso aprovechar para generalizar el uso de netsh en lugar de los comandos más utilizados hasta ahora como pueden ser ipconfig, route o netstat. Veamos más en detalle el uso de netsh: Netsh: Netsh es una utilidad de línea de comandos que nos ofrece varias opciones para la configuración de una red. Entre las principales opciones que se pueden realizar, están la posibilidad de ver, modificar, administrar y diagnosticar la configuración de una red. En la línea de comandos podemos escribir los comandos netsh completos o podemos entrar en el entorno de netsh, y el prompt cambiará a: C:\>netsh netsh> Escribiendo, por ejemplo: interface obtenemos netsh interface> y así con todas las opciones, podemos usar.. para subir de nivel. Para obtener ayuda sobre el comando: C:\>netsh /? O estando dentro de netsh: netsh>? netsh>exit Para salir. Algunos Ejemplos DESCRIPCIÓN Guardar la configuración actual de una red Rescatar una configuración guardada Activar Firewall en XP Desactivar Firewall en XP Instalar IPv6 Desinstalar IPv6 COMANDO netsh dump > C:\MiRed.cmp netsh exec C:\MiRed.cmp netsh firewall set opmode enable netsh firewall set opmode disable netsh interface ipv6 install netsh interface ipv6 uninstall ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 57

60 Restablecer configuraciones de IPv4 Reinicia las interfaces IPv6 Restablecer configuraciones de IPv6 Mostrar las direcciones IPv6 Agregar una dirección IPv6 netsh interface ipv4 reset netsh interface ipv6 renew netsh interface ipv6 reset netsh interface ipv6 show address netsh interface ipv6 add address direcciónipv6 Observamos como a continuación de netsh interface, somos nosotros los que podemos determinar si lo que nos interesa es actuar sobre direcciones ipv4 o ipv6. Las opciones de netsh son muchas. Veamos por ejemplo la ayuda que obtenemos en Windows7: Por ejemplo para la configuración relativa a interfaces, escribimos: netsh interface o netsh in en su formato abreviado. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 58

61 Y observamos las opciones que podríamos ejecutar. Veamos algunos para IPv6: DESCRIPCIÓN Muestra todas las interfaces IPv6 y su estado Muestra las rutas definidas Muestra entradas en cache de vecinos Muestra el estado del tunel Teredo Muestra el estado de 6to4 COMANDO netsh in ipv6 show interface netsh in ipv6 show routes netsh in ipv6 show neighbors netsh in ipv6 show teredo netsh in ipv6 6to4 show state ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 59

62 2.5. Pruebas de conectividad en LAN (ping6) Para completar el análisis práctico de la configuración stateless estudiada en la teoría vamos a analizar el comportamiento en una red de área local o LAN sin Router: El esquema de la configuración a analizar es el siguiente: Como hemos visto anteriormente los sistemas operativos actuales mantienen la configuración IPv4 e IPv6. En caso de ausencia de un servidor o router la configuración IPv6 se realiza de forma automática. Conectamos los ordenadores en red utilizando un Switch IPv4 del fabricante D- Link, es obvio indicar que podríamos utilizar cualquier otro que dispongamos. Esto es debido a que los sistemas operativos actuales mantienen una pila dual IPv4/IPv6, que permite al sistema operativo el uso y la coordinación de ambos tipos de direcciones. Vamos a observar que ocurre si hacemos ping utilizando las direcciones IPv6 entre todos los ordenadores. Desde el Host con Windows XP a Windows 7: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 60

63 Parece que no puede hacer ping, pero este error no debe llevarnos a engaño. La configuración es correcta. No responde al ping porque por defecto Windows 7 incorpora un Firewall que por defecto no responde a los ping realizados desde otro Host, en este caso el nuestro. Vamos al Host con Windows 7 y desactivamos el firewall o agregamos una regla que permite responder al ping. Probamos de nuevo: Responde satisfactoriamente. Desde el Host con Windows XP a Ubuntu-Linux: También responde satisfactoriamente. Desde el Host con Ubuntu-Linux a Windows XP: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 61

64 La respuesta es satisfactoria. Desde el Host con Ubuntu-Linux a Windows 7: Sin problemas. Desde el Host con Windows 7 a Windows XP: En este caso utilizamos la opción -6 que permite al comando ping (en Windows 7) forzar el uso de IPv6. Desde el Host con Windows 7 a Ubuntu-Linux: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 62

65 La configuración automática funciona correctamente. El control dual que ejercen los sistemas operativos, permite el uso de ambos protocolos sobre una red local (LAN) creada usando un switch IPv4. En nuestro caso el switch es un modelo D-Link DES- 3526, pero podría valer cualquier otro switch del que se disponga. Un aspecto muy importante a tener en cuenta en IPv6 es que las direcciones locales de enlace, es decir todas las que comienzan por FE80:: no son enrutables fuera de nuestra red de área local. Por ello, como veremos más adelante, las tarjetas de red pueden tener más de una dirección. En el caso de querer poder acceder a una interfaz concreta desde dentro y también desde fuera de nuestra red local, deberá configurarse una segunda dirección. Para ello puede utilizarse un router y/o un servidor o puede añadirse una dirección manualmente utilizando comandos del sistema operativo como veremos posteriormente. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 63

66 3. Configuración avanzada. Hasta aquí hemos tratado cuestiones generales sobre IPv6, tanto desde el punto de visto del protocolo en si, como desde el punto de vista de distintos sistemas operativos. A continuación nos centraremos en aspectos más avanzados de la configuración de IPv6. Empezaremos analizando el protocolo ICMPv6, que sustituye al ICMP de IPv4. Este protocolo, que para los nos iniciados puede ser desconocido, proporciona una de las herramientas más populares en el mundo del networking: el comando ping. Analizaremos cuáles son los mensajes que se intercambian los ordenadores al hacer uso de ICMPv6 para pasar, a continuación, a analizar las opciones de autoconfiguración que nos ofrece IPv6. Dentro de la autoconfiguración tenemos dos variantes, la llamada Stateless y la que se basa en DHCPv6 (sustituto del DHCP de IPv4) que hasta septiembre de 2007 (momento en que apareció la RFC 4861) era denominada configuración Stateful. La autoconfiguración es una característica que, en breve, puede convertirse en una de las más importantes de IPv6, ya que permite que cualquier equipo disponga de una dirección IPv6 con la que poder comunicarse con su entorno de red, y sin necesidad de tener que hacer ningún tipo de configuración manual. Si tenemos en cuenta las predicciones, con televisores, frigoríficos, consolas, móviles... con capacidad de conexión, no cabe duda de que la autoconfiguración de IPv6 va a facilitar bastante la vida tanto a los usuarios como a los administradores de red ICMPv6. Todo el mundo conoce el comando ping y su uso para comprobar si hay conectividad entre dos equipos. Lo que no suele resultar tan familiar es el protocolo que está detrás del ping, esto es, el ICMP (Internet Control Message Protocol). Dicho protocolo, ya en su versión de IPv4, proporciona información importante sobre la salud de la red por medio de mensajes. La versión de ICMP utilizada en IPv6 se llama, como no podía ser de otro modo, ICMPv6. Aunque los dos protocolos tienen un nombre parecido y comparten su filosofía de funcionamiento, hay que tener en cuenta que son incompatibles entre si debido a la estructura de las datos empleados. ICMPv6 es mucho más potente que la versión anterior ya que se han integrado en el mismo funcionalidades que se lograban en ICMPv4 usando otros protocolos. Por ejemplo: IGMP (Internet Group Management Protocol) para gestión de miembros de los grupos multicast. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 64

67 ARP/RARP (Address Resolution Protocol / Reverse ARP) para mapear direcciones MAC con direcciones IP y viceversa. También se ha añadido la función Neighbor Discovery, para descubrir las direcciones de los host vecinos (conectados en el mismo enlace), routers, etc. El número de mensajes disponibles es mayor en ICMPv6 que en ICMP (de ahí también la incompatibilidad). El protocolo ICMPv6 está definido en la RFC 4443 y Neighbor Discovery lo está en la RFC A continuación se analizará la estructura de los mensajes y el contenido de algunos de los más utilizados. Después se analizarán las nuevas prestaciones ofrecidas por ICMPv6, como el Neighbor Discovery, la Autoconfiguración y otras Los mensajes Una de las cosas que hace ICMPv6 es definir una serie de mensajes de error que pueden ser utilizados por los nodos de la red para informar de situaciones en las que hay problemas en la transmisión. El mensaje lo emite el equipo que detecta el problema y es enviado al equipo origen del paquete problemático. Por ejemplo, si un router no puede enviar un paquete porque es demasiado largo, enviará un mensaje ICMP al host de origen indicándoselo. El host de origen interpretará el mensaje ICMP para elegir un tamaño más adecuado y reenviar los datos. Además de esto, también hay mensajes definidos para valorar el estado de la red. Aquí es donde aparecen los mensajes "Echo Request" y "Echo Reply", que son utilizados por el famoso ping. Por cierto, en ICMPv6 el nombre del comando ping también cambia en algunos sistemas operativos, pasando a denominarse ping6. En otros casos seguiremos utilizando el ping de siempre junto con un atributo que nos permite elegir el modo IPv Formato de los mensajes Al hablar de las cabeceras IPv6 y de las cabeceras de extensión se mencionó el campo Next Header. Las cabeceras ICMPv6 se identifican por un Next Header = 58. Respecto a los mensajes de ICMPv6, hay dos tipos: Mensajes de error. Mensajes informativos. El formato es el siguiente: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 65

68 El bit más significativo del campo TIPO es el que determina el tipo del mensaje. Los mensajes de error siempre empiezan por 0 y los informativos por 1. Por ello, los mensajes de error tienen un tipo comprendido entre 0 y 127 y los informativos están entre 128 y 255. El listado de los códigos asociados a los mensajes se puede encontrar en esta direción de la IANA: El siguiente campo es el de CÓDIGO, que da información adicional acerca del TIPO del mensaje. Este campo se utiliza siempre con mensajes de error. Entre los mensajes informativos, el único que lo utiliza es el 138 (Router Renumbering) Por ejemplo, si TIPO = 1 = Destination Unreachable (Destino inalcanzable), el CÓDIGO puede tomar, entre otros, estos valores: 0 No hay ruta hasta el destino. 1 Comunicación con el destino prohibida por el administrador. 3 Dirección inalcanzable. 4 Puerto inalcanzable. El campo CHECKSUM permite detectar errores en la transmisión de datos. Por último, el campo CUERPO. Éste varía en función del tipo y código del mensaje. En caso de que se trate de un mensaje de error, el CUERPO contendrá una copia lo más completa posible del paquete problemático, que podrá utilizarse en origen para buscar una solución al problema planteado. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 66

69 Mensajes de error La cabecera de los mensajes ICMP sufre ligeras variaciones en función del tipo de error o de la información que transporta. Estos cambios se localizan en el campo CUERPO comentado en el punto anterior. A continuación se comentan algunos mensajes de error: DESTINO INALCANZABLE (Destination Unreachable) TIPO = 1 Este mensaje es generado cuando no es posible entregar un datagrama IP. El CÓDIGO indica el motivo por el que no se ha podido hacer la entrega. Después del checksum, se dejan 4 bytes a cero y a continuación se copia el mensaje original. Si el destino es inalcanzable debido a congestión, no se generan mensajes ICMP. PAQUETE DEMASIADO GRANDE (Packet To Big) TIPO = 2 El MTU = Maximum Transmission Unit es el tamaño de paquete más grande que puede manejar un enlace. En caso de que un router no pueda enviar un paquete porque es más grande que el MTU permitido, generará un mensaje Packet To Big que será enviado a la dirección fuente del paquete. En este caso TIPO = 2 y CODIGO = 0. En el CUERPO se utilizan los 4 primeros bytes para indicar el MTU válido. TIEMPO AGOTADO (Time Exceeded) TIPO = 3 Cuando un router envía un paquete, decrementa siempre su HOP LIMIT en 1. El HOP LIMIT evita que un paquete pueda viajar indefinidamente a través de la red. Si un router recibe un paquete con hop limit = 1 y lo decrementa poniéndolo a 0, descartará el paquete y generará un mensaje de Time Exceeded que será enviado al host del origen. En este caso, el campo CÓDIGO = 0. Ya en el CUERPO, los primeros 4 bytes se mantienen a cero y después se copia el mensaje original. Este error puede ser indicativo de un bucle en el enrutado o de que el hop limit establecido por el emisor es demasiado bajo. Una aplicación práctica: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 67

70 El CÓDIGO = 0 indica mensaje Hop limit exceeded in transit. Este mensaje se utiliza en el comando Traceroute, que determina el camino o path que sigue un paquete cuando viaja por la red. Cómo lo hace? Se envía un primer paquete con hop limit = 1. El primer router en el path decrementa el hop limit poniéndolo a cero, descarta el paquete y envía de vuelta un mensaje ICMP con TIPO = 3 y CÓDIGO = 0. El host origen sabe ahora la dirección IP del primer router de salto. A continuación envía un segundo paquete con hop limit = 2. Este paquete es reenviado por el primero router, que pone hop limit = 1. El segundo router decrementa el hop limit poniéndolo a cero, lo descarta y envía el correspondiente mensaje ICMP con TIPO = 3 y CÓDIGO = 0. Ahora el host origen tiene identificado al segundo router del path. El proceso continua incrementando en uno el hop limit con cada paquete enviado y termina cuando se alcanza el destino final. En caso de que haya varios caminos hasta el destino, traceroute no tiene por qué dar siempre los mismos resultados. PROBLEMA CON PARAMETROS (Parameter Problem) TIPO = 4 Si un nodo IPv6 no puede completar el procesamiento de un paquete porque tiene algun problema para identificar un campo en la cabecera IPv6 o en una cabecera de Extensión, debe descartar el paquete y devolver el mensaje ICMP Parameter Problem Este es el mensaje que se suele utilizar cuando el error que se produce no se ajusta a ninguno de los anteriores. En el CUERPO, los 4 primeros bytes actúan como puntero, señalando el punto del paquete donde se ha detectado la irregularidad. También se envía de vuelta la mayor porción posible del paquete original Mensajes informativos Los mensajes informativos definidos en la RFC 4443 son Solicitud de eco (Echo Request) y Respuesta de eco (Echo Reply). También se usan mensajes ICMP informativos para implementar Path MTU Discovery y Neighbor Discovery, pero éstos están definidos en otras RFCs (concretamente en la 4861 y en la 1981). Los mensajes de Solicitud y Respuesta de Eco son utilizados en una de las utilidades TCP/IP más populares: Packet Internet Groper (ping). Ping se usa para determinar si un host está disponible en la red y está listo para comunicarse. El host de origen pone en circulación un mensaje Echo Request dirigido al destino. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 68

71 El host destino, si está disponible, responde con un mensaje Echo Reply. MENSAJE DE SOLICITUD DE ECO (Echo Request message) TIPO = 128 El campo TIPO = 128 y el CÓDIGO = 0. En el CUERPO, los dos primeros bytes se utilizan como Identificador y los dos siguientes como Número de secuencia. A continuación se insertan cero o más bytes arbitrarios para completar el paquete. Estos dos campos se usan para emparejar las solicitudes con las respuestas. La respuesta debe contener siempre los mismos números que la solicitud. El que se utilice un identificador y un número de secuencia y el tipo de datos arbitrarios que se incluyen en la solicitud depende de la pila TCP/IP que se esté utilizando Captura de mensajes Algunos de los puntos vistos hasta aquí se pueden ver con una simple captura de paquetes en un sniffer. En la imagen se muestran la captura mediante Wireshark de un ping6 lanzado desde un portatil (con sistema operativo GNU/Linux UBUNTU) a un conmutador IPv6 al que está conectado. Como se puede ver en la consola de la parte derecha, el comando ejecutado es: ping6 -I eth0 -c 1 FE80::221:91FF:FEAA:BE00 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 69

72 El -I (es una i latina mayúscula) es para indicar el nombre de la interfaz que se utilizará en el ping. El -c es para indicar el número de pings que se deben realizar. En este caso, con uno es suficiente. FE80::221:91FF:FEAA:BE00 es la dirección del equipo cuya conectividad se quiere probar Como se puede ver en la cabecera IPv6, Next Header = 0x3a = 58, que es el valor indicado anteriormente como asignado a ICMPv6. También se pueden ver las direcciones de origen y destino, que son ambas del tipo de enlace local, porque empiezan por 0xFE80. Si nos fijamos ya en la cabecera ICMPv6, el primer campo indica Type = 128, que es el código del mensaje Echo Request. El ID (= Identificador) es 0x2c20 y el número de secuencia es 0x0001 Después van los 54 bytes de datos arbitrarios. Con solo mirar el campo de los datos arbitrarios podemos saber si el equipo que ha hecho ping es Windows o no, ya que estos equipos utilizan como datos el alfabeto entre las letras a y w. Ya en la respuesta, vemos que en la cabecera IPv6 se mantiene el campo Next Header con el 0x3a = 58 de ICMPv6 y que las direcciones de origen y destino se han intercambiado. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 70

73 En la cabecera ICMPv6, el Type = 129 indica que es la respuesta de eco (Echo Reply). Los campos ID, Secuence y Data son una copia de los enviados en la Solicitud de Eco Neighbor Discovery El Neighbor Discovery o Descubrimiento de Vecinos está definido en la RFC 4861 Neighbor Discovery for IP version 6 (IPv6) (antes RFC 2461). El Neighbor Discovery Protocol (NDP) se usa tanto en hosts como en routers. Algunos de los usos del NDP son los siguientes: Neighbor Discovery (ND) = el descubrimiento de vecinos propiamente dicho. Autoconfiguración de direcciones IPv6. Determinación de prefijos de red (se acabó el tener que configurar a mano las máscaras de subred), rutas... Detección de IPs duplicadas (DAD = Duplicate Address Detection). Búsqueda de las MACs de los vecinos y detección de cambios en las mismas. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 71

74 Router Discovery (RD) = Búsqueda de routers vecinos que puedan darnos servicio. Llevar el control de qué vecinos están disponibles y cuáles no lo están (NUD = Neigbor Unreachability Detection). El protocolo ND consta de 5 mensajes ICMP que serán tratados en las siguientes secciones: Router Solicitation. Router Advertisement. Neighbor Solicitation. Neighbor Advertisement. ICMP Redirect Router Solicitation y Router Advertisement Estos son los mensajes de "Solicitud de Router" y de "Anuncio de Router". Veamos cuándo se utilizan. Los routers envían regularmente mensajes del tipo "Router Advertisement" para anunciar su presencia. A su vez, los hosts pueden solicitar mensajes de Router Advertisement poniendo en circulación mensajes de Router Solicitation, que hacen que el router que lo recibe responda inmediatamente con un Router Advertisement, aunque no le tocara enviarlo todavía. En la cabecera IP del mensaje Router Solicitation se pone como dirección destino la dirección multicast all-routers, es decir, la FF02::2. El límite de saltos se pone a 255. Ya en el mensaje ICMP, el TIPO = 133. El CODE es 0 y los 4 primeros bytes después del CHECKSUM también. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 72

75 En el campo de Opciones se envía la dirección MAC del solicitante en caso de que su dirección IP sea conocida. Si el campo Dirección de Origen de la cabecera IP es la dirección No-Especificada (all-zeros), el campo opciones no se usa. Los routers que reciben el mensaje Router Solicitation, ponen en circulación un mensaje Router Advertisement. Como se ha dicho anteriormente, este tipo de paquete se pone en circulación periódicamente. No obstante, puede ocurrir que se reciba una petición directa. Es posible saber si un mensaje Router Advertisement es de los enviados periódicamente o es la respuesta a un mensaje Router Solicitation? La respuesta es SI. Se puede saber mirando la cabecera IP asociada al mensaje, y más concretamente, el campo Dirección Destino. En el caso del mensaje periódico, la dirección Destino es la dirección multicast all-nodes, es decir, la FF02::1. En el caso de ser respuesta a una solicitud, la dirección destino será la del host que hizo la petición. Ya en la cabecera ICMPv6, el formato de los mensajes Router Advertisement es el mostrado en la siguiente figura. El campo Current Hop Limit (Límite de Saltos Actual) sirve para informar a los nodos del enlace de cuál es el valor de Hop Limit por defecto con el que se tienen que configurar. Si este valor fuera 0, no estaría definido un Hop Limit por defecto y se utilizaría el valor que tenga asignado por defecto el nodo transmisor. El siguiente campo es de 1 bit, el flag M (de Managed address configuration). Cuando está a 1 indica que las direcciones están disponibles vía DHCPv6. Esto es lo ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 73

76 que se llamaba configuración Stateful, pero ese término dejó de utilizarse cuando la RFC 4861 dejó obsoleta a la RFC 2461 (Sept. 2007). Si M = 0, los nodos del link utilizarán la autoconfiguración Stateless (configuración de dirección autónoma). Cuando el flag M está activado, el siguiente flag, O, es redundante y se puede ignorar porque DCHPv6 dará toda la información disponible para realizar la configuración. A continuación va el flag O (de Other Configuration). A 1 indica que hay otra información disponible vía DHCPv6. Por ejemplo información relativa a DNS o de otros servidores dentro de la red. Los 6 bits siguientes que completan este byte van a cero. Los 2 bytes siguientes son el campo Router Lifetime. Este campo solo es importante si el router se va a usado como router por defecto por los nodos del enlace. Si el campo es cero, el router no es el utilizado por defecto. Cualquier otro valor indica, en segundos, el tiempo que el router será considerado el router por defecto. El mayor tiempo que se puede poner con 16 bits es de segundos, lo que equivale a 18,2 horas. El campo Reachable Time (Tiempo alcanzable) indica el tiempo (en ms) que un host va a suponer que los vecinos están al alcance después de haber recibido una confirmación de accesilidad. Un valor de 0 indica que no se especifica. El algoritmo NUD (Neighbor Unreachability Detection) usa este campo. El campo Retrans Timer (Tiempo de Retransmisión) indica el tiempo (en ms) entre retransmisiones de mensajes Neighbor Solicitation. Se utiliza en la resolución de dirección y en los mecanismos de NUD. Si se pone a cero indica que ese router no está configurado con el temporizador de retransmisión. Para el campo Opciones hay tres posibles valores: Dirección de la capa de enlace de la fuente. Tamaño de MTU a utilizar en enlaces donde este parámetro es variable (por ejempo, Token Ring). Información de prefijo. Esta información es importante para la autoconfiguración Stateless. El router inserta todos sus prefijos de enlace que tienen que ser conocidos por los nodos del link Neighbor Solicitation y Neighbor Advertisement Estos dos mensajes cumplen dos funciones: La resolución de direcciones físicas de la que se encargaba ARP en IPv4 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 74

77 El mecanismo de detección de vecinos no alcanzables (Neighbor Unreachability Detection). Si la dirección de destino es una dirección multicast (normalmente la dirección multicast de nodo solicitado ), el host de origen está resolviendo una dirección de la capa de enlace. Si el host de origen está verificando la disponibilidad de un vecino, la dirección de destino será una dirección unicast. Este tipo de mensaje se utiliza también en DAD (Duplicate IP Address Detection). En la cabecera IP de este tipo de mensaje, la Source address puede ser tanto la de la interfaz del host origen como la dirección no especificada (all-zeros). Esto último en caso de autoconfiguración Stateless y DAD. El formato de la cabecera ICMP es el indicado en la figura: El Tipo = 135, Código = 0 y los 4 bytes que van después del Checksum no se usan y se ponen a cero. El campo Dirección Target (= Objetivo) se usa en Neighbor Advertisement y en redireccionamiento de mensajes. Aquí no debe usarse una dirección multicast. El campo Opciones puede contener la dirección MAC del origen, pero solo si no se hace el envío desde la dirección all-zeros. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 75

78 Durante la autoconfiguración Stateless, en un mensaje que usa la dirección no especificada como dirección Source, el campo Opciones se pone a cero. La opción de la capa de enlace se debe utilizar en solicitudes multicast (detección de dirección de capa de enlace) y puede ser usada en solicitudes unicast (Unreachability Detection = Detección de inalcanzabilidad) Los mensajes Neighbor Advertisement o Anuncio de vecino se envían como respuesta a mensajes Neighbor Solicitation o para propagar información rápidamente. El formato del mensaje es el siguiente: Se puede saber si el mensaje es la respuesta a una solicitud o si se envía voluntariamente, mirando el tipo de dirección utilizado en la cabecera IP. En el primer caso, el mensaje irá dirigido al host que hizo la solicitud, por lo tanto, la dirección IP destino será la suya. En caso de que el mensaje sea una respuesta a un mensaje DAD (Duplicate IP Address Detection) originado desde un host desconocido, la respuesta irá dirigida a la dirección multicast all-nodes, esto es, a la FF02::1. Lo mismo ocurre para los envíos periódicos no solicitados. Como se puede ver en la figura anterior, ya en la cabecera ICMP, Tipo = 136, Código = 0 y después del Checksum tenemos unos flags. El primero R = Router flag puesto a 1, indica que el equipo origen es un router. El siguiente es el Solicited flag = S. A 1 indica que el mensaje es una respuesta a un Neighbor Solicitation. Este flag no se usa en anuncios multicast. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 76

79 Por último el flag de Override = O. Indica que la información enviada en el mensaje de Advertisement debería anular las entradas de la Neighbor Cache y actualizar cualquier dirección de enlace cacheada. Si este bit está a cero, el mensaje no actualizará una dirección que ya esté en la caché, pero puede actualizar una entrada de una Neighbor Cache que no tenía la información de la dirección. Este bit no se debe utilizar en anuncios dirigidos a direcciones anycast. En anuncios solicitados, la Dirección Objetivo (Target Address) contiene la dirección de la interfaz que envía la solicitud. En los no solicitados, contiene la dirección de la interfaz. En los anuncios no solicitados, este campo contiene la dirección de la interfaz cuya dirección de la capa de enlace ha cambiado. Una posible opción para el campo de Opciones es la dirección destino de la capa de enlace Otros usos del protocolo Neighbor Discovery El mensaje de Redirección ICMP Son los mensajes de Tipo = 137 Este es un mensaje que los routers ponen en circulación para informar a un nodo de cuál es el mejor primer salto para llegar a un destino determinado. Este tipo de mensaje también puede informar a un nodo de que el destino solicitado es realmente un vecino, y no un nodo en otra subred. Inverse Neighbor Discovery (IND) (RFC 3122) O lo que es lo mismo, Descubrimiento Inverso de Vecinos. IND es el equivalente al RARP (Reverse ARP) de IPv4. Es decir, el protocolo que a partir de una dirección MAC de un equipo es capaz de resolver cuál es su dirección IP. IND utiliza dos tipos de mensajes: IND Solicitation (Tipo = 141), que es enviado por el equipo que quiere hacer la resolución a la dirección multicast all-nodes (FF02::1). IND Advertisement (Tipo = 142), que es enviado por el equipo objetivo y que contiene las direcciones de dicho equipo. Resolución de direcciones de capa de enlace. Equivale al ARP de IPv4, es decir, permite determinar la MAC de un equipo a partir de su IP. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 77

80 Se usa solo con nodos vecinos y se lleva a cabo enviando un mensaje Neighbor Solicitation dirigido a la dirección multicast de nodo solicitado del vecino en cuestión. Si dicho equipo es alcanzable, responderá enviando al equipo solicitante un mensaje Neighbor Advertisement. Neighbor Unreachability Detection (NUD) Se puede traducir como Detección de disponibilidad de vecino Se considera que un equipo está al alcance si hay alguna prueba de que la comunicación con el mismo es posible. Esto ocurre si, por ejemplo, su capa IP está recibiendo los paquetes que se le envían. También puede saberse porque se recibe un mensaje Neighbor Advertisement como respuesta a un Neighbor Solicitation o porque se están recibiendo ACKs de TCP. Para llevar el control de las conexiones activas y alcanzables, Neighbor Discovery usa dos tablas: la caché de vecinos o Neighbor Cache y la de destino o Destination Cache. Neighbor Cache o Es como la Caché ARP de IPv4. o Contiene información de los vecinos con los que se ha intercambiado tráfico recientemente. o La información guardada es la dirección IP unicast, su dirección MAC y un flag que indica si el vecino es un router o un host. o Además tambíen indica si hay algún paquete en espera para ser enviado, si el destino está al alcance y cuando se producirá la siguiente comprobación NUD. Destination Cache o Contiene exactamente la misma información que la Neighbor Cache más la información de los destinos remotos. Es decir, la Neighbor Cache es una parte de la Destination Cache. o Para los destinos remotos, la entrada de la caché contiene la MAC del siguiente router al que saltar. o Esta caché se actualiza con los mensajes de Redirección de ICMPv Otras posibilidades de ICMPv6 Autoconfiguración Esta capacidad ahorrará mucho trabajo a los administradores de red y va a ser una de las características clave de IPv6. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 78

81 Permite que cualquier dispositivo (desde una TV hasta un móvil pasando por frigoríficos, DVDs...) que requiera una dirección IP pueda conseguirla sin necesidad de tener que ser configurado manualmente. Hay dos tipos de autoconfiguración: la stateless y la DHCPv6 (antes llamada stateful ). Para generar su dirección IP, los hosts utilizan una combinación de información local, como su dirección MAC, e información recibida de los routers. Los routers pueden anunciar múltiples prefijos, y los hosts extraen la información del prefijo de esos anuncios. Esto permite la renumeración sencilla de un sitio completo: solo hay que cambiar la información del prefijo en el router. Por ejemplo, si se cambia de ISP y el nuevo ISP asigna un nuevo prefijo IPv6, se pueden configurar los routers para que anuncien el nuevo prefijo, manteniendo el resto de la dirección original. Todos los hosts conectados a esos routers se renumerarán usando el mecanismo de autoconfiguración. Si no hay routers, cada host se puede generar una dirección en enlace local (linklocal address) con el prefijo FE80. La dirección de enlace local es como la dirección que tomaba un nodo en IPv4 cuando no encontraba al servidor DHCP. En ese caso, automáticamente tomaba una dirección de la red /16... y se quedaba aislado del mundo. La gran diferencia en IPv6 es que ahora, esa dirección FE80... es suficiente para la comunicación de todos los nodos conectados al mismo enlace. Las autoconfiguraciones Stateless y DHCPv6 también se pueden combinar. Por ejemplo, un host puede usar autoconfiguración stateless para generar una dirección IPv6 y utilizar después la autoconfiguración DHCPv6 para conseguir los demás parámetros. Llegados a este punto, es interesante saber que las direcciones IPv6 se asignan a los nodos de forma temporal y que existe un intervalo de tiempo definido (lifetime) después del cual la dirección deja de ser válida. Para asegurar que una dirección es única en un enlace se usa el algoritmo DAD (= Duplicate Address Detection RFC 4862). Los estados por los que puede pasar una dirección IPv6 son los siguientes: Tentativa: es el estado de la dirección justo antes de ser asignada, cuando se está aplicando DAD para garantizar que no está en uso. En este estado no es posible la comunicación con el resto de los equipos del enlace, tan solo permite procesar ciertos mensajes ND para autoconfiguración. Preferida: es el estado de la dirección finalmente asignada. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 79

82 Obsoleta (deprecated): es el estado de la dirección cuyo lifetime está a punto de expirar. Una dirección en ese estado se mantendrá en comunicaciones activas con objeto de no interrumpirlas, pero se evitará su uso en nuevas comunicaciones. Válida: son las direcciones que están activas (tanto la preferida como la obsoleta). Inválida: es el estado de una dirección cuya lifetime ha expirado. La dirección deja de estar vinculada a la interfaz del host. Renumeración de red. Este tema se trata en la RFC 4192 "Procedures for Renumbering an IPv6 Network without a Flag Day". El llamado "Flag Day" (Día de la Bandera) es el día clave en el que se va a interrumpir el funcionamiento de la red para realizar una tarea de mantenimiento programada. Para evitar sufrir un "Flag Day" hay que pensar en una estrategia distinta, que permita realizar un cambio progresivo en la configuración sin necesidad de detenerla. Este es el tipo de situación que tiene lugar cuando hay que realizar un cambio en el prefijo de la red, cosa que puede ocurrir, por ejemplo, debido a un cambio de proveedor de Internet. Lo que se permite ICMPv6 es enviar mensajes para informar de cual será el nuevo prefijo a utilizar, pero manteniendo aún el antiguo en funcionamiento. Una vez todos los equipos están enterados del nuevo prefijo se "desactiva" el anterior, de modo que continúan utilizando el nuevo. Se ha modificado la configuración de la red y se ha evitado el flag day. Path MTU Discovery En IPv4, si un router detecta que un paquete es demasiado grande para ser enviado por un enlace determinado, puede fragmentarlo. En IPv6 los routers no se dedican a fragmentar paquetes, dejando esta tarea en mano del host de origen. Antes de nada hay que recordar un par de conceptos. Por un lado, el significado de Link MTU(Maximum Transmission Unit, que es el tamaño máximo de los paquetes que pueden ser manejados en un enlace. Y por otro, el de Path MTU, que es el valor de MTU más grande que se puede utilizar a lo largo de la ruta que siguen los datos desde el origen al destino. Para que no haya problemas en ningún punto, el valor de MTU a utilizar debería ser el más pequeño de los que haya en el path. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 80

83 Como se ha dicho antes, en IPv6, el unico encargado de fragmentar un paquete es el host de origen. Para ello necesita conocer cuál es el menor MTU de todos los que hay en el path. Esta información se obtiene por medio del llamado Path MTU Discovery de ICMPv6. En el proceso de descubrimiento, el primer Path MTU que toma el host origen es el del primer enlace. Cuando un router detecta que ese tamaño es demasiado grande para el siguiente enlace devuelve un mensaje de error ICMPv6: Packet Too Big, que incluirá el MTU válido para el siguiente enlace. Ese será el MTU que usará en lo sucesivo el host origen mientras no reciba un nuevo mensaje de error. El tamaño mínimo de MTU en IPv6 es de 1280 bytes. Puesto que la ruta no es fija, el Path MTU también puede cambiar. En el caso de multicast, se usa el MTU más pequeño de los que hay en los caminos a lo múltiples destinos. Multicast Listener Discovery (MLD) Para empezar veremos algunos detalles del multicast de IPv4: Hay ocasiones en las que interesa el envío simultáneo de paquetes a un grupo de hosts. En este caso el broadcast no es la opción adecuada, porque no se puede enrutar (con lo cual el alcance se limita al enlace local) y además obliga a todos los nodos del enlace a procesar la información. La transmisión multicast posibilita el envío simultáneo de paquetes a un grupo de hosts que están configurados con una dirección multicast de grupo (dirección de clase D). Solo los hosts que son miembros de ese grupo multicast procesarán los paquetes. Además, los mensajes multicast son enrutables y para asegurar que el mensaje solo es propagado a aquellos enlaces en los que hay equipos miembro del grupo multicast, se usa el protocolo IGMP (Internet Group Management Protocol). Ya en IPv6, tenemos que multicast es una característica propia del protocolo y está disponible en todos los nodos IPv6. Como se ha explicado en su momento, el prefijo de las direcciones multicast es FF. En la propia dirección se indica el ámbito de difusión. Así, FF02 denota el ámbito local, FF05 el ámbito del site local y FF0E indica ámbito global. Como se ha comentado más arriba, es necesario un protocolo para limitar el alcance de los paquetes multicast a aquellos enlaces en los que hay equipos miembro del grupo multicast. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 81

84 El IGMP de IPv4, y más concretamente, su 2ª versión (IGMPv2) se implementa en IPv6 por medio de mensajes ICMPv6 y es lo que se llama MLD (Multicast Listener Discovery). Después de una primera versión de MLD se llegó a MLDv2, que está basado en IGMPv3 de IPv4 y que se diferencia de la versión anterior en soportar SSM (Source Specific Multicast). Eso significa que un nodo puede elegir escuchar tan solo los paquetes multicast procedentes de una dirección concreta, o de todas las posibles fuentes excepto de una determinada. Esto es algo que en MLDv1 no es posible por utilizar ASM (Any Source Multicast) en lugar de SSM. Si nos centramos un poco en MLD vemos que este protocolo permite a los oyentes multicast registrar las direcciones multicast que quieren utilizar, con objeto de conseguir un enrutado eficiente. Por otro lado, los routers utilizan MLD para descubrir qué direcciones multicast tienen oyentes en cada uno de los links a los que están conectados. El router mantiene una lista de direcciones con oyentes para cada uno de sus enlaces, pero sin llegar a controlar cuántos oyentes activos hay. Mientras haya algún miembro del grupo en el enlace, la dirección se mantiene. El oyente envía un mensaje al router y éste incluye la dirección multicast es su lista de control. Del mismo modo, un oyente puede darse de baja de un grupo por medio de un mensaje. Cuando el último grupo se da de baja, el router elimina la dirección de ese link de su lista de control. En todos los mensajes MLD se usan direcciones de enlace local como origen y el hop limit = 1. Así se limita el alcance al enlace local. También se usa la opción Hop By Hop y se activa el flag Router Alert para garantizar de que el paquete será procesado por el router aunque no sea miembro del grupo multicast. Multicast Router Discovery (MRD) Es un mecanismo basado en paquetes ICMPv6 que permite el descubrimiento de routers capaces de propagar tráfico multicast. Consta de tres mensajes, dos de los cuales, Multicast Router Advertisement (Tipo = 151) y Multicast Router Termination (Tipo = 153) permiten al router anunciar la activación / desactivación de la difusión multicast. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 82

85 El tercer mensaje, Multicast Router Solicitation (Tipo = 152), permite que cualquier host pueda preguntar a todos los routers (FF02::2) si alguno trabaja con multicast. Al igual que en MLD, todos estos mensajes se envían con Hop Limit = 1 y con la opción Router Alert activa ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 83

86 3.2. Configuración stateless Introducción La configuración automática comienza con la instalación de la dirección de interface de enlace local que se carecteriza por comenzar por FE80. Esta dirección junto con los mensajes de descubrimiento de vecinos ND es la que permite iniciar el proceso de autoconfiguración de direcciones de red públicas Se pueden dar tres tipos de configuración automática: Stateless o sin estado: el host se configura mediante mensajes RA (Anuncio de Router) que incluyen la información necesaria para configurar el enlace Stateful o con estado: utilizan un servidor DHCPv6 de modo similar a la configuración automática utiliza en IPv4. El proceso comienza cuando no hay mensajes RA de ningún router o cuando el host se haya configurado para ello Mixto: mediante mensajes RA configura la IPv6 del host y los datos referentes a las direcciones de los servidores DNS y nombre dominio. En este caso se utiliza una particularidad el servidor DHCPv6 configurado en modo "sin estado", de manera que no da direcciones IPv6 y no controla el estado de los host que se conectan En este apartado veremos la configuración stateless Descripción Autoconfiguración sin estado RFC 4862: Stateless Address Autoconfiguration En la configuración stateless la red se autoconfigura de manera automática. Esta es una característica del protocolo IPv6 que no existía en el protocolo IPv4. Los datos más ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 84

87 importantes a configurar son los mismos que los que se obtendrían de un servidor DHCP con estado : IPv6 global, IP de la puerta de enlace e IP del servidor DNS ipv6 La configuración de direcciones se basa en la recepción de mensajes de anuncio de enrutador RA. Estos mensajes contienen prefijos de direcciones sin estado, así como la IPv6 de la puerta o Gateway. Los prefijos son los que definen la red a crear indicando la parte fija de la dirección IPv6 de los host que formen parte de dicha red. En el proceso de configuración de la red intervienen tanto el router como el host definiendo de forma automática la IPv6 global de cada host perteneciente a la subred que se haya definido. En lo que respecta a la configuración de las direcciones de los servidores DNS, los mensajes RA no incluyen esta información, pero incluyen una indicación de que hay más información disponible en la red para que el host la busque Autoconfiguración de direcciones globales La autoconfiguración a nivel de enlace local ya se ha visto previamente así que en este tema veremos la autoconfiguración de direcciones de enlace global que son las que van a permitir la conexión del host con el resto del mundo Autoconfiguración de la IPv6 Global y la dirección de la puerta de enlace en cada host El funcionamiento del protocolo IPv6 a la hora de crear una red stateless se puede resumir como sigue: El router recibe una configuración (manual o automática) sobre el pool de direcciones IPv6 correspondiente a la subred a configurar, en forma de IPv6 global/máscara de manera que la máscara define la subred a la que pertenece el router. Se define un prefijo para el pool de direcciones de la subred que va a colgar del router en forma IPv6/máscara. Este prefijo debe pertenecer a la subred del router de forma que se cree una jerarquía de direcciones. Los datos configurados en el router se transmiten a todos los host conectados a él se mediante la función RA (Router Advertisment) que se encarga de mandar paquetes a los vecinos con los datos de la configuración de la red. En este paquete se indican principalmente el valor del prefijo que define la red a crear y la dirección local de la puerta de enlace. Para esto se utilizan direcciones multicast, en el caso del los paquetes RA se mandan a la dirección multicast "Todos los nodos del enlace local" (FE02::1) Por otro lado, un host puede solicitar los datos para autoconfiguración mediante el envío de paquetes RS (Router Solicitation) que se envían a la dirección multicast ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 85

88 "Todos los routers del enlace local" (FE02::2), a lo que los routers del enlace local responden con paquetes RA enviados a su dirección local. En la imagen siguiente podemos ver el flujo multicast generado por un host que acaba de conectarse a la red. En este caso se trata de una red donde no se ha activado el envío de paquetes RA, y por tanto intenta encontrar un servidor DHCP Una vez activado el envío de paquetes RA por parte del router, el flujo queda Desde el punto de vista del host podemos ver el estado inicial con las direcciones auto-configuradas durante la instalación del protocolo IPv6 Sin prefijo, la información básica que ofrece el paquete RA es la de anuncio de la dirección de la puerta de enlace Al añadirle el prefijo al paquete RA (en la imagen 2001:5c0:1400:a::/64), la autoconfiguración de la conexión de red en el host crea 2 direcciones IP nuevas, una anónima y otra a partir de algoritmo EUI-64 (termina en 96-A9-0A que son los últimos dígitos de la MAC) ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 86

89 Finalmente tenemos configuradas las direcciones locales y globales así como la de la puerta de enlace y los servidores DNS Obtención de direcciones de autoconfiguración Veamos en este apartado como consigue un host las direcciones IPv6 necesarias para autoconfigurarse Obtención de las direcciones IPv6 globales Mediante autoconfiguración stateless se generan 2 tipos de direcciones globales Mediante algoritmo IEEE EUI-64 El prefijo se añade a las direcciones IPv6 de cada host mediante un algoritmo que combina el prefijo con la MAC de la interface basado en IEEE EUI-64 visto anteriormente para la autoconfiguración de la dirección de enlace local. Esta dirección es pública y fija, ya que siempre es la misma para un mismo prefijo, por lo que puede dar problemas de seguridad al poder ser rastreada fácilmente Direcciones anónimas Para resolver el problema anterior se genera otra dirección global. Esta dirección se puede obtener mediante un algoritmo hash que utiliza MD5 (Mesage Digest 5) o aleatoriamente, dependiendo de que el protocolo IPv6 implementado memorice las direcciones generadas previamente o no Obtención de la IP del servidor DNS y del nombre del dominio En los mensajes RA sólo se envían los parámetros de prefijos de red y la IPv6 de la puerta de enlace así que hay recurrir a otros sistemas para obtener el resto de la configuración. En Windows XP, p.ej, durante el proceso de autoconfiguración stateless, al instalar el protocolo IPv6 se instalan automáticamente 3 direcciones IPv6 para servidores DNS, que utilizan como interface el de bucle invertido (looback). ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 87

90 FEC0:0:0:0:FFFF::1,FEC0:0:0:0:FFFF::2 y FEC0:0:0:0:FFFF::3 En el caso de utilizar una autoconfiguración mixta, el mensaje RA incluye una indicación (flag O) de que hay más información disponible aparte de la enviada en el mensaje y el host busca un servidor DNS utilizando para ello el servidor DHCPv6 en "modo sin estado" que le da las direcciones así como el resto de información que pueda necesitar. Como ejemplo podemos ver la pantalla de configuración del servidor DHCPv6 de Windows Server 2008 con la opción de configuración "Modo sin estado DHCPv6". Al activar esta opción nos pide que introduzcamos las direcciones de los servidores DNS Algoritmos de generación de direcciones globales En modo stateless las direcciones se generan a partir de un prefijo común a todos los host de la misma red y un sufijo generado por el propio host bien mediante algún algoritmo o bien de forma aleatoria Creación de la Dirección Global de Unicast: basado en IEEE EUI-64 El procedimiento es el mismo que el utilizado para crear la dirección de enlace local, con alguna modificaciones: 1. Partimos de la dirección IPv6 ponemos al final los 48 bits de la MAC de la interface ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 88

91 2. Ponemos el séptimo bit, el bit U/L (universal/local) a 1, que indica una dirección administrada de forma remota 3. Insertamos FFFE en medio de la MAC (bit 24 o Byte3º). El nº de 64 bits obtenido se denomina Identificador de Interface 4. En la dirección IPv6 ponemos al final los 64 bits del Identificador de Interface 5. Cuando recibe el prefijo, este se coloca al inicio de la dirección y el resto se rellena con ceros Por ejemplo: MAC: 00-0C-6E-6B-EB-0A Prefijo: 2000::/3 El proceso sería C-6E-6B-EB-0A C-6E-6B-EB-0A C-6E-6B-EB-0A C-6E-FF-FE-6B-EB-0A ::20C:6EFF:FE6B:EB0A Creación de la Dirección Global de Unicast: basado en algoritmo hash El protocolo IPv6 implementado debe memorizar en un historial las direcciones generadas previamente. La primera dirección se genera aleatoriamente. Cuando transcurre el tiempo de caducidad, se inicia el proceso de generación de dirección anónima mediante el algoritmo siguiente: 1. Se recupera el valor de historial almacenado y se anexa el identificador de interfaz basado en la dirección EUI-64 del adaptador. 2. Se calcula el algoritmo hash de cifrado unidireccional MD5 (Message Digest-5) con la cantidad del paso Se memorizan los últimos 64 bits del algoritmo hash MD5 calculado en el paso anterior como valor de historial para el siguiente cálculo de dirección anónima. 4. Se toman los primeros 64 bits del algoritmo hash MD5 calculado en el paso 2 y se pone el séptimo bit (U/L) a 0, que indica una dirección administrada de forma local. El resultado es el identificador de interfaz. Este proceso se repite continuamente cada cierto tiempo. Los tiempos pueden ser configurados Router IPv6 El router adquiere una gran importancia en la configuración stateless ya que es el que distribuye la información de autoconfiguración al resto de los host. Hay que decir que no son compatibles con los router IPv4 ya que deben poder leer los paquetes IPv6 y manejar el protocolo ICMPv6. En la práctica actualmente utilizan protocolos IPv6 de pila dual, lo que viene a significar que pueden trabajar tanto en IPv4 como en IPv6 y a ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 89

92 menudo recurren a túneles para pasar de una red a otra. Algunas de las principales características de un router IPv6 son: Manejo de direcciones IPv6 unicast, multicast y anycast Procesado de paquetes IPv6 y de cabeceras de extensión Descubrimiento de Vecinos (ND) IPv6 Envío de mensajes de Aviso de Router (RA) ICMPv Configuración del router para stateless Para que el router IPv6 pueda iniciar el proceso de autoconfiguración stateless debemos configurar Mensaje RA En los mensajes RA ajustaremos los flags y los tiempos del paquete 1. RA Managed flag: este flag indica si la autoconfiguración va ser stateless (mediante los mensajes RA del router) o si va a ser stateful (mediante un servidor DHCPv6) 2. RA Other flag: mediante este flag se indica a los host que además de las direcciones generadas mediante los paquetes RA (stateless) en la red hay disponible más información, como por ejemplo, las direcciones de los servidores DNS (que serán proporcionadas por el DHCPv6 en modo sin estado) 3. Temporizaciones: Retransmisión time, Life time y Reachable time Como ejemplo de parámetros a configurar se indican los solicitados por el switch L3 DGS-3627 RA Router Advertisement Utilice este menú desplegable para activar o desactivar que el switch sea capaz de aceptar solicitud de un vecino (ND), y así convertirse en un vecino de IPv6. Una vez activada, este switch es capaz de producir mensajes de anuncio de enrutador (RA) para ser devueltos a consulta de vecinos(rs) RA Router Life Time (s) RA Reachable Time Esta tiempo representa la validez de que esta interfaz sea el router por defecto para el enlace local de red. Un valor de 0 representa que este switch no debe ser reconocido como el router predeterminado para este enlace de red local. El usuario puede establecer un tiempo de entre 0 y segundos con una configuración predeterminada de 1800 segundos. Este campo establece el tiempo en que un nodo IPv6 remoto se considera alcanzable. En esencia, este es el campo Detección de Vecino Inalcanzable una vez que la confirmación del acceso a esta nodo se ha hecho. El usuario puede establecer un tiempo de entre 0 y milisegundos con de una configuración predeterminada de milisegundos. Un valor muy bajo, no ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 90

93 RA Retransmit Time (ms) RA Managed Flag RA Other Configure Flag RA Max Router AdvInterval (s) RA Min Router AdvInterval (s) se recomienda. Se utiliza para ajustar un tiempo de intervalo entre 0 y milisegundos para el envío de anuncios de enrutador (RA) en esta interfaz en el enlace de red local, en respuesta a una Mensaje de Solicitación de Vecino (RS). Este valor no debe exceder el valor indicado en el campo el tiempo de vida se ha mencionado anteriormente. Establecer este campo a cero, se especifica que este cambio no se especifica el tiempo de retransmisión para el enlace de red local. (y por lo tanto se especificarán por otro router en la linklocal red. El valor predeterminado es 0 milisegundos. Utilice el menú desplegable para activar o desactivar la bandera administrado. Cuando se activa, el mensaje RA indica que hay que utilizar un proceso de configuración automática con estado para obtener Direcciones IPv6 tanto a nivel global como local. El valor predeterminado es Desactivado. Sería la configuración statefull Use el menú desplegable para activar o desactivar el flag configurar otras. Cuando se activa, el mensaje RA indica que hay que utilizar un proceso de configuración automática con estado para obtener la información de configuración que no es la dirección IP pero que, sin embargo, es importante para la configuración de IPv6, como p.e los direcciones de los servidores DNS. El valor predeterminado es Desactivado. Sería la configuración mixta Se utiliza para establecer el intervalo de tiempo máximo entre el envío de anuncios de enrutador (RA) por esta interfaz a través del vínculo de red local. Esta entrada debe ser no menos de 4 segundos (4000 milisegundos) y no más de 1800 segundos. El usuario puede configurar un tiempo de entre 4 y 1800 segundos, con un valor predeterminado de 600 segundos. Se utiliza para establecer el intervalo de tiempo mínimo entre el envío de anuncios de enrutador (RA) por esta interfaz a través del vínculo de red local. Esta entrada debe ser no menos de 3 segundos y no más de 0 75 (3 / 4) de la MaxRtrAdvInterval. El usuario puede configurar un tiempo entre 3 y 1350 segundos, con un valor predeterminado de 198 segundos. Configuración de RA La siguiente imagen corresponde a una captura realizada con Wireshark del envío de un mensaje RA (Type 134) donde se ven los flags Managed y Other desactivados y demás datos de temporización. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 91

94 Prefijo En este apartado configuraremos la información a enviar en el mensaje RA: el propio prefijo, los flag correspondientes y los tiempos 1. Prefijo: en forma de IPv6/máscara, será el valor a enviar en los mensajes RA y el que utilizarán los host que se vayan a autoconfigurar. Se pueden configurar varios prefijos 2. On Link flag: si está activo indica que el prefijo a utilizar en la autoconfiguración de la red local es el correspondiente a esta interface (el router puede tener más interfaces) 3. Autonomous flag: indica que el prefijo configurado puede ser utilizado para autoconfiguración de la red local 4. Temporizaciones: Valid life time y Preferred life time Como ejemplo de parámetros a configurar se indican los solicitados por el switch DGS-3627 Prefix Prefered Life Time Valid Life Time Flag On-link Utilice este campo para configurar cada uno de los prefijo para direcciones IPv6 Global Unicast que se asignarán a los otros nodos en el enlace de red local. Estos prefijos se enviarán en el mensaje de anuncio de enrutador RA para ser compartido en el enlace de red local. El usuario debe primero tener al menos una Dirección Global Unicast para el switch de la que se obtiene el prefijo. Este campo establece el tiempo durante el que este prefijo se anuncia como preferido en el vínculo local de la red, utilizando la configuración de direcciones sin estado. El usuario puede configurar un tiempo de de entre 0 y milisegundos, con un valor predeterminado de milisegundos. Este campo establece el tiempo que este prefijo se anuncia como válido en el enlace de red local, cuando se utiliza la configuración de direcciones sin estado. El usuario puede configurar un tiempo de entre 0 y milisegundos. Habilitando esta opción se indica, en el paquete IPv6, que el prefijo IPv6 configurado aquí se asigna a este vínculo de red local. Una vez que el tráfico ha sido enviado a estos nodos con este prefijo IPv6 específico, los nodos se considerarán accesibles en el enlace de red local. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 92

95 Flag Autónomo Habilitando este campo se indica que este prefijo puede ser usado para autoconfigurar direcciones IPv6 en el enlace de red local. Configuración del prefijo En la siguiente imagen podemos ver una captura realizada con Wireshark del envío de un mensaje RA con un prefijo de 64 bits de longitud, con los flags Onlink y Auto activados y demás datos de temporización. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 93

96 3.3. DHCPv6. Vamos a probar la configuración de direcciones IPv6 usando DHCPv6 para el siguiente esquema de una LAN: La LAN estará formada por: Un ordenador Ubuntu-Linux (9.10). Un ordenador Windows XP (SP3). Un ordenador Windows 7. Un servidor DHCPv6. (Analizaremos Ubuntu-Server 9.10 y Windows 2008 Server). Un switch compatible IPv6. En nuestro caso D-Link DGS-3627 Para instalar el servidor debemos elegir un sistema operativo. analizaremos DHCPv6 en Windows 2008 server y Ubuntu-Linux Server. Nosotros Servidor DHCPv6 en Ubuntu-Linux Server Servidor DHCPv6 en Windows 2008 Server. Además analizaremos como se instala el cliente DHCPv6 en los siguientes sistemas operativos: Cliente DHCPv6 en Ubuntu-Linux. Cliente DHCPv6 en Windows XP (SP3). Cliente DHCPv6 en Windows 7. Logicamente el ámbito de las direcciones a repartir deberá determinarse en el servidor DHCPv6. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 94

97 DHCPv6 Ubuntu 9.10 Server El siguiente gráfico muestra la configuración a obtener: En este apartado analizaremos la instalación del Servidor DHCPv6 en Ubuntu Server La instalación de los clientes DHCPv6 está en los siguientes apartados Instalación de DHCPv6 en Ubuntu Server 9.10: Existen varios proyectos que desarrollan la instalación de servidores DHCPv6 en linux. Algunos están estancados o con versiones que requieren ser mejoradas. Algunos son: WIDE-DHCPv6 inicialmente desarrollado dentro del proyecto KAME para BSD y Linux. El proyecto DHCPv6 para la distribución Fedora. Dibbler. Puede obtenerse más información en internet por ejemplo consultando: CPv6&sa=D&sntz=1&usg=AFrqEzfcpC1F1DqKZQvy_8PZr1fA1VqxGQ En nuestro caso, para Ubuntu-Linux utilizaremos Dibbler. Dibbler fue desarrollado inicialmente por Tomasz Mrugalski and Marek Senderski y actualmente funciona tanto en plataformas linux como windows. Una vez instalado Ubuntu Server (en nuestro caso la versión 9.10.) procederemos a instalar el servidor dibbler: iplaza@ubuntuserver:~$ sudo aptitude install dibbler-server ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 95

98 Nos preguntará si deseamos que el servidor DHCPv6 se inicie siempre que encendamos el servidor. Nosotros le indicaremos que no, ya que para hacer pruebas preferimos iniciar el servidor manualmente. Automaticamente todos los ficheros de configuración se instalarán en /etc/dibbler. Además debemos asegurarnos de que exista el directorio /var/lib/dibbler y tengamos permisos de escritura en él. Para observar el estado del servidor, podemos ejecutar: iplaza@ubuntuserver:~$ sudo dibbler-server status En principio el servidor estará detenido Configuración de DHCPv6 en Ubuntu Server 9.10: Una vez instalado el servidor para configurarlo debemos editar el fichero server.conf en /etc/dibbler iplaza@ubuntuserver:~$ sudo nano /etc/dibbler/server.conf Obviamente podemos usar el editor de texto que queramos, vi, nano, gedit (si lo hemos instalado). Existen múltiples opciones de configuración. En esta introducción probaremos la más sencilla. Posteriormente analizaremos configuraciones más avanzadas. En cualquier caso, en la documentación de dibbler todas las opciones están documentadas de forma clara y precisa. Basicamente podemos asignar un rango de direcciones de dos maneras: pool minaddress-maxaddress (dirección inicial - dirección final) pool address/prefix (usando la dirección y el prefijo) En nuestro /etc/dibbler/server.conf quedará: # server.conf iface eth0 { class { pool 2000:: ::600 } } Donde eth0 determina la interfaz encargada de repartir las direcciones y mediante class determinamos el inicio y fin del rango de direcciones a repartir. (Las hemos elegido al azar, obiamente el rango podría ser cualquier otro). ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 96

99 Ahora solamente debemos iniciar el servidor dibbler y este comenzará el reparto de direcciones. iplaza@ubuntuserver:~$ sudo dibbler-server start Debemos tener en cuenta que los clientes pueden configurarse de muchas formas. Por ello en los siguientes apartados estudiaremos ls opciones de configuración de cada cliente en cada sistema operativo DHCPv6 Windows 2008 Server El siguiente gráfico muestra la configuración a obtener: En este apartado analizaremos la instalación del Servidor DHCPv6 en Windows 2008 Server. La instalación de los clientes DHCPv6 está en los siguientes apartados Instalación de DHCPv6 en Windows 2008 Server: Una vez instalado Windows 2008 server en el servidor, conviene también instalar un controlador de dominio y un servidor DNS. Se puede realizar ejecutando dcpromo en la interfaz de comandos. A continuación y para comenzar con las instalación de DHCP deberemos dar los siguientes pasos: Inicio --> Herramientas administrativas --> Administrador del servidor ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 97

100 A continuación Agregaremos una función: Leemos las advertencias, nosotros hemos instalado en el servidor una IPv4 estática: Agregamos el servidor DHCP: Podemos leer la ayuda para produndizar: Obtenemos la configuración IPv4 que hemos establecido anteriormente en el servidor: Vamos a definir un ambito IPv4: Red: x Mascara: La puerta de enlace es opcional, en nuestro caso representa un router que podremos añadir posteriormente. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 98

101 Observamos que el ámbito IPv4 es correcto: Comenzamos a configurar el ámbito IPv6. Observar con Atención la siguiente ventana. En nuestro caso debemos debemos Deshabilitar el modo sin estado para este servidor. Usamos las credenciales actuales del usuario Administrador: Confirmamos si todo es correcto: El servidor DHCPv4 se instalará: La instalación ha sido satisfactoria: En el Administrador del servidor vamos al Servidor DHCP: O podemos hacerlo: Inicio-->Herramientas administrativas-->dhcp Una vez IPv4 está activo y con su ámbito definido, nos situamos en IP6, botón derecho Agregamos ámbito: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 99

102 Se ejectuta el asistente de ámbito nuevo: Damos un nombre y descripción al ámbito: Debemos elegir el Prefijo de las direcciónes IPv6 que vamos a repartir. Por ejemplo, elegimos un prefijo de direcciones locales unicas para nuestra organización fd00:1::1 Podríamos por ejemplo definir un ámbito para direcciones globales que empiecen por 2001:xxxx pero en este caso elegimos el prefijo fd00:1::1/64 En cada caso el administrador del sistema elegirá el ámbito que más le interese. La Preferencia determina el grado de prioridad que tiene el servidor DHCPv6. Dentro de una red puede existir más de un servidor DHCPv6, en ese caso, se establece la prioridad de cada uno, siendo el número 0 el que tiene mayor prioridad a la hora de asignar las direcciones IPv6 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 100

103 Si queremos agregar exclusiones (direcciones que no nos interesa que distribuya el servidor), este es el momento. Nosotros de momento no agregaremos exclusiones. Por último, debemos indicar la vigencia de las concesiones: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 101

104 El asistente muestra un resumen de la configuración y nos permite finalizar. En el caso de IPv4 siempre que los sistemas operativos de los ordenadores cliente indiquen en la configuración TCP/IP del adaptador de red que la dirección se obtenga de forma automática para observar las concesiones basta ir a la opción Concesiones de direcciones en el servidor DHCP IPv4. En nuestro caso, observamos los tres ordenadores de la red. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 102

105 En el caso de IPv6 para los clientes Windows XP y Ubuntu-Linux (de momento) es necesario instalar un cliente DHCPv6 como veremos en los siguientes apartados. En el caso de Windows 7 el cliente viene instalado en el propio sistema operativo. Lo único que debemos tener en cuenta en Windows 7 es la configuración del Firewall que incorpora el sistema que en algunos casos impide la asignación de una dirección por parte del servidor. Una vez instalados los clientes (como veremos más adelante), bastaría con ir a la opción Concesiones de direcciones en el apartado IPv6 y obtendríamos la información de cada cliente. En nuestro caso: Para terminar, normalmente, además de repartir las direcciones IP el servidor se encarga de asignar puertas de enlace predeterminadas o servidores DNS. Dichas opciones pueden seleccionarse en Opciones de ámbito. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 103

106 La configuración del servidor DHCPv6 para Windows Server 2008 se ha realizado satisfactoriamente DHCPv6 Cliente Ubuntu 9.10 Al contrario que en Ubuntu 9.04, en Ubuntu 9.10, la configuración de IPv6 puede hacerse en modo comando o desde el entorno gráfico. Observemos la opción en el entorno gráfico: Sin embargo, para obtener una dirección DHCPv6 a través de un servidor no basta con indicar en el modo gráfico que deseamos obtener una dirección IPv6 automaticamente. Debemos instalar un cliente. En nuestro caso vamos a instalar y probar dibbler. Para instalar dibbler en Ubuntu 9.10 Desktop version vamos a utilizar aptitude: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 104

107 Como alternativa, también podríamos descargar el fichero desde tz=1&usg=afrqezdihchtkxvdz6gecxyyvuxl_q2p-g o directamente: r%2fdibbler src.tar.gz&sa=d&sntz=1&usg=afrqezf6nine1oc_l5hvwjlkioewbzpwjw en este caso descargaríamos la versión 0.7.3, descomprimimos con gzip y extraemos con tar. Nosotros ya lo hemos instalado en el paso anterior con sudo aptitude install. Automaticamente todos los ficheros de configuración se habrán instalado en /etc/dibbler. Además debemos asegurarnos de que exista el directorio /var/lib/dibbler y tengamos permisos de escritura en él. Para observar el estado del servidor, podemos ejecutar: En principio el cliente estará detenido. Vamos a realizar una sencilla configuración de nuestra interfaz editando el fichero /var/dibbler/client.conf: Descomentamos (quitamos #) para configurar nuestra interfaz: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 105

108 Iniciamos dibbler-client: y para no tener problemas reiniciamos todos los adaptadores de red: Si el servidor instalado es Ubuntu-Server 9.10 observaremos la dirección IPv6 que nos ha proporcionado: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 106

109 En el caso de Windows 2008 Server la dirección será: El cliente DHCPv6 para la estación de trabajo Ubuntu ya está instalado y funcionando. La configuración del fichero client.conf determinará el grado de complejidad y las diferentes opciones de la dirección obtenida DHCPv6 Cliente Windows XP Como sabemos, la opción TCP/IPv6 en windows XP no puede configurarse de forma gráfica en XP (SP3). El proceso es el mismo tanto si el servidor DHCPv6 es Linux o Windows: Para configurar el cliente de windows XP vamos a utilizar el cliente dibbler, que podemos descargar desde: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 107

110 tz=1&usg=afrqezdihchtkxvdz6gecxyyvuxl_q2p-g o directamente: er win32.exe&sa=d&sntz=1&usg=afrqezenytanrh1fvc_tm80dbgagzc-bnq en este caso instalamos la versión Una vez descargado el fichero la instalación es tan simple como otra cualquiera en windows. Veamos las ventanas: Ejecutamos el.exe: Aceptamos la licencia GNU de dibbler: Vamos a instalarlo en C:\dibbler ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 108

111 Personalizamos la instalación, ya que esta versión para Windows de dibbler permite también instalar el servidor DHCPv6 en cualquier ordenador. En este caso, nosotros desactivamos la opción DHCPv6 server porque para funciones de servidor vamos a usar servidores específicos Ubuntu y/o Windows 2008 Server. Elegimos icono y nombre del programa: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 109

112 Pulsamos install y aceptamos las ventanas siguientes: Al finalizar dibbler se instalará en windows XP como un servicio. Para consultarlo: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 110

113 Inicio-->Panel de control-->herramientas administrativas-->servicios Para la configuración de la interfaz de red usaremos cualquier editor de texto para abrir el fichero de configuración c:\dibbler\client.conf Descomentamos (quitamos #) en las lineas indicadas y sustituimos "Local Network Adapter" por el nombre de nuestro adaptador de red. En nuestro caso "Conexión de área local" (Se debe tener en cuenta las mayúsculas/minúsculas y las tildes). Está es la configuración más básica. En fichero client.conf puede configurarse de muchas maneras. Una vez guardado el fichero la configuración ya ha terminado. Si por ejemplo el servidor que utilizamos es el Ubuntu-Server 9.10 que hemos configurado en el apartado anterior, la dirección otorgada podría observarse desde la interfaz de comandos de la siguiente manera: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 111

114 Utilizando el servidor Windows 2008 Server que hemos configurado el resultado sería: El hecho de que la dirección asignada por Ubuntu-Server sea global (2000::/3) y la asignada por Windows 2008 Server privada dentro de una organización (FD00::/8) no tiene ninguna relevancia. Lo hemos decidido para que exista mayor claridad a la hora de entender las distintas posibilidades. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 112

115 Para terminar, si tenemos algún problema al obtener la dirección desde el servidor, podemos detener y volver a iniciar el servicio dibbler-client desde el entorno gráfico de XP o ejecutando c:\dibbler\dibbler-client stop y a continuación c:\dibbler\dibblerclient start desde la interfaz de comandos. Además podemos reiniciar la obtención de direcciónes ejecutando: netsh interface ipv6 renew también desde la interfaz de comandos DHCPv6 Cliente Windows 7 Windows 7 no necesita instalar ningún cliente para la obtención de direcciones IPv6 desde un servidor DHCPv6. Basta con indicar en la configuración del protocolo TCP/IPv6 que la dirección se obtendrá automaticamente. Veamos: Inicio-->Panel de control-->redes e Internet-->Centro de redes y recursos compartidos-->conexión de área local-->propiedades-->protocolo de Internet versión 6(TCP/IPv6) Si el servidor que poseemos en la red está configurado como nuestro Ubuntu-Server 9.10, el cliente windows 7 obtendrá la siguiente configuración automaticamente: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 113

116 Sin embargo si el servidor de la red es el Windows 2008 Server, obtendríamos: La obtención de la dirección por parte del cliente de windows 7 es automática. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 114

117 3.4. Configuración manual. Como indicamos anteriormente, un PC IPv6 típico no necesita configurar manualmente su dirección IPv6. Este método está orientado a servidores y/o routers IPv6. Sin embargo en caso necesario, la configuración manual es muy sencilla y como es habitual en la mayoría de los sistemas operativos puede hacerse de forma gráfica o mediante la interfaz de comandos. Vamos a analizar la configuración manual de los PC en los siguientes sistemas operativos Ubuntu-Linux 9.10 Windows Configuración manual en Ubuntu-Linux Vamos a analizar los siguientes puntos: Añadir direcciones IPv6 en Ubuntu-Linux. Mediante el entorno gráfico. Mediante comandos. Más opciones de la configuración manual en Ubuntu-Linux. Añadir direcciones IPv6 en Ubuntu-Linux: Mediante el entorno gráfico: Sistema Preferencias Conexiones de red Marcamos la interfaz deseada, en nuestro caso Auto eth0 y pulsamos editar Seleccionamos el metodo Manual ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 115

118 Y podemos escribir la direccón y el prefijo que deseamos introducir de forma manual. En este punto es importante recalcar que el usuario que ejecuta el entorno gráfico debe tener privilegios de administrador o root. Si es un usuario normal la opción APLICAR permanecera inactiva. Por ejemplo, supongamos que queremos introducir la siguiente dirección unicast: 2001:db8:290c:1291::3/64 Pulsamos Aplicar y probablemente nos pedirá una contraseña con privilegios para realizar el cambio. Introducimos la contraseña. La dirección ha sido asignada tal y como lo indica la ventana gráfica. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 116

119 Para corroborar que la dirección ha sido asignada correctamente podemos abrir la terminal y ejecutar el comando ip addr show. Como observamos en el gráfico, es correcto Mediante comandos: Por ejemplo, para configurar una dirección IPv6 unicast 2001:db8:290c:1291::3 en la interfaz eth0: En nuestro caso: ip addr add direccion_ipv6 dev nombre_interfaz ip addr add 2001:db8:290c:1291::3 dev eth0 Si lo hemos escrito correctamente veremos que la nueva dirección ha sido añadida para la interfaz especificada. Como indicamos anteriormente, aunque podamos usar ifconfig, este comando ha sido sustituido por el uso del comando ip. Veamos la respuesta obtenida en ambos casos: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 117

120 Para determinar el correcto funcionamiento podemos utilizar el comando ping6 a la nueva dirección. ping c :db8:290c:1291::3 Los resultados obtenidos son satisfactorios. Más opciones de la configuración manual en Ubuntu-Linux: En el caso anterior, hay que destacar que la configuración que hemos realizado desaparecerá cuando reiniciamos el ordenador. Es decir, la dirección de ámbito ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 118

121 global 2001:db8:290c:1291::3 no será asignada. Solamente se configura automáticamente la dirección de enlace local. Para hacer permanente la asignación de la dirección global deberemos especificarlo en el fichero /etc/network/interfaces de Ubuntu-Linux. Veamos como podemos hacerlo: Vamos a editar el fichero usando gedit Deberemos introducir la nueva dirección a continuación: Para reiniciar el adaptador anteriormente usábamos ifdown y luego ifup Sin embargo, actualmente se recomienda el uso del comando ip sudo ip link set dev eth0 down sudo ip link set dev eth0 up Veamos la configuración y observaremos que la dirección es permanente. Obviamente, si reiniciamos el ordenador, la dirección de ámbito global permanecerá configurada: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 119

122 Como vimos anteriormente el comando ip permite muchas más opciones de configuración: Para mostrar las interfaces bastaría con escribir: sudo ip link show Podríamos mostrar una interface concreta indicándolo: sudo ip link show eth0 Si queremos eliminar la dirección que hemos introducido anteriormente, bastaria con ejecutar: sudo ip addr del 2001:db8:290c:1291::3 eth0 Como hemos indicado para modificar opciones de una interfaz ip link set posee las siguientes opciones: Para activar o desactivar una interface: ip link set eth0 on ip link set eth0 off Por ejemplo para indicar la unidad máxima de transferencia de una interfaz: ip link set eth0 mtu tamaño_en_bytes Hemos utilizado eth0 para los ejemplos, pero logicamente la interfaz puede ser la que cada uno desea dentro de las interfaces configuradas en el ordenador. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 120

123 Mediante el uso de la ayuda en cada caso, el usuario interesado podría profundizar más en el estudio de cada una de las opciones Configuración manual en Windows Vamos a analizar los siguientes puntos: Añadir direcciones IPv6 en Windows XP. Mediante el entorno gráfico. Mediante comandos. Añadir direcciones IPv6 en Windows 7 Mediante el entorno gráfico. Mediante comandos. Más opciones de la configuración manual en Windows Añadir direcciones IPv6 en Windows XP: Veamos que posibilidades existen tanto desde el entorno gráfico como desde la interfaz de comandos: a)mediante el entorno gráfico: En Windows XP de momento (es casi seguro que Microsoft no realizará los cambios necesarios) la configuración de IPv6 no puede modificarse desde el interface gráfico. Al contrario de lo que ocurre para IPv4, la opción Propiedades de cualquier interfaz de red que seleccionemos ( Inicio Panel de control Conexiones de red, seleccionar interfaz y botón derecho ) permanece inactiva. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 121

124 Por lo tanto para modificar las configuraciones usaremos la interfaz de comandos con netsh. b)mediante la interfaz de comandos: Por ejemplo, para configurar una dirección IPv6 unicast 2001:db8:290c:1291::1 en la interfaz Conexión de área Local con un valor infinito para los parámetros valid lifetime y preferred lifetime y hacer que este cambio sea persistente (no cambie cada vez que se reinicia el sistema): netsh interface ipv6 add address "Conexión de área local" 2001:db8:290c:1291::1 Se debe tener cuidado al escribir el nombre puesto que "Conexión de Area local" es distinto de "Conexión de área local" tanto en la A mayúscula como en la tilde. Cualquier error de sintaxis obtendra la siguiente respuesta: Si lo hemos escrito correctamente veremos que la nueva dirección ha sido añadida para la interfaz especificada. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 122

125 Una opción mucho más sencilla es indicar el índice de la interfaz (el número) en lugar de su nombre, en nuestro caso, sería el 4, por tanto, podríamos hacer lo mismo escribiendo: netsh interface ipv6 add address :db8:290c:1291::1 Para determinar el correcto funcionamiento podemos utilizar el comando ping a la nueva dirección. ping :2001:db8:290c:1291::1 Los resultados obtenidos son satisfactorios ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 123

126 Añadir direcciones IPv6 en Windows 7: Veamos que posibilidades existen tanto desde el entorno gráfico como desde la interfaz de comandos: a) Mediante el entorno gráfico: Usando el entorno gráfico: Inicio--> Panel de control --> Redes e internet --> Centro de redes y recursos compartidos: Pulsamos Conexión de área local. Aparece una ventana indicando el estado de la conexión, pinchamos sobre Propiedades ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 124

127 Pulsamos Protocolo de Internet versión 6 (TCP/IPv6) y Propiedades Basta con escribir la nueva dirección IPv6, la longitud del prefijo y la puerta de enlace si es que existe. b) Mediante la interfaz de comandos: Desde la interfaz de comandos, utilizando netsh: En Windows 7 al ejecutar la interfaz de comandos, a veces como en este caso es necesario ejecutarla con privilegios de administrador (como ocurre con sudo en Linux). Para ello, buscaremos el icono de la interfaz de comandos desde Inicio y pulsaremos sobre el botón derecho: A continuación clickaremos sobre la opción "Ejecutar como administrador". Vamos a configurar una nueva dirección IPv6 2001:db8:290c:1291::2 en la interfaz Conexión de área local con un valor infinito para los parámetros valid lifetime y ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 125

128 preferred lifetime y hacer que este cambio sea persistente (no cambie cada vez que se reinicia el sistema): netsh interface IPv6 add address "Conexión de área local" 2001:db8:290c:1291::2 Tal como indicamos en la instalación manual de XP se debe tener cuidado al escribir el nombre puesto que "Conexión de Area local" es distinto de "Conexión de área local" tanto en la A mayúscula como en la tilde. Si lo hemos escrito correctamente veremos que la nueva dirección ha sido añadida para la interfaz especificada: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 126

129 Una vez entendida la instalación de IPv6 y su resultado en W7 para determinar el correcto funcionamiento podemos utilizar el comando ping a las siguientes direcciones. ping 2001:db8:290c:1291::2 Los resultados obtenidos son satisfactorios c) Más opciones de la configuración manual en Windows: El entorno netsh diseñado por Microsoft puede utilizarse en todas las versiones modernas de Windows. Por ello, vamos a analizar algunas opciones más que podeis probar desde Windows XP, Windows Vista, Windows 7, etc Obviamente, la configuración manual de IPv6 no consiste unicamente en añadir direcciones IPv6. Existen muchas más opciones. En el entorno netsh in ipv6 aparecen: Donde se especifica para que podemos utilizar cada opción. Por ejemplo, si quisieramos eliminar la dirección añadida utilizaríamos la opción delete. Para ver sus opciones: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 127

130 Por tanto escribiríamos: netsh in ipv6 delete address 2001:db8:290c:1291::2 Podemos eliminar una interfaz completa, una dirección concreta de una interfaz, etc. Para reiniciar las direcciones IPv6: netsh in ipv6 renew Otra opción interesante para realizar modificaciones es set Por ejemplo dentro de la opción: netsh in ipv6 set address ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 128

131 Podríamos indicar que nuestra dirección IPv6 es permanente o persistente, es decir se mantiene aunque reiniciemos el ordenador, indicando: netsh in ipv6 set address Conexión de área local 2001:db8:290c:1291::2 store=persistent El usuario interesado podría profundizar más en el estudio de cada una de las opciones. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 129

132 3.5. Planificación de una red IPv6 La secuencia de pasos a dar para realizar la implementación de una red IPv6 sería la indicada en la tabla siguiente Tarea 1. Preparar el hardware para admitir IPv6. 2. Disponer de un ISP que admita IPv6. Descripción Comprobar que el hardware se pueda utilizar con IPv6. Buscar un ISP que admita IPv6. Se pueden utilizar dos ISP, uno para IPv6 y otro para IPv4. 3. Comprobar que las aplicaciones estén preparadas para funcionar con IPv6. Verificar que las aplicaciones sean compatibles con IPv6. 4. Disponer de prefijo de sitio Solicite al ISP un prefijo de sitio de 48 bits. 5. Crear un plan de direcciones de subredes. 6. Diseñar un plan para el uso de túneles. 7. Crear un plan de direcciones para entidades de la red. 8.Desarrollar directrices de seguridad de IPv6. 9. (Opcional) Configurar una DMZ. 10.Habilitar los nodos para que admitan IPv6. Se debe planificar la topología de red IPv6 global y el esquema de direcciones para poder configurar IPv6 en los distintos nodos de la red. Establezca los routers que deben ejecutar túneles a otras subredes o redes externas. Se debe planificar la dirección de servidores, routers y hosts antes de configurar IPv6. A la hora de desarrollar directrices de seguridad de IPv6, consulte las funciones de filtro IP, arquitectura de seguridad IP (IPsec), Internet Key Exchange (IKE) y otras funciones de seguridad Por motivos de seguridad, se precisa un plan de direcciones para la DMZ y sus entidades antes de configurar IPv6. Configurar IPv6 en todos los hosts y routers. 11. Activar los servicios de red Comprobar que los servidores puedan admitir IPv Actualizar los nombres de servidor para la compatibilidad Comprobar que los servidores DNS, NIS y LDAP se actualicen con las nuevas direcciones ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 130

133 con IPv6. IPv6. Más información en el documento original Guía de administración de sistema: Servicios IP de Sun Microsystem ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 131

134 4. Mecanismos de trasición para conseguir conectividad. En la transición buscamos la compatibilidad de los host y redes IPv6 con redes IPv4 existentes. El Mecanismo explica la forma de crear túneles. El túnel es el camino virtual que se crea para atravesar redes IPv4. El mecanismo se sirve de túneles para enviar datagramas IPv6 encapsulados en paquetes IPv4 y además, emplea infraestructuras IPv4 para comunicación con redes IPv6 y viceversa, ya que es necesaria la coexistencia de los dos protocolos durante un tiempo indefinido. Existen varios mecanismos para utilizar las infraestructuras IPv4 mientras la red IPv6 está siendo implantada. Los mecanismos se clasifican en: IPv6 in IPv4 IPv6 to IPv4 Teredo Mientras nuestro proveedor de Internet no nos ofrezca una dirección ipv6 para nuestro ADSL no podremos tener una red IPv6 nativa en la Empresa. EJEMPLO: Supongamos un ordenador de la Red Empresa1 desea ver la página Web de otro ordenador de la Red de la Empresa 2. Cada Empresa tiene un túnel configurado cuyo ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 132

135 extremo inicial es un nodo (Firewall, host de la Empresa) que conecta con un servidor en Internet (extremo final). Los dos nodos tienen una dirección IPv4 asociada. En el Navegador pondríamos de ord. Pagina web] El paquete que se genera en el ordenador es un paquete con formato IPv6. Este paquete llega hasta el Firewall y se encuentra con el extremo inicial del túnel. En este momento se encapsula en un paquete IPv4. Sale por el ADSL hasta llegar al broker1 (mecanismo usado para crear el túnel) IPv6 ori. IPv6 desti. Datos Una vez el paquete llegue al broker1 este vuelve a desencapsularse y se convierte a un paquete con formato IPv6. Este paquete atraviesa la red IPv6 nativa hasta llegar al broker2 (broker con el que tiene el túnel la Empresa 2. No necesariamente el mismo que el de la Empresa1). IPv6 ori. IPv6 desti. Datos En este momento el paquete debe encapsularse en un paquete IPv4 nuevamente para llegar a la Empresa2 atravesando el túnel que tiene configurado IPv6 ori. IPv6 desti. Datos Al final del túnel se vuelve a desencapsular convirtiéndose en un paquete IPv6 llegando al ordenador final que tiene la página Web que se ha pedido. La dirección del extremo final del túnel ha de ser determinada a través de información de configuración en el nodo que realiza el túnel (extremo inicial del túnel), Túnel configurado se denomina a aquel tipo de túnel donde el extremo final del túnel es explícitamente configurado IPv6 in IPv4 Los proveedores de túneles (broker) que se ajusten a los principios de RFC 3053 describen un sistema con el cual los usuarios pueden solicitar la creación de un túnel IPv6 en un host llamado Punto de Presencia (PoP) ofreciendo al usuario conectividad IPv6. Existen aplicaciones que permiten utilizar, de forma libre y gratuita, nuestras direcciones Ipv4 actuales, sobre las infraestructuras IPv4, para acceder a redes y sitios IPv6. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 133

136 El tunnel broker es el lugar donde el usuario se conecta para registrar y activar su túnel. El broker gestiona (crea, modifica, activa y desactiva) el túnel en nombre del usuario. No requiere la configuración de un Router. Se trata de ISP s IPv6 virtuales, proporcionando conectividad IPv6 a usuarios que ya tienen conectividad IPv4. El mecanismo para su configuración es tan sencillo como indicar en un formulario Web, datos relativos al S.O., la dirección IPv4, un apodo para la máquina, y el país donde está conectada. El servidor de túneles crea los registros DNS, el extremo final del túnel, y genera un script para la configuración del cliente. Un ejemplo de este sistema es El tunnel server es un Router con pila doble (IPv4 e IPv6), conectado a Internet, que siguiendo órdenes del broker crea, modifica o borra los servicios asociados a un determinado túnel/usuario. Pila doble: Consiste en usar los protocolos Ipv4 e Ipv6 simultáneamente en pilas separadas. En cada pila tendrá una dirección IP de cada tipo, estas pueden estar o no relacionadas. De esta forma, un dispositivo de este tipo puede comunicar enviando tráfico con nodos que soportan uno de los dos protocolos. El túnel creado es un túnel directo entre un punto y otro punto. No se tiene acceso directo a internet con IPv6. Se puede configurar el túnel manualmente (bien el usuario mediante un comando o el sistema operativo porque lo tiene configurado) o automáticamente (el broker). Hay una variedad de proveedores de túneles que proporcionan sus propias implementaciones basadas en los objetivos de negocio. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 134

137 Vamos a mostrar una tabla con los distintos proveedores de Túnel broker existentes. Proveedor Cobertura Subred Protocolos Estático Hurricane Electric [4] Estados Unidos, Canadá, Europa (6 países), Hong Kong, Tokio / 64 y /48 subred RD NS B G P Registro 6in4 Sí Sí Sí Requiere registro Configuración Idioma Sitio web Inglés SixXS Estados Unidos, Brasil, Europa (13 países), Nueva Zelanda [5] / 64 del túnel y de subred / 48 6in4, AYIYA Sí Sí RIPE, ARIN, APNIC, LACNIC, AFRINIC, O directamen te registro TIC /AICCU, Manual, página web Inglés gogo6/free net6 [2] Montreal, Amsterdam, Taipei, Sydney / 56 de subred 6in4, 4in6, TSP Sí Sí Anónimo, o un registro (mediante el registro en gogonet ] ) TSP, Sitio web Inglés En la tabla anterior se muestra la siguiente información: Proveedor Cobertura Subredes Protocolos Estático Reversos BGP El nombre del proveedor de túneles. Lugares donde el proveedor de túneles tiene puntos de presencia. Las máscaras de red que provee. Los protocolos de tunelado son provistos por el proveedor. Esto tiene impacto para la posibilidad de usar los túneles en máquinas que se encuentran detrás de NAT o en casos donde la IPv4 del usuario cambia frecuentemente. Indica si el proveedor de túneles provee direcciones estáticas. Si el proveedor entrega DNS inversos. Si el proveedor provee opcionalmente ruteo BGP sobre el túnel. BGP significa Border Gateway Protocol. Este último es un protocolo ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 135

138 mediante el cual se intercambia información de encaminamiento entre sistemas autónomos. Registro Los métodos de registro disponibles, si se requirieran. Configuración Métodos que están disponibles para configurar túneles y subredes provistas por el proveedor. Idiomas Idiomas que están soportados por las interfases web y otros canales de comunicación de los proveedores. Brokers Manuales: Hurricane Electric... Brokers automáticos: SixXS, Freenet6, Hexago... NOTA: Freenet es un bróker que se comunica muy bien con cualquier tipo de túnel (6in4, 6to4). Hurricane se comunica bien hacia Freenet pero no hacia 6to4. Para que esta comunicación sea posible hace falta un relay router IPv6 to IPv4 Este mecanismo fue diseñado para permitir conectividad IPv6 sin la cooperación de los proveedores de internet. Este sistema puede funcionar en un Router (proveyendo conectividad a toda una red) o en una máquina en particular. En ambos casos se necesita una dirección IP pública para crear el túnel. Muchas máquinas están conectadas a Internet IPv4 a través de uno o varios dispositivos NAT, por lo general a causa de la escasez de direcciones IPv4. En tal situación, la única dirección IPv4 pública disponible se asigna al dispositivo NAT, el extremo del túnel 6to4 debe aplicarse en el dispositivo NAT. La clave del sistema consiste en la asignación de direcciones IPv6 que contienen embebida la dirección IPv4 pública. No hace falta configuración, ya que todas las IPv4 públicas son únicas y por lo tanto, tendremos también una IPv6 equivalente única. Estas direcciones tienen todas el prefijo 2002::/16. De esta manera, cuando es necesario convertir un paquete IPv6 para que atraviese la red IPv4, el Router sabe la dirección a la que debe estar dirigido el paquete IPv4 generado. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 136

139 Ejemplo del resultado de una IPv6 a partir de una IPv4 pública: IPv4: IPv6: 2002:0102:0304::1 Vamos a ver un ejemplo de creación de un túnel 6to4 en una máquina Debian y que tiene asignada una IPv4: Para calcular una dirección IPv6 a partir de una IPv4 podemos usar las órdenes ipv6calc y printf. Para usar la orden ipv6calc previamente deberemos instalarla. #apt-get install ipv6calc # ipv6calc --quiet --action conv6to #printf 2002:%02x%02x:%02x%02x::1\n a b c d El gateway es siempre una dirección especial anycast ( ) que apunta al Router 6to4 más cercano. Vamos a usar la Interface sit0 que tiene el debían desactivada. IP pública ADSL DECIMAL IP pública ADSL HAXADECIMAL f de #nano /etc/network/interfaces auto sit0 iface sit0 inet6 static address 2002:4f94:71de::1 (4F94:71 de IP pública del ADSL en hexadecimal) netmask 16 gateway :: endpoint any local (Ip pública del ADSL) ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 137

140 Este mecanismo funciona aún cuando la dirección IPv4 global (pública) es única y se accede a la red mediante mecanismos NAT (Network Address Translation), que es el caso más común en las redes actuales para el acceso a Internet a través de ISP s. El mecanismo 6to4 está basado en la creación de túneles ipv6-in-ipv4. Su filosofía es permitir a los nodos Ipv4 que implementen el mecanismo 6to4. Obtener una dirección Ipv6 basada en la dirección Ipv4 pública del nodo y poder contactar a través de Ipv6 bien con otros nodos 6to4, usando para ello la red Ipv4 como transporte, o bien con otros nodos Ipv6 nativos usando para ello relays 6to4. En el caso en el que se conectan dos redes que utilizan 6to4 la relación es simétrica. los Routers de ambos sistemas intercambian entre sí los paquetes. Para enviar un paquete a una dirección IPv6 "nativa" es necesario, en cambio, enviarlo a un Router que esté conectado a la red IPv6 real. Esto se logra enviando el paquete a una dirección anycast: El emisor no necesita saber dónde está ese Router, y se espera que muchas de las distintas redes que conforman internet provean Routers que respondan a esta dirección. Asimismo, desde la red pura IPv6 cuando un paquete está destinado a una red 6to4 debe ser dirigido a un Router que anuncie manejar el prefijo 2002::/16. Cuando la dirección IPv4 utilizada es fija, el prefijo IPv6 que se genera en base a ella es fijo también. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 138

141 4.3. Teredo. El objetivo de este mecanismo es dar conectividad IPv6 a aquellos usuarios que se encuentran detrás de un NAT y que por lo tanto el host tiene una IP privada. Su función es encapsular paquetes Ipv6 dentro de datagramas UDP-IPv4 para poder atravesar dispositivos NAT y la red de Internet IPv4. De forma similar a 6to4, este sistema se habilita de forma automática aportando una dirección IPv6 a los nodos Windows Xp/ 2003/ Vista y Windows 7 finales del usuario cuando se cumplen las siguientes condiciones: La pila IPv6 está habilitada No existe conectividad nativa IPv6 y no dispone de una dirección IPv4 pública. Teredo desempeña múltiples funciones: Determina la conectividad UDP sobre IPv4 y descubre el tipo de nat presente (DNAT, SNAT). Asigna una dirección IPv6 única global a cada host. Enruta tráfico entre host con Teredo y host IPv6 nativos (es decir, que no usan Teredo) Teredo aporta una dirección IPv6 con la siguiente forma a cada host: Bits Longitud 32 bits 32 bits 16 bits 16 bits 32 bits Descripción Prefijo Teredo Server Flags puerto UDP IPv4 pública del cliente IPv4 Ejemplo 2001: :e bf c000:022d código Nat El mecanismo Teredo requiere de cierta infraestructura, como servidores y relays Teredo. Los servidores usualmente no redireccionan paquetes de datos. Su función principal es facilitar el direccionamiento entre clientes y relays Teredo. Por lo tanto, Teredo Server debe estar en la red pública de internet IPv4. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 139

142 Los host se conectan con los nodos Teredo Server y estos últimos detectan detrás de qué tipo de nat se encuentra el cliente. El host (Teredo cliente) mantiene un vínculo permanente con Teredo Server enviando cada cierto tiempo paquetes UDP. Este sistema asegura que el servidor puede contactar con cualquiera de sus clientes y que el túnel está activo. Los Relays Teredo son puertas de enlace entre internet IPv6 y los clientes teredo. Su función principal es la transmisión y recepción real de los paquetes de tráfico IPv6. Los relays deben estar en internet IPv4 e IPv6. Estos relay pueden contactar con Servidores Teredo si lo necesitan para redireccionar paquetes. En la práctica, cuándo un nodo Teredo Cliente quiere contactar con un nodo IPv6 nativo, debe encontrar el Teredo relay que le corresponde (el cuál pública los nº de puertos UDP y una dirección pública IPv4 para enviar paquetes IPv6 encapsulados). Gracias a esta información el paquete se encapsula en paquetes IPv4 y se transmiten a través de su túnel hasta el Teredo relay. Este desencapsula el paquete y lo envía a Internet IPv6, de modo que el paquete finalmente debe alcanzar el nodo IPv6. El servidor Teredo requiere poco ancho de banda debido a que no están involucrados en la transmisión y recepción real de los paquetes de tráfico IPv6. Además, no requiere de ningún acceso a los protocolos de enrutamiento de Internet. Un Teredo Relay potencialmente requiere mucho ancho de banda de Red. De esta forma, Teredo Relay recibirá el tráfico desde cualquier host IPv6 dirigido a cualquier cliente Teredo, y lo remitirá en formato UDP/IPv4. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 140

143 Servidores de Teredo públicos: teredo.remlab.net / teredo-debian.remlab.net (Francia) teredo.autotrans.consulintel.com (España) teredo.ipv6.microsoft.com (por defecto para Windows XP/ 2003 / Vista / 2008 / 7) teredo.ngix.ne.kr (Sur de korea) teredo.managemydedi.com (USA, Chicago) Teredo sólo puede proporcionar una dirección IPv6 única por el túnel a un punto final. Como tal, no es posible utilizar un único túnel Teredo para conectar varios hosts. Para que los túneles Teredo funcionen los Firewalls no deben filtrar los paquetes UDP 3544 entrantes ni salientes. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 141

144 5. EJEMPLOS de tuneles: Tunnel Broker y Teredo En este apartado vamos a exponer diferentes ejercicios resueltos. 1. Creación de túnel en un host con Windows con freenet6 2. Creación de túnel de un firewall de Debian con hurricane 3. Creación de túnel Teredo 5.1. Creación de túnel en un host con Windows con Freenet6. La red que tenemos es una LAN IPv4 detrás de un ADSL con su IP pública. Esta vez no existe un Firewall entre el ADSL y la LAN. Vamos a ver los pasos a seguir para crear un túnel con freenet6 en un host (Windows) de la LAN (en este caso estamos detrás de NAT) y de esta manera conseguir conectividad Ipv6 para este host teniendo Ipv4. Antes de comenzar unas notas: 1. Nosotros vamos a configurar en el host la parte cliente (gogoclient) del túnel. El cliente deberá interactuar con el servidor (gogoserver). 2. El túnel utiliza el protocolo TSP que establece y mantiene el túnel de datos estático. GogoCLIENT conecta con gogoserver y obtiene información relativa al túnel usando el protocolo TSP. Si el host donde se va a crear el túnel se encuentra detrás de un FIREWALL deberemos abrir el puerto 3653 en el mismo. En nuestro caso no estamos detrás de un FIREWALL por lo tanto no abriremos ningún puerto. 3. El código fuente es la misma para casi todas las plataformas cliente. 4. Se puede configurar el cliente para conectarse a un único gogoserver o a múltiples SERVIDORES. Esta flexibilidad tiene dos propósitos: Ofrecer mejor calidad de servicio permitiendo a los usuarios conectarse al servidor más cercano y mantener redundancia de forma que ante cualquier suceso en el que un servidor no esté disponible el túnel seguirá funcionando. 5. Existe un interfaz gráfico para el sistema Operativo Microsoft Windows que permite una fácil configuración del túnel y que ofrece un informe con el estado del servicio. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 142

145 COMENCEMOS: Crear una cuenta Como primer paso, tenemos que ir a la web de gogo6: Haremos clic en el vínculo que pone Freenet6 y nos aparecerá la siguiente ventana en la cual tendremos que elegir la opción Sign Up: Rellenaremos el formulario que nos aparece completando así el registro. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 143

146 Una vez registrados, podremos iniciar sesión introduciendo los datos del registro y haciendo clic en Sign In. Descarga de software Una vez iniciada la sesión, nos aparece una ventana en la que tendremos que hacer clic en DOWNLOAD Latest gogoclient. Se nos abrirá una ventana con dos versiones diferentes, Basic Version y Home Access versión. Descargamos la que nos convenga. Esta última se diferencia de la primera porque dispone de una herramienta llamada HomeAccess que permite utilizar el software como servicio web. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 144

147 Instalación de gogoclient Se nos descargará un fichero ejecutable en el que haremos doble clic y con una rápida y sencilla instalación dispondremos del software de gogo instalado en nuestro PC. Ejecutamos gogoclient utility. Debemos tener permisos de administrador. Esta utilidad nos permite conectarnos Identificándonos o anónimamente al servidor freenet6 haciendo clic en el botón Connect de la pestaña Basic. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 145

148 La conexión se realizará según el botón de opción seleccionado: Seleccionando Connect anonymously en Server Address escribiremos anonymous.freenet6.net. Esta será una conexión anónima. Tan sólo nos permitirá navegar con IPv6 en Internet. No podrá nadie acceder a una página Web que tengamos alojada en nuestra máquina. Además, no dará una dirección Ipv6 a ningún host de nuestra LAN. Seleccionando Connect Using the Following Credentials en Server Address pondremos authenticated.freenet6.net y en user name y password el nombre de usuario y la contraseña del registro realizado en freenet. En este caso tendremos todas las opciones comentadas si las tenemos activas en la configuración avanzada que se explica más adelante. La opción launch de gogoclient service system at startup activada cada vez que reiniciamos o encendemos el ordenador pondrá el túnel en marcha. De forma predeterminada tendremos la red con IPv6. No es conveniente tenerla activada por seguridad. Para conectarnos con una identificación, previamente tendremos que registrarnos desde la página web en la que nos aparecían las diferentes versiones de gogoclient haciendo clic en here. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 146

149 Utilizaremos los datos del registro para conectarnos con nuestra identificación en la pestaña Basic, con esta identificación, podremos utilizar la utilidad de servicio web en la versión HomeAccess. Si clicamos en la pestaña Status, veremos la información que freenet6 nos ha asignado, observando que se trata de una configuración Ipv6 in UDP Ipv4. (Significa que estamos detrás de nat). La longitud del prefijo asignado es de 64 bits. En los túneles con conexión anónima el prefijo cambia respecto a la conexión autenticada. En el primer caso, el prefijo tiene la forma 2001:5c0:1400:a:: /64 (acaba con a) y la dirección IPv6 que tiene asociada cambia con cada conexión del túnel mientras que en el segundo el prefijo tiene la forma 2001:5c0:1400:b:: /64 (acaba con b) y la dirección IPv6 es asignada de forma ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 147

150 permanente al usuario y no cambia aunque el usuario se desplace a una dirección IPv4 nueva. En el modo de autenticación, existen dos métodos disponibles para realizar la autenticación: autenticación simple o autenticación encriptada. Con la autenticación simple, la identificación de usuario y contraseña se envían como texto sin cifrar, con la autenticación encriptada (MD5), SASL-DIGEST-MD5 se utiliza para cifrar la cuenta. Para cada túnel autenticado se crea un registro AAAA en el servidor DNS de Freenet6. El FQDN asociado con los túneles autenticados utiliza el formato userid.broker.freenet6.net, donde userid es el nombre de la cuenta del usuario final. Un usuario registrado como "increibleipv6" tendría la siguiente entrada DNS: increibleipv6.broker.freenet6.net. Un usuario anónimo no tiene registro DNS. Varios host simultáneamente no pueden autenticarse con el mismo usuario. De forma anónima desde cualquier host de la LAN se puede crear un túnel. Se puede conseguir diferentes cuentas en freenet siempre y cuando tenga direcciones de correo diferentes. El túnel expirará a los pocos minutos después de desconectado. que el cliente se haya Desde este momento, podemos comprobar la conexión Ipv6 haciendo un ping a la dirección de google desde la consola cmd. En el momento en el que ejecutamos el software, podremos comprobar que nos ha creado una conexión virtual que funciona de túnel. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 148

151 NOTA: Para navegar bien con direcciones IPv6 es necesario que la versión del Navegador Explorer sea 8 o posterior. Podemos personalizar la configuración. Para ello en el software de gogo6client elegiremos la ficha Advanced: La primera opción Tunnel Mode : Nos permite elegir entre varias opciones. IPv6-inIPv4 Tunnel, IPv6-inIPv4 Tunnel (Native), IPv6-in-UDP-IPv4 Tunnel (NAT Transversal), y IPv6-inIPv4 Tunnel (DSTM). Si dejamos seleccionado el valor por defecto (se muestra en la imagen), gogoclient preguntará a gogoserver cuál es el tipo de túnel que más le conviene crear. gogserver analizará a gogoclient y determinará el tipo de túnel que le conviene establecer (nativo o con NAT transversal). En la ficha Status podremos consultar el tipo de túnel que finalmente ha creado. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 149

152 La opción Tunnel Authenticaion Method tiene por defecto Automatic(ANY). Significa que va unida a la opción seleccionada en la ficha Basic. Esta ficha puede tener seleccionado anonymous o authenticated. Si decidimos autentificarnos en Server Address pondremos authenticated.freenet6.net. Además, añadiremos el usuario y contraseña. De lo contrario, pondremos anonymous.freenet6.net. Connect to Best Server. gogoclient enviará ping a todos los gogoserver y se conectará con el gogoserver que devuelva en primer lugar la respuesta. Si no consigue crear el túnel entonces lo intentará con el gogoserver que haya respondido al ping en segundo lugar. Seguirá intentándolo mientras no tenga éxito o no le queden más gogoserver con quien intentarlo. Si fallasen todos los intentos dará error. Connect Using Preferred gogoserver se conectará al servidor especificado. Si no consiguiese crear el túnel se limitará en notificar el error. Entre las dos últimas opciones elegiremos una de ellas. Hay varias razones por las cuales gogoclient puede no conseguir establecer el túnel: 1. Cada gogoserver tiene un nº máximo de usuarios que pueden conectarse simultáneamente. En periodos de mucho tráfico podría ocurrir que se supere el número. 2. gogoclient puede estar intentando crear un tipo de túnel con un gogoserver que no lo soporta. Obtain Source IP Address Automatically es la opción por defecto. Si el host tiene varias tarjetas de red elegiremos Specify Source IP Address. En este caso se escribirá en la caja la dirección IPv4 con la cual se quiere crear el túnel. Enable Keepalive Funcionally indica cada cuánto tiempo debe enviar un paquete ICMP a gogoserver para asegurarse que la sesión del túnel sigue activa. El valor por defecto es 30 segundos. Enable Routing Advertisements option es usado para publicar la disponibilidad de la conectividad IPv6 al grupo de interfaces de la red y proporcionar el prefijo para que generen su propia dirección IPv6. Cuándo se activa esta opción, gogoclient espera que el servidor provea el prefijo como parte de la negociación del túnel. Si esta opción está activada una vez realizada la conexión, gogoserver le va a proveer de un prefijo al túnel y este host publicará este prefijo a todas los host de la LAN. Cada host formará su propia dirección IPv6 y tendrá acceso a las páginas con IPv6. De esta ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 150

153 manera podemos con un solo túnel dar direcciones IPv6 a cada host de la LAN. Poner una página Web accesible desde Internet. Trabajaremos con las otras dos pestañas que tiene nuestro aplicativo HomeWeb y HomeAccess. En la primera ficha activaremos el cuadro Enable Home Web y en la caja de texto pondremos la ruta donde tenemos nuestra página Web alojada en el disco duro. En la ficha HomeAccess activaremos la casilla Enable Homeaccess y añadiremos una línea indicando la dirección Ipv6 que tenemos asignada en el host y un nombre (el que queramos). ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 151

154 La página web estará accesible en la siguiente conexión que realicemos Creación de túnel de un firewall de Bebian con Hurricane. La red que tenemos es una red LAN IPv4 detrás de un Firewall Debian que a su vez este está conectado a un ADSL con su IP pública estática. El objetivo es crear un túnel desde un firewall dotándole de una dirección ipv6 hacia internet y que pueda llegar a ver páginas web ipv6. Es suficiente con registrarse en la página web Al pulsar en Register saldrá un formulario con la siguiente forma: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 152

155 Rellenamos el formulario, lo enviamos y recibiremos por un mensaje con la información del usuario con el que a continuación vamos a logearnos. Una vez hemos entrado, elegimos Create regular tunnel se visualizará una ventana que nos pedirá la IP pública que tiene nuestro ADSL. Al tener una IP estática y estar asociada a nuestro usuario en el servidor del Broker no nos obliga a identificarnos constantemente. A continuación saldrá una ventana mostrándonos la información de nuestro túnel. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 153

156 Entre toda la información que hay observamos, la dirección IPv4 e IPv6 de los dos extremos del túnel. Además, un prefijo IPv6 que tenemos asignado en exclusividad para dar una dirección IPv6 a cada host de nuestra LAN que se encuentra detrás del Firewall. Con la cuenta creada en el Broker, procedemos a realizar nuestra instalación en el Debian. Este Host es un ordenador con distribución Debian que tiene dos tarjetas de Red, una de ellas unida a la red LAN (eth1) y la otra a la Red del ADSL (eth0). Este Host además es un Firewall y un servidor Apache. Al Firewall le hemos puesto políticas por defecto de Aceptar. REQUISITOS: 1. La IPv4 pública del ADSL debe ser estática. 2. La dirección IPv4 de cada host de la LAN puede ser estática o dinámica. 3. El túnel que se crea es autenticado no existe anónimo como en Freenet6. Desde la web de Hurrricane, por usuario solo se pueden crear 5 túneles, tiene esa limitación. Primeros pasos: 1. Probar que el kernel de debían admite IPv6. Este debe ser posterior a 2.6 #cat /proc/net/if_inet6 && echo 'IPv6 sistema preparado!' echo 'No se encuentra el soporte IPv6. Compile el Kernel!!' ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 154

157 2. Probar que el módulo IPv6 está cargado: modprobe IPv6 o Resultado: lsmod grep ipv6 ipv Creamos un archivo que tiene las ordenes iptables que configura el Firewall. Al archivo le damos el nombre de permitir y lo almacenamos en la ruta /etc/init.d apacheaeg:/etc/init.d# cat permitir #!/bin/bash pt=/sbin/iptables for TABLE in filter nat do $pt -t $TABLE -F $pt -t $TABLE -X $pt -t $TABLE -Z done echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv6/conf/all/forwarding iptables -t nat -A POSTROUTING --protocol! 41 -o eth0 -j MASQUERADE En este archivo además de poner las políticas por defecto Aceptar, se da la orden de forwardear entre las tarjetas los paquetes IPv4 e IPv6. Además, se da la orden de enmascarar únicamente los paquetes IPv4. Los paquetes IPv6 usan el protocolo 41 y se le está indicando al Firewall que no enmascare estos paquetes. Este archivo tiene un enlace creado en /etc/rc2.d para que se ejecute cada vez que se inicia el Host. /etc/init.d# chmod 777 permitir /etc/init.d# ln s /etc/init.d/permitir /etc/rc2.d/s99_permitir Ordenes para crear el túnel: ip tunnel add he-ipv6 mode sit remote local ttl 255 Sintaxis: ip tunnel [add change delete] nombre_tunel mode [ipip sit gre] remote [direci. Ipv4 b broker] local [la ip de nuestro host] dev [periferico] Los argumentos posibles son: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 155

158 name NOMBRE -- selecciona el nombre del túnel mode MODO -- hay 3 modos disponibles: ipip, sit y gre El modo ipip corresponde a un simple túnel IP sobre IP. Se encapsulan los paquetes sin más. El modo sit se usa para túneles IPv6. El modo gre corresponde a los túneles GRE especificados por la compañía Cisco, que son túneles IP sobre IP cifrados. remote DIRECCION -- dirección de 'salida' del túnel local DIRECCION -- dirección local de 'entrada' del túnel dev PERIFERICO-- nombre del periférico a través del que se envían los paquetes ip tun show Esta orden muestra los túneles ip link set he-ipv6 up Esta orden sirve para levantar el túnel llamado he-ipv6 ip addr add 2001:470:1f08:744::2/64 dev he-ipv6 Permite asignar una dirección IPv6 al extremo local del túnel ip route add ::/0 dev he-ipv6 Permite poner una ruta estática. Cualquier paquete que esté destinado a una dirección IPv6 deberá salir por el túnel llamado he-ipv6. ip -f inet6 addr El -f significa family, y al poner inet6 hace referencia a la familia IPv6. Si no se pone nada por defecto es IPv4. Esta orden tiene carácter informativo y muestra las direcciones IPv6. Todas las órdenes juntas forman el script para crear el túnel. Se puede usar cualquier editor de texto (nano, vi,..) : apacheaeg:/etc/init.d# nano tunel ip tunnel add he-ipv6 mode sit remote local ttl 255 ip link set he-ipv6 up ip addr add 2001:470:1f08:744::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6 ip -f inet6 addr /etc/init.d# chmod 777 tunel /etc/init.d# ln s /etc/init.d/tunel /etc/rc2.d/s99_tunel A este archivo se le ha dado permisos de ejecución, se ha creado el enlace a rc2.d para su ejecución en el arranque. La orden ifconfig me muestra: apacheaeg:/home/apacheweb# ifconfig ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 156

159 Neighbor Discovery (ND) es un protocolo de IPv6, y es equivalente al protocolo Address Resolution Protocol (ARP) en IPv4. Consiste en un mecanismo con el cual un nodo que se acaba de incorporar a una red, descubre la presencia de otros nodos en el mismo enlace. Este protocolo también se ocupa de mantener limpios las caches donde se almacena la información relativa al contexto de la red a la que está conectado un nodo. Así cuando una ruta hacia un cierto nodo falla el enrutador correspondiente buscara rutas alternativas. Emplea los mensajes de ICMPv6, y es la base para permitir el mecanismo de autoconfiguración en IPv6. Ahora debemos configurar el radvd (router advertisement daemon) en el Firewall para que publique el prefijo de nuestra subred a todos los nodos que se encuentran en la LAN. Para esto, modificamos el archivo /etc/radvd.conf (sustituimos cualquier línea que ya existiese en el archivo) añadiendo las siguientes líneas: NOTA: Si radvd no está instalado a priori deberemos hacerlo. #apt-get install radvd apacheaeg:/etc/init.d# cat../radvd.conf interface eth1 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 2001:470:1f09:744::/64 { AdvPreferredLifetime 120; }; }; ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 157

160 El valor de MaxRtrAdvInterval significa el valor máximo en segundos entre envíos de paquetes "Router advertisement" y MinRtrAdvInterval tiempo mínimo en segundos para el envío de un paquete "Router advertisement. AdvSendAdvert on, establece que se enviaran paquetes Router advertisement" bajo solicitud por parte de uno de los nodos o automáticamente cada cierto tiempo. Para poner el demonio radvd en marcha damos la orden: apacheaeg:/etc/init.d# /etc/radvd restart Stopping radvd: radvd. Starting radvd: radvd. Para que se ejecute de forma automática el radvd deberemos en el archivo rc.local que se encuentra en /etc añadir la línea /etc/radvd.conf restart. Este archivo tiene un enlace a rc2.d llamado S99rc.local. /etc# nano rc.local Añadir la línea: /etc/radvd.conf restart NOTA: La última acción ha sido necesaria ya que el enlace que tiene el demonio radvd en rc2.d llamado S50radvd no se ejecuta. Después de dar esta orden cada interface de la LAN tendrá una dirección IPv6 formada con el prefijo que le ha dado el demonio más la Mac de la tarjeta de Red. En este instante tenemos una Red IPv6. La Red IPv4 se mantiene y está funcionando. Tan sólo falta darle una dirección IPv6 a la interface eth1 perteneciente al prefijo que nos han dado: 2001:470:1f09:744::1. Para ello, editamos en archivo /etc/network /interfaces y añadimos las siguientes órdenes: iface eth1 inet6 static address 2001:470:1f09:744::1 netmask 64 El archivo quedaría de la siguiente forma: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 158

161 En este instante desde cualquier host de nuestra red tenemos posibilidad de consultar Páginas web IPv6 en Internet. Además, podemos ver nuestra página web en el Firewall desde cualquier host que tenga una dirección IPv6. Consultando la información de la interface del host que está detrás de la LAN observamos: La puerta de enlace que está detrás de la LAN es la dirección IPv6 (fe80:---) local de la interface del Firewall. No utiliza la dirección global IPv6. El servidor DNS no coge una dirección IPv6 utiliza una dirección IPv4. El servidor DNS IPv4 resuelve direcciones IPv4 e IPv6. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 159

162 Un paquete que debe salir a Internet desde un host de la LAN, inicialmente será enviado a la interface del Firewall local (fe80), una vez el paquete ha llegado al router este consulta en su tabla de enrutamiento la dirección Ipv6 por la que debe salir para llegar a internet. Vamos a ver la tabla de enrutamiento de direcciones Ipv6. #route A inet6 La línea resaltada indica que para ir a cualquier dirección IPv6 (::/0) se saldrá por el túnel he-ipv Creación de túnel Teredo Este sistema tan sólo permite salir hacia fuera (ver páginas web) desde el host y nadie puede entrar en él. Es lógico ya que es una dirección IPv6 formada a partir de una IPv4. Este sistema crea un túnel para cada host. No obtiene un prefijo y no permite dar direcciones IPv6 a las máquinas. El protocolo IPv6 y Teredo está habilitado por defecto tanto en Windows Vista, Windows 7 como en Windows XP SP3. Vamos a ver un ejemplo: Deberemos tener un host con Windows 7 detrás de una ADSL. Antes de dar las órdenes deberemos entrar en la ventana CMD con permisos de Administrador. Sobre el Símbolo del sistema pulsamos botón derecho del ratón y elegimos Ejecutar como Administrador. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 160

163 Podemos comprobar nuestro host a que servidor Teredo accede dando la orden: Netsh interface ipv6 show teredo Observamos que en tipo pone client. Este parámetro indica que nuestro host utiliza Teredo cliente. El servidor al que va a acceder nuestro host es teredo.ipv6.microsoft.com. El Intervalo de actualización del cliente tiene como valor 60 y su objetivo es la comprobación del estado del túnel enviando un paquete. El puerto se ha especificado con el valor y su estado es dormat. El hecho de que tenga este valor significa que ha conectado con un servidor teredo. Si no lo consigue (porque el Router ADSL no se lo permite) tendrá el valor offline. Si deseamos acceder a otro servidor teredo tenemos que dar la orden: Netsh interface ipv6 set teredo client teredo.remlab.net ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 161

164 Vamos a comprobar los valores que tiene nuestra tarjeta de red: Usando la orden ipconfig veremos: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 162

165 Comprobamos que la interface teredo Tunneling Pseudo-Interface tiene una dirección IPv6 que comienza en 2001:. Ahora probamos a navegar a páginas IPv6: Vamos a acceder a la página Web creada en un host que se encuentra detrás de un Firewall y que obtiene una dirección IPv6 creando un túnel con la aplicación gogo6 usando el Broker Freenet6. Vamos a acceder a la página Web creada en un host Debian que tiene un túnel creado con el bróker Hurricane. Su dirección IPv6 es : Este host con Windows 7 nos permite ver páginas Web en otros host con IPv6 pero tan sólo se puede salir de él y nadie podrá llegar al mismo a ver su página web si la tuviera ni haciendo ping. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 163

166 6. Inyección y captura de paquetes WireShark OBJETIVO: Capturar paquetes Ivp6 con el programa Wireshark. Como primer paso, hemos instalado Wireshark en un PC con Debian. Para instalarlo hay que escribir el siguiente comando en el terminal: apt-get install wireshark Después, hemos ejecutado el programa como root (Wireshark as root), se nos abre la pantalla principal y hay que hacer una pequeña configuración. Hacemos clic en el icono de la imagen y se abrirá otra ventana en la que tenemos que elegir la interface a utilizar. En ella elegimos he-ipv6. Se trata del nombre que le hemos dado al túnel. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 164

167 El círculo rojo de mayor tamaño, es para elegir algún tipo de filtro si deseamos filtrar los paquetes capturados. Si hacemos clic en el botón de los filtros, nos aparece la siguiente ventana donde podremos elegir el protocolo a filtrar o alguna de las opciones que nos aparecen en la lista. Nosotros no vamos a elegir ningún filtro. Aceptamos la ventana de los filtros si hemos elegido algún filtro y sino cancelamos y una vez realizados estos pasos, clicamos en el botón Start y el programa iniciará la captura de paquetes en modo promiscuo. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 165

168 La siguiente imagen, muestra los paquetes capturados navegando desde el mismo equipo con Ipv6. Como podemos ver, por cada captura nos muestra los siguientes apartados. Nº de Paquete. Tiempo tardado. IP Origen. IP Destino. Protocolo. Información acerca del paquete (puerto que se ha utilizado, acción que se ha realizado, tardanza de la acción...) En el siguiente ejemplo, muestra los paquetes capturados accediendo al Debian mediante ssh desde un Windows Vista. En el debian, tendremos que instalar el ssh con el comando: apt-get install ssh Cuando finalice ya tendremos instalado y funcionando a la perfección el demonio de ssh. Es necesario reiniciar el demonio de red, lo haremos con: /etc/init.d/ssh restart. Para acceder mediante ssh desde un Windows Vista, hay que usar el software Putty que lo descargamos desde: ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 166

169 Ejecutaremos el programa y nos pedirá la IP del host destino (IPv6 en nuestro caso). Clicando en el botón Open se nos abrirá una ventana parecida a CMD donde tendremos que introducir un usuario y contraseña del otro host destino. ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 167

170 Supongamos que la máquina TK1 con IPv6 2001:5c0:1400:b::6895 conecta usando ssh con otra máquina TK2 con IPv6 2001:470:1f08:744::2. La máquina TK1 hace una petición (Request) de conexión hacia la máquina TK2. Esta segunda máquina acepta la petición (Response). Observamos que el tráfico está encriptado. Esta otra imagen, muestra los paquetes capturados accediendo a la web que el Debian tiene alojada con el navegador desde otro PC con conectividad Ipv6. Una máquina TK1 con IPv6 2001:5c0:1400:b::70db consulta la página web de otra máquina TK2 con IPv6 2001:470:1f08:744::2 ZAMALBIDE AUZOA Z/G ERRENTERIA GIPUZKOA TEL: Pag: 168