Direcciones IPv6 Transición IPv4

TRANSICIÓN IPv6

Direcciones IPv6 Transición IPv4 Lo importante de la transición es la interoperabilidad. Una transición abrupta no es aconsejable. IETF ha trabajado sobre cuestiones específicas que permitan una transición no abrupta y que brindan soluciones para interoperabilidad de software y hardware, para que los dispositivos IPv6 puedan acceder a los IPv4. El embebido de direcciones IPv4 en IPv6 es un ejemplo. También se han definido métodos especiales: Dispositivos Dual Stack : Routers y otros dispositivos IPv4/IPv6, para que se puedan comunicar con ambos tipos de hosts. Traducción IPv4/IPv6: NAT IPv4 Tunneling de IPv6: Los dispositivos IPv6 conectados por red IPv4 encapsulan datagramas IPv6 en IPv4, como si estuvieran usando IPv6 sobre IPv4.

Transición IPv6 - Dual Stack Para sistemas finales existe la aproximación dual stack. SemantieneIPv4cuandoseinstalaIPv6. Convivencia indefinida hasta migración completa de aplicaciones. Unnodoposeeambaspilas(IPv4eIPv6)ydirecciones. Una aplicación IPv6 pregunta por los dos tipos de direcciones destino. DNS retorna direcciones IPv6, IPv4 o ambas. Las aplicaciones IPv6/IPv4 eligen la dirección y luego se comunican. ConnodosIPv4usandoIPv4o ConnodosIPv6usandoIPv6

Transición IPv6 - Encapsulado Para poder alcanzar Internet IPv6, un host aislado o una red debe usar la infraestrutura IPv4 existente para transporte de paquetes IPv6. Tunneling: encapsular paquetes IPv6 dentro de paquetes IPv4, para poder usar IPv4 comocapadeenlaceparaipv6. ElencapsuladoseindicaconelcampodeprotocoloIPen41. También se puede encapsular paquetes IPv6 en paquetes UDP, por ejemplo para atravesar un router o NAT que bloquee dicho número de protocolo.

Transición IPv6. Tunneling Interfaz de ingreso al túnel: paquetes IPv6 en paquetes IPv4 que se rutean sobre las redes IPv4. Alasalidadeltúnel:des-encapsuladoaIPv6. Extremos deben ser dual stack. EnelcaminoeltúnelesunsaltoenIPv6. ParaIPv6,laredIPv4escomocapadeenlace. LaMTUdeltúneldebeconsiderarlos20bytesdeheaderIPv4. ElTúnelpuedeser:Routertorouter/Hosttorouter/Hosttohost

6to4 Conexiónde dominiosipv6 víaredesipv4 -Mesh Para cada red IPv6 aislada, asigna un prefijo que incluye la dirección IPv4 de su router 6to4. Tunnel Mesh. Relaciona la dirección de cada red IPv6 aislada a la IPv4 de su router 6to4: 2002::IPv4router6to4/48. IPv4 pública. Una comunicación saliente de una red IPv6 se encapsula en el router 6to4 y el extremo del túnel se configura a partir de la dirección IPv6 destino. Router-to- Router, Mesh. Si la red destino es Internet IPv6, se encapsula hacia un relay 6to4. En este caso, el router 6to4 debe conocer de antemano la dirección del relay. El relay 6to4 avisa los prefijos 2002:IPv4::/48 de todas las redes aisladas IPv6 a la Internet IPv6. El problema en el relay es que debe sumar una ruta por cada red aislada IPv6 y su anuncio genera lo mismo sobre la Internet IPv6. Prefijo no agregable implica problemas en escalamiento de ruteo.

6to4 - Componentes Prefijo Global, sin depender de un ISP. IPv4 debe ser pública IPv4 IPv6 Interfaz túnel 6to4 Interfaz túnel 6to4 Re-envío para hosts Dirección global 6to4 No puede realizar túnel. Dentro de un sitio, el router local IPv6 anuncia prefijos 2002:WWXX:YYZZ:SubnetID::/64 para que los hosts creen sus direcciones 6to4.

6to4 - Direccionamiento El router 6to4 con salida a Internet, dirección pública IPv4: 157.60.0.1 => crea el prefijo: 2002:9D3C:1::/48, (9D3C:1 es 157.60.0.1) y anuncia el prefijo 2002:9D3C:1:1::/64 sobre su LAN (SubnetID configurable manualmente o asignado automáticamente por el router). Hosts IPv6 configuran por ejemplo 2002:9D3C:1:1::1. Host/router B 6to4 se conecta directamente a Internet con una dirección pública IPv4, 131.107.0.1 => dirección IPv6 2002:836B:1::836B:1.

6to4 - Enrutamiento

