IPV6. Casarero, Eduardo;Clemente, Alejandro;Ruiz, Santiago Universidad Argentina de la Empresa

Transcripción

1 IPV6 Casarero, Eduardo;Clemente, Alejandro;Ruiz, Santiago Universidad Argentina de la Empresa Abstract El presente documento tiene como objetivo describir las principales características del protocolo IPv6, destacando sus ventajas tecnológicas. También plantear métodos de transición desde IPv4. Se realizó una consolidación de los principales documentos RFC que describen el protocolo, a partir de la extracción de datos relevantes que en su conjunto brindan al lector un panorama general de los diferenciales con su antecesor. Además se incluyen un caso de éxito en el despliegue de IPv6 y varios enfoques posibles para encarar con éxito la transición en una empresa. Palabras Clave IPv6 Transición Despliegue Protocolo Objetivos El objetivo de este trabajo es realizar una investigación sobre el estado de la implementación de IPv6 a nivel general y evaluar el impacto que puede tener este cambio de tecnología en una empresa. Alcances Comprende analizar los cambios en el protocolo y las formas de implementación. En la evaluación de impacto se hace mención a algunas formas de transición. Introducción Cada computadora conectada a Internet necesita una dirección IP única, que la identifique de manera lógica y jerárquica. Las direcciones actualmente en uso están referidas al Internet Protocol version 4 (IPv4). Este protocolo pertenece a la capa de red del modelo OSI y hoy en día es el utilizado como base para las comunicaciones de internet. En él, las direcciones son representadas por un número binario de 32 bits permitiendo una cantidad total de 2 32, aproximadamente 4,3 billones, direcciones posibles. También se pueden expresar como números de notación decimal dividiendo los 32 bits de la dirección en cuatro octetos. El valor decimal de cada octeto está comprendido en el rango de 0 a 255, y están separados con un carácter único ".". Por ejemplo: Si bien 4,3 billones parece ser una cantidad elevada de direcciones posibles, es realmente insuficiente para las necesidades futuras. Durante mediados de los años noventa se ha ido adoptando Internet de forma masiva y comercial. Desde entonces ha crecido exponencialmente y seguirá creciendo de tal manera debido al desarrollo económico y al crecimiento de la población mundial. Cada vez más dispositivos están siendo diseñados teniendo la conectividad a internet como parte de su esencia: netbooks, notebooks, tablets, smartphones, consolas de videojuegos, automóviles, televisores y demás electrodomésticos. Está en auge el concepto de la internet de las cosas que tiene como visión que cada artefacto electrónico pueda estar conectado a internet, ya sea para permitir ser controlado remotamente, o para intercambiar información con otros dispositivos, entre muchas otras posibilidades. Desde antes de la adopción masiva comercial de internet se han escrito informes que concientizan sobre el futuro agotamiento de las direcciones IPv4 de 32 bits. La RFC1287 [1], es un informe que Página 1/14

