Internet2 e IPV6

 

 

 Marcelo Claudio Périssé

Universidad Nacional de La Matanza

 Palabras Claves: Tecnología de la Información, Computación, Redes, Internet, Internet2, IPv6

 

Sumario

1. Introducción

1.1. Internet2

1.1.1. Internet2 en Argentina

1.1.1.1. Aspectos técnicos

1.1.2. Interne2 en Latinoamérica

1.1.2.1. Descripción Técnica

1.1.2.2. Servicios de RedCLARA

1.1.2.3. Ingeniería de Tráfico de RedCLARA

2. IPv6

2.1. Introducción a IPv6

2.1.1. Historia de IPv6

2.1.2. Porqué surge IPv6

2.1.3. Características de IPv6

2.1.4. Descripción general de las redes IPv6

2.1.5. Descripción general de las direcciones IPv6

2.1.6. Partes de una dirección IPv6

2.1.7. Tecnologías Involucradas en IPv6

2.1.7.1. Multicast

2.1.7.2. Calidad de Servicio QoS

2.1.7.3. Video conferencia

2.1.7.4. Servidores NTP

3. Planificación de una red IPv6

4. Aplicación en la UTN – Regional la Plata (UTN-FRLP)

5. Bibliografía

 

1. Introducción

1. 1. Internet2

Internet2 es un consorcio, conducido por más de 200 universidades que trabajan en conjunto con la industria y el gobierno para desarrollar aplicaciones y tecnologías avanzadas de redes con origen en EE.UU.

Internet2 se encuentra construyendo alianzas similares entre el sector académico, la industria y el gobierno de EE.UU. que dieron origen a la actual Internet.  Así como las herramientas que utilizamos todos los días en Internet son el resultado de la colaboración y las inversiones previas en el área académica y de investigación, se espera que lo mismo ocurra con las nuevas posibilidades que se desarrollan actualmente.

Las metas de Internet2 son:

Crear una red de alta capacidad para la comunidad académica,

desarrollar nuevas aplicaciones de Internet.

Que se traducen en el objetivo primario de unir los esfuerzos y recursos de las instituciones académicas, la industria y el gobierno para desarrollar nuevas tecnologías y aplicaciones que luego serán extendidas a la Internet global.

Cabe destacar que Internet2 no es una red separada físicamente ni reemplazara a Internet tal cual hoy está conformada.

El backbone de Internet2 está constituido por redes de alta velocidad, fundamentalmente:

Abilene (http://www.internet2.edu/network/),

Red de Ingeniería e Investigación para la Defensa (DREN - http://www.hpcmo.hpc.mil/Htdocs/DREN/index.html),

Red de Ciencias de la Energía del Departamento de Energía de los EE.UU. (ESnet - http://www.es.net/),

Red de Servicios Integrados de la NASA (NISN - http://www.nisn.nasa.gov/),

Red de Investigación y Educación de la NASA (NREN - http://www.nren.nasa.gov/)

vBNS+ (Defense Research and Engineering Network -http://www.vbns.net/).

Este backbone de redes atraviesa el país uniendo 53 redes regionales que están estratégicamente dispersas a lo largo de los EE.UU. Cada red regional provee una conexión llamada un GigaPop (gigabit Point of Presence); el cual es  punto de acceso a Internet que admite, al menos, una conexión de un gigabit por segundo y que vincula Abilene con sus nodos de acceso. Aproximadamente 150 de estos nodos de acceso están distribuidos a lo largo de los EE.UU.

 

Figura 1. Fuente http://www.internet2.edu/pubs/networkmap.pdf

 

Internet2  no es simplemente una Internet con mayores anchos de banda, sino que está compuesta de nuevas aplicaciones que no se pueden realizar en la actualidad, entre ellas se puede citar a título de  ejemplo:

Bibliotecas Digitales,

laboratorios virtuales,

educación independiente de la distancia y tele-inmersión.

Paralelamente a esta iniciativa de los EE.UU. surgen proyectos similares en otras partes del mundo, con los mismos objetivos; entre ellos se encuentran:

CANARIE (http://www.canarie.ca/) – Canada’s Advanced Network

con su CA*net3 (http://www.canet3.net/),

APAN (http://www.apan.net/) – Asia-Pasific Advanced Network,

NORDUnet (http://www.nordu.net/) – Nordic Infrastructure for Research & Education,

TERENA (http://www.terena.nl/) - Trans-European Research and Education Networking Association,

GÉANT (http://www.geant2.net/) y otras.

1.1.1. Internet2 en Argentina

Con fecha 18 de diciembre de 2006 se firmó un convenio entre la Secretaría de Comunicaciones de la Nación (SECOM), la Secretaría de Ciencia, Tecnología e Innovación Productiva (SECYT) hoy el Ministerio de Ciencia Tecnología e Innovación Productiva, y el Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET); por el cual se encomendó a la Fundación INNOVA-T (entidad vinculada al CONICET), que efectúe las gestiones necesarias para obtener la conexión internacional con el sistema de Redes Avanzadas (Internet2), y tome a su cargo la operación nacional de la misma dentro del proyecto denominado Innova|Red.

El mencionado convenio prevé la creación de un consejo asesor y de seguimiento de Innova|Red, constituido por representantes de las instituciones estatales mencionadas y de los usuarios y prestadores del sistema.

El objetivo principal de Innova|Red es el desarrollo de  Redes Avanzadas reservadas en Argentina para las comunidades académicas, de manera que científicos y tecnólogos puedan intercambiar información y comunicarse de manera más ágil y efectiva. Un elemento técnico diferenciador de las Redes Avanzadas es la llamada Calidad de Servicio, que en términos simples implica la ausencia de congestión excesiva y fallas en la comunicación. Esto permite, entre otras ventajas, la operación remota de sistemas críticos tales como brazos robóticos en telemedicina o el control de plantas, procesos o sistemas de alto riesgo, aplicaciones para las cuales es inaceptable una interrupción o demora en la red de comunicaciones.

La Fundación INNOVA-T asumió a partir del 1° de abril de 2007 las actividades mencionadas comprometiéndose a una administración ágil y eficiente de Innova|Red, y a procurar una creciente incorporación de nuevos usuarios que posibiliten la expansión de la red y la autosustentabilidad del proyecto en el mediano plazo.

Figura 2. Topología Argentina 2005
 

1.1.1.1.  Aspectos técnicos

En el equipo ws2.retina.ar (Debian <http://www.debian.org/>  stable con quagga <http://www.quagga.net/>) se ha configurado el stack IPv6 y se han configurado túneles (RFC 2893 ) y Protocolo de enrutamiento exterior BGP4 (Border Gateway Protocol)  con los siguientes puntos:


· UNAM: Universidad Nacional Autónoma de México

· RedIRIS: Red española de I+D

· RAU: Red Académica Uruguaya

· UACH: Universidad Austral de Chile

· ITESM: Tecnológico de Monterrey

· UBA CCC: Universidad de Bs As - Centro de Comunicación Científica

· CRIBABB: Centro Regional de Investigaciones Básicas y Aplicadas de Bahía Blanca

Figura 3. Conexiones vía Tuneling
 

Se configuró un router Cisco 2501 con dual stack de IPv4 e IPv6. Este router posee 16 MB de RAM y 16 MB de flash. La versión de IOS es la c2500-is-l.122-13.T1. Algunas estaciones de trabajo tendrán direcciones IPv6 además de las IPv4 y serán ruteadas a través de túneles o en modo nativo para llegar a otras instituciones.

A título comparativo se presenta la topología de la Red de la Universidad Nacional Autónoma de México (UNAM).

 

Figura 4. RedUNAM IPv6 nueva (provisional)
 

1.1.2. Interne2 en Latinoamérica

A nivel de Latinoamérica se encuentra la organización de Cooperación Latino Americana de Redes Avanzadas denominada RedCLARA y que se encuentra interconecta a las redes académicas avanzadas nacionales de Latinoamérica y a éstas con las redes de Europa GÉANT2, Estados Unidos Internet2, Asia APAN y el resto del mundo, otorgando a los científicos, académicos e investigadores de la región, una infraestructura que les permite colaborar efectivamente con la comunidad científica global.

RedCLARA comenzó a proveer conectividad a la región el 15 de noviembre de 2004 , enlazando a las redes de investigación y educación nacionales de América Latina, mediante los Puntos de Presencia (PoPs) establecidos en Argentina, Brasil, Chile, Panamá y México, y conectándolas con GÉANT2 a 622 Mbps a través de la conexión entre São Paulo (Brasil) y Madrid (España). En 2007 RedCLARA sumó un sexto nodo (PoP) a su troncal, en Miami (Estados Unidos), al que se conectan las redes centroamericanas. Gracias al proyecto WHREN/LILA, RedCLARA se conecta también con Estados Unidos, lo que se lleva a cabo mediante los enlaces del nodo de Tijuana (México) con San Diego (Costa Pacífico de EE.UU.) y del de São Paulo con Miami.

La arquitectura e ingeniería de RedCLARA, los tipos de enlaces y los procedimientos de intercambio de tráfico, están a cargo del Grupo de Ingeniería de la Red (NEG) de CLARA. El centro de Operaciones de la Red (NOC) es responsable de la administración, el control, el monitoreo y la operación diaria de todas las infraestructuras físicas y lógicas que conforman la troncal de RedCLARA, asegurando altos niveles de rendimiento y de operación de la red y de sus interconexiones.

RedCLARA no es sólo una infraestructura ideal para el crecimiento de las redes nacionales de investigación de la zona, con una capacidad de tráfico de datos sin precedentes, lo es también para el desarrollo de colaboraciones regionales e intercontinentales. Estimulando la cooperación regional, la promoción del desarrollo científico y tecnológico, y la integración directa con las comunidades científicas del mundo, RedCLARA es fundamental para la investigación y educación en América Latina: conecta a 12 países y 729 universidades a través del continente, a velocidades de hasta 622Mbps.

 

Figura 5. Topologia del backbones de la RedeCLARA
desde agosto de 2007
 

1.1.2.1. Descripción Técnica

CLARA es responsable de la implementación y manejo de la infraestructura de red que interconecta a las redes académicas nacionales (NREN) de América Latina. Con un gran número de universidades y centros de investigaciones conectados a RedCLARA, muchos proyectos que carecían de una infraestructura adecuada para sustentar los procesos de comunicación y colaboración, hoy están en posición de avanzar.

La troncal (backbone) de RedCLARA está compuesta por 6 nodos enrutadores principales, conectados en una topología lineal (punto-a-punto). Cada nodo principal (IP) representa a un PoP (Punto de Presencia) para RedCLARA, 5 de ellos están ubicados en un país de América Latina - São Paulo (SAO - Brasil), Buenos Aires (BUE - Argentina), Santiago (SCL - Chile), Panamá (PTY - Panamá) y Tijuana (TIJ - México)- y el sexto en Miami (MIA - Estados Unidos).

 

Figura 6. Backbone de RedCLARA y LA-NRENs 2007
 

Todas las conexiones de las redes nacionales latinoamericanas (NREN) a RedCLARA son a través de uno de estos seis nodos. La troncal de RedCLARA está interconectada con la red paneuropea GÉANT2 a través del enlace del PoP de CLARA en SAO con el punto de acceso de GÉANT2 en Madrid (España - ES), posibilitado por el Proyecto ALICE, y, con Estados Unidos, mediante los enlaces establecidos en los PoP de CLARA en SAO y TIJ, el primero con el PoP de AtlanticWave y el segundo con el PoP de PacificWave, estos dos últimos accesos son posibilitados por WHREN-LILA.



Figura 7. GÉANT2 Operada por DANTE - NRENs

 

Cuando una NREN latinoamericana hace conexión con RedCLARA, lo hace a través de uno de los seis nodos principales de la troncal de CLARA; esta conexión le brinda a estas NREN y a sus miembros (clientes), acceso a RedCLARA, otorgándoles un Punto de Intercambio.

1.1.2.2. Servicios de RedCLARA:

IPv4

Multicast

IPv6

QoS

Mediciones

Servicios específicos para proyectos: Mallas Computacionales (Grids).

1.1.2.3. Ingeniería de Tráfico de RedCLARA

Uso de Ingeniería de Tráfico MPLS en la troncal MPLS (Multiprotocol Label Switching) es un mecanismo de transporte de datos estándar creado por la IETF y definido en el RFC 3031. Opera entre la capa de enlace de datos y la capa de red del modelo OSI. Fue diseñado para unificar el servicio de transporte de datos para las redes basadas en circuitos y las basadas en paquetes. Puede ser utilizado para transportar diferentes tipos de tráfico, incluyendo tráfico de voz y de paquetes IP.

 

Tabla 1. Multiprotocol Label Switching
Label (20 bits): Es la identificación de la etiqueta.
Exp (3 bits): Llamado también bits experimentales, también aparece como CoS en otros textos, afecta al encolado y descarte de paquetes.
S (1 bit): Del inglés stack, sirve para el apilado jerárquico de etiquetas. Cuando S=0 indica que hay mas etiquetas añadidas al paquete. Cuando S=1 estamos en el fondo de la jerarquía.
TTL (8 bits): Time-to-Live, misma funcionalidad que en IP, se decrementa en cada enrutador y al llegar al valor de 0, el paquete es descartado. Generalmente sustituye el campo TTL de la cabecera IP.

 

Las aplicaciones sensitivas al retardo podrían "indicar" a la red su requerimiento por una vía diferente.
Los túneles definidos manualmente deberían prevalecer por sobre la decisión normal de proceso de enrutamiento IGP. 

2. IPv6

2.1. Introducción a IPv6

La Internet Enginnering Task Force (IETF - http://www.ietf.org/) creó el proyecto IPng: Internet Protocol the Next Generation, también llamado IPv6.

Esta nueva versión del Protocolo de Internet (IP) sustituirá progresivamente a IPv4, ya que brinda mejores características entre las que destacan:

espacio de direcciones prácticamente infinito;

posibilidad de autoconfiguración de computadoras y ruteadores;

soporte para seguridad, computación movil, calidad de servicio;

un mejor diseño para el transporte de tráfico multimedia en tiempo real, aplicaciones anycast y multicast;

posibilidad de transición gradual de IPv4 a IPv6.

El Internet Engineering Task Force (IET) ha producido un conjunto comprensible de especificaciones (RFC 1752, 1883, 1886, 1971, 1993, etc.) que definen la siguiente generación del IP conocido como " IPng " o " IPv6 ".

La nueva versión del Protocolo de Internet (IP) a la que nos estamos refiriendo es IPv6 y que está diseñada como un paso evolutivo del IPv4. Representa el fruto de muchas propuestas del IETF y de grupos de trabajo centrados en desarrollar un Internet Protocol the Next Generation (IPng).

2.1.1. Historia de IPv6

Para el invierno de 1992 la comunidad del Internet había desarrollado cuatro propuestas diferentes para el IPng que eran: CNAT, IP Encaps, Nimrod y Simple CLNP.

Después para diciembre del mismo año, aparecieron tres propuestas más el "PIP" (The P Internet Protocol), el "SIP" (The Simple Internet Protocol) y el "TP/IX".

En la primavera de 1992 el "Simple CLNP" se desarrolló en el " TUBA" (TCP and UDP with Bigger Addresses", y el " IP Encaps " en " IPAE " (IP Address Encapsulation)

Para el verano de 1993, IPAE se combinó con el SIP aunque mantuvo el nombre SIP, que posteriormente se fusionó con la PIPA, y al grupo de trabajo resultante se le llamó "SIPP" (Simple Internet Protocol Plus). Casi al mismo tiempo el grupo de trabajo TP/IX cambió su nombre por el de "CATNIP" (Common Architecture for the Internet)

Posteriormente, en la reunión del IETF del 25 de julio de 1994 en Toronto Canadá, los directores de área del mismo organismo recomendaron el uso del IPng y lo documentaron en el RFC 1752 como la recomendación para el protocolo IP de siguiente generación.

El 17 de noviembre del mismo año fue aprobada esta recomendación por el "IESG" (Internet Engineering Steering Group) que elaboró una propuesta de Estándar.

IPv6 en América Latina

Participantes

RETINA, UBA, UTN, Argentina

RNP, Brasil

UniCauca, UniPamplona, Colombia

Grupo de trabajo IPv6,Cuba

REUNA, UACH, Chile

ITAM, UNAM, UDG, ULSA, México

RAU, Uruguay

2.1.2. Porqué surge IPv6

Un problema de Direcciones IPv4 ¿recurso de Internet en agotamiento?

Cuando IPv4 se diseñó, con un espacio de direcciones de 32 bits,  a principios de la década de 1980 su número máximo, pero ideal de direcciones de cuatro mil millones, parecía astronómico; hoy, cerca del 81 % del total ya han sido asignadas, es decir, sólo queda el 19% del espacio. En cambio IPv6, al ofrecer un espacio de direcciones de 128 bits el número de direcciones asciende a 340 trillones de trillones.

 Dentro del problema de las direcciones lo importante no es saber cuándo se agotarán las direcciones IPv4, sino estar conscientes que el número de direcciones disponibles seguirá decreciendo.

Por ejemplo, a medida que más usuarios móviles y nuevas redes también móviles, requieran una dirección pública propia, habrá quienes intentarán seguir utilizando mecanismos como NAT (Traducción de Dirección de Red) y tratarán de recuperar bloques de direcciones IPv4, poco o no usados, para continuar con este recurso unos pocos años más.

 

Figura 8. Estimación del agotamiento de IPv4 según Geoff Huston.
 

ARIN (American Registry for Internet Numbers) y su equivalente en Latinoamérica LACNIC (Registro de Direcciones de Internet para América Latina y el Caribe), son organizaciones (RIRs) sin fines de lucro que adjudican o confieren direcciones IP a proveedores de Internet e instituciones, en Norteamérica y en Latinoamérica respectivamente. Junto con los otros tres RIRs restantes (AFRINIC, APNIC y RIPE), obtienen los bloques de direcciones de la IANA, en ese sentido, la jerarquía de adjudicaciones y asignaciones de los recursos de Internet es la siguiente:

IANA -> RIR -> NIC nacional (si existe) -> ISPs -> usuario final,

Por tanto IPv6 se presenta como alternativa al problema que podría ocasionar la falta de direcciones; que sin sustituir totalmente a las IPv4, pueden convivir ambas versiones mientras las aplicaciones así lo requieran.

Ante esta alternativa, se presenta como factor crítico el hecho de que mientras más tiempo se deje pasar en empezar a habilitar y probar IPv6, mayores serán los costos en inversión en aspectos como actualizaciones en Humanware, software y hardware; de lo que se estima que los costos más altos en la transición a IPv6 ocurrirán con el entrenamiento y no con el software.

En IPv6 (Internet Protocol Version 6) o IPng (Next Generation Internet Protocol) se mantuvieron las funciones del IPv4 que son utilizadas, las que no son utilizadas o se usan con poca frecuencia, se quitaron o se hicieron opcionales, agregándose nuevas características.

Otros de los problemas de IPv4 es la gran dimensión de las tablas de ruteo en el backbone de Internet, que lo hace ineficaz y perjudica los tiempos de respuesta.

Debido a la multitud de nuevas aplicaciones en las que IPv4 es utilizado, ha sido necesario agregar nuevas funcionalidades al protocolo básico, aspectos que no fueron contemplados en el análisis inicial de IPv4, lo que genera complicaciones en su escalabilidad para nuevos requerimientos y en el uso simultáneo de dos o más de dichas funcionalidades. Entre las más conocidas se pueden mencionar medidas para permitir la Calidad de Servicio (QoS), Seguridad (IPsec) y movilidad.

2.1.3. Características principales de IPv6

La característica que distingue a IPv6 es un mayor espacio de dirección comparado con IPv4. Asimismo, IPv6 mejora la capacidad en Internet en numerosos aspectos.

Direcciones ampliadas

El tamaño de direcciones IP pasa de 32 bits en IPv4 a 128 bits en IPv6, para permitir más niveles en la jerarquía de direcciones.

Figura 9. Headers IPv4 e IPv6. Fuente CISCO
 

Configuración automática de direcciones y descubrimiento de vecinos
El protocolo ND (Neighbor Discovery, descubrimiento de vecinos) de IPv6 facilita la configuración automática de direcciones IPv6. La configuración automática consiste en la capacidad de un host de IPv6 de generar automáticamente sus propias direcciones IPv6, cosa que facilita la administración de direcciones y supone un ahorro de tiempo.

El protocolo ND se corresponde con una combinación de los siguientes protocolos IPv4: Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Router Discovery (RDISC), e ICMP Redirect. Los encaminadores de IPv6 utilizan el protocolo ND para anunciar el prefijo de sitio de IPv6. Los hosts de IPv6 utilizan el descubrimiento de vecinos con varias finalidades, entre las cuales está solicitar el prefijo de un encaminador de IPv6.

Simplificación del formato del encabezado

El formato del encabezado de IPv6 prescinde o convierte en opcionales determinados campos de encabezado de IPv4. Pese al mayor tamaño de las direcciones, este cambio hace que el encabezado de IPv6 consuma el mínimo ancho de banda posible. Aunque las direcciones IPv6 son cuatro veces mayores que las direcciones IPv4, el encabezado de IPv6 sólo tiene el doble de tamaño que el encabezado de IPv4.

Más posibilidades en las opciones de encabezado de IP

Los cambios en la forma de codificar las opciones de encabezado de IP permiten un reenvío más eficaz. Asimismo, las opciones de IPv6 presentan unos límites de longitud menos estrictos. Los cambios aportan una mayor flexibilidad a la hora de incorporar opciones nuevas en el futuro.
Compatibilidad de aplicaciones con direcciones IPv6

Muchos de los principales servicios de red de Solaris reconocen y admiten direcciones IPv6; por ejemplo:

Servicios de nombres como DNS, LDAP y NIS.

Aplicaciones de autenticación y protección de la privacidad, por ejemplo IP Security Architecture (IPsec) e Internet Key Exchange (IKE).

Servicios diferenciados, como los que proporciona IP Quality of Service (IPQoS).

Detección de fallos y funcionamiento a prueba de fallos, como se proporciona mediante IP multirruta de redes (IPMP).

Otros recursos de IPv6

Petición de comentarios IPv6 y borradores de Internet

Hay disponibles numerosas RFC referidas a IPv6. En la tabla siguiente aparecen los principales artículos y sus ubicaciones Web de Internet Engineering Task Force (IETF) a partir de su escritura.

2.1.4. Descripción general de las redes IPv6

En la figura siguiente se muestran los componentes básicos de una red IPv6.

Figura 10. Componentes básicos de una red IPv6


La figura 10 ilustra una red IPv6 y sus conexiones con un ISP. La red interna la forman los vínculos 1, 2, 3 y 4. Cada vínculo está ocupado por hosts y terminado por un encaminador. El vínculo 4, considerado la DMZ de la red, queda terminado en un extremo por el encaminador de límite. El encaminador de límite ejecuta un túnel IPv6 a un ISP, que ofrece conexión a Internet para la red. Los vínculos 2 y 3 se administran como subred 8a. La subred 8b se compone sólo de sistemas del vínculo 1. La subred 8c es contigua a la DMZ en el vínculo 4.

Como se muestra en la figura, una red IPv6 tiene prácticamente los mismos componentes. No obstante, la terminología de IPv6 presenta ligeras diferencias respecto a la de IPv4. A continuación se presenta una serie de términos sobre componentes de red empleados en un contexto de IPv6.

nodo : Sistema con una dirección IPv6 y una interfaz configurada para admitir IPv6. Término genérico que se aplica a hosts y encaminadores.

encaminador de IPv6 : Nodo que reenvía paquetes de IPv6. Para admitir IPv6, debe configurarse como mínimo una de las interfaces del encaminador. Un encaminador de IPv6 también puede anunciar el prefijo de sitio IPv6 registrado para la empresa en la red interna. -

host de IPv6: Nodo con una dirección IPv6. Un host IPv6 puede tener configurada más de una interfaz para que sea compatible con IPv6. Al igual que en IPv4, los hosts de IPv6 no reenvían paquetes.

Vínculo: Un solo soporte contiguo de red conectado por un encaminador en cualquiera de sus extremos.

Vecino: Nodo de IPv6 que se encuentra en el mismo vínculo que el nodo local.

subred IPv6: Segmento administrativo de una red IPv6. Los componentes de una subred IPv6 se pueden corresponder directamente con todos los nodos de un vínculo, igual que en IPv4. Si es preciso, los nodos de un vínculo se pueden administrar en subredes independientes. Además, IPv6 no permite subredes multivínculo, en las cuales los nodos de vínculos distintos pueden ser componentes de una sola subred. Los vínculos 2 y 3 de la figura son componentes de la subred 8a multivínculo.

túnel de IPv6 :Túnel que proporciona una ruta de extremo a extremo virtual entre un nodo de IPv6 y otro punto final de nodo de IPv6. IPv6 permite la configuración manual de túneles y automática de túneles de 6to4.

encaminador de límite: Encaminador en el límite de una red que proporciona un extremo del túnel de IPv6 a un punto final fuera de la red local. Este encaminador debe tener como mínimo una interfaz de IPv6 a la red interna. En cuanto a la red externa, el encaminador puede tener una interfaz de IPv6 o IPv4.

2.1.5. Descripción general de las direcciones IPv6

Las direcciones IPv6 se asignan a interfaces en lugar de a nodos, teniendo en cuenta que en un nodo puede haber más de una interfaz. Asimismo, se puede asignar más de una dirección IPv6 a una interfaz.

IPv6 abarca tres clases de direcciones:

unidifusión : Identifica una interfaz de un solo nodo.

multidifusión: Identifica un grupo de interfaces, en general en nodos distintos. Los paquetes que se envían a una dirección multidifusión se dirigen a todos los miembros del grupo de multidifusión.

difusión por proximidad: Identifica un grupo de interfaces, en general en nodos distintos. Los paquetes que se envían a una dirección de difusión por proximidad de dirigen al nodo de miembros del grupo de difusión por proximidad que se encuentre más cerca del remitente.

2.1.6. Partes de una dirección IPv6

Una dirección IPv6 tiene un tamaño de 128 bits y se compone de ocho campos de 16 bits, cada uno de ellos unido por dos puntos. Cada campo debe contener un número hexadecimal, a diferencia de la notación decimal con puntos de las direcciones IPv4. En la figura siguiente, las equis representan números hexadecimales.

 

Figura 11. Formato básico de las direcciones IPv6

 

Los tres campos que están más a la izquierda (48 bits) contienen el prefijo de sitio. El prefijo describe la topología pública que el ISP o el RIR (Regional Internet Registry, Registro Regional de Internet) suelen asignar al sitio.

El campo siguiente lo ocupa el ID de subred de 16 bits que el administrador asigna al sitio. El ID de subred describe la topología privada, denominada también topología del sitio, porque es interna del sitio.

Los cuatro campos que están más a la derecha (64 bits) contienen el ID de interfaz, denominado también token. El ID de interfaz se configura automáticamente a partir de la dirección MAC de la interfaz o de forma manual en formato EUI-64.

Obsérvese nuevamente la dirección:

2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b

En este ejemplo se muestran los 128 bits completos de una dirección IPv6. Los primeros 48 bits, 2001:0db8:3c4d, contienen el prefijo de sitio y representan la topología pública. Los siguientes 16 bits, 0015, contienen el ID de subred y representan la topología privada del sitio. Los 64 bits que están más a la derecha, 0000:0000:1a2f:1a2b, contienen el ID de interfaz.

Abreviación de direcciones IPv6

La mayoría de las direcciones IPv6 no llegan a alcanzar su tamaño máximo de 128 bits. Eso comporta la aparición de campos rellenados con ceros o que sólo contienen ceros.

La arquitectura de direcciones IPv6 permite utilizar la notación de dos puntos consecutivos (::) para representar campos contiguos de 16 bits de ceros. Por ejemplo, la dirección IPv6:

 2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b

se puede abreviar reemplazando los dos campos contiguos de ceros del ID de interfaz por sendos dos puntos; siendo la dirección resultante es:

 2001:0db8:3c4d:0015::1a2f:1a2b

Otros campos de ceros se pueden representar con un solo cero. También se pueden omitir los ceros iniciales de un campo; por ejemplo, 0db8 se puede cambiar por db8.

Así pues, la dirección 2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b se puede abreviar en

001:db8:3c4d:15::1a2f:1a2b.

La notación de los dos puntos consecutivos se puede emplear para reemplazar cualquier campo contiguo de ceros de la dirección IPv6. Por ejemplo, la dirección IPv6

001:0db8:3c4d:0015:0000:d234::3eee:0000 se puede contraer en 2001:db8:3c4d:15:0:d234:3eee::.

Prefijos de IPv6

Los campos que están más a la izquierda de una dirección IPv6 contienen el prefijo, que se emplea para encaminar paquetes de IPv6. Los prefijos de IPv6 tienen el formato siguiente:

prefijo/tamaño_bits

El tamaño del prefijo se expresa en notación CIDR (encaminamiento entre dominios sin clase). La notación CIDR consiste en una barra inclinada al final de la dirección, seguida por el tamaño del prefijo en bits.

El prefijo de sitio de una dirección IPv6 ocupa como máximo los 48 bits de la parte más a la izquierda de la dirección IPv6. Por ejemplo, el prefijo de sitio de la dirección IPv6 2001:db8:3c4d:0015:0000:0000:1a2f:1a2b/48 se ubica en los 48 bits que hay más a la izquierda, 2001:db8:3c4d. Utilice la representación siguiente, con ceros comprimidos, para representar este prefijo:

2001:db8:3c4d::/48

También se puede especificar un prefijo de subred, que define la topología interna de la red respecto a un encaminador. La dirección IPv6 de ejemplo tiene el siguiente prefijo de subred:

2001:db8:3c4d:15::/64

El prefijo de subred siempre contiene 64 bits. Estos bits incluyen 48 del prefijo de sitio, además de 16 bits para el ID de subred.

Los prefijos siguientes se han reservado para usos especiales:

2002::/16

Indica que sigue un prefijo de encaminamiento de 6to4.

fe80::/10

Indica que sigue una dirección local de vínculo.

ff00::/8

Indica que sigue una dirección multidifusión.

Direcciones unidifusión

IPv6 incluye dos clases de asignaciones de direcciones unidifusión:

Dirección unidifusión global

Dirección local de vínculo

El tipo de dirección unidifusión viene determinado por los bits contiguos que están más a la izquierda (orden superior) de la dirección, los cuales contienen el prefijo.

El formato de direcciones unidifusión se organiza conforme a la jerarquía siguiente:

Topología pública

Topología de sitio (privada)

ID de interfaz

Dirección unidifusión global

La dirección unidifusión global es globalmente exclusiva de Internet. La dirección IPv6 de ejemplo que hay en Prefijos de IPv6 es de unidifusión global. En la figura siguiente se muestra el ámbito de la dirección unidifusión global, en comparación con las partes que componen la dirección IPv6.

 

Figura 12. Partes de la dirección unidifusión global

 

Topología pública

El prefijo de sitio define la topología pública de la red respecto a un encaminador. El ISP o el RIR proporcionan el prefijo de sitio a las empresas.

Topología de sitio y subredes IPv6

En IPv6, el ID de subred define una subred administrativa de la red y tiene un tamaño máximo de 16 bits. Un ID de subred se asigna como parte de la configuración de redes IPv6. El prefijo de subred define la topología de sitio respecto a un encaminador especificando el vínculo al que se ha asignado la subred.

Desde un punto de vista conceptual, las subredes IPv6 y las IPv4 son iguales en el sentido de que cada subred suele asociarse con solo vínculo de hardware. Sin embargo, los ID de subredes IPv6 se expresan en notación hexadecimal, en lugar de decimal con puntos.

ID de interfaz

El ID de interfaz identifica una interfaz de un determinado nodo. Un ID de interfaz debe ser exclusivo en la subred. Los hosts de IPv6 pueden aplicar el protocolo ND para generar automáticamente sus propios ID de interfaz. El protocolo ND genera de forma automática el ID de interfaz, a partir de la dirección MAC o la dirección EUI-64 de la interfaz del host. Los ID de interfaz también se pueden asignar manualmente, lo cual es preferible en el caso de encaminadores de IPv6 y servidores habilitados para IPv6. Direcciones unidifusión globales de transición

Por motivos de transición, el protocolo IPv6 incluye la posibilidad de incrustar una dirección IPv4 en una dirección IPv6. Esta clase de dirección IPv4 facilita la colocación en túneles de paquetes IPv6 en redes IPv4 ya configuradas. La dirección 6to4 es un ejemplo de dirección unidifusión global de transición.


Dirección unidifusión local de vínculo

La dirección unidifusión local de vínculo sólo se puede utilizar en el vínculo de red local. Las direcciones locales de vínculo no son válidas ni se reconocen fuera del ámbito corporativo u organizativo. A continuación se muestra un ejemplo del formato que tienen las direcciones locales de vínculo.

 

Figura 13 Partes de la dirección unidifusión local de vínculo
 

Un prefijo local de vínculo presenta el formato siguiente:

fe80::ID_interfaz/10

A continuación se muestra una dirección local de vínculo:

fe80::23a1:b152

fe80

Representación hexadecimal del prefijo binario de 10 bits 1111111010. Este prefijo identifica el tipo de dirección IPv6 como local de vínculo.

ID_interfaz

Dirección hexadecimal de la interfaz, que en general se deriva de la dirección MAC de 48 bits.
Al habilitar IPv6 durante la instalación de Solaris, la interfaz con el número más bajo del equipo local se configura con una dirección local de vínculo. Cada interfaz necesita por lo menos una dirección local de vínculo para identificar el nodo en los demás nodos del vínculo local. Así pues, las direcciones locales de vínculo deben configurarse manualmente para las interfaces adicionales de un nodo. Tras la configuración, el nodo utiliza sus direcciones locales de vínculo para la configuración automática de direcciones y el descubrimiento de vecinos.

Direcciones multidifusión

IPv6 permite el uso de direcciones multidifusión. La dirección multidifusión identifica un grupo de multidifusión, que es un grupo de interfaces, en general en nodos distintos. Una interfaz puede pertenecer a cualquier cantidad de grupos de multidifusión. Si los primeros 16 bits de una dirección IPv6 son ff00 n, la dirección es del tipo multidifusión.

Las direcciones multidifusión se usan para el envío de información o servicios a todas las interfaces que se definen como miembros del grupo de multidifusión. Por ejemplo, uno de los usos de las direcciones multidifusión es comunicarse con todos los nodos de IPv6 del vínculo local.

Al crearse la dirección unidifusión IPv6 de una interfaz, el núcleo convierte automáticamente la interfaz en miembro de determinados grupos de multidifusión. Por ejemplo, el núcleo convierte cada nodo en un miembro del grupo de multidifusión del nodo solicitado, que utiliza el protocolo ND para detectar la accesibilidad. El núcleo convierte automáticamente también un nodo en miembro de los grupos de multidifusión de todos los nodos o todos los encaminadores.

Grupos y direcciones de difusión por proximidad

Las direcciones de difusión por proximidad IPv6 identifican un grupo de interfaces en distintos nodos de IPv6. Cada grupo de interfaces se denomina grupo de difusión por proximidad. Cuando se envía un paquete al grupo de difusión por proximidad, recibe el paquete el miembro del grupo que esté más próximo al remitente.

Descripción general del protocolo ND de IPv6

IPv6 aporta el protocolo ND (Neighbor Discovery, descubrimiento de vecinos), que emplea la mensajería como medio para controlar la interacción entre nodos vecinos. Por nodos vecinos se entienden los nodos de IPv6 que están en el mismo vínculo. Por ejemplo, al emitir mensajes relativos al descubrimiento de vecinos, un nodo puede aprender la dirección local de vínculo de un vecino. El protocolo ND controla las principales actividades siguientes del vínculo local de IPv6:

Descubrimiento de encaminadores: ayuda a los hosts a detectar encaminadores en el vínculo local.
Configuración automática de direcciones: permite que un nodo configure de manera automática direcciones IPv6 para sus interfaces.

Descubrimiento de prefijos: posibilita que los nodos detecten los prefijos de subred conocidos que se han asignado a un vínculo. Los nodos utilizan prefijos para distinguir los destinos que se encuentran en el vínculo local de los asequibles únicamente a través de un encaminador.

Resolución de direcciones: permite que los nodos puedan determinar la dirección local de vínculo de un vecino solamente a partir de la dirección IP de los destinos.

Determinación de salto siguiente: utiliza un algoritmo para establecer la dirección IP de un salto de destinatario de paquetes que está más allá del vínculo local. El salto siguiente puede ser un encaminador o el nodo de destino.

Detección de inasequibilidad de vecinos: ayuda a los nodos a establecer si un nodo ya no es asequible. La resolución de direcciones puede repetirse tanto en encaminadores como hosts.
Detección de direcciones duplicadas: permite que un nodo pueda determinar si está en uso o no una dirección que el nodo tenga la intención de utilizar.

Redirección: un encaminador indica a un host el mejor nodo de primer salto que se puede usar para acceder a un determinado destino.

El protocolo ND emplea los tipos de mensajes ICMP siguientes para la comunicación entre los nodos de un vínculo:

Solicitud de encaminador

Anuncio de encaminador

Solicitud de vecino

Anuncio de vecino

Redirección

Configuración automática de direcciones IPv6

Una de las características principales de IPv6 es la capacidad que tiene un host de configurar automáticamente una interfaz. Mediante el protocolo ND, el host busca un encaminador de IPv6 en el vínculo local y solicita un prefijo de sitio. Como parte del proceso de configuración automática, el host lleva a cabo los pasos siguientes:

Crea una dirección local de vínculo para cada interfaz, lo cual no precisa un encaminador en el vínculo.

Verifica la exclusividad de una dirección en un vínculo, lo cual no precisa un encaminador en el vínculo.

Determina si las direcciones globales deben obtenerse a partir del mecanismo con estado, sin estado o ambos. (Precisa un encaminador en el vínculo.)

Descripción general de configuración automática sin estado

La configuración automática no necesita la configuración manual de hosts, una configuración mínima de encaminadores (si los hay) ni servidores adicionales. El mecanismo sin estado permite que un host genere sus propias direcciones. Para generar las direcciones, el mecanismo sin estado utiliza la información local y la no local anunciada por los encaminadores.

Pueden implementarse direcciones temporales en una interfaz, configuradas también de manera automática. Se puede habilitar un token de direcciones temporales para una o varias interfaces en un host. Sin embargo, a diferencia de las direcciones IPv6 estándar configuradas automáticamente, una dirección temporal consta del prefijo de sitio y un número de 64 bits generado aleatoriamente. Ese número aleatorio constituye la parte del ID de interfaz de la dirección IPv6. Una dirección local de vínculo no se genera con la dirección temporal como ID de interfaz.

Los encaminadores anuncian todos los prefijos que se han asignado al vínculo. Los hosts de IPv6 emplean el protocolo ND para obtener un prefijo de subred a partir de un encaminador local. Los hosts crean direcciones IPv6 automáticamente combinando el prefijo de subred con un ID de interfaz que se genera a partir de la dirección MAC de una interfaz. Si no hay encaminadores, un host puede generar únicamente direcciones locales de vínculo. Las direcciones locales de vínculo sólo son aptas para comunicaciones con nodos del mismo vínculo.

Descripción general sobre los túneles de IPv6

En la mayoría de las empresas, la implantación de IPv6 en una red IPv4 ya configurada debe realizarse de manera gradual y por fases. El entorno de redes de pila doble de Solaris permite el funcionamiento compatible de IPv4 e IPv6. Debido a que casi todas las redes emplean el protocolo IPv4, en la actualidad las redes IPv6 necesitan una forma de comunicarse más allá de sus límites. Para ello, las redes IPv6 se sirven de los túneles.

En buena parte de las situaciones hipotéticas para túneles de IPv6, el paquete de IPv6 saliente se encapsula en un paquete de IPv4. El encaminador de límite de la red IPv6 configura un túnel de extremo a extremo a través de varias redes IPv4 hasta el encaminador de límite de la red IPv6 de destino. El paquete se desplaza por el túnel en dirección al encaminador de límite de la red de destino, que se encarga de desencapsular el paquete. A continuación, el encaminador reenvía el paquete IPv6 desencapsulado al nodo de destino.

La implementación de IPv6 en Solaris permite las siguientes situaciones hipotéticas de configuración de túneles:

Túnel configurado manualmente entre dos redes IPv6, a través de una red IPv4. La red IPv4 puede ser Internet o una red local dentro de una empresa.
Túnel configurado manualmente entre dos redes IPv4, a través de una red IPv6, en general dentro de una empresa.
Túnel de 6to4 configurado dinámicamente entre dos redes IPv6, a través de una red IPv4 de una empresa o por Internet.

2.1.7. Tecnologías Involucradas en IPv6

Multicast: es un servicio de red para distribución de datos a varios usuarios preestablecidos, ofreciendo ventajas principalmente en aplicaciones multimedia compartidas.
QoS :La implantación de calidad de servicio (QoS) es esencial para el suceso de aplicaciones avanzadas.

Video conferencia: Implantación de un servicio de videoconferencia en el backbone.

Servidores NTP: Los servidores NTP permiten la sincronización de los relojes de computadores y otros equipos de red a partir de una referencia padrón de tiempo.

Tunneling

Los nodos o redes IPv6 que se encuentran separadas por infraestructuras IPv4 pueden construir un enlace virtual, configurando un túnel. Paquetes IPv6 que van hacia un dominio IPv6 serán encapsulados dentro de paquetes IPv4. Los extremos del túnel son dos direcciones IPv4 y dos IPv6. Se pueden utilizar dos tipos de túneles: configurados y automáticos.

Los túneles configurados son creados mediante configuración manual. Un ejemplo de redes conteniendo túneles configurados es el 6bone.

Los túneles automáticos no necesitan configuración manual. Los extremos se determinan automáticamente determinados usando direcciones IPv6 IPv4-compatible.

 

3. Planificación de una red IPv6
 

mplementar IPv6 en una red nueva o ya configurada supone un importante esfuerzo de planificación. En este capítulo se presentan las tareas principales imprescindibles para poder configurar IPv6. En el caso de redes ya configuradas, la implementación de IPv6 se debe establecer por fases.

Planificación de IPv6 (mapas de tareas)

Para realizar las tareas de planificación relativas a la implementación de IPv6 el procedimiento indicado se describe en la siguiente tabla.

A esta descripción propuesta por Sun de qué actividades deben ser realizadas se han dejado las citas con sus respectivos hipervínculos a la documentación recomendada para que especificas las técnicas correspondientes a cada actividad.

 

Tabla 2. Mapas de tareas

Tarea 

Descripción 

Instrucciones 

1. Preparar el hardware para admitir IPv6. 

Compruebe que el hardware se pueda actualizar a IPv6. 

Preparación de la topología red para admitir IPv6

2. Disponer de un ISP que admita IPv6. 

Compruebe que el ISP que utiliza admita IPv6. De no ser así, busque uno que sea compatible con IPv6. Puede utilizar dos ISP, uno para IPv6 y otro para comunicaciones de IPv4. 

3. Comprobar que las aplicaciones estén preparadas para funcionar con IPv6. 

Verifique que las aplicaciones puedan funcionar en un entorno IPv6. 

Cómo preparar servicios de red para admitir IPv6

4. Disponer de prefijo de sitio. 

Solicite al ISP o al RIR más próximo un prefijo de sitio de 48 bits. 

Obtención de un prefijo de sitio

5. Crear un plan de direcciones de subredes. 

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. 

Creación de un esquema de numeración para subredes

6. Diseñar un plan para el uso de túneles. 

Establezca los encaminadores que deben ejecutar túneles a otras subredes o redes externas. 

Planificación de túneles en la topología de red

7. Crear un plan de direcciones para entidades de la red. 

Se debe planificar la dirección de servidores, encaminadores y hosts antes de configurar IPv6. 

Creación de un plan de direcciones IPv6 para nodos

8. Desarrollar directrices de seguridad de 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 de Solaris. 

Parte IV, Seguridad IP

9. (Opcional) Configurar una DMZ. 

Por motivos de seguridad, se precisa un plan de direcciones para la DMZ y sus entidades antes de configurar IPv6. 

Aspectos relacionados con la seguridad en la implementación de IPv6

10. Habilitar los nodos para que admitan IPv6. 

Configure IPv6 en todos los hosts y encaminadores. 

Configuración de IPv6 en encaminadores (mapa de tareas)

11. Activar servicios de red. 

Compruebe que los servidores puedan admitir IPv6. 

Tareas de administración principales de TCP/IP (mapa de tareas)

12. Actualizar nombres de servidor para la compatibilidad con IPv6. 

Compruebe que los servidores DNS, NIS y LDAP se actualicen con las nuevas direcciones IPv6. 

Configuración de la compatibilidad con el servicio de nombres para IPv6

 

4. Aplicación en la UTN – Regional la Plata (UTN-FRLP)

La Red IPv6 de la UTN-FRLP cubre toda la red interna de la facultad, actualmente nos encontramos conectados en forma nativa.


Experiencia en el 6bone

La UTN FRLP perteneció a la red 6bone donde las direcciones IPv6 tenían una asignación jerárquica, existiendo varios niveles de jerarquía. La red de prueba, conocida como 6bone utilizaba éstas jerarquías con muy pequeñas modificaciones.

La UTN FRLP contaba con el siguiente prefijo de 6bone:

· 3ffe::/16 (prefijo para el 6bone)

· 3ffe:3800::/24 (prefijo para el pTLA FIBERTEL, como la longitud del prefijo es de 24 bits la parte significativa es 3ffe:38).

· 3ffe:38e1::/32 (prefijo para el pNLA UTN).

· 3ffe:38e1:0100::/48 (prefijo para UTN-FRLP)

· 3ffe:38e1:0100:a001::/64 (prefijo para la subred a001 dentro de UTN-FRLP).

· 3ffe:38e1:0100:a001::10 (dirección IP completa, los últimos 64 bits corresponden al interface identifier 10, antes conocido como número de host).

 

3ffe

38

e1

0100

a001

0000000000000010

6bone

FIBERTEL
pTLA

UTN
pNLA

UTN-FRLP
site

Subred dentro de UTN-FRLP

Interface ID

16 bits

8 bits

8 bits

16 bits

16 bits

64 bits

 

El Interface ID normalmente se deriva de la MAC address de la interfaz y se asigna automáticamente, permitiendo un 2^64 hosts por subred (2^32 veces más hosts que el límite teórico del espacio de direcciones de IPv4). 

Topología de la red

Este gráfico resume el trabajo realizado en nuestra red durante esta etapa, actualmente dicha topología es mas sencilla y solo cuenta con una única conexión nativa a IPv6.

 

 

Figura 14.Topología de la UTN – Regional la Plata
 

5. Bibliografía

Carpenter, B., Fink, B., and Moore, K., “Connecting IPv6 Routing Domains Over the IPv4 Internet,” The Internet Protocol Journal, Volume 3, No. 1, March 2000.

Deering, S. and Hinden, R., “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998.

Draves, R., “Default Address Selection for Internet Protocol Version 6 (IPv6),” RFC 3484, February 2003.

Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and Carney, M., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” RFC 3315, July 2003.

François Donzé, “IPv6 Address Autoconfiguration,” The Internet Protocol Journal, Volume 7, No. 2, June 2004.

Fernández A , Azael. y Porto, Eriko. IPv6 en las Redes Académicas. Grupos de Trabajo de IPv6 y de Ingeniería en CLARA. Primera Cumbre Peruana de IPv6, mayo 2007. http://www.ipv6.unam.mx/documentos/IPv6_Redes-Academicas-Eriko-Azael.pdf

GARCÍA B. Rafael R. PROTOCOLO DE INTERNET (IPv6). Universidad Central de Venezuela, Fac. de Ingeniería, Esc. Eléctrica. Apartado 47411, Caracas 1041-A. http://neutron.ing.ucv.ve/revista-e/No5/RGarcia.html

Iljitsch van BeijnumIPv6 InternalsThe Internet Protocol Journal - Volume 9, Number 3 http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html
Karrenberg D., Ross G., Wilson P., and Nobile L., “Development of the Regional Internet Registry System,” The Internet Protocol Journal, Volume 4, No. 4, December 2001.

Martínez Ignacio. Nueva Generación del Protocolo. Boletín Red Iris N. 33. 22/11/2007 IP:IPv6. http://www.rediris.es/rediris/boletin/33/enfoque3.html#[6]

Nichols, K., Blake, S., Baker, F., and Black, D., “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” RFC 2474, December 1998.

Narten, T., Nordmark, E., and Simpson, W., “Neighbor Discovery for IP Version 6 (IPv6),” RFC 2461, December 1998.

Narten, T. and Thomson, S., “IPv6 Stateless Address Autoconfiguration,” RFC 2462, December 1998.
 
Narten, T. and Draves, R., “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” RFC 3041, January 2001.

Postel, J., “Internet Protocol,” RFC 791, September 1981.

Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Guía de administración del sistema: servicios IP. Cap3-4 Introducción a IPv6 http://docs.sun.com/app/docs/doc/820-2981/ipv6-overview-7?l=es&a=view

Troan, O. and Droms, R., “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) Version 6,” RFC 3633, December 2003.

UTN FRLP IPv6. implementación de la red IPv6 en la Universidad Tecnológica Nacional, Facultad Regional La Plata. http://www4.ipv6.frlp.utn.edu.ar/
 
Azael Fernández A. IPv6 in Latin America. Capítulo Mexicano del Foro IPv6. Presentada en: IPv6 Congress, Las Vegas, E.U.A., febrero 2006.  http://www.ipv6.unam.mx/documentos/IPv6_LatinAmerica.pdf

Azael Fernández A. IPv6. Herramienta crucial de la innovación. Publicado en: Boletín Info@CITEL, agosto 2006. http://www.citel.oas.org/newsletter/2006/agosto/ipv6-gral_e.asp

Guía de administración del sistema: servicios IP. Sun Microsystems Capítulo 4. Planificación de una red IPv6. http://docs.sun.com/app/docs/doc/820-2981/ipv6-planning-1?l=es&a=view

Guía de administración del sistema: servicios IP. Sun Microsystems. Capítulo 3 Introducción a IPv6 (descripción general). http://docs.sun.com/app/docs/doc/820-2981/ipv6-overview-7?l=es&a=view

RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). Describe las características y funciones del protocolo ND (descubrimiento de vecinos) de IPv6 . http://www.ietf.org/rfc/rfc2461.txt?number-2461

RFC 3306, Unicast—Prefix—Based IPv6 Multicast Addresses . Describe el formato y los tipos de direcciones IPv6 multidifusión . ftp://ftp.rfc-editor.org/in-notes/rfc3306.txt

RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6) . Describe los algoritmos que se usan en la selección de direcciones predeterminadas de IPv6 . http://www.ietf.org/rfc/rfc3484.txt?number=3484

RFC 3513, Internet Protocol version 6 (IPv6) Addressing Architecture. Contiene información exhaustiva sobre los tipos de direcciones IPv6 con abundantes ejemplos . http://www.ietf.org/rfc/rfc3513.txt?number=3513

RFC 3587, IPv6 Global Unicast Address Format . Define el formato estándar de las direcciones IPv6 unidifusión. http://www.ietf.org/rfc/rfc3587.txt?number=3587

Foro de IPv6 . En este sitio web hay vínculos a presentaciones, eventos, clases e implementaciones sobre IPv6 en todo el mundo. http://www.ipv6forum.com/

Grupo de trabajo de IPv6 de Internet Educational Task Force . La página inicial de este grupo de trabajo de IETF proporciona vínculos a todos los borradores de Internet y RFC importantes relacionados con IPv6. http://www.ietf.org/html.charters/OLD/ipv6-charter.html

 

 

Tcnica Administrativa
ISSN 1666-1680

http://www.cyta.com.ar -

Tipo de Informe: Revisión

2008-06-27

URL