6to4 El router 6to4 y el relay 6to4 son sin estados. De este modo, no queda limitado por el número de usuarios. El relay 6to4 debe anunciar todos los prefijos /48 a la red IPv6 global. Trae problemas de escalabilidad de enrutamiento. Se trata de un esquema mesh no escalable como solución a largo plazo. El relay 6to4 es generalmente accesible en la dirección anycast 192.88.99.1, no pudiendo el usuario tener control sobre el relay elegido para la comunicación. Problemas potenciales de seguridad. Problema de seguridad: routers y relay 6to4 son un agujero para ataques spoofing desde IPv4 sobre IPv6 (en la mayoría de los mecanismos de túnel pasa lo mismo)

6over4 IPv6 sobredominiosipv4 portúnelentre hosts Tansmisión de IPv6 sobre redes IPv4 sin túnel explícito (por Protocolo 41) para hosts IPv6 aislados, utilizando multicast IPv4 para construir LAN virtual Host-to- Host. Define método para generar Dirección Link-Local: FE80::DirIPv4. 192.0.2.142 -> FE80::C000:28E. Define mapeo multicast : FF02::1 (Todos los nodos) -> 239.192.0.1; FF02::2 (Todos los routers) -> 239.192.0.2; FE80::C000:28E (Multicast nodo solicitado) -> 239.192.2.142 Con estas direcciones, el nodo puede usar ND ICMPv6 para descubrir vecinos y routers y hacer autoconfiguración sin estados. 6over4 depende del despliegue de multicast IPv4. No es tan fácil el funcionamiento de protocolos de LAN para configuración sin estados ND, con peligro de inyección de mensajes falsos ND. Soporte limitado en ISP por necesidad de soporte multicast. Dificultad adicional para habilitar autoconfiguración en la LAN virtual

ISATAP Mecanismo de Túnel host-to-host Intra-Site Automatic Tunnel Adressing Protocolo. Host-to-Host. Para hosts con capacidad IPv6 que se comunican a través de redes IPv4. Utiliza IPv4 como capa de enlace virtual. Host ISATAP: Link-local IPv6 con prefijo FE80::5EFE/96 + IPv4 propia. Encapsulado en IPv4 => Dirección Fuente y Destino IPv4 extraída de IPv6. Es sin estados. GW ISATAP también puede ser extremo de un túnel, avisando a los hosts ISATAP los prefijos globales (prefijos de configuración) por medio de ND. Los hosts ISATAP deben ser configurados apuntando al GW ISATAP. Buena performance porque es sin estados, pero complicado en el plano de control. Mejor es 6rd. Riesgos de seguridad en el caso de atacantes IPv4 que pretendan ser parte de la red.

ISATAP - Componentes Avisos de prefijo de subred ISATAP para configuración Dirección ISATAP Link Local, comunicación túnel directa intranet Interfaz Túnel Link Local ISATAP para intranet Ruta default (Global ISATAP) a Link Local ISATAP de router Requerimiento DNS para posterior configuración

6rd rd es por despliegue rápido de IPv6 a través de infraestructura IPv4 de ISP. Hostto-Host 6rd es una extensión de 6to4 que permite a proveedores conectar redes IPv6 clientes con Internet IPv6 nativo. La principal diferencia es que: 6to4 usa bloque pre-definido 2002::/16. El prefijo de 6rd pertenece al SP. Así, 6rd provee conectividad IPv6 casi nativa y sus clientes no son inmediatamente distinguibles por sus direcciones. 6to4 usa la dirección completa IPv4 en el prefijo. En 6rd esto no es necesario. Componentes 6rd: CE: router de borde de cliente, el que lo conecta al SP. BR: relay de borde, similar al relay 6to4, pero lo maneja el SP.

6rd CE1: 10.1.1.2 CE2: 10.2.2.2 BR: 10.3.3.2. Prefijo 6rd (del SP): 2001:db8::/32 => asegura alcanzabilidad. Parte de la dirección IPv4 elegida: 10 es común, descartar. Prefijo delegado: de 56 bits Prefijo delegado para CE1: 2001:db8:0101:0200::/56 Prefijo delegado para CE2: 2001:db8:0202:0200::/56 Prefijo delegado para BR: 2001:db8:0303:0200::/56

6rd Tráfico a otro nodo 6rd en el dominio 6rd: Por ejemplo, CE1 recibe tráfico IPv6 desde la LAN, destinado a 2001:db8:0202:0200::1. La dirección cae dentro del rango de su prefijo 6rd (2001:db8::/32). CE1 determinará cuántos bits de la dirección IPv4 se encuentran codificados en esa dirección ( restando la máscara de red IPv4). Extrae la dirección IPv4 y le agrega su propia parte de subred. Así calcula qu el destino del túnel es: 10.2.2.2, la dirección IPv4 de CE2. Tráfico a Internet IPv6 nativa: Por ejemplo, CE1 recibe tráfico para 2001:c034:adbf::1. Entiende que el destino no pertenece a su dominio 6rd y envía el tráfico al 6rd BR que, a su vez, lo reenvía al destino final. Existe un formato de opción DHCPv4 que permite especificar el prefijo 6rd y la dirección del router 6rd BR, para que los routers CE se puedan configurar apropiadamente.