2 analiza la evolución de la futura arquitectura de internet, emitida por la Internet Engineering Task Force (IETF) en diciembre del 1991; en él se describe el enrutamiento y direccionamiento como: "El problema arquitectónico más urgente, ya que está directamente involucrado en la capacidad de internet de continuar creciendo exitosamente". A lo largo de los años se han desarrollado mejoras con el objetivo de combatir algunas de las problemáticas relacionadas con el agotamiento de direcciones. Sin embargo tienen ventajas y desventajas discutibles. A continuación se describirán algunas técnicas y mecanismos. - Classless Inter-Domain Routing (CIDR) fue estandarizado en 1993 por RFC 1518 [2] y RFC 1519 [3] como una medida de mediana magnitud para disminuir la velocidad en la cual el espacio de las direcciones IPv4 se agote, extendiendo la vida útil de IPv4. La introducción de CIDR permitió una mayor flexibilidad al dividir rangos de direcciones IP en redes separadas. De esta manera permitió un uso más eficiente de las cada vez más escasas direcciones IPv4, y un mayor uso de la jerarquía de direcciones ('agregación de prefijos de red'), disminuyendo la sobrecarga de los enrutadores principales de Internet para realizar el encaminamiento. - Network Address Traslation (NAT), estandarizado en 1994 por RFC 1631 [4], abordó la demanda permitiendo que una simple dirección sea usada para conectar una red completa, cuando antes una dirección había sido requerida para cada dispositivo de la red. En NAT, las direcciones IP dentro del dominio no son únicas en el mundo. Se vuelven a utilizar en otros dominios. Además de haber sido una buena solución a corto plazo para el agotamiento de direcciones, la principal ventaja es que permitió ser instalado de forma incremental sin cambios en routers o hosts. Sin embargo su inserción ha introducido problemas técnicos para muchos protocolos y servicios, los cuales han llevado al desarrollo de "soluciones provisorias", entre las cuales están: - NAT Port Management Protocol (NAT- PMP). - Traversal Using Relay NAT (TURN). - Standard Traversal of UDP through NAT (STUN). Desafortunadamente, ninguno de estos es universal y cada uno introduce sus propios problemas técnicos. A pesar de sus desventajas, NAT es actualmente un medio utilizado para conectar redes de internet. Se implementan múltiples sistemas NAT, generalmente denominados "NAT en capas", como medida de reducción de demanda de direcciones IPv4. Sin embargo no es una solución óptima porque de esta forma los inconvenientes que NAT presenta en sí mismo, por ejemplo los problemas de rendimiento, se ven agravados. Como solución a largo plazo para los problemas de IPv4 se desarrolló: Internet Protocol version 6 (IPv6), oficialmente estandarizado en 1995 en el RFC 1883 [5], seguido por una actualización en 1998 (RFC 2460 [6] ). A partir de los años correspondientes a estas publicaciones, puede notarse que se desarrolló de forma paralela a NAT y CIDR. También vale aclarar que su número de versión se debe a que ya existía IP version 5 (IPv5), un protocolo creado como versión experimental para testear las características de transferencia de medios. IPv6 tiene direcciones mucho más largas que IPv4, definidas con 128 bits en oposición a los 32 bits respectivamente. Ésta es una gran ventaja ya que la cantidad de direcciones posibles es extraordinaria: Página 2/14

3 3,4 x direcciones, o 6,7 x direcciones por metro cuadrado de la superficie de la Tierra. A pesar de los beneficios de este nuevo protocolo, a causa de la falta de información y difusión todavía hay grandes barreras para la adopción de IPv6 a nivel global. Desarrollo Agotamiento En Febrero de 2011 el IANA ( Internet Assigned Numbers Authority) entrego dos de los últimos siete bloques de direcciones /8 que tenía disponibles a la región Asia- Pacifico. Al quedar solo cinco bloques se disparo un proceso por el cual cada uno de los cinco RIR (Regional Internet Registry) recibe un último bloque de direcciones para que lo asignen a las entidades que lo soliciten. En base a proyecciones basadas en el consumo actual de bloques IPv4 los RIR van a agotar su stock de direcciones en las siguientes fechas estimadas: APNIC Actualmente Agotado [7] RIPE NCC 15 de Junio de 2012 [7] ARIN 30 de Mayo de 2013 [7] LACNIC 16 de Febrero de 2014 [7] AFRINIC 29 de Mayo de 2014 [7] agotamiento ocurrirá en el primer semestre de 2014, lo que permite un escenario de transición mas tranquilo. Qué es IPv6? IP versión 6 (IPv6) es una nueva versión del Protocolo de Internet (IP) designado como sucesor de IPv4. Los cambios de IPv4 a IPv6 pueden encuadrarse en las siguientes categorías: - Aumento de la capacidad de direccionamiento. - Simplificación del formato del encabezado. - Mejoramiento del soporte para extensiones y opciones. - Capacidad para etiquetar flujos de tráfico. - Capacidades de autenticación y privacidad. Direccionamiento El protocolo IPv6 establece tres tipos de direcciones: Unicast: Identifica una única interfaz. Un paquete enviado a una dirección unicast es entregado a la interfaz identificada por esa dirección. Anycast: Identifica a un conjunto de interfaces (que pertenecen a diferentes equipos). Un paquete enviado a una dirección anycast se entrega a una de las interfaces identificadas pero siendo esta la más cercana, de acuerdo a la medida de la distancia de la ruta. Figura 1: RIR IPv4 Address Run-Down Model [7] Como se puede observar la región de APNIC (Asia pacifico) ya agotó su pool de IPv4, y la próxima región en agotar su stock seria Europa. Respecto a la situación Latinoamericana se estima que el Multicast: Identifica a un conjunto de interfaces (normalmente pertenecientes a diferentes equipos). Un paquete enviado a una dirección multicast se entrega a todas las interfaces identificadas por esa dirección. Página 3/14

