IPV4

 Objetivos 1.- Agotamiento del espacio de direcciones IPv4 2.- IPv6 Cabecera IPv4 vs. IPv6 Cabeceras extendidas en IPv6 Direcciones en IPv6 Asignación de las direcciones URL y DNS Funcionamiento de IPv6: ICMPv6 3.- Transición: estrategias de integración y coexistencia Dual-stack network Túneles Ejemplos A.- Referencias Referencias principales RFCs Otras referencias Referencias Web B.- Glosario Objetivos El objetivo de este trabajo es el de mostrar como, dentro de pocos años Internet se verá transformada por la aparición del nuevo protocolo IPv6. Se ha divido el trabajo en 3 partes. La primera parte es el motivo por el cual se pensó en que las direcciones IPv4 se agotarían. Por lo que durante los años 90 empezó a desarrollarse el nuevo protocolo de Internet IPv6. Solucionando de una vez por todas los problemas del agotamiento de direcciones IPv4. La segunda parte trata sobre IPv6, la especificación del nuevo protocolo. La nueva cabecera básica de IPv6, con muchos cambios respecto a la cabecera IPv4. Se introducen las cabeceras extendidas, mucho más flexibles que las antiguas opciones en IPv4. Se tratan los distintos tipos de direcciones que aparecen en el nuevo protocolo y se introducen algunas nociones sobre el funcionamiento de IPv6. La tercera y última parte, trata sobre los mecanismos de transición hacia IPv6. La coexistencia de ambos protocolos y las distintas técnicas que especifica la ietf para su implantación. Como conclusión final se puede decir que IPv6, no es sólo aumentar el tamaño de las direcciones IPv6 a 128 bits, sino que, se ven modificados todos los protocolos de routing para poder hacer que ambos protocolos convivan. Además se producen modificaciones en los DNS para que puedan resolver direcciones de ambos tipos. Es un cambio mucho mayor de lo que parece a simple vista. ____________________Agotamiento del espacio de direcciones IPv4 IPv4 fue desarrollado a finales de los años 70, principios de los 80. En IPv4 se utilizan 32 bits, por lo que se tienen alrededor de 4 billones de direcciones. Por aquel entonces a nadie le cabía en la cabeza que 20 años después se estaba pensando que podían acabarse tal cantidad de direcciones. Alrededor de 1990 la IETF reconoció el problema del agotamiento y predijo que serían necesarios alrededor de 10 años para solucionar el problema. Para ello se creó un grupo de trabajo, ALE (1993) encargado de estudiar cuando se produciría el agotamiento de las direcciones. En diciembre de 1994 se llego a la conclusión de que con el crecimiento que se estaba produciendo durante el “boom” Internet y la www, las direcciones se habrían agotado alrededor del año 2008. Recientemente, algunos medios como la BBC se han aventurado a decir que el número de direcciones de red se terminarán durante 2005 26 de Octubre de 2003. Ian Hardy (http://news.bbc.co.uk/2/hi/technology/3211035.stm) de [1] , algo absurdo a tan corto plazo. La mejor forma de hacer una valoración del problema es estudiando directamente el organismo encargado del reparto de direcciones, IANA. Éste organismo divide las direcciones mediante bloques /8, del tamaño de una red clase A (16.777.26). La forma de reparto es la siguiente: la IANA gestiona en un primer nivel de red un rango de 221 /8 bloques de direcciones. Asigna un bloque /8 a los RIRs cada vez que es necesario y estos a su vez reparten estas direcciones en bloques más pequeños, que son asignados a los LIRs y a los ISPs de mayor tamaño. Se realiza un último reparto a ISPs más pequeños y por último al usuario final. Actualmente la IANA gestiona 3.707.764.736 direcciones, es decir, 221 bloques /8, el resto de bloques hasta los 256/8 que pueden ser direccionados, no pueden ser utilizados, ya que pertenecen a direcciones multicast (16/8), reservadas (16/8) y no utilizables (3/8). Con fecha de 15 de enero de 2004, el número total de bloques /8 no asignados es de 71 (quedan 18 reservados 240 a 255), lo que nos da un total de más de 1 billón de direcciones. Parece ser que a corto plazo aún tenemos direcciones, mientras los RIRs sigan utilizando la misma estrategia de reparto de direcciones. Observando el crecimiento de bloques /8 asignados a los RIR y realizando una aproximación según las pautas actuales de crecimiento, se llega a la conclusión que las direcciones gestionadas por el IANA se terminarán hacia el año 2019, y el reparto final por parte de los RIRs hacia el año 2026 [1]. Parece, por lo tanto, que de momento podemos estar tranquilos. Lo cierto es que no, la aparición de NAT, DHCP y CIDR postergó el problema, pero existen otros, como el alto crecimiento del tamaño de las talas BGP. Y también habrán de tenerse en cuenta las nuevas tecnologías como los teléfonos de 3ª generación, PDAs, HANs, “Internet conected-transportations” (coches), videoconsolas, alarmas, incluso hasta frigoríficos, todo dispositivo que pueda ser digital; esto producirá, que posiblemente, antes de lo previsto tengamos que realizar la migración al nuevo protocolo IPv6. IPv6 Características básicas de IPv6 Cabecera: IPv4 vs. IPv6 [RFC2460] IPv4 básica (20 bytes) IPv6 básica (40 bytes) V. IHL DS Long. Total V. TC Flow Label Identification F Frag. Ofset Payload Length Next H HL TTL Protocol Checksum Source address (128 bits) Source address Destination address Options Opc. Destination address (128 bits) Cabecera básica simplificada: - Desaparecen los campos IHL, Indentificación, Flags, Fragment Offset, Header checksun, options En realidad, las opciones y la fragmentación no desaparecen, ahora son manejadas mediante una extensión de la cabecera. y padding. - Los campos DS y TTL En realidad, el campo TTL recibió dicho nombre porque tenía que ir decrementándose respecto del tiempo, aunque las distintas implementaciones lo decrementan a cada salto. pasan a llamarse Traffic Class y Hop Limit respectivamente, ambos cambian su posición. - El campo Protocolo se convierte en el campo Next Header y la longitud total en Payload Lenght. - Flow label Experimental y sujeto a cambios. debe ser utilizado para etiquetar secuencias de paquetes que tienen que ser tratados por los routers a petición del nodo origen, como una QoS que no es por defecto, o servicio en tiempo real. - El campo versión se mantiene, y los campos de dirección origen y destino son ampliados a 128 bits. Ventajas: Aumento del número de direcciones. Menor número de campos en la cabecera básica. Mayor velocidad de procesamiento de una cabecera IPv6 básica, no es necesario recalcular el checksun cada vez. Todos los campos en la cabecera IPv6 son de 64 bits, mayores ventajas para la generación actual de procesadores de 64 bits. Los routers no deben examinar las cabeceras de IPv6, salvo la cabecera hop-by-hop. Los routers no pueden hacer fragmentación en IPv6, esto elimina el tiempo de proceso que necesitaban en IPv4 para realizar la fragmentación, con lo cual se obtiene una mayor velocidad de proceso. Sólo los nodos origen pueden realizar la fragmentación. Cabeceras extendidas en IPv6 Nos permiten una mayor eficiencia en el procesado, menos exigencias en la longitud de las opciones y una mayor flexibilidad a la hora de introducir nuevas opciones en el futuro. Next Header: identifica el tipo de la siguiente cabecera que sigue a la cabecera. Header Extensión Lenght: usualmente 8 bits, en unidades de 8 octetos, alineación a 64 bits. V. TC Flow Label Valor ‘anterior’ Next Header Tipo Payload Length Next H HL Source Cabecera IPv6 0 Hop-by-Hop Options Destination 60 Destination Options 43 Routing N.H. H.E.L 44 Fragment Datos de la cabecera extendida 51 Authentication 50 Encapsulating Security Payload N.H. H.E.L Datos de la cabecera extendida 59 ICMPv6 60 Destination N.H. H.E.L 6, 17, … upper-layer (TCP, UDP, …) 59 ‘no next header’ · · · Salvo la cabecera Hop-by-hop, que tiene que ser procesada por todos los routers hasta el destino final, las cabeceras no tienen que ser examinadas o procesadas hasta que lleguen a la dirección indicada el campo dirección de destino. Todas las cabeceras tienen que ser múltiplos de 8 octetos. El orden que deben seguir las cabeceras, es el que aparece en la tabla anterior. Aunque todos los nodos IPv6 deben de aceptar y procesar cabeceras extendidas en cualquier orden “Se estricto al enviar y tolerante al recibir”, salvo la cabecera Hop-by-Hop, que estrictamente debe continuar a la cabecera IPv6. Cada cabecera debe aparecer sólo una vez, salvo Destination Options que como mucho puede aparecer dos veces. La primera a procesar por el destino y los destinos que pueda haber en la cabecera de Routing. Y la segunda aparición para ser procesada sólo por el destino final del paquete. Las cabeceras Authentication y Encapsulating Security Payload son tratadas en el RFC 2402 y RFC 2406, respectivamente. Cambios en la pseudocabecera TCP y UDP. Cuando se utiliza TCP sobre IPv6, el MSS Maximum Segment Size se calcula como el tamaño máximo del paquete menos 60 octetos. Direcciones en IPv6 [RFC2373] Formato direcciones IPv6: 128 bits (≈ 3,4 x 1038 nodos direccionables) Ahora disponemos de un espacio de direcciones enorme y junto con los prefijos de red, podemos obtener una arquitectura de red mucho más flexible. Podemos formar una arquitectura de red jerárquica. Este diseño nos permite reducir el tamaño de las tablas rutas de Internet (CIDR solucionaba parte del problema pero no era escalable ni eficiente). Asignación: Una dirección IPv6 es asignada a un interfaz, no a un nodo. Pero a un solo interfaz se le pueden asignar múltiples direcciones IPv6. Por lo que un nodo puede ser identificado por cualquiera de sus direcciones unicast. Los routers no tienen asignada una dirección cuando se conectan mediante una línea punto a punto, porque no funcionan como origen o destino de un datagrama IP. Representaciones Prefijo de red Interface ID XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX Donde X indica un número hexadecimal. Una dirección en IPv6 se representa mediante 32 dígitos en hexadecimal. 1080:0:0:0:8:800:200C:417A Simplificaciones - se puede utilizar “::” para indicar múltiples grupos de 16 bits de ceros, sólo puede aparecer una vez. 1080::8:800:200C:417A - también se pueden mezclar con valores de IPv6: x:x:x:x:x:x:d.d.d.d 0:0:0:0:0:FFFF:129.144.52.38 ó de forma comprimida ::FFFF:129.144.52.38 Prefijos: Son representados de forma parecida a IPv4 con la notación CIDR. Dirección-ipv6/longitud-prefijo Tipos de direcciones Unicast: dirección para un único interfaz. Se pueden distinguir varios tipos según los fabricantes. Ocupan un octavo de todo el espacio de direcciones IPv6. Globales: son definidas por un prefijo 001 Global Routing Prefix (proveedor) Subred ID (site) Interface ID (host) TLA RES NLA SLA 3  45 bits   16 bits   64 bits  TLA: Top-Level Aggretation Identifier (13 bits) RES: Reservado para un uso futuro (8 bits) NLA: Next-Level Aggretation Identifier (24 bits) SLA: Site-Level Aggretation Identifier (16 bits) El formato estándar es el que se indica arriba, pero cada organización puede elegir la forma de repartir su espacio, dependerá de su política de registro [RFC2374] | [Redes 3-118 Formato Ripe]. Site-local: equivalentes a las direcciones privadas en IPv4 1111 1110 11 0 Subred Interface ID FEC0::/10  38 bits   16 bits   64 bits  Link-local: utilizadas en el descubrimiento de los nodos vecinos y la autoconfiguración 1111 1110 10 0 Interface ID FE80::/10  54 bits   64 bits  IPv4 mapped IPv6: utilizada para representar la dirección de un nodo IPv4 como una dirección IPv6 0 XXXX Dirección IPv4  80 bits   16 bits   32 bits  IPv4 compatible IPv6: obsoleta (CISCO y MSoft) 0 Dirección IPv4  96 bits   32 bits  Interfaz ID se representa en el  formato EUI-64 standards.ieee.org/regauth/oui/tutorials/EUI64.html (dirección MAC extendida) Anycast: nuevo tipo de dirección asignada a un grupo de interfaces, típicamente pertenecientes a diferentes nodos, por lo tanto una dirección identifica múltiples interfaces. Un paquete enviado a una dirección anycast es enviado a la interfaz más cercana, según la especificación de los protocolos de routing. No se distinguen de las direcciones unicast globales.  Multicast: dirección que identifica un conjunto de interfaces que usualmente pertenecen a distintos nodos 1111 1111 Flag Scope Identificador de grupo  8 bits   8 bits   112 bits  FLAG (tiempo de vida) ÁMBITO 0 Permanente 1 Interface-local 1 Temporal 2 Enlace-local 3 Subred-local 4 Admin-local 5 Site-local 8 Organización-local E Global Ejemplos: FF0::1 - para el host FF02::1 - los nodos en el enlace local FF01::2 - routers dentro del nodo local FF01::2 - routers dentro del enlace local FF05::2 - todos los routers en el mismo site Especiales Dirección IPv6 sin especificar: es utilizada por un nodo cuando no tiene una dirección, utilizada por ejemplo cuando arranca el computador y aún no se le ha asignado una dirección por DHCP. 0:0:0:0:0:0:0:0 (0::0 o ::/128). No puede ser asignada a ningún interfaz y no puede ser utilizada como dirección de destino. Loopback: 0:0:0:0:0:0:0:1 o ::1. Igual que en IPv4. Asignación actual de direcciones IPv6 IANA  2001::/16 del total Cada registro obtiene un prefijo /23 del espacio de IANA. APNIC: 2001:0200::/23 2001:0C00::/23 ARIN: 2001:0400::/23 RIPE NCC: 2001:0600::/23 2001:0800::/23 Los registros asignan inicialmente prefijos /32 a los proveedores. Y estos a su vez asignan prefijos /48 a los usuarios o sitios. REDIRIS www.ripe.net: distintos rangos dependiendo del enlace en la misma página, en principio asignado /35 pero reservado /29. 2^35 sitios direccionables. Más direcciones que todo el rango IPv4.  2001:0720::/32 RedIRIS-CSIC (2004/05/13) 2001:0720::/35 2001:0720:2000::/35 2001:0720:4000::/34 2001:0720:8000::/33 TELEFONICA  2001:09D8::/32 UV  2001:0720:1014::/48 ?? Luego en cada sitio pueden formarse hasta 65.535 LANs, en caso de que se les asigne una red /48, que es lo que se especifica por defecto. Ya que los últimos 64 bits son para el identificador del host. Para poder recibir un prefijo /32, un proveedor debe de tener un protocolo exterior de routing con al menos otros 3 ISPs y tener al menos 40 clientes o demostrar un claro intento de suministrar servicios IPv6 en 12 meses. Los puntos neutros reciben directamente prefijos /48. ESPANIX  2001:07F8:000F::/48 Formato URL para una dirección IPv6 [RFC2732] En una URL los dos puntos indican opcionalmente el puerto. Por lo que no los podemos utilizar en IPv6. La dirección debe de ir contenida entre corchetes. http://[2100:1:4F3A::206:AE14]:8080/index.html DNS IPv6 introduce nuevos tipos de registro DNS. Aunque los root-servers de DNS aún no son capaces de resolverlas. Ahora tenemos los siguientes tipos: AAAA: “quad-A” convierte un nombre de host en una dirección IPv6. name-to-IP A6: equivalente a AAAA, pero experimental. PTR record: DNAME and Binary Label records Cuando un nodo necesite la dirección IPv6, generará una petición de tipo AAAA al DNS. Este responderá con la dirección en formato IPv6. Funcionamiento de IPv6: ICMPv6 ICMPv6 adquiere un papel esencial en el funcionamiento de IPv6. Aunque se han modificado todos los protocolos de routing interior e exterior, es interesante conocer algunas de las funciones de ICMPv6. Entre las cuales destacan: descubrimiento de vecinos, de routers, autoconfiguración, descubrimiento del MTU del camino. Utiliza el valor 58 del valor siguiente cabecera en un paquete básico IPv6. V. TC Flow Label Payload Length 58 HL Source Destination Tipo ICMPv6 Codigo ICMPv6 Checksum Datos ICMPv6 Los campos tipo y código identifican el tipo de paquete ICMPv6. El campo datos contiene información sobre el error o el diagnóstico relevante para el procesado del paquete. Aunque el ICMPv6 puede ser bloqueado por las políticas de seguridad incorporadas en los firewalls para evitar ataques, tiene la capacidad de utilizar autenticación y encriptación IPSec. Por lo que disminuyen las posibilidades de un ataque a través de paquetes ICMPv6. ICMPv6 junto con el protocolo para el descubrimiento de vecinos, so especialmente importantes para el funcionamiento de IPv6. Protocolo para el descubrimiento de nodos vecinos: utilizado para determinar la dirección de enlace de un vecino en el mismo enlace, encontrar routers vecinos, realizar un seguimiento de los vecinos. Se envían paquetes ICMPv6 de solicitud de vecino a la dirección multicast del enlace del nodo solicitado, utiliza el campo tipo igual a 135. El nodo contesta con un mensaje ICMP con el valor 136. Similar al protocolo ARP, pero de esta forma podemos evitar mensajes broadcast. Anuncio de Routers: los routers envían periódicamente mensajes ICMPv6 con el valor 134 en el tipo. Se envían a la dirección multicast FF02::1 –enlace local de todos lo nodos– por cada una de sus interfaces. En el mensaje incluyen información de prefijos, flags para la autoconfiguración, tiempos de vida de los prefijos, el router por defecto, y el numero de saltos límite, la MTU, … Para solicitar un router se utiliza el valor 133 en el campo tipo del paquete ICMPv6, y se utiliza la dirección no especifica IPv6 0::0. Protocolo Mínima MTU MTU Recomendada IPv4 68 576 IPv6 1280 1500 Transición: integración y coexistencia Mecanismos de transición La transición entre la actual Internet IPv4 y la futura IPv6 será un largo proceso durante el cual ambos protocolos deberán coexistir. Para ello la IETF ha creado un grupo de trabajo para ayudar a la transición y proponer soluciones técnicas para su cumplimiento, NGTrans WG. En IPv6, además de incrementar la el tamaño de la dirección a 128 bits, se ha modificado el formato de la cabecera y la forma en que la información de la misma se procesa. El cambio de IPv4 a IPv6 no es directo y hay que estandarizar los mecanismos para la coexistencia de ambos protocolos. Migrar hacia IPv6 de forma casi directa, siguiendo un modelo Y2K sería impracticable. Requeriría la re-definición de toda la arquitectura IP a nivel mundial, habría que instalar el protocolo IPv6 en todos los routers y hosts, y la modificación de todas las aplicaciones actuales para poder ejecutarse sobre IPv6. Los costes económicos y las más que seguras interrupciones de los servicios sería inaceptables. Sólo de pensarlo ya dan escalofríos. En general, ninguna regla puede ser aplicada para realizar la transición. En algunos casos la mejor opción será un cambio directo de IPv4 a IPv6. También debemos considerar las grandes inversiones en redes IPv4 de empresas y proveedores en IPv4, para poder rentabilizar sus inversiones optarán por una transición gradual entre ambos protocolos. Algunos estudios anticipan que ambas redes coexistirán durante al menos 30 años, durando la transición desde nuestros días hasta el año 2030-2040. Periodo en el cual las redes IPv4 habrán desaparecido por completo. El grupo creado por la IETF (NGTrans), ha definido tres técnicas para realizar la transición. Dual-stack network: los hosts y routers implementaran ambos protocolos, IPv4 e IPv6. Tuneles: permitiendo la interconexión de “nubes IP”. Estáticos, dinámicos, implícitos (6to4 , 6over4) TB (Túnel Broker) ISATAP (Intra-Site Automatic Tunnnel Addressing Protocol) Mecanismos de traducción, cuando un host IPv6 deba comunicarse con un host IPv4. Estas 3 técnicas pueden mezclarse entre sí de distintas maneras por lo que distintos autores pueden variarlas, Cisco propone 4 estrategias distintas. Coincidiendo en las dos primeras y añadiendo el IPv6 sobre enlaces dedicados y MPLS backbones. La primera parte de la transición consistirá en implantar las redes desde el borde hacia el centro, con tal de reducir los costes y el impacto operacional de la integración. Estas técnicas permiten a las redes ser actualizadas y desplegar IPv6 de forma incremental, con pocas interferencias en los servicios IPv4. La idea es ir creando nubes de IPv6 aisladas que para enlazarse con otras redes IPv6 atravesaran redes IPv4 mediante mecanismos de tunneling. En el futuro las redes IPv4 serán minoritarias y habrá que aplicar técnias distintas que consistirán en ir conectando las “pocas” redes IPv4 que queden con la mayoría de redes IPv6. Dual Stack Se requieren dispositivos de red como routers y sistemas finales corriendo dos pilas con los protocolos IPv4 e IPv6 Permite a las aplicaciones que no han sido actualizadas para soportar IPv6, coexistir con aplicaciones que sí lo han sido. Se necesita una nueva API que soporte ambos tipos de direcciones y que pueda aceptar las respuestas DNS. Deberá de seleccionar el tipo de dirección IPv4 / IPv6 correcta que le será devuelta por el DNS, ya que este responderá con ambos tipos de direcciones, en caso de tenerlas. Fuente: cisco abcipv6 IPv6 sobre túneles Los conceptos de túnel y de encapsulado de paquetes van siembre asociados entre sí IPv4 Consiste en el encapsulado de tráfico IPv6 dentro de los paquetes IPv4. De forma que se envía a través de las redes IPv4 hasta un router destino que se encarga de extraer el paquete IPv6 y mandarlo dentro de la red IPv6. La idea básica es la de conectar redes IPv6 aisladas con lo cual se han propuesto varios tipos de técnicas: Configuración manual IPv6 over IPv4 GRE Túnel Automatic IPv4-Compatible Túnel (reemplazado por 6to4) Automatic 6to4 Tunel Otros: ISATAP Túnel, Teredo Túnel Túnel IPv6 manual Su principal uso es para proveer conexiones estables y seguras, entre 2 routers de frontera, o para la conexión a redes remotas IPv6, como 6 Bone. Los routers y los sistemas usados como puntos finales deben de ser dual-stack. Serán necesarios tantos túneles como puntos finales tengamos. No se permite NAT a lo largo del túnel. IPv6 sobre túnel GRE Diseñados para proveer los servicios necesarios para implementar esquemas de encapsulación punto-a-punto. Como los anteriores son enlaces entre 2 puntos. Muy similares a los túneles manuales, donde ahora el paquee IPv6 es encapsulado dentro de un paquete GRE que a su vez se encapsula en un paquete IPv4. Cab. IPv4 Cab. GRE Cab. IPv6 Datos IPv6 Túnel automático IPv4-compatible Utiliza direcciones IPv4-compatible IPv6 Dirección IPv4-compatible IPv6: 0::192.1.2.3. Cisco las considera obsoletas y Microsoft ni tan siquiera las implementa.. Igual que el primer caso, pero ahora el túnel se crea de manera automática. No tiene buena escalabilidad por lo que son reemplazados por los túneles 6to4. Túnel 6to4 automático Diseñado para conectar dominios IPv6 aislados mediante redes IPv4, por ejemplo 6Bone. Interconectan múltiples sitios IPv6 con conexiones a una red IPv4. Como por ejemplo Internet o una red corporativa. Cada dominio IPv6 requiere un router dual-stak de frontera que crea automáticamente el túnel utilizando únicamente un prefijo 2002::/16 en la dirección IPv6, concatenado con la dirección IPv4 del destino del túnel. Necesitan de una dirección 6to4 IPv6. De forma que si el router destino tiene la dirección IPv4 192.168.30.1, la dirección del router será 2002:c0a8:1e01::/48 (192.168.30.1d  c0.a8.1e.01h). Todos Túnel 6to4 automático – relay routers Routers de retransmisión Durante la siguiente fase, el número de redes IPv6 será mayoritario, serán necesarios nuevos routers capaces de tener direcciones 6to4 y direcciones IPv6 normales. Los routers 6to4 permiten redireccionar paquetes a direcciones 2002::/16, pero no pueden enrutar a direcciones IPv6 nativas. Por lo tanto necesitaremos de relay routers para poder conectar redes IPv6 aisladas, que disponen de un router 6to4, con redes IPv6 e Internet IPv6. Otros tipos de mecanismos: Además de los vistos anteriormente, existen otros tipos de diseños para túneles, como son ISATAP y Teredo Tunels. También se han diseñado otras estrategias para redes con enlaces de datos dedicados que conectan proveedores con clientes, quedando fuera de una mera introducción a las redes IPv6. Ejemplo: 6Bone [RFC2921] Red mundial de redes IPv6 que utiliza enlaces IPv6 llevando tráfico IPv6 a través de redes WAN o LAN sobre túneles IPv4. Es una red para poder testear todos los nuevos protocolos, implementaciones, mecanismos de transición y procedimientos operacionales. En principio, el 31 de diciembre de 2003 finalizaba el plazo para la petición de nuevas direcciones 6Bone, aunque se han seguido asignando. Esta previsto que deje de estar en funcionamiento en Junio de 2006. Fuente: RedIris 001 TLA 1FFE pseudo TLA NLA SLA Subred ID (site) Interface ID (host) 3 13 12 20 16  0 bits   64 bits  Las direcciones de la red 6Bone empiezan todas por 3FFE::16. Los pseudos-ISP tomarán un prefijo /28. Dentro de 3FFE:0800::/28. REDIRIS: 3FFE:3300::/24 UV: 3FFE:3330:1::/48 Referencias Referencias principales The ABCs of IP Version 6 Cisco IOS Learning Services IPv6 2nd edition. Christian Huitema. Prentice Hall. 1997 IPv6 Consulintel IPv6Forum Otras referencias [1] The Internet Protocol Journal, Cisco Systems Volume 6, Número 4. Diciembre 2003 Pg. 2: “IPv4: How long do we have?” [2] ISOC Member Briefing #6: The transition to IPv6 Enero de 2002  RFCs : relacionados CONF: configuración; DIR: direcciones; PROT: protocolos; ROUT: routing; TRANS: transición [2461] Neighbor Discovery for IP Version 6 (IPv6) CONF [2462] IPv6 Stateless Address Autoconfiguration CONF [2894] Router Renumbering for IPv6 CONF [3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6) CONF [2373] IP Version 6 Addressing Architecture DIR [2374] IPv6 Aggregatable Global Unicast Address Format DIR [2375] IPv6 Multicast Address Assignments DIR [2732] Format for Literal IPv6 Addresses in URL's DIR [2460] Internet Protocol, Version 6 (IPv6) Specification PROT [1981] Path MTU Discovery for IP version 6 PROT [2402] IP Authentication Header PROT [2406] IP Encapsulating Security Payload (ESP) PROT [2463] Internet Control Message Protocol (ICMPv6) PROT [2080] RIPng for IPv6 ROUT [2545] Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing ROUT [2740] OSPF for IPv6 ROUT [2858] Multiprotocol Extensions for BGP-4 ROUT [2473] Generic Packet Tunneling in IPv6 Specification TRANS [2529] Transmission of IPv6 over IPv4 Domains without Explicit Tunnels TRANS [2766] Network Address Translation - Protocol Translation (NAT-PT) TRANS [2893] Transition Mechanisms for IPv6 Hosts and Routers TRANS [3056] Connection of IPv6 Domains via IPv4 Clouds TRANS [1924] A Compact Representation of IPv6 Addresses DIR [2874] DNS Extensions to Support IPv6 Address Aggregation and Renumbering DIR [2921] 6BONE pTLA and pNLA Formats (pTLA) 6BONE [3701] 6bone (IPv6 Testing Address Allocation) Phaseout 6BONE Referencias Web www.6bone.net www.ietf.org www.rediris.es/red/iris-ipv6 www.ripe.net www.ipv6forum.com www.ipv6ready.org www.hs247.com playground.sun.com www.cs-ipv6.lancs.ac.uk net-stats.ipv6.tilab.com/bgp/index.html carmen.ipv6.tilab.com/ipv6 www.stben.net/ipv6.html lab.verat.net/ipv6 ipv6.nokia.net Glosario ALE Address Lifetime Expectations API Application Programming Interface CIDR Classless Inter-Domain Routing GRE Generic Routing Encapsulation HAN Home Area Netwoks IANA Internet Assigned Numbers Authority IETF Internet Engineering Task Force MPLS MultiProtocol Label Switching MTU Maximum Transfer Unit NAT Network Address Translation José Andrés Fos Olivert Ingeniería en Informática: REDES Universidad de Valencia Mayo de 2004 PAGE 18 EMBED PowerPoint.Slide.8 IPv4 IPv6 IPv6