6rd Al usar un prefijo propio del SP, el mismo se puede agregar en el BR para ser anunciado a la Internet IPv6. Así se remueven problemas de escalabilidad de rutero propios de 6to4. En el plano de encapsulado de datos, el mecanismo es sin estados. Asegura buena performance. Se permite la comunicación entre CE s sin pasar por BR.

Teredo TúnelIPv6 sobreudp paranat Problema para atravesar NAT en IPv4. 6rd y 6to4 usan encapsulado IP Protocolo 41. NAT típico permite paso de paquetes TCP/UDP/ICMP. No reconoce Protocolo 41. Teredo usa encapsulado IPv6 over UDP over IPv4. Host-to-Host. Un Cliente Teredo, iniciador del túnel, adopta un prefijo de 64 bits: 2001:0000/32+ DirIPv4ServerTeredo. El identificador de interfaz: puerto UDP + DirIPv4 mapeada en el NAT extremo. El Cliente aprende la dirección IPv4 y el puerto por interacción con el Servidor, al mismo tiempo que instala la traducción en el NAT (o NATs). Debe refrescar este mapeo cada tanto, por interacción con el Servidor. Complicado en el plano de control.

Teredo TúnelIPv6 sobreudp paranat Dos clientes Teredo se pueden comunicar directamente con el esquema de direcciones adoptado. Se encapsula en UDP y la dirección IPv4 Destino y Puerto Destino se extraen de la dirección IPv6 Destino. Para comunicación entre Clientes y Host IPv6, se usa relay Teredo como concentrador. El relay Teredo debe anunciar los prefijos Teredo sobre la red IPv6. Configuración inicial: Router Solicitation a server Teredo de preferencia. Router Advertisment con prefijo y mapeo (diripv4, port UDP) en el NAT => obtiene dirección y entiende si está detrás de un cone NAT o un NAT restringido. Descubrimiento de relay por parte del Cliente: ICMPv6 Eco Request a nodo IPv6, por túnel al Server y luego a destino. Eco Replay re-enviado al relay en la red IPv6. Luego en túnel al Cliente. Este puede ver la dirección IPv4 Fuente y Port Fuente del paquete encapsulado.

Teredo NAT-T paraipv6 Host-specific relay: IPv6/IPv4 con conectividad con redes IPv4 e IPv6 y se puede comunicar directamente con clientes Teredo sobre IPv4 sin necesidad de relay Teredo. IPv6/IPv4, interfaz Teredo para túnel host-to-host o hostto-router. Teredo server: IPv6/IPv4 conectado a Internet IPv4 e Internet IPv6. Asiste en la configuración inicial de los clientes Teredo y facilita comunicación inicial entre clientes Teredo o entre estos y nodos IPv6. Teredo relay: Router IPv6/IPv4, túnel host-to-router y router-tohost para re-enviar paquetes entre clientes Teredo en IPv4 y hosts IPv6en IPv6.

Teredo- Direcciones Prefijo Teredo: (32 bits) 2001::/32 (RFC 4380) Dirección Teredo server IPv4: (32 bits) IPv4 pública del servidor que asiste en la configuración de esta dirección. Flags: (16 bits) Protección. Obscured external port: (16 bits) para el puerto externo UDP que corresponde a todo el tráfico Teredo para este cliente. Obscured external address: (32 bits) para la dirección externa IPv4 que corresponde a todo el tráfico para ese cliente.

Teredo- Direcciones Cliente A, detrás de cone NAT: Su servidor está en 206.73.118.1(CE49:7601), sale por 157.60.0.1:4096 (9D3C:0001+FFFFFFFF=62C3:FFFE; 1000+FFFF=EFFF). Cliente B, detrás de cone NAT: Su servidor está en 206.73.118.1(CE49:7601), sale por 131.107.0.1:8192 (836B:0001+FFFFFFFF=7C94:FFFE; 2000+FFFF=DFFF).

Teredo- Enrutamiento

Teredo AtravesarNAT restringido luegode configuración inicial 1. No pasa el NAT de TCB porque no hay map. Instala map en NAT de TCA (así TCB se podrá comunicar luego). 2. La dirección IPv4 destino la obtiene de la dirección IPv6 de TCB. 3. Debido a la configuración inicial, hay map previo. Este paquete atraviesa NAT de TCB. 4. Atraviesa NAT de TCA porque 1 lo mapeó. 5. Al Rx 4, TCA determina que TCB tiene un map en el NAT (y él también). De este modo entiende que la comunicación es posible.