4 A diferencia de IPv4 en IPv6 no existen direcciones de Broadcast debido a que su funcionalidad queda incluida en el tipo Multicast de IPv6. Representación de una dirección IPv6 La forma estándar de representar una IPv6 como cadena de texto es x:x:x:x:x:x:x:x donde las x son valores hexadecimales de 16 bits. Ejemplos: 2001:0:4137:9e76:1015:2828:3f57:fedd fe80::1015:2828:3f57:fedd La numeración IPv6 soporta una representación comprimida en la cual los grupos que son "0" se pueden comprimir de forma tal de acortar las direcciones. Y si hay una secuencia de grupos que son "0" es posible comprimir todos los grupos. Ejemplos: 2001:0DB8:0000:0000:0000:0000:1428:57 ab 2001:0DB8:0000:0000:0000::1428:57ab 2001:0DB8:0:0:0:0:1428:57ab 2001:0DB8:0::0:1428:57ab 2001:0DB8::1428:57ab Payload Lenght: entero sin signo de 16 bits que indica la longitud de datos (en octetos) que el paquete está llevando. Next Header: un campo de 8 bits que identifica qué tipo de encabezado se adjunta después de este encabezado (igual que en IPv4). Hop Limit: entero sin signo de 8 bits. Se decrementa en una unidad por cada nodo que reenvía el paquete. Source Address: dirección IPv6 de 128 bits que origina el paquete. Destination Address: dirección IPv6 de 128 bits de destino. Arquitectura de Direccionamiento [8] Los tipos de direcciones IPv6 son identificados por los bits de mayor orden de la dirección como se indica a continuación: Tipo Notación IPv6 Inespecífica ::/128 Loopback ::1/128 Multicast FF00::/8 Link-Local Unicast FE80::/10 Global Unicast Todas las demás Las direcciones Anycast son tomadas del espacio de direcciones Unicast y no son distinguibles sintácticamente de ellas. Encabezado El encabezado de un paquete IPv6 respecto a uno IPv4 fue simplificado. La cabecera consta de ocho campos: Version: un campo de 4 bits = 6 Traffic Class: un campo de 8 bits con la clase de tráfico que el paquete transporta. Flow Label: 20 bits para la etiqueta del flujo. Direcciones Unicast Las direcciones IPv6 unicast son agregables con prefijos arbitrarios como se hace en IPv4 mediante CIDR. Existen varios tipos de direcciones unicast en IPv6, en particular, Global-Unicast y Página 4/14

5 Link-Local unicast. Además existen varios subtipos dentro de Global-Unicast. La dirección de 128 bits usualmente se divide en dos secciones de n bits y 128-n bits para definir el prefijo de subred y el identificador de la interfaz. Esto facilita las tareas de ruteo de paquetes y jerarquización de la red. Identificadores de Interfaces Los identificadores de interfaz sirven para etiquetar interfaces en un mismo medio físico. Son únicas dentro de un mismo prefijo de subred. En general los identificadores de interfaz son de 64 bits y se generan con el formato EUI-64 y se derivan de la dirección MAC asignada a cada interfaz física de red. La dirección inespecífica La dirección 0:0:0:0:0:0:0:0 se denomina dirección inespecífica. Jamás debe ser asignada a un nodo. Indica la ausencia de dirección. Esta dirección se utiliza en el campo Source Address de un paquete IPv6 enviado por un host antes de haber aprendido su propia dirección. La dirección Loopback La dirección unicast 0:0:0:0:0:0:0:1 se denomina dirección de loopback. Puede ser usada por un host para enviarse un paquete IPv6 a sí mismo. No debe ser asignada a ninguna interfaz y debe tratarse con un alcance Link-Local. Direcciones Globales Unicast. El formato general para las direcciones IPv6 Globales Unicast es el siguiente: N bits: global routing prefix M bits: subnet ID 128-N-M bits: interface ID El global routing prefix es un prefijo asignado al sitio (empresa, oficina, hogar, etc.). El id de subnet, identifica a la subred en el sitio. El id de interfaz identifica al host dentro de la red. Direcciones Unicast Link-Local Las direcciones de Enlace Local (Link- Local) solo se utilizan en la misma capa física compartida por todos los host de la red (no se encaminan). Poseen el siguiente formato: 10 bits: bits: con 0 64 bits: interface ID El propósito de las direcciones locales es para poder realizar la autoconfiguración de la dirección global, o utilizar el protocolo Neighbor Discovery o cuando no hay routers presentes en la red. Direcciones Anycast Una misma dirección anycast es asignada a diferentes hosts con la funcionalidad de que los paquetes enviados a esta dirección sean respondidos por el host más cercano al origen. Típicamente usada en los servidores raíz de DNS. Direcciones Multicast Una dirección IPv6 de multicast identifica a un grupo de interfaces (típicamente en Página 5/14

6 diferentes hosts). Una interfaz puede pertenecer a diferentes grupos multicast. El formato es el siguiente: 8 bits en 1 4 bits de flag 4 bits de scope 112 bits de identificador de grupo Existe varios grupos de direcciones multicast reservados. Dos direcciones útiles son: FF01::1 Todos los hosts FF01::2 Todos los routers En caso de que enviemos paquetes a FF01::1 todos los hosts de la red van a recibirlos, en el caso de enviar una solicitud de ECHO (ping) vamos a recibir por cada echo enviado, una respuesta de cada host en la red. Autoconfiguración de Interfaces [9] El proceso de autoconfiguración incluye generar una dirección del tipo link-local, otra dirección del tipo global mediante el proceso SLAAC (Stateless Address Autoconfiguration) y verificar que las direcciones no estén duplicadas mediante el procedimiento DAD (Duplicate Address Detection). La autoconfiguración es realizada solo sobre enlaces con capacidad multicast y comienza cuando una interfaz es iniciada (por ejemplo cuando arranca un host). En una primera etapa se genera la identificación de la interfaz y se adjunta al prefijo de las direcciones link-local (FE80::0) de forma tal de tener la dirección IPv6 link-local en el host. Antes que el host pueda utilizar su dirección link-local es necesario verificar que esa misma dirección no esté siendo usada por otro host en la misma LAN. Puntualmente el host envía mensajes de Neighbor Solicitation que contienen la IPv6 linklocal que pretende usar. Si otro nodo está usando esa dirección va a responder con un Neighbor Advertisement informando de esta situación. Si la dirección está en uso es necesaria la configuración manual de la interface. Una vez que el host se asegura que la IPv6 link-local está disponible, la asigna a la interfaz. En este punto el host tiene conectividad IP en la LAN. El próximo paso de la autoconfiguración es la obtención de una dirección de alcance global, para esto la interfaz envía paquetes de Router Solicitations a la LAN utilizando la IP link-local. El Router va a responder con la información necesaria (global routing prefix, subnet ID, MTU, hop limit, next hop) para poder realizar la autoconfiguración o solicitar la información a un servidor DHCPv6. Los mensajes de Neighbor Solicitation, Advertisement, Router Solicitations, etc. se podrían equiparar en IPv4 a ARP (Address Resolution Protocol), ICMP Router Discovery, e ICMP Redirect. Mecanismos de Transición Para redes que recién comienzan a armarse o redes ya desarrolladas es necesario contemplar los mecanismos de transición que van a permitir a redes nativas IPv6 comunicarse con redes IPv4, y redes IPv4 comenzar el camino hacia IPv6. Hay que entender que este proceso no es sencillo y se tienen que planear los pasos Página 6/14