Traductor Para comunicación directa entre redes IPv4 y redes IPv6. La idea es convertir paquetes IPv6 en paquetes IPv4 y al revés. Router de Borde oficia de traductor. Por ejemplo H1 en IPV6 (iniciador) quiere comunicarse con H2 en IPV4. Primero tiene que conocer la dirección IPv4 del destino. A su vez, la dirección fuente IPv4 de la comunicación será la calculada por el traductor. Es un NAT entre espacios de direcciones pero el gran problema es el escalamiento y la asimetría entre ambos espacios. Existen dos formas: sin estado y con estado.

Traductor Sin Estados En este modo, un rango de direcciones IPv6 representará sistemas IPv4 (direcciones convertidas). Los sistemas IPv6 tienen direcciones traducidas mediante un algoritmo a un subconjunto de direcciones IPv4 del proveedor. Las direcciones traducidas son un subconjunto de las convertidas. Premisa sin estados: cada host IPv6 posee una dirección IPv4. Prefijo 1+ IPv4 propia es la IPv4 traducida, que se asigna a un host IPv6 => ::ffff:0:a.b.c.d. Prefijo 2 agregado a IPv4 es la dirección IPv6 de un host IPv4. Es IPv4 mapeada. Esto genera las reglas de mapeo para un lado y el otro. El problema es que genera nuevas rutas para anunciar del lado IPv6 (por el uso del prefijo fijo) y se sigue dependiendo del abastecimiento de direcciones IPv4. Se podría generar IPv6 con prefijo NSP y permitir así el agregado de rutas. Se podría entregar las direcciones IPv6 mediante DHCPv6 o ND. Se podrían aprender las direcciones IPv4 mediante un Servidor DNS64.

Traductor Con Estados Consiste en mantener un pool de direcciones en el traductor y traducir por número de puerto. NAT-PT presenta los hosts IPv4 a la red IPV6: IPv4 mapeada. NAT-PT presenta los hosts IPv6 a la red IPV4: dependiendo del mapeo. Según el flujo real de las comunicaciones: Mapeo (IPv6-puerto --- IPv4- puerto). Anuncia prefijos del pool IPv4 a la red IPv4. Anuncia prefijos ::/96 a la red IPv6. Traducir un paquete IPv6 a IPV4: Dir.Fte- PortFte según mapeo. DirDest- PortDest por remoción del prefijo. Traducir un paquete IPv4 a IPV6: Dir.Fte- PortFte por agregado de prefijo. DirDest-PortDest por búsqueda en el mapeo. Iniciar comunicación desde IPv6: destino por mapeo. Iniciar comunicación desde IPv4: precisa que se haya establecido mapeo. Posible Solución: Servidor DNS convirtiendo AAAA-A-AAAA por prefijo y A- AAAA-A por mapeo. Mejor utilización de direcciones IPv4 pero tiene retardos en la creación por flujo.

NAT64 NAT y PT (Client IPv6-Server IPv4) Red IPv6 NAT map Red IPv4 DirFte: IPv61 DirDst: Pref+IPv41 PortFte: 3331 PortDst: 80 IPv61, 3331 -> IPv4 pool, 3331 DirFte: IPv4 pool DirDst: IPv41 PortFte: 3331 PortDst: 80 DirFte: DirDst: PortFte: PortDst: DirFte: DirDst: PortFte: PortDst: Pref+IPv4 1 IPv61 80 3331 IPv4 1 IPv4 pool 80 3331

NAT64 NAT y PT (Client IPv6-Server IPv4) Sólo especifica comunicación iniciada del lado IPv6. El prefijo IPv6 usado para mapeo IPv4 es: 64:FF9B::/96. El traductor NAT64 debe anunciar el prefijo 64:FF9B::/96 a la red IPV6 y el prefijo del pool de direcciones IPv4 a la red IPv4. En el traductor hay un servidor DNS64. Traslada Query AAAA de host IPv6 a Query A y la Respuesta A a Respuesta AAAA según la regla de mapeo IPv4. Sigue creando mapeo por flujo y con estado, como NAT-PT, lo cual no lo hace escalable a un escenario de conexión masivo.

Traducción- Resumen Escalabilidad: Sin estados requiere consumo de direcciones IPv4. Con estados requiere mantenimiento por flujo. Ninguno puede escalarse a masivo. Espacio de Direcciones Heterogéneo: El iniciador debería conocer la dirección del otro extremo, ya sea porque la construye él mismo o porque un servidor DNS se la entrega. Esto último requiere el registro de todos los hosts en el DNS. No es posible realizar traducción IPv4 a IPv6 por estados. Traducciones a nivel aplicación: Imposible en tiempo real, debido a la variedad de aplicaciones.