7 de manera correcta para no encontrar problemas graves. Para poder realizar la transición existen varias tecnologías como: Dual Stack, IPv6-in-IPv4 tunnelling, Tunnel Brokers, ISATAP, 6to4 y Teredo entre otros. En este documento vamos a analizar únicamente Túneles Teredo y Dual Stack ya que son los que más importancia han tomado y de más sencilla implementación. Dual Stack Por su sencillez, ésta es la forma más deseable para que coexistan IPV4 e IPV6; y probablemente sea el camino más utilizado a largo plazo. No es un mecanismo de transición en sí ya que en realidad consiste en integrar IPV6. Utilizando este método los nodos IPv4/IPv6 (Dual Stack) son configurados con direcciones en ambas versiones del protocolo, por lo tanto este nodo puede enviar y recibir datagramas que pertenecen a IPv4 e IPv6 respectivamente y comunicarse con los equipos de la red en cada versión. El problema de este tipo de solución es que hace pocos años los Firewalls y Routers de marcas importantes (Juniper, Cisco, etc.) comenzaron a soportar este tipo de arquitectura; pero equipos más pequeños de pequeñas y medianas empresas todavía no tienen soporte, por lo tanto es necesario que inviertan parte de su capital en actualizar sus equipos (HW y/o SW) y poder desplegar esta tecnología. Túneles Teredo Figura 2: [11] Red Dual Stack Los túneles Teredo es una forma de túnel automático con la intención de proveer conectividad IPv6 a host que funcionan en redes IPv4 detrás de un NAT. Es un túnel automático Host-to-Host que encapsula los paquetes IPv6 en IPv4 utilizando mensajes UDP en el puerto Para que el servicio funcione es necesario disponer de un servidor Teredo el cual va a desencapsular los paquetes IPv6 que se encuentran dentro de la conexión IPv4; luego los reenviará a lo que se llama "Teredo Relay", que es un router IPv6 encargado de dirigir el paquete al host IPv6 correspondiente. En el momento en el que el cliente se conecta al servidor Teredo se lo otorga una dirección IPv6 la cual es usada como dirección de origen para sus próximas conexiones contra hosts IPv6. La estructura de la dirección se ve en el esquema de la figura 3. Figura 3: [12] Teredo Address IPv6 en protocolos de capa superior y aplicaciones. El impacto de IPv6 en los protocolos de capa superior es mínimo, porque el Página 7/14

8 servicio de datagramas no cambió demasiado. DHCP El servicio de DHCP es utilizado globalmente para configurar hosts automáticamente con IPv4 además de otros parámetros adicionales. En las redes IPv6, DHCP no es necesario para la asignación de direcciones debido a la existencia de SLAAC, excepto para las redes que requieran un direccionamiento que no pueda ser cumplimentado con SLAAC, o con asignación dinámica de direcciones. O en casos en que se requiere configurar mas parámetros que solamente la IP, como ser servidores de DNS, nombre de dominio, etc. En estos casos si es necesario el despliegue de DHCP. DNS El servicio de DNS es utilizado en el mundo IPv4 para hacer mapeos iphostname y viceversa. Esto no cambia en IPv6, de hecho se vuelve algo mas crítico y necesario, debido a que ya no va a ser posible recordar direcciones IP de memoria. A los efectos de realizar un mapeo hostname-ip se introducen los registros AAAA (Quad A) Un ejemplo de registro AAAA puede ser: dom.com IN AAAA 4321:0::89ab Para los registros reverses (PTR) se establece un dominio raiz IP6.ARPA ip6.arpa IN PTR gx-in-x67.1e100.net. A los efectos prácticos al día de hoy la mayoría de los servidores de DNS autoritativos soporta los registros AAAA (Bind, powerdns, etc.). HTTP y Browsers. Los principales servidores Web ya cuentan con soporte IPv6, lo único necesario es habilitar el servicio en la interface IPv6. Los browsers por otro lado también cuentan con soporte IPv6, básicamente tienen mecanismos de auto detección IPv6, de forma que pueden saber si cuentan con doble pila o no. En caso de contar con doble pila, cuando el usuario ingresa el URL de un sitio en el navegador, se realizan 2 consultas de DNS, una A y una AAAA, si el sitio web esta publicado en IPv6, el browser va a darle más prioridad al contenido IPv6 y en caso de que no esté disponible va a intentar por IPv4. Despliegue IPv6 Caso: Universidad de Southampton La universidad de Southampton ha estado utilizando IPv6 en sus redes desde 1996, pero desde 2005 a adoptado este protocolo como un protocolo de producción. La implementación abarca las siguientes categorías de componentes: - Equipamiento de red - Direccionamiento - Servicios - Plataformas y dispositivos Página 8/14

9 Red - Herramientas de usuario Las tecnologías utilizadas en la red son, Switches Ethernet, Gigabit Ethernet y Wireless networking (802.11b). La capa de ruteo está compuesta por switches Layer 3 con rutas estáticas. El firewall posee dos DMZ (zona desmilitarizada), una para los hosts cableados y otra para los dispositivos inalámbricos. Existen puntos de entrada para usuarios remotos por VPN. Direccionamiento En la actualidad se poseen 10 segmentos IPv4 /24 asignados al departamento de sistemas del campus. Para IPv6, JANET (ISP regional para entidades académicas) tiene el prefijo 1001:630::/32 asignado por RIPE NCC. El departamento recibió un bloque / :630:d0::/52. En el despliegue inicial, se espera que las subredes IPv4 e IPv6 corran sobre los mismos vínculos físicos. Asignación de direcciones IPv6 La asignación de direcciones va a ser realizada por medio de una combinación de mecanismos: - Configuración manual para algunos servidores - Stateful DHCPv6 (para dispositivos cableados y algunos servidores). - SLAAC (para dispositivos inalámbricos). Servicios Existen tres hosts que reciben correo electrónico desde internet y dos servidores de correo internos. Sendmail es el principal MTA (Mail Transfer Agent). POP e IMAP son usados para acceder a las casillas de correo. Además existe un servidor Microsoft Exchange utilizado por 200 usuarios (que requieren funcionalidades de colaboración) Alojamiento Web El contenido web es publicado con Apache 1.3.x o MS IIS 5.0. Bases de Datos Todas las bases de datos son presentadas mediante una interfaz web. Existen bases de datos financieras, de alumnos, proyectos, publicaciones, etc. Servicios de Directorio Se utilizan diferentes servicios de directorio, NIS, LDAP, Active Directory y RADIUS. DNS Existen tres servidores de DNS BIND9 y un DNS secundario se encuentra alojado en otra universidad de UK. PKI El departamento tiene al menos 10 certificados SSL provistos por Thawte para cifrar sitios web. Página 9/14

10 Plataformas de Servidores y Hosts Se cuenta con dispositivos con sistemas operativos Windows Server, Solaris, RedHat Linux, MacOS/x, BSD, etc. Estado de la transición El proyecto se focalizó en proveer funcionalidades IPv6 en un ambiente de doble pila (dual-stack), con el objetivo de permitir que dispositivos que solo soporten IPv6 puedan conectarse a la red y operar satisfactoriamente los servicios básicos (DNS, NTP, SMTP, etc). Debido a que parte del equipamiento del core de la red no soporta ruteo IPv6, se planteó un método alternativo para poder entregar IPv6 en la infraestructura IPv4 existente. Para permitir esto, se implementó una infraestructura paralela para poder entregar Router Advertisements. Esto se implementó mediante routers BSD que permiten inyectar diferentes prefijos de subred IPv6 en diferentes subnets IPv4 usando como base las vlans ipv4 existentes. Figura 4: [11] Southampton (ECS) IPv4/v6 dual stack deployment Como el tráfico dentro de la red crece, paulatinamente se pueden agregar diferentes routers para procesar el tráfico o agregar un router con múltiples interfaces. Actualmente existen cuatro routers con cuatro interfaces cada uno. Sin embargo, los sistemas BSD están llegando a un límite de capacidad cuando hay picos de trafico IPv6. La conectividad IPv6 externa se hace mediante un Cisco 7206 para trafico unicast y multicast, internamente se rutea el trafico a las diferentes vlans usando el soporte multicast de los routers BSD. La conectividad a JANET IPv6 se realiza por medio del ISP LeNSE. A largo plazo, se prevé utilizar el firewall Nokia IP740, momentáneamente el firewall es otro sistema BSD con un firewall parcialmente statefull que bloquea el trafico por default. En lo que respecta al servicio de DNS, los tres servidores de DNS primarios corren IPv6. Y esto incluye la delegación de los reversos de las bloques ipv6 asignados. El servidor Linux principal posee dual stack, con acceso ssh y sftp para transferencias de archivos (permitido por el firewall bsd). Una vez que IPv6 está presente en la infraestructura interna lo único que se necesita hacer es abrir el puerto requerido en el firewall bsd, publicar un registro AAAA y habilitar el soporte ipv6 en la aplicación que queremos publicar. Para el caso de nuevos servicios solo se recomienda usar las versiones securizadas por certificados debido a que es más fácil de hacer en servicios nuevos más que en servicios no seguros operativos. Los servicios SMTP y servidores MX son publicados en IPv6, los registros de DNS Página 10/14

11 fueron agregados para los hosts que proveen estos servicios. Si se presenta el caso de tener disponibilidad v4 o v6 para enviar trafico smtp, se prefiere v6 por default. Casi la mayoría de los servicios web fueron publicados en IPv6 utilizando Apache 2, son aproximadamente 100 sitios. El acceso inalámbrico del departamento (más de 30 access points) habilitó IPv6, utilizando 802.1x como control de acceso permitiendo securizar IPv4 e IPv6 simultáneamente. Un punto para remarcar es que la transición al dual stack no produjo efectos colaterales sobre los actuales servicios en IPv4, tampoco afecto la robustez y la disponibilidad de la red. Usuarios remotos Para los usuarios remotos se proveyó de túneles 6to4. Ya sean estudiantes en sus hogares, o empleados en accesos wifi en conferencias. Actualmente se asignan direcciones /128 o /64. Para poder asignar bloques /48, es necesario que la universidad adquiera el estado de ISP para poder solicitar un bloque IPv6 /32. Próximos pasos Aunque mucho se ha hecho, los principales puntos pendientes son: - Despliegue de DHCPv6 con actualización de registro reverso. - Actualización de SNORT para adecuar la funcionalidad de IDS a IPv6 - Instalar un servicio de DNS dinámico para los hosts configurados con SLAAC Además se va a desplegar nueva infraestructura de red de marca Cisco. Un switch L y 30 switches 3750 van a ser desplegados con doble pila con soporte unicast y multicast. Componentes faltantes En el proceso de la transición se identificaron varios componentes carentes de soporte IPv6. Cabe destacar que esta transición fue documentada en 2005 y muchos componentes pueden disponer de soporte IPv6 en Principalmente la falta de soporte se dio en los siguientes sistemas: - Capacidad de ruteo IPv6 en switches L3. - NFS/Samba. - MS Exchange y Outlook - IDS - Active Directory - Windows 98/2000/ME - Irix - Varios modelos de PDA Esta lista de componentes sin soporte, no lograron impedir el despliegue IPv6, al contrario, favorecieron la creación de un nuevo ambiente, nuevas aplicaciones. Algunos nodos fueron actualizados a IPv6 y otros simplemente van a permanecer en IPv4 en modo legacy. Transición en la Empresa Una de las decisiones más complejas respecto a IPv6 a la que se enfrenta una organización es por dónde comenzar. En la infinidad de escenarios, tomamos tres para desarrollar. Página 11/14

12 Vuelco masivo Planificar un vuelco masivo puede parecer profesional y acertado, pero es un error pensar que es un buen comienzo para la transición. Realizar un vuelco masivo implica convertir todo el equipamiento de red, los servicios de DHCP, DNS, aplicaciones, clientes, servidores, etc. Esta postura es inviable debido que tiene altísimo riesgo y no provee beneficios de negocio. Trabajar desde el exterior al interior Esta estrategia se enfoca en el sitio web de la organización. Usualmente los servidores web (IIS de Microsoft, Apache HTTPD, etc.) se alojan detrás de balanceadores de carga (OpenSource o comerciales). En este plan, el objetivo es simple: actualizar a IPv6 todos los componentes en el camino desde el proveedor de Internet y el balanceador de carga, permitiendo que el balanceador haga la traducción IPv6-IPv4. El alcance de este proyecto es razonable y tangible que puede ser explicado a la gerencia sin ser demasiado técnicos. Sin embargo le aporta al sector técnico de la empresa know-how sobre el nuevo protocolo. Una visión más local A nivel local, el desarrollo de IPv6 es lento, recién en 2011 algunos ISP están realizando pruebas con clientes reales y empezando a cursar trafico IPv6 nativo por sus redes. Si miramos la conectividad a internet como 3 grandes capas casa de cliente red de acceso backbone, los mayores problemas de despliegue están en las redes de acceso, desde el CPE hasta el Router de borde del ISP. Es imprescindible que las áreas técnicas de las empresas empiecen a familiarizarse con IPv6, la mayoría del personal IT tiene años, incluso décadas de experiencia IPv4, pero escasa experiencia en IPv6. La transición a v6 requiere: una nueva forma de administrar las redes (IPAM). nuevas formas de securizacion. planificar un entrenamiento en ipv6. realizar relevamientos de las capacidades del equipamiento de red. permite comenzar de nuevo con el diseño de la infraestructura, corrigiendo errores del pasado. Aporte El presente paper brinda al lector una mirada sobre la problemática de la transición de IPv4 a IPv6. En la actualidad, Internet brinda excelentes sitios que contienen información sobre el tema, sin embargo, todavía no existen tendencias claras en cuanto a cómo resolver muchos de los problemas de la transición. Además muchos de éstos están siendo discutidos actualmente en las listas de la IETF con el objetivo de generar mejores estándares. Discusión El presente trabajo es introductorio, el alcance está acotado a una explicación general del protocolo y a ciertos criterios de transición. Conclusión La transición a IPv6 es algo inevitable. Cisco Systems calcula que 200 millones de Página 12/14

13 ingenieros van a tener que ser capacitados en todo el mundo en este nuevo protocolo. El agotamiento de direcciones es algo que está acelerando la transición, pero todavía en el volumen total del tráfico de internet la porción que corresponde a IPv6 es casi inexistente. Depende de nosotros, los usuarios, estudiantes y profesionales de IT, concientizar e influenciar a los proveedores de equipamiento e Internet a que desplieguen IPv6 en sus equipos y redes. Mucho se ha hecho en la evolución de los protocolos de internet, pero todavía hay muchos puntos oscuros en cómo realizar una transición ordenada. Es necesario que las universidades incluyan IPv6 en los contenidos de las materias de Redes de Comunicaciones. Sólo de esta forma los futuros profesionales van a estar mejor preparados, y tendrán un camino más llano al momento de proponer mejoras en las redes de las empresas. (Accedido: 10 de Octubre de 2011) [9] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address Autoconfiguration", [online] (Accedido: 10 de Octubre de 2011) [10] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", [online] (Accedido: 10 de Octubre de 2011) [11] GAO, "Example of a Dual Stack Network", [online] (Accedido: 10 de Octubre de 2011) [12] Mynetworkingwiki.com, "Teredo Address", [online] eredo-address.jpg/700px-teredo-address.jpg (Accedido: 10 de Octubre de 2011) Datos de Contacto: Eduardo Casarero. UADE ecasarero@uade.edu.ar Santiago Santiago. UADE saruiz@uade.edu.ar Alejandro Clemente. UADE aclemente@uade.edu.ar Referencias [1] D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby, "Towards the Future Internet Architecture", [online], (Accedido: 10 de Octubre de 2011) [2] Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with CIDR", [online] (Accedido: 10 de Octubre de 2011) [3] V. Fullner, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", [online] (Accedido: 10 de Octubre de 2011) [4] K. Egevang, P. Francis, "The IP Network Address Translator (NAT)", [online] (Accedido: 10 de Octubre de 2011) [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", [online] (Accedido: 10 de Octubre de 2011) [6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", [online] (Accedido: 10 de Octubre de 2011) [7] Huston, Geoff. "IPv4 Address Report, daily generated". [online] (Accedido 15 de Octubre de 2011) [8] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", [online] Página 13/14

14 Página 14/14