IPv6 2024 v1

Sitio: Facultad de Ingeniería U.Na.M.
Curso: Redes II - IC421
Libro: IPv6 2024 v1
Imprimido por: Invitado
Día: miércoles, 4 de diciembre de 2024, 23:34

1. Introducción

Apenas a 10 años de la implementación de IPv4, los organismos se dieron cuenta de que sería un problema la cantidad de IPs Públicas y que se agoratían.
Agotamiento de IPV4

Las direcciones IPv4, permite identificar la interfaz de red en todo internet. Estas IP debe ser única, para que funcione.
Sabemos que para IPV4 la cantidad de Direcciones posibles se forman con 32 bits.
Por lo tanto IPv4 = 4.294.967.296 (= 232 ).

¿Es esta cantidad de direcciones disponibles es totalmente cierta?


Matemáticamente es totalmente cierta, pero el punto es cómo se utilizaron.

Esto a priori parecía una cantidad extremadamente alta, pero algunas decisiones de distribución,  sumadas al gran crecimiento causaron que esta cantidad de direcciones no fuera suficiente.
Los routers de Internet, son los que analizan el camino a seguir para llegar de una IP de origen a otra IP de destino, siempre hablando de IP Púbicas(ruta). Como ya vimos IPv4, tiene 32 bits para generar las IP, sobre este espacio, no se ha asignado con efectividad, como ya señalamos, lo que perjudicó la falta de IPs.
ICANN,es el organismo que distribuye las IPs publicas en el mundo. (https://www.icann.org/es)

https://www.icann.org/es/system/files/files/getting-to-know-icann-quicklook-30apr20-es.pdf

Este organismo distribuye las IPs entre los RIRS y estos a su vez a los ISP Internet Service Provider y estos a los usuarios finales.

RIR: Registro Regional de Internet, en inglés Regional Internet Registry (RIR), es una organización que supervisa la asignación y el registro de recursos de números de Internet dentro de una región particular del mundo. Los recursos incluyen direcciones IP (tanto IPv4 como IPv6) . Hay 5 RIRs a nivel mundial, cada uno ubicado en una zona geográfica. Cada RIR tiene sus propias políticas de asignación de IPs.


Figura 1: Distintas Regiones de IANA

IANA: https://www.iana.org/

Acerca de IANA:

La entidad Internet Assigned Numbers Authority desempeña un papel esencial en la gestión de Internet, ya que es responsable de asignar nombres y sistemas de números únicos que se usan de acuerdo con los estándares técnicos –protocolo de red– de Internet y constituyen la base del direccionamiento de páginas web. Aunque Internet no es una red gestionada de forma centralizada, debido a determinadas circunstancias técnicas algunos componentes básicos deben coordinarse a escala mundial, actividad de la que ya se ocupaba la IANA con ARPANET, lo que la convierte en una de las instituciones más antiguas de Internet.

Desde 1998, la IANA se constituye como una sección de la ICANN, organización compuesta, además, por otros grupos que representan diferentes intereses en Internet y participan juntos en la toma de decisiones. Se dividen en organizaciones de apoyo (supporting organizations) y comités asesores (advisory commitees).



1. AfriNIC (African Network Information Centre), región África http://www.afrinic.net.
2. APNIC (Asia Pacific Network Information Centre), región Asia/Pacífico http://www.apnic.net.
3. ARIN (American Registry for Internet Numbers), región América del Norte http://www.arin.net.
4. LACNIC (Regional Latin-American and Caribbean IP Address Registry), América Latina y algunas islas del Caribe http://www.lacnic.net.
5. RIPE NCC (Reseaux IP Europeans), Europa, Medio Oriente y Asia Central http://www.ripe.net.

El 3 de febrero de 2011(hace mas de 10 años!!!) la IANA asignó su último bloque de direcciones IPV4 a los RIRs.
•APNIC, últimas IPS 15 de Abril del 2011.
•RIPS NCC, últimas Ips 14 de Septiembre de 2012.
•ARIN, últimas Ips 23 de Abril del 2014.
•LACNIC últimas Ips 10 de Junio del 2014.
•AFRINIC (falta información).

Niveles de ISP

Los ISP se designan mediante una jerarquía basada en su nivel de conectividad al backbone de Internet.
Cada nivel inferior obtiene conectividad al backbone por medio de la conexión a un ISP de nivel superior. La jerarquía o nivel se conoce como Tier (nivel) y los hay Tier1, Tier2 y Tier3.
Desde los Tier1 hacia Tier3 se van distribuyendo las IPs.

Observación:  

Tier en inglés significa nivel.

Tránsito: una red informática permite que el tráfico de la red la cruce proporcionando servicios de tránsito. Normalmente, el tránsito lo pagan redes más pequeñas para obtener acceso al resto de Internet. Podría ser el caso de Marandu.
Par: los propietarios de redes pueden ver un beneficio mutuo al permitirse mutuamente acceso a sus respectivas redes. En esta situación, ninguna de las partes tiene que pagar por el intercambio de tráfico, lo que se conoce como intercambio sin liquidación, esto podría ser el caso de Telecom..

Cuestiones como:

Hicieron que las direcciones de IPv4 que parecían tantas en un primer momento no sean suficientes, esto se vió venir a los pocos años de que se comenzó utilizar IPv4.
Veamos como crecieron las cantidades de desde 1998 al 2003:

Routing Table SizeFigura: Crecimiento de tablas en Routers core.

En este sitio : http://www.singularity.com/charts/page79.html se indica la "SINGULARIDAD ESTÁ CERCA" indicando claramente que se avecinan un momento singular, ver que los datos son del 2005!.

Figura Crecimiento de host por año.

CISCO tiene un gráfico similar: https://www.isc.org/survey/


Existen una serie de videos sobre IPv6 realizados por LANIC, son interesantes para ver como introducción para el Alumno.

Dejo el link al canal de LACNIC en Youtube :

En este sitio de Google https://sites.google.com/site/tknikaipv6/home encontré bastante información, no es totalmente académica, pero es de un grupo que intenta aprender y documentar todo lo de IPv6.

CCNA de Cisco Capa de Red: https://www.sapalomera.cat/moodlecf/RS/1/course/module6/#6.0.1.1

RFC: https://www.rfc-editor.org/rfc/rfc4291

2. IoT

En la actualidad, Internet es significativamente distinta de como era en las últimas décadas.
Hoy en día, Internet es más que correo electrónico, páginas Web y transferencia de archivos entre PC.
Internet evoluciona y se está convirtiendo en una Internet de las cosas.

Fuente: 6LoWPAN_The Wireless Embedded Internet


La Internet de hoy está formada por un núcleo de Internet de enrutadores y servidores troncales, que incluye millones de nodos (cualquier tipo de dispositivo de red) en total. El núcleo de Internet cambia raras veces y tiene una capacidad extremadamente alta. La gran mayoría de los nodos de Internet de hoy se encuentran en lo que a veces se denomina Internet marginal o Fringe.(Nosotros)

La Internet marginal o Fringe incluye todas las computadoras personales, portátiles e infraestructura de red local conectadas a Internet. Esta franja cambia rápidamente y se estima que tiene hasta mil millones de nodos. En 2008 se estimó que Internet tenía aproximadamente 1.400 millones de usuarios habituales, y Google anunció que existían más de un billón de URL únicas en sus índices de búsqueda. El crecimiento de la franja depende del número de usuarios de Internet y de los dispositivos personales que utilizan.

La Internet de las cosas, a veces denominada Fringe/Embbedded Fringe, es el mayor desafío y oportunidad para Internet en la actualidad. Se compone de dispositivos integrados habilitados para IP conectados a Internet, incluÍdos sensores, máquinas, etiquetas de posicionamiento activo, lectores de identificación por radiofrecuencia (RFID) y equipos de automatización de edificios, por nombrar solo algunos. El tamaño exacto de Internet de las cosas es difícil de estimar, ya que su crecimiento no depende de los usuarios humanos. Se supone que Internet de las cosas pronto superará al resto de Internet en tamaño (número de nodos) y seguirá creciendo a un ritmo vertiginoso.

El tamaño potencial a largo plazo del Internet de las cosas se expresa en billones de dispositivos.

El mayor potencial de crecimiento en el futuro proviene de redes y dispositivos inalámbricos integrados de bajo consumo de energía que hasta ahora no han sido habilitados para IP: la Internet integrada inalámbrica.

En 2008, líderes de la industria formaron la IP Smart Objects (IPSO) Alliance [IPSO] para promover el uso de protocolos de Internet por parte de objetos inteligentes y la Internet de las cosas a través del marketing, la educación y la interoperabilidad. La Internet inalámbrica integrada es un subconjunto de la Internet de las cosas y el tema principal de este libro.

Para este escenario presentado, IPv4 no podría satisfacer las necesidades: Solución -> IPv6!!

En este sitio de Google podemos ver las "adopciones de IPv6": https://www.google.com/intl/en/ipv6/statistics.html
Solo a modo ilustrativo ponemos una imagen del sitio que muestra en tiempo real el crecimiento y permite discriminar por país.

Nota: Teredo es una tecnología de transición que proporciona conectividad IPv6 a hosts que soportan IPv6 pero que se encuentran conectados a Internet mediante una red IPv4.1

3. Solución: IPV6

Apenas en 1990, antes de que se comience a explotar comercialmente internet, ya un grupo visionario vió el problema en el horizonte y se comenzaron a trabajar en alternativas. Estas aparecieron en 1992.

  • 1) En 1992 IETF crea el Grupo ROAD (ROuting Addressing) comienza a estudiar posibles soluciones.
  • 2) Tipos de tildes - Clases, categorías y clasificación(visto) CIDR (RFC 4632) Dejar de usar Clases. Classless Inter-Domain Routing se introdujo en 1993 por IETF y representa la última mejora. Su introducción permitió una mayor flexibilidad al dividir rangos de direcciones IP en redes separadas.
    • De esta manera permitió:
      • a) Un uso más eficiente de las cada vez más escasas direcciones IPv4.
      • b) Un mayor uso de la jerarquía de direcciones (agregación de prefijos de red), disminuyendo la sobrecarga de los enrutadores principales de Internet para realizar el encaminamiento.
      • c) Bloques de direcciones de tamaño apropiado a las necesidades y usos.
      • d) Dirección de red = prefijo/longitud.
  • 3. Tipos de tildes - Clases, categorías y clasificación(visto) Agregación de rutas.DHCP.
    • a) NAT + RFC 1918 :
    • b) En el año 1995 se comienza a usar NAT + CIDR.
      • 1) Permite usar una Dirección Pública para una toda una red.
      • 2) Problema. Acceso y fué insuficiente.
Observación 1: Creo que es indudable que las medidas utilizadas que se mencionan en los puntos 2 y 3, fueron tan buenas que la tasa de sobrevida de IPV4 se extendió mas allá de lo esperado.

Observación 2: Ver que el problema de falta de Direcciones se comenzó a tratar en 1990, solo apenas 9 años desde su implementación en 1980...

A continuación les dejo un par de videos que hablan sobre este tema:

  ¿Porqué usar IPv6 hoy?.

  Desarrollo de IPv6 en la región.

4. Aquitectura Direcciones IPv6

Este capítulo se basa en el RFP 4291 que trata sobre: IP Version 6 Addressing Architecture.

También se usó imágenes e información: "IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6". . Second Edition. Autor Rick Graziani.

Vamos a definir la terminología usada:

  • router: nodo que reenvía paquetes IP que no son para él mismo.
  • host: cualquier nodo que no es router.
  • nodo: dispositivo que implementa IP (router o host).
  • enlace (link): medio o facilidad que comunica los nodos.
  • interfase: lo que usa el nodo para conectarse al enlace.


4.1. Datagrama IPv6


  • 128 bits para Direccionamiento.
  • Cabecera base simplificada.
  • Cabeceras de extensión.
    • Son opcionales y puede haber varias.
    • Proveen información adicional.
    • Hay una cantidad limitada de Extension Headers.
    • Se ubican entre la cabecera IPv6 y la cabecera de la capa superior.
    • Tienen que estar declaradas en la cabecera anterior.
    • Son para el host destino.
    • Se deben procesar en orden.
  • Identificación de flujo de datos (QoS).
  • Mecanismos de IPSEC incorporados al protocolo.
    • IPsec (abreviatura de Internet Protocol security) es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos. IPsec también incluye protocolos para el establecimiento de claves de cifrado.
  • Fragmentación solo en origen y Re-ensamblado de paquetes en destino.
  • No requiere el uso de NAT, permitiendo conexiones Punto a Punto.
  • Mecanismos que facilitan la configuración de las redes.
UDP IP v6 (campos del  Datagrama)

  • Versión (4 bits): número de la versión del protocolo Internet; el valor es 6.
  • Clase de tráfico (8 bits): disponible para su uso por el nodo origen y/o los dispositivos de encaminamiento para identificar y distinguir entre clases o prioridades de paquete IPv6.
  • Etiqueta de flujo (20 bits): se puede utilizar por un computador para etiquetar aquellos paquetes para los que requiere un tratamiento especial en los dispositivos de encaminamiento dentro de la red. Sería algo como identificar el flujo que requiera una QoS para darle prioridad.
  • Longitud de la carga útil (16 bits): longitud del resto del paquete IPv6 excluida la cabecera, en octetos. En otras palabras, representa la longitud de todas las cabeceras de extensión más los datos de la capa de transporte.
  • Cabecera siguiente (8 bits): identifica el tipo de cabecera que sigue inmediatamente a la cabecera IPv6; se puede tratar tanto de una cabecera de extensión IPv6 como de una cabecera de la capa superior, como TCP o UDP.
  • Límite de saltos (8 bits): el número restante de saltos permitidos para este paquete. El límite de saltos se establece por la fuente a algún valor máximo deseado y se decrementa en 1 en cada nodo que reenvía el paquete. El paquete se descarta si el límite de saltos se hace cero. El consenso fue que el esfuerzo extra de contabilizar los intervalos de tiempo no añadía un valor significativo al protocolo. De hecho, y como regla general, los dispositivos de encaminamiento en IPv4 tratan el campo tiempo de vida como un límite de saltos.
  • Dirección origen (128 bits): dirección del productor del paquete.
  • Dirección destino (128 bits): dirección de destino deseado del paquete. Puede que éste no sea en realidad el último destino deseado si está presente la cabecera de encaminamiento, como se explicará después.
Observación: Notar que NO existe FCS o CRC!
Extension Headers ( NO figuran en la imagen)
  • Son opcionales y puede haber varios.
    • Proveen información adicional.
    • Hay una cantidad limitada de Extension Headers.
    • Se ubican entre la cabecera IPv6 y la cabecera de la capa superior.
    • Tienen que estar declaradas en la cabecera anterior.
    • Son para el host destino.
    • Se deben procesar en orden.
  • MTU mínimo de 1280 octetos ( importante!).
  • Se recomienda mínimo 1500 octetos, para tunelizado con IPv4.
  • IPv6 no soporta fragmentación.
  • Si un enlace no puede transmitir 1280 octetos, debe encargarse de la fragmentación en una capa inferior.
  • Carga útil máximo de 64KB.
  • Jumbo Payload option rfc2675: 4GB
Solo para contrastar recordamos el UDP IPv4:

Y finalmente una tabla que permite resumir las diferencias:


Veamos de manera gráfica que campos fueron eliminados y cuales cambiaron de nombre entre  IPv4 respecto de IPv6.



 En datagrama IPv6 NO EXISTE 

  • Header Checksum.

  • ID de datagrama

4.2. Proximo Header (Informativo)

A modo informativo, mencionamos los posibles valores de la siguiente cabecera.

Se resalta este último por que es algo que se verá mas adelante.

5. IPv6 ADDRESSING

Las direcciones IPv6 de cualquier tipo son asignadas a las interfases.

Una sola interfase puede tener múltiples direcciones IPv6 (unicast, multicast, anycast que ya veremos.)

Excepción: Direcciones de unidifusión con un alcance mayor que el alcance del enlace, no son necesarios para interfaces que no se utilizan como origen o destino de ningún paquete IPv6 hacia o desde no vecinos. A veces esto es conveniente para interfaces punto a punto.

Cada interfase pertenece a un solo nodo.

Hay en principio 3 tipos de direcciones:

Unicast.

Una IPv6 de Unicast identifica una única interfase. Un paquete con dirección de Unicast es distribuido a UNA, la única interface con esa dirección.

Multicast.

Una IPv6 de Multicast identifica un conjunto de interfases de red, típicamente de distintos nodos.  Un paquete con dirección de Multicast es distribuido a TODAS las interfaces con esa dirección.

Def nodo: dispositivo que implementa capa 3 IP.

Anycast.

Una IPv6 de Anucast identifica un conjunto de interfases de red, típicamente de distintos nodos.  Un paquete con dirección de Multicast es distribuido a UNA las interfaces con esa dirección, la que esté mas cerca.

Broadcast NO existe en IPv6!!


6. Representación de Direcciones.

Hay tres formas de representar una dirección de IPv6.

1- Preferida : x:x:x:x:x:x:x:x donde x es un valor de cuatro dígitos Hexadecimal (0,1,2,3..8,9,A,B,C,D,E,F). Cada dígito Hexadecimal tiene 4 bits => x tiene 4 valores Hexadecimales => 16  bits (4*4).

Ejemplos:

  • FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
  • 1080:0:0:0:8:800:200C:417A

Nota: Tenga en cuenta que no es necesario escribir los ceros iniciales (izquierda) en un campo individual, pero debe haber al menos un número en cada campo (excepto el caso descrito  continuación).

2) En algunas direcciones de IPv6 pueden existir varios campos seguidos de ceros, se puede reemplazar por un solo cero.

  • 1080:0:0:0:8:800:200C:417A   ser escribe 1080::8:800:200C:417A a unicast address.
  • FF01:0:0:0:0:0:0:101  se escribe FF01::101  a multicast address.
  • 0:0:0:0:0:0:0:1 se escribe ::1   the loopback address.
  • 0:0:0:0:0:0:0:0 se escribe ::   unspecified addresses.
3) Forma Alternativa, en entornos mixtos de IPv4 e IPv6, se suele usar una notación del siguiente tipo:

x:x:x:x:x:x:d.d.d.d

Donde donde las 'x son los valores hexadecimales de las seis partes de 16 bits de orden superior de la dirección, y las 'd' son los valores decimales de las cuatro piezas de 8 bits de orden inferior del dirección (representación IPv4 estándar).

Ejemplo:
  • 0:0:0:0:0:0:13.1.68.3
  • 0:0:0:0:0:FFFF:129.144.52.38
que en formato comprimido sería:
  • ::13.1.68.3
  • ::FFFF:129.144.52.38
Nota:
Ver que en IPv6 se usan : (dos puntos), esto  en IPv4 se correspondería con un puerto de TCP, es por eso que en algunas ocasiones al momento de presentar una dirección IPv6 (como dirección en un navegador, por ejemplo) se la pone entre corchetes para evitar esa confusión:
En una dirección URL, las direcciones IPv6 se muestran entre corchetes. Ejemplo:
http://[2001:0db8:83a3:08d3::0380:7344]/
Los números de los puertos se escriben detrás de los corchetes de cierre separados por dos puntos. Ejemplo:
http://[2001:0db8:83a3:08d3::0380:7344]:8080/

En algunas ocasiones se podría ver el  signo de porcentaje(%), se sigue utilizando para identificar la codificación de caracteres hexadecimales en los URL. Dentro del URL, el signo de porcentaje se sustituirá por su propio código hexadecimal "%25" (RFC 6874). Esto es necesario si se desea forzar la conexión a través de una interfaz específica.


7. Prefijos de Direcciones.

Los prefijos de IPv6 son similares a los de IPv4.

Un prefijo se representa: ipv6-address/prefix-length , donde:

ipv6-address: es la notación de IPv6.

prefix-length: valores decimales de bits contíguos a la izquierda que componen el prefijo.

Ejemplo:

  • 12AB:0000:0000:CD30:0000:0000:0000:0000/60
  • 12AB::CD30:0:0:0:0/60 (alternativa 1)
  • 12AB:0:0:CD30::/60 (alternativa 2)
Ejemplos NO válidos:
  • 12AB:0:0:CD3/60 , no puedo eliminar ceros finales
  • 12AB::CD30/60  => 12AB:0000:0000:0000:0000:000:0000:CD30, no puedo eliminar ceros finales.
  • 12AB::CD3/60 =>  12AB:0000:0000:0000:0000:000:0000:0CD3 no puedo eliminar ceros finales


8. Identificación de Direcciones

En IPv6 aparece un concepto de direccionamiento que se conoce como "ámbito". Hay 3 ámbitos.

  • Ámbito enlace.
  • Ámbito sitio.
  • Ámbito global.


Ámbito enlace: Direcciones únicas para ser usadas en una SOLA interface de red. Conocidas como Link Local (FE::/64). Con estas direcciones para asignar las direcciones globales, y para la detección de vecinos, los protocolos de enrutamiento dinámico también utilizan estas direcciones para compartir las rutas.

Ámbito sitio: Similares a direcciones IPv4 Privadas. Se conocen como Unique Local Address. Son FC00:/7 a FD00/7. Se obtienen con un proceso aleatorio que permite asegurar que son únicas. Aunque sean únicas no se pueden utilizar para comunicarse en Internet, los enrutadores de Internet no tienen rutas para llegar a ellas.

Ámbito Global: Estas direcciones son únicas globalmente, 2000::/3 a 3FFF::/3. Globalmente las asigna la IANA.

Cualquier dirección de IPv6 se puede identificar por los bits de mayor orden :

Notas:

  1. Veremos que las direcciones de Anycast, son tomadas de las Unicast Global, por eso no figuran en la tabla.
  2. La IANA (http://www.iana.org/) dividió todo el rango de direcciones IPv6 en 8 partes. Para ello utilizó los 3 primeros bits, 23 = 8. Por el momento usa 1⁄8 parte de las Direcciones totales con los tres primeros bits en 001.
  3. Direcciones posibles de Unicast al momento de escribir este capítulo:
    •     => como los tres primeros bits están en 001.
    •     => 0010 0000 0000 0000 a 0011 1111 1111 1111=> 2000 a 3FFF.
    •     2000 = 0010 0000 0000 0000 (primera IP Unicast Global).
    •     3FFF = 0011 1111 1111 1111(ultima IP Unicast Global).

Hay dos tipos de direcciones que se pueden asignar a una organización de usuarios finales:
  • Agregable por el proveedor (PA).
  • Independiente del proveedor (PI).

Agregable por el proveedor (PA)
El espacio de direcciones agregable por el proveedor (PA) es un bloque de direcciones asignadas por un RIR a un ISP. Esto permite al ISP agregar (resumir) su espacio de direcciones para un enrutamiento de mayor eficiencia.


Independiente del proveedor (PI)

El cliente final también puede elegir un espacio de direcciones independiente del proveedor yendo directo al RIR. 
El espacio de direcciones IP es asignado por un RIR directamente a una organización de usuarios finales. Este sería el caso de la Facultad de Ingeniería, vemos que por un lado la Facultad de Ingeniería forma parte de la U.Na.M desde la cual recibe un prefijo de red y por otro lado el ISP Obercom el cual le da otro prefijo de red. 
Desde la Facultad de Ingeniería, se envió una nota a Obercom, para que publique sus IPs v6 del prefijo de la U.N.a.M. y así que desde afuera se podría observar que el rango de IPv6 de Obercom NO es el mismo que el de la Facultad de Ingeniería.
Veamos algunos detalles de esto.

Sistemas Autónomos.

Internet es una red de redes, y los sistemas autónomos son las grandes redes que componen Internet. Más concretamente, un sistema autónomo (AS) es una red grande o grupo de redes que tiene una política de enrutamiento unificada, cada AS tiene un nro que lo identifica.


AS 263235 U.Na.M.

Desde el sitio: https://bgp.he.net/AS263235#_prefixes6, podemos ver las IPv6 asignadas a U.Na.M desde la secretaría de Educación:



AS 266668 Obercom

También para la búsqueda: https://bgp.he.net/AS266668#_prefixes6
Podemos ver:


 sigue hasta 2803:a920:990::/44


AS 4270 RIU

La RIU es la Rede de Interconexión Universitaria. Proporciona conectividad a la totalidad de universidades miembro con ancho de banda de 500 Mbps simétricos, tecnología cien por ciento en fibra óptica contratada a distintas compañías de telecomunicaciones. La misma se despliega con topología estrella, donde los enlaces convergen en un datacenter con equipos propios administrados por la ARIU. La U.Na.M es parte de la RIU.




Finalmente podemos mostrar como se interconectan estos sistemas autónomos.

9. Unicast

Las direcciones de unidifusión o unicast global de IPv6 tiene la siguiente estructura:


pero en otras ocasiones puede interpretar un poco mas de los 128 bits, y puede conocer los prefijos de subred para los enlaces en los que se encuentra.

Prefijo de subred: conjunto de bits de una dirección.

Se suele indicar igual que en IPv4 con una / y un número decimal que indica de cuantos bits es el conjunto.



9.1. Global Unicast Address-GUA

El formato de dirección de Unicast Global es:

El "subnet ID" identifica un enlace o link.

El campo "interface ID", lo vimos y lo crea aleatoriamente u obtiene de la mac el host.

Direcciones de unidifusión global que comienzan con binario 000 no tiene tal restricción en el tamaño o estructura del  campo de ID de interfaz estas direcciones se unan para IPv4 embebido en IPv6, como ya veremos.



Se pueden asignar de tres manera (veremos mas adelante):

  1. Manual
    1. Manual.
    2. Manual + EUI-64.
    3. IPv6 unnumbered (IPv6 sin numerar es lo mismo que IPv4. Permite una interfaz
      utilizar la dirección IPv6 de otra interfaz del mismo dispositivo, solo en CISCO
      ).
  2. Stateless Address Autoconfiguration (SLAAC).
  3. Stateful DHCPv6.

Vemos que las GUA Global Unicast Address tienen 3 campos: 

  1. Global Routing Prefix.
  2. Subnet ID.
  3. Interfase ID.
Esta división hace que se conozca como regla 3-1-4, 3 hextetos para el Global Routing Prefix, 1 Hexteto para Subnet ID y 4 Hextetos para Unterfase ID.

Nota Informativa: 
Cisco SO, permite asignar una etiqueta (texto) para hacer referencia a los prefijos, no usaremos esto en nuestra materia ya que no usamos Cisco, pero es a modo informativo. Esto facilita mucho la configuración de routers por ejemplo.



9.2. IPv6 en Linux

Si se usa el comando :

ip -6 addr

Podemos ver los distintos tipos de direcciones IPv6 que tiene en mi caso el LInux/Ubuntu, con el equipo conectado a UNAM Libre:


Vamos a concentrarnos en las del tipo Global, luego en otros capítulos veremos las demás.

La dirección que dice noprefixroute quiere decir que esta IPv6 .2803:70e0:101:125:d881:cb40:e933:4c31/64 :

No tiene una ruta automática para esa interface -> nonprefixroute

mas Info con : man ipv6

9.3. Subnet ID

Subnet ID.

A diferencia de IPv4 es mas sencillo de entender, por que es un campo separado SOLO para ID de subnet, en IPV4 se tomaba parte de otro campo: Host para crear el de subred.
Como son 16 bits, se permitirían 65535 subredes (216 ).

El uso de todos ceros o todos unos para este campo está permitido, pero NO es recomendado, por que puede crear confusión.


Subnet IP extendido (solo Informativo)

En realidad la RFC 4291 no indica el tamaño de subnet ID, esto surge de asignar un /48 a prefijo global y 64 bit al ID de interfase de red, por lo que deja 16 bits para ID de subnet, dicho esto el campo de Subnet ID puede variar su longitud!!

En otras palabras, se puede elegir cualquier número de bits después del prefijo de enrutamiento global para la ID de subred. Al igual que con IPv4, si desea ampliar el número de subredes o más probablemente en IPv6: reduzca la cantidad de hosts por subred, debe tomar prestados bits del  Identificación de interfaz.
Es importante señalar que las mejores prácticas dictan que esto debe hacerse sólo en enlaces de infraestructura de red. Cualquier segmento que incluya sistemas finales debe tener un prefijo /64, que es necesario para admitir SLAAC.


A modo de ejemplo una subred con prefijo /112 sería posible:


Existen variaciones al campo Sub net ID pero DEBE ser en múltiplos de 4 bits o nibbles.

Nibble Boundary : es una mascara de red con 4 bits.

El tratamiento de la variación de prefijo de subred en IPv6 escapa a nuestra materia.


Subnet para enlaces punto a punto en IPv6: ¿/127 o /126?

En IPv6 no hay Broadcast por lo que no se necesita destinar una dirección para broadcast. Tampoco se tiene una dirección reservada para Red, por lo tanto tampoco necesitamos una dirección para ello. Siendo así en principio solo serían necesarias dos direcciones!!! una para cada interfase del enlace punto a punto.
En IPv4 estos enlace era /2, lo que permite 4 direcciones, dos para cada interfase, una para red y otra para broadcast. 
En IPv6 con un /127 sería suficiente.



Este RFC de IETF: https://datatracker.ietf.org/doc/html/rfc6164 trata el uso de /127 para prefijos de IPv6 en enlaces punto a punto entre Routers. En el mismo se hace referencia en un par de ocasiones a NO usar /127 para el caso de estudio, sin embargo aunque los análisis en los RFC son correctos y la experiencia operativa con IPv6 ha demostrado que los prefijos /127 se pueden utilizar con éxito, escapa a nuestra materia un tema tan puntual y vamos a tomar /126 para los enlaces punto a punto entre routers.
Recordemos que somos parte de una institución y la IPv6 que configuremos deben respetar y seguir los lineamientos de la institución, en nuestro caso el /126 fue tomado por los administradores de red de la Facultad de Ingeniería.
 


9.4. Interface de red

Identificador de Interfase.


Cada Dirección Unicast IPv6  tiene una parte que corresponde al Identificador de interfase de 64 bits.

Note que esta porción de "ID de interfase" puede formar parte de OTRAS direcciones globales, en realidad lo que nunca va existir el conjunto prefijo de subred+ id de interfase iguales.
En algunos SO esta porción se genera a partir de la MAC de la placa de red y en otros de manera aleatoria, veamos cada una de ellas, por lo que si bien podrían generarse en el algún lugar del mundo, la parte de ID de Interfase de red aleatoria, sin duda la parte de red NO sería igual, así que esto NO crearía conflicto de IP duplicada, este caso de IP duplicada se acotaría al contexto de una red de una organización solamente.
Veamos como lograr ID de interfase.

1) EUI-64

Para lograr los 64 bits de la id de interfase se usa un mecanismo llamado EUI-64 que toma los 48 bits de la MAC de la placa de Red y genera el id de interfase de 64 bits.

En la figura vemos los 48 bits de una MAC, hay dos bits indicados como u y g.
Si u=0, indica ambito Local si u=1 indica ambito Global, es por eso que el proceso de EUI-64 .

Veamos como se logra esto a partir de la MAC de una interfase.


El Apéndice A de RFC 2373 APPENDIX A: Creating EUI-64 based Interface Identifiers (página 19) explica de forma aproximada cómo se realiza el EUI-64.

Nota :
La comprensión de identificador local o global escapa a la materia, pero tenemos que mencionar que existen casos de enlaces serie, punto a punto de túneles, etc. en la que el administrador debe configurar manualmente los identificadores de alcance local cuando la MAC de hardware no están disponibles, aquí el bit u cobra mas sentido, pero esto escapa a la materia.

2) Extensión de la Privacidad.

Esto de generar aleatoriamente la parte baja de la dirección IPv6, se conoce como Privacy Extensions for SLAAC (que es una manera dinámica de asignar IPv6) y es tratado en RFC 4941, es el caso de usar esta configuración el SLAAC tiene algunos parámetros extra que configurar.
La idea es que se puede rastrear el equipo sabiendo la IPv6, y esto de alguna manera atenta contra la privacidad. Desde Windows Vista, Microsoft ha habilitado la extensión de privacidad en su sistema operativo Windows al por defecto.

Vemos en la figura que si el Host representado en la figura como WinPC tiene habilitado por defecto el Random Identifier, la parte de IPv6 correspondiente a el identificador de interfase se genera aleatoriamente.
En este escenario parte de ID de interfase que se crea aleatoriamente se utilizan como dirección IPv6 de origen cuando el dispositivo origina la conexión.


Direcciones Temporales.

No lo mencionamos, pero también existen direcciones IPv6 temporales.
Las direcciones temporales en IPv6 (o direcciones de privacidad temporales) se utilizan para mejorar la privacidad de los usuarios cuando se conectan a redes públicas o acceden a servicios en Internet. Estas direcciones también se generan de manera aleatoria como en Privacy Extensions for SLAAC y cambian periódicamente para evitar que un dispositivo sea rastreado a lo largo del tiempo por su dirección.

El uso de direcciones temporales es opcional y configurable en el SO. En la mayoría de los sistemas operativos modernos (como Windows, Linux, macOS y Android), las direcciones temporales están habilitadas por defecto, pero los administradores de red o los usuarios pueden desactivarlas si es necesario.
Las direcciones temporales tienen una vida útil corta, normalmente horas o días. 
Es común tener varias direcciones temporales para asegurarse de que las existentes las conexiones pueden continuar mientras se crea una nueva dirección temporal para nuevas conexiones.


Tiempos de Vida de las Direcciones (informativo)


Las direcciones IPv6 tienen distintos tiempos de vida, el tratamiento en profundidad de este tema, escapa a la materia y se puede profundizar en el RFC 4862.
  • Direcciones tentativas: las que están en proceso de verificación.
  • Dirección válida: La dirección es una dirección preferida o en desuso.
  • Dirección Preferida: Se verificó que la dirección es única.
  • Dirección en desuso: La dirección todavía es válida pero no lo será en el futuro.
  • Dirección Inválida: Una dirección que se volvió inválida.
  • Vida útil preferida: este es el período de tiempo que se prefiere una dirección válida hasta que queda obsoleto. Cuando expira el Período de Vida Preferido, la dirección pasa a ser obsoleto.
  • Vida útil válida: este es el período de tiempo que una dirección permanece en el estado válido.
  • La Vida Válida debe ser mayor o igual a la Vida Preferida. Cuando expira la vida útil, la dirección deja de ser válida.
Las IPv6 que NO son temporales, aparece con la etiqueta "forever" esto NO quiere decir que sean para siempre. A modo de ejemplo.


En otro momento:



Podemos ver que si bien son "forever" al ser aleatorias, cambian, por el principio de Privacy Extensions for SLAAC :-).

9.5. LLA Link Local Address FE80::/10

Link-Local es otra de las direcciones de IPv6 de tipo Unicast.

  1. Todo servicio de IPv6 DEBE tener esta dirección de Link Local.
  2. Se diseñaron para ser usadas en el direccionamiento de un único enlace o link LOCALES o sub red.,
  3. Es común poner las mismas direcciones para distintos enlaces de un router por ejemplo.
  4. Un Router no reenvía paquetes del tipo Local Link.
  5. Los dispositivos usan un mecanismo llamado: Duplicate Address Detection (DAD) para determinar si es o no única esta dirección en su enlace/subred.

El formato es:


Las direcciones IPv6 link-local están en el rango de FE80::/10 (en binario 1111 1110 1000 0000).

Estas direcciones se usan para: 
  1. Configuración automática de direcciones.
  2. Descubrimiento de vecinos o cuando no hay enrutadores presentes.

Nota:
Algunos autores recomiendan utilizar la misma dirección link-local para todas las interfases del router (FE80::1) debido a que es una dirección fácil de recordar y como todas las interfaces del router son una red separada no habría problemas porque, como sabemos, las direcciones de enlace local no se enrutan, esto NO se puede hacer en el RouterOS de MK por que el mismo asigna el "interface-ID", los últimos 64 bits por EUI-64.

Nota informativa:
Existen direcciones llamada de Sitio local o Site-Local del tipo Unicast que son OBSOLETAS y comenzarían con el tipo: FEC0/10, pero no si existen deberían desaparecer en el futuro.

Observación:
La idea de que un dispositivo cree su propia dirección IP al iniciarse es realmente un beneficio sorprendente en IPv6.
Un dispositivo puede crear su propia dirección de enlace local IPv6, sin ningún tipo de configuración manual ni los servicios de un servidor DHCP, con esto se logra que el dispositivo puede comunicarse inmediatamente con cualquier otro dispositivo en la red local (subred IPv6).

Es posible que un dispositivo solo necesite una dirección de enlace local porque solo necesita comunicarse con otros dispositivos en su misma red (como una impresora por ejemplo). O puede usar su dirección de enlace local comunicarse con un dispositivo donde pueda obtener información para obtener o crear un dirección de unidifusión global (como un enrutador IPv6 o un servidor DHCPv6). 
El dispositivo puede entonces utilizar esta información para comunicarse con dispositivos en otras redes.

Red AD HOC o peer-to-peer.


En el caso de que se quiera formar una red AD HOC entre dos equipos, si lo pensamos bien,  deberíamos crear un Servidor de DHCP, con rangos de IPs, luego un mecanismo para que se pongan de acuerdo cual de los dos va a ser servidor y cual cliente para que finalmente se puedan comunicar en capa 3, pero nada de eso ocurre.
Muchos sistemas operativos utilizan un mecanismo llamado APIPA (Automatic Private IP Addressing) o Link-Local Addressing.
Las Direcciones Link-Local en IPv6 (fe80::/10), son usadas para redes AD HOC o peer to peer.
En IPv6, cada interfaz de red genera automáticamente una dirección link-local dentro del prefijo fe80::/10. Estas direcciones son equivalentes a las direcciones 169.254.0.0/16 en IPv4, y se usan para la comunicación local en la misma red física

Ver AD HOC en IPv4

9.6. Loop back


  1. Es una dirección del tipo Unicast: 0:0:0:0:0:0:0:1.
  2. No se puede asignar ninguna interfase
  3. Se asocia a una interfase virtual.
  4. Un paquete con esta dirección como una dirección de origen o como  una dirección de destino nunca se enviará más allá del dispositivo.
  5. El dispositivo debe descartar un paquete recibido en una interfaz si la dirección de destino es una dirección de loop back.
  6. Típicamente se usa para probar la pila TCP/IP.


Formas de escribirla:

  • 0000:0000:0000:0000:0000:0000:0000:0001
  • 0:0:0:0:0:0:0:1 (notación comprimida)
  • ::1 ( Regla de los ceros y los dos puntos ::)
  • ::1/128 (usando prefijo de red)

Nota: En IPv4 la dirección de Loopback se corresponde con una Red del tipo a :127.0.0.0/8, es por ello que ping a 127.a.b.c serán respondidos (con a, b en [0,255] y c [0, 254]). Para IPv6  la dirección de loopback es UNA SOLA dirección IP, no una red!



9.7. UA Unspecified Address

La dirección 0:0:0:0:0:0:0:0, se conoce como Dirección No específica. Indica la ausencia de dirección, y se usa durante el proceso de inicialización deIPv6 en el campo de IP de Origen cuando el nodo no tiene IP.

  1. Nunca se debe asignar ningún nodo. (definición nodo: dispositivo que implementa capa 3 IP)
  2. Una dirección de origen no especificada indica la ausencia de una dirección.
  3. No se puede asignar una dirección no especificada a una interfaz física.
  4. Una dirección no especificada no se puede utilizar como dirección de destino.
  5. Un router nunca reenviará un paquete que tenga una dirección de origen no especificada.


Ícono de validado por la comunidad

Formas de escribir:

  • 0:0:0:0:0:0:0:0
  • ::/128
  • ::

Nota :

Un ejemplo en el que se puede utilizar una dirección no especificada es como dirección de origen en ICMPv6. Detección de direcciones duplicadas (DAD). DAD es un proceso que utiliza un dispositivo para garantizar que su dirección de unidifusión es única en el enlace local (red).

9.8. ULA - Unique Local Address FD00::/8

Sería el equivalente a las direcciones IPv4 privadas.

Las direcciones locales únicas también son conocidas como direcciones IPv6 privadas o direcciones IPv6 locales (que no deben confundirse con direcciones Link Local Address).

Las direcciones locales únicas están en el rango de FC00::/7 a FDFF::/7, las LLA FE80::/10


  • Las direcciones ULA se pueden usar de manera similar a las direcciones de unidifusión global, pero son para uso privado  y no debe enrutarse en la Internet global. 
  • Las direcciones ULA solo se deben utilizar en un área más limitada, como dentro de un sitio o entre un número limitado de dominios administrativos.
  • Las direcciones ULA son para dispositivos que nunca necesitan acceso a Internet y nunca es necesario que sea accesible desde Internet (seguro), pero no tiene como propósito ser usadas para ocultar un dispositivo.
  • Estas direcciones pueden ser enrutadas por los routers internos de una organización, pero cuando llegan al borde de la organización y, pasan a un router del ISP, éstas serán descartadas.
ULA a NAT:
ULA y NAT son un tema un poco complicado. El concepto de traducir una dirección local única ULA a una dirección de unicast global GUA es objeto de debate continuo dentro de la comunidad IPv6, y fomenta opiniones emocionales en ambos lados del argumento. La IAB Interne Architecture Board publicó un RFC informativo que destaca sus pensamientos sobre NAT e IPv6 en RFC 5902, IAB Reflexiones sobre la traducción de direcciones de red IPv6.
En este RFC, la IAB resume el uso de NAT de la siguiente manera:
La traducción de direcciones de red se considera una solución para lograr una serie de propiedades deseadas para redes individuales, evitando varias cuestiones y permitiendo ocultar detalles de la red interna y proporcionar seguridad simple.

L Flag y Global ID
Como los primeros  7 bits son  1111 110x, dependiendo si x es 0 ó 1 las ULAs se dividen en dos partes.
  1. fc00::/8 (1111 1100): cuando la bandera L de Local vale 0,  no está definda.
  2. fd00::/8 (1111 1101): cuando la bandera L de Local vale 1.
Por lo tanto las únicas direcciones legítimas de ULA serán:  fd00::/8 .

9.9. SLA Site Local Address

Existen direcciones llamada de Sitio local o Site-Local del tipo Unicast que son OBSOLETAS y comenzarían con el tipo: FEC0/10, pero no si existen deberían desaparecer en el futuro.

No trataremos el tema.

9.10. IPv6 con IPv4 embebida

IPv6 tiene un mecanismo de transición desde IPv4, este mecanismo incorpora la técnica para que host y routers hagan dinámicamente un túnel de IPv4 con paquetes IPv6.

Las direcciones IPv6 asignadas a IPv4 pueden ser utilizadas por un dispositivo de doble pila que necesita enviar un paquete IPv6 a un dispositivo solo IPv4. Como se muestra en la Figura, los primeros 80 bits están configurados como todos 0, y el segmento de 16 bits que precede a la dirección IPv4 de 32 bits todo 1. Los últimos 32 bits de la dirección IPv4 se representan en notación decimal con puntos. Así, la primera 96 bits están representados en hexadecimal y los últimos 32 bits contienen la dirección IPv4 en notación decimal con puntos.


IPv6 asigna direcciones IPv6 de unicast que llevan en la parte mas baja direcciones de IPv4.

Hay dos tipos de IPv6 embebida:

tipo 1) IPv4-Compatible IPv6 address: para la ayudar en la "transición".

tipo 2) IPv4-Mapped IPv6 Address , esta es usada para representar direcciones de nodos IPv4 como IPv6.


esta última es para representar SOLO a los nodos IPv4 que NO soportan IPv6.

Es un esquema de direcciones de transición y no profundizaremos e la materia.


10. Anycast


  • Se asignan a MAS DE UNA INTERFACE típicamente de distintos nodos.
  • Notar que la parte de "interface ID" son CEROS (NO está asociado a UNA SOLA INTERFACE).
  • Tienen la propiedad de que un paquete con esta dirección de anycast es dirigido a la interface MAS CERCANA, para ello usan "subnet prefix" que identifica un enlace o link específico.
  • Los paquetes enviados a esa dirección IP se reenvían al servidor más cercano.
  • Todos los enrutadores deben admitir las Direcciones anycast de Subred-Router para las subredes a las que tienen interfaces.
  • Son direcciones que se ubican en el espacio de direcciones de Unicast.
  • Se usan para comunicarse con  un grupo o conjunto de Routers.


Nota del Docente: podemos decir que Anycast sería un subconjunto de Unicast, la diferencia está en que la parte de "interface ID" son CEROS.

Beneficios:

Redundancia: el servicio no depende de un único servidor, de modo que si un equipo falla, los demás asumen sus funciones y el servicio sigue disponible.

Balanceo de carga: los distintos servidores se reparten el trabajo de modo que no haya un equipo sobrecargado (con la consiguiente merma de rendimiento) y otro inactivo.

Eficiencia: la gran ventaja del "Anycasting" es que simplifica la búsqueda del servidor más apropiado (que suele ser el más cercano).

NOTAS INFORMATIVAS:

Los Servidores de DNS usan este método, para ubicar el servidor de DNS mas cercano a donde lo solicitan.

El emisor NO tiene control sobre la interfase de destino (id de interfase es cero) así que el/los routers toman la decisión del destino.


 

La dirección anycast del enrutador de subred está predefinida. Su formato es como siguiente:


El prefijo de subnet de esta dirección de anycast es un prefijo que identifica un link o enlace específico.

Notar que esta dirección anycast es sintácticamente lo mismo que una dirección de unidifusión para una interfaz en el enlace con el  identificador de interfaz establecido en cero.

Los paquetes enviados a esta dirección van a ser distribuidos al router o a la subred.
Todos los enrutadores deben admitir la Direcciones anycast de Subred-Router para las subredes a las que tienen interfaces.

Nota: esto tiene relación con el planteo de cuantas IPs se necesitan en IPv6 para un enlace punto a punto entre dos routers?
La primer respuesta sería /127. Pero tomando en cuentas esta dirección de anycast de subred de router vemos que debería ser /126 (visto en 9.3 Subnet ID)

Características:

    • Redundancia: el servicio no depende de un único servidor, de modo que si un equipo falla, los demás asumen sus funciones y el servicio sigue disponible.

    • Balanceo de carga: los distintos servidores se reparten el trabajo de modo que no haya un equipo sobrecargado (con la consiguiente merma de rendimiento) y otro inactivo.

    • Eficiencia : la gran ventaja del "Anycasting" es que simplifica la búsqueda del servidor más apropiado (que suele ser el más cercano).

11. Multicast FF02


Una dirección de IPv6 del tipo Multicast, es un identificador de un grupo de interfases, típicamente de nodos diferentes.

Las direcciones de Multicast están solo en el Campo de IP de Destino de un datagrama!!.

El formato es:


  • Se las identifica fácilmente porque son direcciones que empiezan por 0xFF (es decir, por 1111 1111, en binario).
  • Los nodos que se configuran con una dirección multicast determinada forman lo que se llama un GRUPO DE MULTIDIFUSIÓN.
  • Un nodo puede pertenecer a varios grupos de multidifusión.
  • Cuando un paquete es enviado a una dirección de multidifusión, todos los miembros del grupo procesan el paquete.    

Scope o alcance

El campo “Scope” (= ámbito de aplicación) se utiliza para limitar el alcance de una dirección de multidifusión.

En función del valor asignado el ámbito puede ser de interfaz local, de enlace local, de sitio local, global...


  •          0  reserved.
  •          1  Interface-Local scope.
  •          2  Link-Local scope.
  •          3  reserved.
  •          4  Admin-Local scope.
  •          5  Site-Local scope.
  •          6  (unassigned).
  •          7  (unassigned).
  •          8  Organization-Local scope.
  •          9  (unassigned).
  •          A  (unassigned).
  •          B  (unassigned).
  •          C  (unassigned).
  •          D  (unassigned).
  •          E  Global scope.
  •          F  reserved.

Flags.


T=0, indica que es permanente la dirección asignada.

T=1, indica que NO es permanente la dirección asignada.

El segundo bit (R) indica si esta dirección de multidifusión incluye el llamado Rendezvous Point (Punto de Encuentro).

Tipos de Direcciones de Multicast

Hay algunas direcciones reservadas de Multicast y nunca deben ser asignadas a ningún grupo de Multicast.

1) Dirección multicast asignada


Grupo multicast de todos los nodos FF02::1 
Se explica el uso en Network Discovery  ND.
Grupo multicast al que se unen todos los dispositivos con IPv6 habilitado. Los paquetes que se envían a este grupo son recibidos y procesados por todas las interfaces IPv6 en el enlace o en la red. Esto tiene el mismo efecto que una dirección de broadcast en IPv4.

Grupo multicast de todos los routers FF02::2
Se explica el uso en Network Discovery  ND.
Grupo multicast al que se unen todos los routers con IPv6 habilitado. Un router se convierte en un miembro de este grupo cuando se habilita como router IPv6 mediante el comando de configuración global ipv6 unicast-routing. Los paquetes que se envían a este grupo son recibidos y procesados por todos los routers IPv6 en el enlace o en la red.

2) Dirección multicast de nodo solicitado

Las direcciones multicast de nodo solicitado son similares a las direcciones multicast de todos los nodos. Recuerde que la dirección multicast de todos los nodos es esencialmente lo mismo que una dirección IPv4 de broadcast. 
Todos los dispositivos en la red deben procesar el tráfico enviado a la dirección de todos los nodos. 
Para reducir el número de dispositivos que deben procesar tráfico, utilice una dirección multicast de nodo solicitado.

Prefijo multicast FF02:0:0:0:0:1:FF00::/104:
Los primeros 104 bits de la dirección multicast de todos los nodos solicitados. Los  24 bits menos significativos (finales) o que se encuentran más hacia la derecha de la dirección multicast de nodo solicitado se copian de los 24 bits del extremo derecho de la dirección unicast global o unicast link-local del dispositivo.


Ejemplo 1:

Para la IPv6 : 4037::01:800:200E:8C6C , la dirección sería de nodo solicitado sería:   FF02::1:FF0E:8C6C. Vemos que los últimos 24 bits coinciden: E:8C6C

Ejemplo 2:


Multicast capa 2 vs Multicast de capa 3

Las direcciones de multicast de capa 3, deben tener su equivalente en capa 2. 

Multidifusión IPv6: Los 32 bits bajos de una dirección Ethernet para el tráfico de multidifusión IPv6 son los 32 bits bajos de la dirección IPv6 de multidifusión utilizada.

Por ejemplo, el tráfico de multidifusión. 

Origen:

  • capa 3 IPv6 que utiliza la dirección ff02::d
  • capa 2 utiliza la dirección MAC 33-33-00-00-00-0D

Destino:

  • capa 3 el tráfico a ff05::1:3
  • capa 2 la dirección MAC 33-33-00-01-00-03.
Resaltemos esto:
Direcciones comunes de Multcast usadas en RouterOS (Mikrotik)

12. Resumen de direcciones IPv6

Host.

Un host con IPv6 necesitan reconocer varias direcciones:

  1. Direcciónes GUA Global Unicast Address.
  2. Dirección ULA: FC00::/7 a FDFF::/7
  3. Dirección de Link Local de cada interface LLA. FE80::/10
  4. Dirección de Loopback : ::1/128
  5. Dirección de Multicast de todos los nodos: FF01::1 ó FF02::1
  6. Dirección de Multicast de todos los routers: FF01::2 ,FF02::2...hasta FF05::2

Router

Un router necesitan reconocer las siguientes direcciones.

  1. Direcciónes GUA Global Unicast Address.
  2. Dirección de Loopback : ::1/128
  3. Dirección de Link Local de cada interface LLA. FE80::/10
  4. Dirección de Multicast de todos los nodos: FF01::1 ó FF02::1
  5. Dirección de Multicast de todos los routers: FF01::2 ,FF02::2...hasta FF05::2




13. Neighbor Discovery ND

En Neighbor Discovery envía mensajes ICMPv6 a se hace uso de diferentes direcciones de IPv6 todas ellas definidas en RFC4291.

IPv6 NDP (Neighbor Discovery Protocol) (Protocolo de Descubrimiento de Vecinos, en español) es el protocolo que proporciona el descubrimiento de nodo de red como su nombre indica, esto sirve para dos propósitos:

1) Reemplazar a ARP.

2) Autoconfigurar el host para la Red.

Los mensajes informativos y de error encontrados en ICMPv6 son muy similares a los mensajes de  control y error implementados por ICMPv4. Sin embargo, ICMPv6 usado en ND, tiene nuevas características y funcionalidades mejoradas que no se encuentran en ICMPv4. Los mensajes ICMPv6 se encapsulan en IPv6.


  • Estos mensaje se usan para la configuración de prefijo de red, dirección de gateway, DNS (usado en SLAAC, DHCP).
  • Estos se usan para obtener la dirección MAC a partir de la IPv6, este mecanismo reemplaza al ARP (para comunicarse con cualquier equipo de la red).

Mensajes de ND.


Este Mecanismo Neighbor Discovery o simplemente ND es usado entre: 

  • A) Mensajes de ruter-dispositivo utilizados para la asignación dinámica de direcciones.

  • B) Mensajes de dispositivo a dispositivo utilizados para la resolución de direcciones.

Para implementar estos dos mecanismos se usa en principio 4 (*)  mensajes ICMPv6.

A) Los Mensajes que comienzan con R de router <-> equipo  (RA y RS) para la asignación dinámica de direcciones:

1) Mensaje de solicitud de enrutador (RS).
2) Mensaje de anuncio de enrutador (RA).


B) Los mensajes que comienzan con N de equipo <-> equipo  (NA y NS) utilizados para la resolución de direcciones:

  ó

3) Mensaje de solicitud de vecino (NS)
4) Mensaje de anuncio de vecino (NA)

 

Importante!!!

  • Notar que  1 y 2, Router -Dispositivo es para OBTENER IPV6.
  • Notar que 3 y 4 Dispositivo - Dispositivo (cualquier tipo, incluso Router) es para RESOLVER DIRECCIONES.


(*)Nota:
Existe un 5to mensaje de Redirección utilizados para comunicar equipo con Router para la selección del 1er salto, esto No veremos en nuestra materia y es similar a ICMP4.

Tipos de mensajes de ND

Existen 5 tipos de mensajes ICMP6 para estos cuatro mecanismos. Algunas de los cuales pueden aparecer varias veces en el mismo mensaje.

Hay cinco  opciones de descubrimiento de vecinos ICMPv6:
Tipo 1: Dirección de capa de enlace de origen: esta opción contiene la dirección de capa 2 MAC.
(normalmente Ethernet) del remitente del paquete
. Se utiliza en NS , RS, RA.


Tipo 2: dirección de capa de enlace de destino: esta opción contiene la dirección de capa 2 MAC
(normalmente Ethernet) del objetivo previsto.
Se utiliza en NA y y mensajes de redireccionamiento(*).

Tipo 3: Información de prefijo: la opción Información de prefijo proporciona a los hosts prefijos y otra información para SLAAC. Aparece la opción Información de prefijo en mensajes de anuncio de enrutador. RA.

Tipo 4: encabezado de redireccionamiento: esta opción se utiliza en mensajes de redireccionamiento para contener todos o parte del paquete que se está redirigiendo.

Tipo 5: MTU: la opción MTU se utiliza en los mensajes de anuncio del enrutador para ayudar
Asegúrese de que todos los dispositivos en un enlace utilicen la misma MTU


13.1. Direcciones usadas en ND

ND utiliza las siguientes direcciones:
  • Multicast a todos los nodos: es una dirección del tipo link-local para alcanzar a todos los nodos, y es FF02 :: 1.
  • Multicast a todos los routers: es una dirección del tipo link-local para alcanzar a todos los enrutadores, y es FF02 :: 2.
  • Link-Local: Es una dirección unicast que sirve para alcanzar a los vecinos, siendo de la forma FE80 :: / 10. Cada interfaz de un enrutador debe tener direcciones de este tipo.
  • Direcciones de Multicast de capa 2 33:33:
  • Direcciones de Unicast Global.

Estas direcciones son usadas en 4 tipos de mensajes.

Mensaje     Origen -> Destino
Mensaje de Solicitud (RA) De Router a Dispositivos
Mensaje de solicitud de Router (RS) De Dispositivos a Routers
Mensaje de solicitud de vecino (NS) De Dispositivo a Dispositivos
Mensaje de anuncio de vecino (NA) De Dispositivo a Dispositivos

13.2. Mensajes RS y RA de ND


Mensaje RS


Los mesajes RS son utilizado por un equipo que  no router:
  1. Descubrir quien es el Gateway de la red.
  2. Autoconfigurarse IPv6: en caso de que el dispositivo final no cuente con una IPv6 asignada también utilizara el RS para autoconfigurarse basada en la respuesta del RS donde obtiene el prefijo de red local por parte del Gateway.
Un equipo WinPC envía un mensaje RS (ver parámetros del ICMP6 , Nro. 133) cuando necesita obtener información de Direccionamiento. Esto sucede al iniciar el equipo en la mayoría de los SO.
En el RS, se solicita un RA (una respuesta por parte del Router), por lo que si hay un router habilitado y configurado responderá con un mensaje RA en respuesta a un mensaje RS. 
En la imagen, PC1 envía un mensaje RS para determinar cómo recibir dinámicamente su información de dirección IPv6.


La PC envía un mensaje RS, esperando como respuesta un mensaje de RA.
La direcciones de este mensaje son:
origen de este mensaje es la de Unicast del tipo Link Local Address (LLA)  fe80::d0f8:9ff6:4201:7086
destino la FF02::2 (Multicast de Nodo solicitado de todos los Routers.)

Si capturamos con Wireshark este mensaje RS, veríamos que incluye la MAC de origen, y va dirigido a una dirección de multicast, en la que todos los routers forman parte, este mensaje sería del Tipo 1 (visto en el capítulo anterior). La dirección 33:33 es la dirección de multidifusión Ethernet para IPv6. Los 32 bits inferiores, 00:00:00:02, se asignan desde la dirección de multidifusión IPv6 de destino, ff02::2.



El router R1 responde con un mensaje RA del tipo 1 (ver parámetros del ICMP6 , Nro. 134) , en nuestro ejemplo:

RS Resumen
WinPC -> Router
Capa 3 IP Origen: fe80::d0f8:9ff6:4201:7086 (Unicast Link Local)
Capa 3 IP Destino:  FF02::2 (Multicast, todos los routers)
Capa 2 Origen: 00:50:56:af:97:68
Capa 2  Destino: 33:33:0:0:0:2



Mensaje RA:

Los mensajes RA son enviados por routers habilitados para IPv6 cada 200 segundos para proporcionar información de direccionamiento a los hosts habilitados para IPv6 o como respuesta a un mensaje RS.

Antes de enviar mensajes RA, se debe configurar un enrutador como enrutador IPv6, utilizando la configuración de enrutamiento de unidifusión ipv6.

Esto también permite que el router habilite protocolos de enrutamiento IPv6 dinámicos y reenvíe paquetes IPv6.

En nuestro ejemplo, el RA (ver parámetros del ICMP6 , Nro. 134), sería una respuesta al RS enviado desde R1 a WinPC.

El mensaje de RS sería del tipo 133 y el de RA sería 134, y si lo capturamos con Wireshark se vería:


 


La IP dirección de destino (recordar que el equipo NO tiene IP) es la dirección de multicast del router donde está el router : 33:33:00:00:00:01.

Se incluye le dirección MAC del Router:  58:ac:78:93:da:00, necesaria en el futuro para los paquetes de capa 2 que tengan destino fuera de la red.

La dirección IPV6 de origen (la del router) es la fe80:1, dirección de LLA (Local Link Address).

La dirección IPV6 de destino es la dirección multicast FF02:1, o la dirección de RS que envió el dispositivo multicast de todos los dispositivos.

Se puede ver que el RA, notifica el equipo que puede usar el prefijo 2001:db8:cafe:1:: al host sobre el prefijo que se puede usar para configuración automática de direcciones sin estado.

RA Resumen
Router -> WinPC
Capa 3 IP Origen: fe80::1 (Unicast Link Local)
Capa 3 IP Destino:  FF02::1 (Multicast, todos los nodos)
Capa 2 Origen: 58:ac:78:93:da:00
Capa 2  Destino: 33:33:0:0:0:1


13.3. Mensajes NS y NA de ND

Mensaje NS



Este Mecanismo Neighbor Discovery o simplemente ND es usado entre un Equipo y otro Equipo (PCs. o Routers) para gestionar la comunicación con IPv6.

a) Resolución de direcciones:

La resolución de direcciones en IPv6 es similar a la ARP en IPv4. Un dispositivo envía un mensaje de solicitud de vecino cuando conoce la dirección IPv6 de destino pero necesita solicitar su dirección de capa 2 (normalmente una dirección Ethernet). Esto es similar a una solicitud de ARP en IPv4. En respuesta al mensaje de solicitud de vecino, el dispositivo de destino envía un mensaje de anuncio de vecino, similar a una respuesta de ARP.
La resolución de direcciones incluye la detección de direcciones duplicadas (DAD), que verifica la exclusividad de una dirección en el enlace. DAD es muy similar a un ARP gratuito. El dispositivo envía un mensaje de solicitud de vecino para su propia dirección IPv6 para detectar si otro dispositivo en el enlace está usando la misma dirección. Si no se recibe un mensaje de anuncio de vecino, el dispositivo sabe que su dirección es única en el enlace.

b) Caché de vecinos y detección de no alcanzabilidad de vecinos (NUD)

Los dispositivos IPv6 utilizan mensajes NS y sus mensajes NA asociados para crear un caché de vecinos. El caché de vecinos contiene una asignación de direcciones MAC de IPv6 a Ethernet, similar a un caché ARP de IPv4.

Veamos como funcionan. En nuestro ejemplo como el propósito es comunicar dos equipos, vamos a tomar en particular, Router y PC, no cambia nada, son dos equipos que en este caso se quieren comunicar (NO se habla de configurar IPv6, eso lo vimos en el capítulo anterior). 

Este tema no se verá, si desea mas información puede remitirse a: "IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6". . Second Edition. Autor Rick Graziani.


Resolución de direcciones:


R1 se quiere comunicar con WinPC, mira su "TABLA DE VECINOS" (IPv6/MAC), antes conocida como tabla ARP. Pero no tiene MAC para ese vecino.

Paso 1) Mensaje NS

R1 envía un mensaje de solicitud de vecino a través de su interfaz G0/0. La dirección IPv6 de destino es una dirección de multidifusión de nodo solicitado derivada de la dirección de destino en el mensaje ICMPv6. La dirección de destino en el mensaje NS es la dirección IPv6 de destino en el paquete, 2001:db8:cafe:1:d0f8:9ff6:4201:7086.
La dirección de multidifusión de nodo solicitado es ff02::1:ff01:7086, que utiliza los 24 bits de orden inferior de la dirección de destino. 
La dirección IPv6 de nodo solicitado se asigna a la dirección MAC de destino Ethernet. 33:33 se antepone a los 32 bits de orden inferior de la dirección de multidifusión de nodo solicitado, lo que da como resultado una dirección de multidifusión Ethernet de 33:33:ff:01:70:86. (Esta asignación se analiza con más detalle más adelante en este capítulo, y verá la ventaja de utilizar una dirección de multidifusión Ethernet en comparación con una dirección de difusión en una solicitud ARP
IPv4).


NS Resumen
Router -> WinPC 
Capa 3 IP Origen: 2001:db8:cafe:1::1 (Unicast Global)
Capa 3 IP Destino:  FF02::1ff01:7086 (Multicast, todos los nodos derivada de la IPv6 destino)
Capa 2 Origen: 58:ac:78:93:da:00
Capa 2  Destino: 33:33:ff:01:ff01:70:86 (Multicast todos los nodos derivada de la IPv6 destino)

Paso 2) WinPC procesa lo que recibe

WinPC recibe el mensaje de solicitud de vecino y determina que es el destino previsto del mensaje. Agrega la dirección IPv6 de origen 2001:db8:cafe:1::1 del encabezado IPv6 y la dirección de capa de enlace 58:ac:78:93:da:00 del mensaje NS a su propia caché de vecino. Luego, usará esta información en su mensaje de anuncio de vecino a R1.



Paso 3) Mensaje NA


WinPC responde con un mensaje de anuncio de vecino NA. El mensaje NA incluye la dirección IPv6 de WinPC, la dirección IPv6 de destino 2001:db8:cafe:1:d0f8:9ff6:4201:7086 y la dirección MAC Ethernet 00:50:56:af:97:68. El anuncio de vecino se envía como unidifusión a R1.



NA Resumen
WinPC   -> Router
Capa 3 IP Origen: 2001:db8:cafe:1:d0f8:9ff6:4201:7086 (Unicast Global)
Capa 3 IP Destino:  2001:db8:cafe:1::1 (Unicast Global)
Capa 2 Origen: 00:50:56:af:97:68
Capa 2  Destino: 58:ac:78:93:da:00

Paso 4) Router procesa lo que recibe.

R1 recibe el mensaje NA de anuncio de vecino de WinPC. R1 ahora puede agregar la dirección MAC de WinPC, 00:50:56:af:97:68, y su dirección IPv6 asociada, 2001:db8:cafe:1:d0f8:9ff6:4201:7086, a su caché de vecinos.
00:50:56:af:97:68 se incluye como la dirección MAC de destino en el encabezado Ethernet, y R1 puede reenviar la trama a WinPC.



Como se puede observar, los pasos para lograr la comunicación entre dos equipos son sencillos, utilizan direcciones que ya hemos mencionado, pero no tiene sentido profundizar en estos temas, ya que son propios de gente que se especialice en comunicaciones y configuraciones de IPv6, en nuestro caso excede la profundidad de nuestra materia.

13.4. Cache de los Hosts

Los host tienen 2 tipos de cache.

Cache de Vecinos (Neighbor Cache) : 

La caché vecina equivale a una caché ARP o una tabla ARP en IPv4. El Neighbor Cache mantiene una lista de entradas sobre los vecinos a los que se ha dirigido tráfico recientemente enviado. El caché también indica si el el vecino es un enrutador o un host, el estado de accesibilidad de la dirección, si hay alguna en cola.

Comandos en Linux:

ip -6 neighbor show

Cache de Destino (Destination Cache): 

Mantiene una lista de los destinos a los que se ha enviado tráfico recientemente, incluidos aquellos en otros enlaces o redes. En esos casos, la entrada es la Capa 2 dirección del enrutador del siguiente salto.

Un host IPv6 mantiene una lista de enrutadores predeterminada desde la cual selecciona un enrutador para el tráfico a destinos fuera del enlace. El enrutador seleccionado para un destino luego se almacena en caché en la caché de destino.

14. Direcciones Dinámicas

Notar que la obtención de direcciones IP de capa 3, y la relación de direcciones de capa 3  con capa 2 (MAC), están relacionadas, es por eso que este tema obtención de "Direcciones Dinámicas" y "Neighbor Discovery ND", el siguiente tema, están íntimamente relacionados.

Direcciones Dinámicas

En esta sección veremos las formas en las que un dispositivo con IPv6 puede obtener de manera dinámica la dirección global unicast.

Ellas son:

  • Método 1: Stateless Address Autoconfiguration (SLAAC).
  • Método 2: SLAAC and a stateless DHCPv6 server.
  • Método 3: Stateful DHCPv6 server.

¿Cuándo se usa uno u otro?

SLAAC es a menudo suficiente para redes domésticas o pequeñas oficinas donde la configuración básica de red es todo lo que se necesita. Es simple y no requiere un servidor adicional.
DHCPv6 es preferido en entornos empresariales o redes más grandes donde se necesita un control más granular sobre la configuración de red y la gestión del espacio de direcciones IP.
Recordemos que un host necesita de:
  1. Prefijo de Red.
  2. Longitud del Prefijo de red.
  3. Dirección del Gateway.
  4. Direcciones de Servidores DNS.
  5. MAC de Gateway.
para poder utilizar internet, estos elementos son los que deberían proveer los métodos de asignación de direcciones dinámicas.

A modo de anticipo, en estas autoconfiguraciones se intercambiar los siguientes mensajes:

Mensaje     Origen -> Destino
Mensaje de Solicitud (RA) De Router a Dispositivos
Mensaje de solicitud de Router (RS) De Dispositivos Routers

14.1. SLAAC

Servicio sin estado - Stateless Address Autoconfiguration (SLAAC)


Este tipo de configuración es el que usamos en la práctica de Laboratorio IPv6.

Con esta modalidad de asignación o de adquisición dinámica de dirección IPv6, el dispositivo usa la información que recibe en un mensaje RA (Router Advertisement) que incluye el prefijo de red y puede crear su propia dirección global de unicast.

SLAAC utiliza mensajes ICMPv6 conocidos como RA (Router Advertisement) para proporcionar direccionamiento y otra información de configuración que normalmente proporcionaría un servidor DHCP.

El mensaje RA (Router Advertisement), lo envía de manera periódica, típicamente cada 200 segundos, el equipo solo debería esperar este mensaje para obtener la parte de la dirección global que desconoce, se ve la imagen el procedimiento:

Lógicamente el Router R1 DEBE ser configurado como Router IPv6 para que envíe estos mensajes de RA. Para ello se debe habilitar el Advertisment en la interfase que corresponda del MK.

x.x. Interface de red

La opción “advertise” en el contexto de los Router Advertisements en IPv6 no reemplaza completamente a un servidor DHCP, pero puede funcionar de manera similar bajo ciertas circunstancias gracias a SLAAC.

Paso 1

Se puede ver en la figura que el mensaje de RA tiene como dirección de origen unicast LLA Link Local Address : FE80::1/10 y como dirección de destino una multicast Link Local All Nodes :FF02::1.

La dirección de enlace local se configuró manualmente en R1, y es la dirección que los dispositivos receptores pueden usar para su configuración predeterminada de Gateway.

Se puede ver que se incluye el prefijo de dirección global y la longitud del prefijo en el mensaje de RA.

El mensaje de RA puede de manera opcional incluir el servidor de DNS.

Nota Informativa: Existen Flags
  1. A (de Address): Indicador de configuración automática de dirección, cuando se establece en 1 (activado), este indicador le indica al host receptor utiliza SLAAC para crear su dirección de unidifusión global.
  2. O (de Other): Cuando se establece en 1 (activado), este indicador le indica al host que obtenga otra información de dirección, distinta de su dirección de unidifusión global, de un sistema sin estado Servidor DHCPv6.
  3. M (de Managed): Cuando se establece en 1 (activado), este indicador le indica el host utilice un servidor DHCPv6 con estado para su dirección de unidifusión global y todos los demás abordar la información.

RA Resumen
Router -> WinPC
Capa 3 IP Origen: fe80::1 (Unicast Link Local)
Capa 3 IP Destino:  FF02::1 (Multicast, todos los nodos)
Capa 2 Origen: 58:ac:78:93:da:00
Capa 2  Destino: 33:33:0:0:0:1

En campo datos: Prefijo de red: 2001:db8:cafe:1::, Longitud de prefijo: /64, Flag A=1, DNSs.


Paso 2: WinPC procesa lo recibido.

El equipo recibe el RA desde FE80::1 y lo toma como Default Gateway, el flag A le indica al equipo que puede usar la información para crear su global unicast address GUA, también obtiene la MAC del Gateway.

Paso 3:

Este método SLAAC, WinPC a partir de los datos recibidos genera dos direcciones de unicast, una  global pública y otra global temporal.

La parte de IPv6 que corresponde a la interfase de red se genera de manera automática usando EUI-64 o de manera aleatoria dependiendo de la configuración del  Sistema Operativo.


14.2. DHCPv6 sin estado + SLAAC (Informativo)

Esta forma de asignación dinámica de IPv6 se trata en RFC 3736

Se pueden ver en detalle en :https://cloud.fio.unam.edu.ar/index.php/apps/files/?dir=/ComunicacionesDigitales/Libros&openfile=3280098

Este proceso se conoce como DHCPv6 stateless/sin estado, debido a que el servidor no mantiene información o registro del estado del cliente (es decir, una lista de direcciones IPv6 asignadas y disponibles). El servidor de DHCPv6 stateless solo proporciona parámetros de configuración para los clientes, no direcciones IPv6, proporciona por ejemplo dirección IPv6 del Servidor DNS.

Nota:

Si bien DHCPv6 es similar a DHCPv4 en cuanto a lo que proporciona, los dos protocolos son independientes respecto sí.

Paso 1:

El equipo envía un RS (Router Solicitation) si no recibe un RA antes.

Paso 2:

El mensaje RA con el flag A=1, sugiere que el host use SLAAC. El flag O=1 sugiere que también se puede disponer de la configuración usando DHCPv6 sin estado. El flag M=0, es su estado de default, indicando que el servicio DHCPv6 con estado NO es necesario.


Paso 3:

Forma su dirección según SLAAC y determina su GW. Por defecto se generan dos direcciones una pública y otra temporal (random).


Paso 4:

El equipo realiza la verificación de dirección duplicada DAD sobre la dirección de Unicast (GUA o LLA), si no recibe respuesta, asume que es única.

Paso 5:

El flag O=1 indica que se puede conseguir información adicional en un DHCPv6 sin estado, entonces envía un mensaje de Multicast de nodo solicitado FF02::1:2.

Paso 6:

Algún servidor de  DHCPv6 responde al mensaje del punto 5, indicando que el tiene un servicio disponible.

Paso 7:

El equipo responde consultando por la información de configuración que le falta.

Paso 8:

El DHCPv6, responde con la información de configuración que falta.








14.3. DHCPv6 con estado.

Esta opción es la más similar al DHCP que estudiamos en redes IPv4. 

En este caso, el mensaje RA informa al cliente que no debe usar la información de su mensaje y toda la información de direccionamiento IPv6 y los parámetros de configuración adicionales deben obtenerse de un servidor DHCPv6 con estado. 

Se define con este nombre porque el servidor DHCPv6 mantiene la información de estado de IPv6 (Lista de direcciones IPv6 asignadas, por ejemplo).


Paso 1:

El equipo envía un RS (Router Solicitation)solicitando un RA.

Paso 2:

El router responde con RA y  M=1. Sugiriendo que hay un servidor de DHCPv6 con estado. El flag A=0 indicando que no existe SLAAC.

Paso 3:

Luego que el equipo recibe el RA con M=1 que le indica que hay un DHCPv6 Server con estado, el equipo envía una solicitud, usando como dirección de destino FE80::1 Default Gateway, ya que A=0.

Paso 4:

Como el mensaje RA con M=1, envía una solicitud al servicio de  DHCP.

Paso 5:

Algún servidor de DHCP responde indicando que está disponible.

Paso 6:

El equipo solicita la dirección y otras informaciones para su configuración.

Paso 7:

El servidor de DHCP responde con un mensaje que contiene la dirección de unicast global y las otras informaciones de configuración.

Paso 8:

El equipo lanza el proceso de DAD (detección de dirección duplicada).












14.4. Duplicate Address Detection (DAD)

Un dispositivo puede utilizar la detección de direcciones duplicadas (DAD) ICMPv6 para determinar si una dirección que desea asignar a una interfaz ya está en uso por otro dispositivo. 

Con algunas excepciones, RFC 4861 recomienda que DAD se realice en cada dirección de unidifusión, enlace local o global, antes de asignarlo a una interfaz, independientemente de si fue asignado mediante SLAAC, DHCPv6 o configuración manual. 

Hay algunas excepciones a este comportamiento, como se analiza en RFC 4429, "Detección optimista de direcciones duplicadas (DAD) para IPv6". 

Este proceso se realiza en 4 Pasos, no vamos a entrar en detalle en esta materia.

Para mas detalles ver página 402 del libro: "IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6". . Second Edition. Autor Rick Graziani.


15. ICMPv6

El protocolo ICMPv6 es utilizado por los nodos IPv6 para detectar errores encontrados en la interpretación de paquetes y para realizar otras funciones de la capa de internet como el diagnóstico (ICMPv6 ping).

Ver tabla de tipos de ICMPv6

El protocolo ICMPv6 incorpora la función de descubrimiento de vecinos, que en IPv4 realiza el protocolo ARP. Dentro de esta funcionalidad se incorpora el descubrimiento de enrutadores que incluso permite la configuración automática de las direcciones globales.

A través de esta funcionalidad de descubrimiento de vecinos y de enrutadores, un equipo conectado a la red con una dirección de enlace local puede descubrir el enrutador que está en su misma red y obtener el prefijo global asignado a la red.

Los paquetes ICMPv6 tienen el formato Tipo, Código y Checksum.



Los 8 bits del campo Tipo indican el tipo de mensaje. Si el bit de mayor peso tiene el valor 0 (valores entre 0 y 127) entonces es un mensaje de error, por el contrario si el bit de mayor peso es 1 (valores entre 128 y 255) entonces es un mensaje informativo.

Los 8 bits del campo Código dependen del tipo de mensaje, y son usados para crear un nivel adicional de clasificación de mensajes, de tal forma que los mensajes informativos en función del campo Código se pueden subdividir en varios tipos. 

A modo de ejemplo si Type=1 => Destino Inalcansable en campo de Code podría tener:



El campo Checksum es usado para detectar errores en los mensajes ICMP y en algunos de los mensajes IPv6.

Mensajes de Error

Los mensajes de error de ICMPv6 son similares a los mensajes de error de ICMPv4. Se dividen en 4 categorías: destino inaccesible, paquete demasiado grande, tiempo excedido y problemas de parámetros.

            1    Destination Unreachable (Destino Inalcanzable).      
            2    Packet Too Big (Paquete Demasiado Grande).
            3    Time Exceeded (Tiempo Agotado).
            4    Parameter Problem (Problema de Parámetros).

Mensajes Informativos

El segundo tipo de mensajes ICMP son los mensajes informativos. Estos mensajes se subdividen en tres grupos: mensajes de diagnóstico, mensajes para la administración de grupos multicast y mensajes de Neighbor Discovery.

            128  Echo Request (Solicitud de Eco)                 
            129  Echo Reply (Respuesta de Eco)

Cada mensaje ICMPv6 está precedido por una cabecera IPv6 y cero o más extensiones de cabecera IPv6. La cabecera ICMPv6 es identificada por un valor 58 en "Cabecera Siguiente" en la cabecera inmediatamente predecesora. (Nota: el valor del campo "Cabecera Siguiente" es distinto del valor utilizado para identificar ICMP para IPv4).


Determinación de la Dirección de un Paquete

Cuando un nodo envía un mensaje ICMPv6 debe especificar la direcciones IPv6 origen y destino en la cabecera de la dirección IPv6 antes de calcular el checksum. Si el nodo tiene más de una dirección unicast, éste debe elegir la dirección origen como sigue:

(a) Si el mensaje es una respuesta a un mensaje enviado a una de las direcciones unicast del nodo, la dirección origen de la respuesta debe esa misma dirección.

(b) Si el mensaje es una respuesta a un mensaje enviado a cualquier otra dirección, tal como:

  •   una dirección de un grupo multicast,
  •   una dirección anycast implementada por el nodo, o
  •   una dirección unicast que no pertenece al nodo.

La dirección origen del paquete ICMPv6 debe ser una dirección unicast perteneciente al nodo. La dirección debería ser elegida de acuerdo con las reglas que serán utilizadas para seleccionar la dirección origen de cualquier paquete originado por el nodo, dada la dirección de destino del paquete. Sin embargo, debería ser seleccionada en una forma alternativa si va a derivar en una opción más informativa de la dirección accesible desde el destino del paquete ICMPv6.

Como veremos mas adelante, los mensajes de ICMPv6 permiten implementar un mecanismo llamado Neighbor Discovery que reemplaza al ARP de IPv4.

ICMP Accesibilidad al Host
El protocolo ICMP es utilizado en una herramienta de diagnóstico (aplicación) que se llama "ping".
Permite diagnosticar el estado, velocidad y calidad de una red determinada y utiliza el envío de paquetes ICMP de solicitud (ICMP Echo Request) y de respuesta (ICMP Echo Reply).
Muchas veces se utiliza para medir la latencia o tiempo que tardan en comunicarse dos puntos remotos, y por ello, se utiliza el término PING para referirse al retardo o latencia (en inglés, lag) de la conexión en los juegos en red, esto daría una idea de congestión por ejemplo.
Veamos unos ejemplos de ping a www.google.com:

The response for 'www.google.com' using IPv6 is:PING www.google.com(nuq04s43-in-x04.1e100.net) 56 data bytes
64 bytes from nuq04s43-in-x04.1e100.net: icmp_seq=1 ttl=120 time=1.40 ms
64 bytes from nuq04s43-in-x04.1e100.net: icmp_seq=2 ttl=120 time=1.58 ms
64 bytes from nuq04s43-in-x04.1e100.net: icmp_seq=3 ttl=120 time=1.46 ms
64 bytes from nuq04s43-in-x04.1e100.net: icmp_seq=4 ttl=120 time=1.54 ms
64 bytes from nuq04s43-in-x04.1e100.net: icmp_seq=5 ttl=120 time=1.82 ms

--- www.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.404/1.564/1.823/0.145 ms
En este caso la utilidad ping hizo solo "5 pings" y podemos ver que al finalizar muestra un detalle que es el que permite obtener información o inferir el estado de la red contra www.google.com.
Podemos ver que el ping se hace a un Nombre (www.google.com) así que es de esperar que se realice una resolución de nombres previo al ping.


15.1. MTU Discovery Packet Too Big.

Como sabemos IPv6 no fragmenta en el camino, es por eso que debe conocer el MTU máximo a lo largo del camino para que no tenga que fragmentar, bueno, ICMPv6 hace este trabajo.

Patch MTU Discovery es definido en RFC 1981 llamado Path MTU Discovery for IP version 6.

El MTU Discovery se realiza en 4 pasos.


Paso 1: 

El equipo de origen asume que el MTU es igual al MTU del primer router de la red o el de la interface de red, en este caso es una Ethernet por lo que se toma como 1500.

Paso 2:

En este caso el paquete de R1-> R2 tiene un MTU menor (1350 <1500) entonces el paquete es descartado por R2, y genera un mensaje de ICMPv6 Packet Too Big e indica que el MTU es de 1350. Esto llega a R1 y luego al Origen, que se da por enterado que ese MTU de 1500 no es el que debe usar.

Paso 3:

El origen se da por enterado y reduce el tamaño del paquete, para que pueda coincidir con MTU de 1350, y lo vuelve a transmitir como dos paquetes con el código 44 en el campo extension header que indica que es una fragmento de un mensaje mas grande.

Nota: Recordar que MTU mínimo de 1280 octetos en IPv6, no hablamos del tamaño mínimo del campo de datos del datagrama. Este valor está fijado por la norma y tiene que ver con el mínimo valor para ser eficiente, recordar que enlaces punto a punto (no Ethernet) pueden tener valores distintos de 1500.

Paso 4:

Si hubiera mas routers en el camino, el proceso continuaría hasta llegar a encontrar el mínimo MTU desde origen a destino, siempre siendo mayor que 1280.

16. Migración IPv4 a IPv6

Los mecanismos de Migración IPv4 a IPv6 se ven en la materia a modo INFORMATIVO, no se realizan prácticas de implementaciones de los mismos, mas allá de algo básico en el Laboratorio de IPv6.

Es razonable pensar que IPv4 e IPv6 coexistirán por muchos años. Por eso se han previsto técnicas para permitir a los dos protocolos de convivir y a las empresas y organizaciones de actualizar sus equipos e infraestructuras poco a la vez. Hay tres principales categorías:


1) Técnicas de doble pila (Dual Stack) que permiten a IPv4 e IPv6 coexistir en el mismo equipo o red.

2) Técnicas de tunneling para enrutar tráfico IPv6 dentro de paquetes IPv4.

3) Técnicas de traducción (NAT), para permitir a nodos IPv6 poderse comunicar con nodos IPv4.

Dentro de estas se pueden encontrar implementaciones como las siguientes:

Hay diferentes mecanismos, que podéis buscar y de los que podéis encontrar información:

  •  
    • Stateless IP/ICMP Translation (SIIT)
    •     Tunnel Broker (6in4)
    •     6to4
    •     6over4
    •     6rd (IPv6 rapid development)
    •     ISATAP
    •     NAT64
    •     464XLAT
    •     Dual-Stack Lite (DS-Lite)
    •     Teredo

Les dejo un link a un

sobre el tema.

16.1. Técnicas de Doble pila (DUAL STACK)

La técnica de Dual Stack consiste en que un nodo tiene soporte completo para las dos implementaciones de IP. Cuando se trata de comunicar con nodos IPv4, el nodo se comporta como si fuese un nodo IPv4, mientras que con los nodos IPv6 se comporta como un nodo IPv6.

 Esto permite una transición progresiva uno a uno manteniendo la operación de la red y permitiendo administrar las transiciones.

Los inconvenientes de esta técnica son que los nodos necesitan una completa actualización de software de red => 


La presencia de las dos pilas se traduce en un aumento de la carga para el procesador y una mayor ocupación de memoria: de hecho los routers y los hosts deben tener dos copias de las tablas de enrutamiento y de otros recursos asociados a los protocolos.


Las aplicaciones deberán ser capaces de reconocer si el host está comunicando con otro host IPv6 o IPv4. A menudo habrá dos versiones de la misma aplicación, una por cada protocolo (p.ej. ping y ping6 bajo Windows). La ventaja es que cuando ya no sea necesario el IPv4, se podrá quitar o remover el modulo correspondiente del sistema operativo.

En una PC con Windows esto se vería:
https://www.profesionalreview.com/wp-content/uploads/2017/12/Propiedades-Ethernet.jpg
En una PC con Linux:

Como podemos ver, en general los equipos nuevos ya están implementando dual stack. El cambio que resta serían en los ISPs intermedios, donde no es tan fácil ni económico incorporar dual stack a routers.

Hay disponible una API (Application Programming Interface) que soporta requerimientos DNS para IPv4 e IPv6 y permite responder a diferentes situaciones:

Una aplicación que no soporta IPv6 o está forzada a utilizar IPv4, hace una solicitud DNS de un registro tipo A para IPv4. 
En consecuencia la aplicación enviará su solicitud de servicio utilizando IPv4. Una aplicación que soporta solamente IPv6 o prefiere utilizar IPv6 operará sobre IPv6.

La aplicación envía una solicitud exclusivamente de un registro AAAA (un registro AAAA determina qué dirección IPv6 se asigna a su dominio. De esta forma, el nombre del dominio será redirigido a la dirección IPv6 específica.) con lo que obtendrá una dirección IPv6. En consecuencia la aplicación establecerá la conexión con el servidor utilizando IPv6.
Una aplicación que puede operar indistintamente con IPv4 o IPv6, para cada nombre que debe resolver envía una solitud DNS de cada tipo (IPv4 e IPv6). El servidor DNS responde enviando todas las direcciones IP disponibles (v4 y/o v6) que están asociadas a ese nombre.

Ya con la información de ambos protocolos, es la aplicación la que elije utilizar una u otra. El comportamiento típico por defecto es utilizar IPv6.

Cisco IOS soporta la operación en modo dual-stack tan pronto como ambos protocolos están configurados en una interfaz. A partir de ese punto puede reenviar ambos tipos de tráfico, desde la consulta sería:

ipv6 unicast-routing !
interface GigabitEthernet0/0
ip address 192.168.0.1 255.255.255.0 ipv6 address 2001:abc:1::/64 eui-64

Eso puede realizarse tanto cuando se asignan direcciones IPv6 estáticas o por un proceso de configuración automática.

Implementación dual-stack

1. Revise la red, las aplicaciones y las políticas de seguridad para asegurarse que la implementación de IPv6 sea tan inclusiva como sea posible.

2. Actualice nodos, routers y servicios de infraestructura para soportar IPv6. Se debe prestar especial atención en servicios de infraestructura tales como DNS, HTTP, SNMP y servicios de autenticación.

3. Habilite el soporte IPv6.

4. Actualice todos los servicios siempre que sea posible, para proveer funcionalidades sobre IPv6. Hay que estar atentos a que algunos servicios pueden requerir alguna atención adicional en función de que IPv6 será el protocolo de transporte preferido. 

5. Asegúrese que la operación dual-stack está funcionando correctamente y que todos los servicios funcionan correctamente. Hay que verificar particularmente la implementación de las políticas de seguridad.

Consideraciones a tener en cuenta

1) La implementación de dual-stack no puede ser por tiempo indefinido ya que puede afectar la performance (algunos dispositivos reenvían más rápido el tráfico IPv4 que el IPv6), la seguridad y generar mayores costos dada la mayor complejidad de gestión.

2) Hay  que tener presente que dispositivos terminales viejos pueden interpretar erróneamente respuestas DNS que contengan registros A y AAAA y actuar de modo errático.
Mantener políticas de seguridad semejantes sobre IPv4 e IPv6 puede ser complejo, pero son necesarias.

3) A medida que avance la implementación global de IPv6 se hará más complejo y costoso el mantenimiento de sistemas IPv4 en estado operativo.

Mecanismos de tunelizado

Durante la implementación de IPv6 un escenario posible es que parte de la red no soporte IPv6, o que se desee realizar una implementación gradual por sectores de la red. En cualquiera de estos casos la solución más simple es encapsular el tráfico IPv6 y enviarlo a través de la red IPv4. Son los denominados mecanismos de tunelizado.

En este caso, los túneles son utilizados para crear redes virtuales IPv6 sobre redes físicas IPv4 ya existentes. En este caso, un encabezado IPv6 es encapsulado dentro de un paquete IPv4:

Opción 1: Un dispositivo dual-stack con una interfaz conectada a la red IPv6 y otra interfaz conectada a la red IPv4, recibe un paquete IPv6. Encapsula el paquete IPv6 en un paquete IPv4 y lo envía a través de la red IPv4. La red IPv4 reenvía el tráfico sobre la base del encabezado IPv4, únicamente, hasta el dispositivo que terminal el túnel. El túnel termina en otro dispositivo dual-stack conectado a la red IPv4 por una interfaz y a la red IPv6 por la otra. Recibe el paquete IPv4, retira el encabezado, lee en encabezado IPv6 y lo reenvía sobre la red IPv6. Este procedimiento permite conectar 2 “islas” o redes IPv6 a través de un backbone o red IPv4.

Consideraciones a tener en cuenta
El MTU efectivo es reducido en al menos 20 bytes cuando el encabezado IPv4 no contiene datos adicionales ya que hoy que considerar un segundo encabezado de capa de red.

Una red tunelizada es difícil de diagnosticar, por lo que debe ser considerada una solución de transición y no una arquitectura final.

Los túneles pueden establecerse:
  1. Entre 2 routers.
  2. Entre un host y un router.
  3. Entre 2 hosts.

Técnicas de tunelizado disponibles para implementaciones IPv6.

Los túneles IPv6 sobre IPv4 descriptos antes pueden ser logrados a través de 2 metodologías diferentes: configuración manual o automática.

Túneles de configuración manual:


  • Red IPv6 Red IPv6
  • Red IPv4
  • IPv4 IPv6 Dispositivos dual-stack

Este modo de implementación requiere que el túnel inicie y termine en dispositivos dual-stack que tienen conectividad IPv4 entre sí. Es necesario utilizar una interfaz túnel con una dirección IPv6 link-local asociada a la interfaz IPv4 de cada extremo del túnel.

Está disponible en la mayoría de las plataformas, aunque es un recurso limitado ya que no escala bien.

IPv6-in-IPv4.

Permite establecer conexión entre 2 puntos (site-to-site).
Requiere de la configuración de las direcciones de origen y destino del túnel. Impone muy poco overhead.

GRE (Generic Routing Encapsulation).
Utiliza el protocolo de tunelizado IPv4 estándar. Permite establecer túneles punto a punto.
Es necesario solamente para soportar redes que utilizan enrutamiento IS-IS (IS-IS (del inglés Intermediate System to intermediate System) es un protocolo de estado de enlace, o SPF (shortest path first)).  VPN (Virtual Private Network).

Túneles de configuración automática:

En estos casos el túnel se configura automáticamente sin necesidad de que al momento de configurar un extremo del túnel se conozca el otro extremo del mismo.

Esta metodología escala mejor que la configuración estática ya que no es necesario configurar explícitamente cada punto terminal de los túneles. Como contrapartida, estos túneles dependen de servidores provistos por terceras partes en Internet y no soportan bien el tráfico de multicast.

6to4.
Permite conectar “islas” IPv6 a través de una red IPv4.
En este tipo de túneles no se pueden utilizar direcciones IPv6 unicast globales. El túnel utiliza direcciones con prefijo 2002::/16.

6rd (6 rapid deployment).
Mecanismo de tunelizado para transición a IPv6 utilizado en redes de service providers para transporte de tráfico IPv6.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol).
Túneles para intranets corporativas en las que la infraestructura aún no soporta IPv6, mientras que los terminales requieren conectividad IPv6.

Teredo.
Permite establecer túneles desde terminales que soportan IPv6 pero están conectadas a redes IPv4, contra servidores Teredo.
Encapsula el tráfico IPv6 en un paquete IPv4 UDP, por lo que tiene objeciones desde la perspectiva de seguridad.

Traducción de direcciones IPv6 a IPv4
Es posible comunicar nodos conectados a redes IPv6 con nodos conectados a redes IPv4 implementando un proceso de traducción mejor conocido como AFT (Address Family Translation).

Esta es considerada una estrategia de corto plazo que permite la coexistencia de ambas redes para facilitar una transición hacia la red IPv6. Aplicaciones que utilizan protocolos que incluyen información IP en la porción de datos (como FTP o SIP) requieren la implementación de gateways de capa de aplicación para soportar la traducción. Hay 2 tecnologías disponibles para realizar estas traducciones:

  • NAT-PT
  • Network Address Translation – Protocol Translation  NAT64
  • Network Address Translation IPv6 to IPv4

El uso de NAT-PT no es recomendado por la IETF merced a su débil interacción con DNS y sus limitaciones para la traducción. Estos problemas están documentados en el RFC 4966. La sugerencia es trabajar con NAT 64.

La traducción de IPv6 a IPv4 o viceversa, supone la conversión de 3 elementos en cada paquete:

  • El encabezado IPv6 debe ser reemplazado por un encabezado IPv4.
  • La dirección IPv6 de origen debe ser traducida a una dirección IPv4 de origen. 
  • La dirección IPv6 de destino debe ser traducida a una dirección IPv4 de destino. Cuando la sesión se inicia desde un host IPv6, el destino será un nodo IPv4, paran representar la dirección de destino IPv4 en formato IPv6 se genera un ID compuesto por el prefijo 64:FF9B::/96 y los 32 bits de la dirección IPv4 de destino.
Del mismo modo, cuando la sesión se inicia en un host IPv4, la dirección IPv4 de origen será traducida por una dirección IPv6 compuesta por el prefijo 64::BB9F::/96 y los 32 bits de la dirección IPv4 del host.

Para la traducción de las direcciones de host IPv6 se utiliza un rango de direcciones IPv4 destinado por el Administrador para este propósito.

16.2. Técnicas de Tunneling

Las técnicas de tunneling consisten en que los paquetes IPv6 se encapsulan en paquetes IPv4 como si fueran de otro protocolo de nivel superior (por ejemplo TCP) y se enrutan en redes IPv4 (redes existentes) a lo largo de un túnel, que tiene un extremo que se ocupa de encapsular y otro que saca el paquete IPv6 y lo enruta hacía su destino. Los túneles pueden ser configurados de manera manual o bien ser de tipo automático.



COMO FUNCIONA EL TUNNELING

Las fases de la encapsulación de paquetes IPv6 son las siguientes:

1. El router a la entrada del túnel decrementa el valor del campo Hop Limit del paquete IPv6 de una unidad y crea un paquete IPv4 con el valor 41 en el campo Protocol Type. La longitud del paquete es calculada sumando la longitud de la cabecera IPv6, las eventuales cabeceras adicionales y el contenido del paquete. Si es necesario el router fragmenta el paquete. El destino del nuevo paquete IPv4 es la salida del túnel.

2. El router a la salida del túnel recibe el paquete IPv4. Si es fragmentado, espera todos los fragmentos y los reúne. Luego saca el paquete IPv6 y lo encamina hacía su destino.

El túnel es considerado como un salto único. No hay manera para que un host IPv6 se entere de que el paquete ha sido encapsulado a lo largo de su camino por medio de herramientas como traceroute.

A modo de ejemplo:


Esta empresa ofrece un servicio Gratuito de Tunelización de IPv6 sobre Redes IPv4.
El Servicio de intermediación de túneles le permite acceder a Internet IPv6 mediante la tunelización a través de conexiones IPv4 existentes desde su host o enrutador habilitado para IPv6 a uno de nuestros enrutadores IPv6.
Para utilizar este servicio, debe tener un host compatible con IPv6 (el soporte IPv6 está disponible para la mayoría de las plataformas) o un enrutador que también tenga conectividad IPv4 (Internet existente). El servicio de túneles está orientado a desarrolladores y experimentadores que desean una plataforma de túnel estable.

16.3. Traducción o Transición IPV4 a IPV6


Esta técnica consiste en utilizar algún dispositivo en la red que convierta los paquetes de IPv4 a IPv6 y viceversa. Ese dispositivo tiene que ser capaz de realizar la traducción en los dos sentidos de forma de permitir la comunicación. Dentro de esta clasificación podemos mencionar NAT64/DNS64.

NAT64/DNS64

La red es IPv6 nativa y para llegar a sitios que son sólo IPv4 se realiza una traducción al estilo NAT, mediante un mapeo entre los paquetes IPv6 e IPv4.

Se utiliza un prefijo especial para mapear direcciones IPv4 a IPv6: 64:ff9b::/96. De esta forma, la complejidad de administración se simplifica al sólo tener que administrar una red IPv6-only. Las conexiones IPv6 son nativas, por lo que a medida que el despliegue de IPv6 crece en el mundo, el costo de esta solución no se incrementa. Es necesario también utilizar una modificación al DNS, llamada DNS64, que permite generar un registro AAAA aún cuando el destino no tenga dirección IPv6 (es decir, el DNS responda sólo con registros de tipo A).


Registros DNS más comunes y a que servicios afectan:

  • A record: contiene una dirección IPv4. Afecta al sitio web mostrado (para navegadores que prefieren IPv4).
  • AAAA: contiene una dirección IPv6. Afecta al sitio web mostrado (para navegadores que prefieren IPv6).
  • CNAME: contiene el nombre de dominio y es solamente para subdominios. Redirige el sub-dominio al dominio deseado.
  • MX: contiene el nombre del servidor de e-mail (por ejemplo mx1.active24.com). Define donde se tienen que entregar los correos electrónicos.
Veamos como se vería gráficamente:

464XLAT

Se basa en la técnica anterior, pero introduce una doble traducción para los casos en que se
necesite utilizar una aplicación que no soporta IPv6. Esto soluciona algunos problemas de NAT64
y es una técnica muy adecuada para redes de celulares (móviles) ya que los sistemas Android ya
la incorporan. También para montar datacenters IPv6-only.

MAP-E y MAP-T

Son técnicas de transición similares a las anteriores pero que trabajan por compartición de puertos (A+P, ver RFC6346).
MAP-T usa traducción para transportar el tráfico IPv4.
MAP-E utiliza encapsulado (túneles).

16.4. Observaciones sobre la Migración (Informativo)

Las técnicas de transición en etapa inicial involucraron unir islas de IPv6 sobre un océano de IPv4. La transición de etapa intermedia involucra ambos protocolos en paralelo en una configuración de doble pila. Las técnicas de transición de última etapa aún se están desarrollando a medida que las organizaciones buscan operar un entorno de protocolo único y solo IPv6.

En 2007, la guía típica sobre la implementación de IPv6 era “IPv6: doble pila donde pueda; túnel donde debes“.

En los primeros días de la implementación de IPv6, había muchos enfoques basados ​​en túneles destinados a permitir que los implementadores implementaran IPv6 sobre una red IPv4 existente.

Sin embargo, había desventajas en técnicas como 6to4 (RFC 7526), ​​ISATAP (RFC 5214) y Teredo (RFC 4380).

Las técnicas de tunelización agregaron sobrecarga, redujeron el tamaño de la MTU y requirieron backhauling (transporte de retorno ) para agregar latencia a través de una puerta de enlace. También hubo muchas preocupaciones de seguridad sobre IPv6 durante este período inicial. Estos problemas dieron lugar a debates en el IETF sobre la desaprobación de los enfoques de tunelización dinámica.

Se tomaron medidas para degradarlos en las tablas de políticas de preferencias de selección de direcciones (RFC 6724 sección 2.1) en los sistemas operativos host.

Es por eso que los prefijos de IPv6 2002::/16, 2001::/32 tienen valores de precedencia bajos.

Ahora, Windows 10 y Windows Server 2019 tienen ISATAP (desde Creators Update – 1703) y 6to4 (desde Anniversary Update – 1607) deshabilitados de forma predeterminada.

Durante la etapa intermedia de la transición, la Guía de implementación de IPv6 empresarial predominante (RFC 7381) ha sido implementar IPv6 para crear una red de protocolo dual.

Incluso hoy en día, algunas empresas están luchando por comenzar su viaje IPv6 y posponen sus implementaciones de protocolo dual.

Parece que algunas empresas están "jugando a la gallina" con el requisito de IPv6 que se acerca rápidamente y están retrasando la implementación.

Están en peligro de convertirse en la categoría de "rezagados tecnológicos" cuando se trata de IPv6.

Podrían estar retrasando por una variedad de razones, como la falta de talento o habilidades con IPv6, la incapacidad de articular los beneficios comerciales, las razones financieras u operativas para adoptar IPv6 u otras demoras no técnicas.


Otra parte del Artículo presenta un mandato del Gobierno de EEUU, que dice:

Este es parte del pensamiento y la justificación detrás de algunos mandatos gubernamentales de IPv6.

La Oficina de Administración y Presupuesto (OMB, por sus siglas en inglés) del gobierno federal de EE. UU. publicó un mandato en noviembre de 2020 (M-21-07) que vuelve a enfatizar la importancia de IPv6 para los departamentos y agencias gubernamentales y establece un cronograma para deshabilitar IPv4. El cronograma es tener un 20 % solo de IPv6 para fines del año fiscal 2023, un 50 % solo de IPv6 para fines del año fiscal 2024 y un 80 % solo de IPv6 para fines del año fiscal 2025 (consulte el gráfico a continuación). La idea aquí es que en la etapa del 80%, Internet utilizará predominantemente IPv6. El estado de Washington tiene una "Política 300" de IPv6 para deshabilitar IPv4 a fines de 2025, y el gobierno chino tiene una meta de 100 % de IPv6 para 2025.


Este artículo continúa, en caso de ser de su interés dejo el link de la fuente.

Obtenido de:  https://blogs.infoblox.com/ipv6-coe/ipv6-only-where-you-can-dual-stack-where-you-must/


17. ping6

DNS de Google IPv4:  8.8.8.8 como servidor principal y 8.8.4.4 como el secundario. 

DNS de Google IPv6: 2001:4860:4860::8888 como servidor principal y 2001:4860:4860::8844 como el secundario.


Se puede usar ping6  o ping -6 desde la terminal de Linux


PING(8)                             iputils                            PING(8)

NAME
       ping - send ICMP ECHO_REQUEST to network hosts

SYNOPSIS
       ping [-aAbBdDfhLnOqrRUvV46] [-c count] [-F flowlabel] [-i interval]
            [-I interface] [-l preload] [-m mark] [-M pmtudisc_option]
            [-N nodeinfo_option] [-w deadline] [-W timeout] [-p pattern]
            [-Q tos] [-s packetsize] [-S sndbuf] [-t ttl]
            [-T timestamp option] [hop...] {destination}

DESCRIPTION
       ping uses the ICMP protocol's mandatory ECHO_REQUEST datagram to elicit
       an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams
       (“pings”) have an IP and ICMP header, followed by a struct timeval and
       then an arbitrary number of “pad” bytes used to fill out the packet.

       ping works with both IPv4 and IPv6. Using only one of them explicitly
       can be enforced by specifying -4 or -6.

       ping can also send IPv6 Node Information Queries (RFC4620).
       Intermediate hops may not be allowed, because IPv6 source routing was
       deprecated (RFC5095).

OPTIONS
       -4
           Use IPv4 only.

       -6
           Use IPv6 only.

       -a
           Audible ping.

       -A
           Adaptive ping. Interpacket interval adapts to round-trip time, so
           that effectively not more than one (or more, if preload is set)
           unanswered probe is present in the network. Minimal interval is
           200msec unless super-user. On networks with low RTT this mode is
           essentially equivalent to flood mode.

       -b
           Allow pinging a broadcast address.

       -B
           Do not allow ping to change source address of probes. The address
           is bound to one selected when ping starts.

       -c count
           Stop after sending count ECHO_REQUEST packets. With deadline
           option, ping waits for count ECHO_REPLY packets, until the timeout
           expires.

       -d
           Set the SO_DEBUG option on the socket being used. Essentially, this
           socket option is not used by Linux kernel.

       -D
           Print timestamp (unix time + microseconds as in gettimeofday)
           before each line.

       -f
           Flood ping. For every ECHO_REQUEST sent a period “.” is printed,
           while for every ECHO_REPLY received a backspace is printed. This
           provides a rapid display of how many packets are being dropped. If
           interval is not given, it sets interval to zero and outputs packets
           as fast as they come back or one hundred times per second,
           whichever is more. Only the super-user may use this option with
           zero interval.

       -F flow label
           IPv6 only. Allocate and set 20 bit flow label (in hex) on echo
           request packets. If value is zero, kernel allocates random flow
           label.

       -h
           Show help.

       -i interval
           Wait interval seconds between sending each packet. Real number
           allowed with dot as a decimal separator (regardless locale setup).
           The default is to wait for one second between each packet normally,
           or not to wait in flood mode. Only super-user may set interval to
           values less than 2 ms.

       -I interface
           interface is either an address, an interface name or a VRF name. If
           interface is an address, it sets source address to specified
           interface address. If interface is an interface name, it sets
           source interface to specified interface. If interface is a VRF
           name, each packet is routed using the corresponding routing table;
           in this case, the -I option can be repeated to specify a source
           address. NOTE: For IPv6, when doing ping to a link-local scope
           address, link specification (by the '%'-notation in destination, or
           by this option) can be used but it is no longer required.

       -l preload
           If preload is specified, ping sends that many packets not waiting
           for reply. Only the super-user may select preload more than 3.

       -L
           Suppress loopback of multicast packets. This flag only applies if
           the ping destination is a multicast address.

       -m mark
           use mark to tag the packets going out. This is useful for variety
           of reasons within the kernel such as using policy routing to select
           specific outbound processing.

       -M pmtudisc_opt
           Select Path MTU Discovery strategy.  pmtudisc_option may be either
           do (prohibit fragmentation, even local one), want (do PMTU
           discovery, fragment locally when packet size is large), or dont (do
           not set DF flag).

       -N nodeinfo_option
           IPv6 only. Send ICMPv6 Node Information Queries (RFC4620), instead
           of Echo Request. CAP_NET_RAW capability is required.

           help
               Show help for NI support.

           name
               Queries for Node Names.

           ipv6
               Queries for IPv6 Addresses. There are several IPv6 specific
               flags.

               ipv6-global
                   Request IPv6 global-scope addresses.

               ipv6-sitelocal
                   Request IPv6 site-local addresses.

               ipv6-linklocal
                   Request IPv6 link-local addresses.

               ipv6-all
                   Request IPv6 addresses on other interfaces.

           ipv4
               Queries for IPv4 Addresses. There is one IPv4 specific flag.

               ipv4-all
                   Request IPv4 addresses on other interfaces.

           subject-ipv6=ipv6addr
               IPv6 subject address.

           subject-ipv4=ipv4addr
               IPv4 subject address.

           subject-name=nodename
               Subject name. If it contains more than one dot, fully-qualified
               domain name is assumed.

           subject-fqdn=nodename
               Subject name. Fully-qualified domain name is always assumed.

       -n
           Numeric output only. No attempt will be made to lookup symbolic
           names for host addresses.

       -O
           Report outstanding ICMP ECHO reply before sending next packet. This
           is useful together with the timestamp -D to log output to a
           diagnostic file and search for missing answers.

       -p pattern
           You may specify up to 16 “pad” bytes to fill out the packet you
           send. This is useful for diagnosing data-dependent problems in a
           network. For example, -p ff will cause the sent packet to be filled
           with all ones.

       -q
           Quiet output. Nothing is displayed except the summary lines at
           startup time and when finished.

       -Q tos
           Set Quality of Service -related bits in ICMP datagrams.  tos can be
           decimal (ping only) or hex number.

           In RFC2474, these fields are interpreted as 8-bit Differentiated
           Services (DS), consisting of: bits 0-1 (2 lowest bits) of separate
           data, and bits 2-7 (highest 6 bits) of Differentiated Services
           Codepoint (DSCP). In RFC2481 and RFC3168, bits 0-1 are used for
           ECN.

           Historically (RFC1349, obsoleted by RFC2474), these were
           interpreted as: bit 0 (lowest bit) for reserved (currently being
           redefined as congestion control), 1-4 for Type of Service and bits
           5-7 (highest bits) for Precedence.

       -r
           Bypass the normal routing tables and send directly to a host on an
           attached interface. If the host is not on a directly-attached
           network, an error is returned. This option can be used to ping a
           local host through an interface that has no route through it
           provided the option -I is also used.

       -R
           ping only. Record route. Includes the RECORD_ROUTE option in the
           ECHO_REQUEST packet and displays the route buffer on returned
           packets. Note that the IP header is only large enough for nine such
           routes. Many hosts ignore or discard this option.

       -s packetsize
           Specifies the number of data bytes to be sent. The default is 56,
           which translates into 64 ICMP data bytes when combined with the 8
           bytes of ICMP header data.

       -S sndbuf
           Set socket sndbuf. If not specified, it is selected to buffer not
           more than one packet.

       -t ttl
           ping only. Set the IP Time to Live.

       -T timestamp option
           Set special IP timestamp options.  timestamp option may be either
           tsonly (only timestamps), tsandaddr (timestamps and addresses) or
           tsprespec host1 [host2 [host3 [host4]]] (timestamp prespecified
           hops).

       -U
           Print full user-to-user latency (the old behaviour). Normally ping
           prints network round trip time, which can be different f.e. due to
           DNS failures.

       -v
           Verbose output. Do not suppress DUP replies when pinging multicast
           address.

       -V
           Show version and exit.

       -w deadline
           Specify a timeout, in seconds, before ping exits regardless of how
           many packets have been sent or received. In this case ping does not
           stop after count packet are sent, it waits either for deadline
           expire or until count probes are answered or for some error
           notification from network.

       -W timeout
           Time to wait for a response, in seconds. The option affects only
           timeout in absence of any responses, otherwise ping waits for two
           RTTs. Real number allowed with dot as a decimal separator
           (regardless locale setup). 0 means infinite timeout.

       When using ping for fault isolation, it should first be run on the
       local host, to verify that the local network interface is up and
       running. Then, hosts and gateways further and further away should be
       “pinged”. Round-trip times and packet loss statistics are computed. If
       duplicate packets are received, they are not included in the packet
       loss calculation, although the round trip time of these packets is used
       in calculating the minimum/average/maximum/mdev round-trip time
       numbers.

       Population standard deviation (mdev), essentially an average of how far
       each ping RTT is from the mean RTT. The higher mdev is, the more
       variable the RTT is (over time). With a high RTT variability, you will
       have speed issues with bulk transfers (they will take longer than is
       strictly speaking necessary, as the variability will eventually cause
       the sender to wait for ACKs) and you will have middling to poor VoIP
       quality.

       When the specified number of packets have been sent (and received) or
       if the program is terminated with a SIGINT, a brief summary is
       displayed. Shorter current statistics can be obtained without
       termination of process with signal SIGQUIT.

       If ping does not receive any reply packets at all it will exit with
       code 1. If a packet count and deadline are both specified, and fewer
       than count packets are received by the time the deadline has arrived,
       it will also exit with code 1. On other error it exits with code 2.
       Otherwise it exits with code 0. This makes it possible to use the exit
       code to see if a host is alive or not.

       This program is intended for use in network testing, measurement and
       management. Because of the load it can impose on the network, it is
       unwise to use ping during normal operations or from automated scripts.

ICMP PACKET DETAILS
       An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet
       contains an additional 8 bytes worth of ICMP header followed by an
       arbitrary amount of data. When a packetsize is given, this indicates
       the size of this extra piece of data (the default is 56). Thus the
       amount of data received inside of an IP packet of type ICMP ECHO_REPLY
       will always be 8 bytes more than the requested data space (the ICMP
       header).

       If the data space is at least of size of struct timeval ping uses the
       beginning bytes of this space to include a timestamp which it uses in
       the computation of round trip times. If the data space is shorter, no
       round trip times are given.

DUPLICATE AND DAMAGED PACKETS
       ping will report duplicate and damaged packets. Duplicate packets
       should never occur, and seem to be caused by inappropriate link-level
       retransmissions. Duplicates may occur in many situations and are rarely
       (if ever) a good sign, although the presence of low levels of
       duplicates may not always be cause for alarm.

       Damaged packets are obviously serious cause for alarm and often
       indicate broken hardware somewhere in the ping packet's path (in the
       network or in the hosts).

TRYING DIFFERENT DATA PATTERNS
       The (inter)network layer should never treat packets differently
       depending on the data contained in the data portion. Unfortunately,
       data-dependent problems have been known to sneak into networks and
       remain undetected for long periods of time. In many cases the
       particular pattern that will have problems is something that doesn't
       have sufficient “transitions”, such as all ones or all zeros, or a
       pattern right at the edge, such as almost all zeros. It isn't
       necessarily enough to specify a data pattern of all zeros (for example)
       on the command line because the pattern that is of interest is at the
       data link level, and the relationship between what you type and what
       the controllers transmit can be complicated.

       This means that if you have a data-dependent problem you will probably
       have to do a lot of testing to find it. If you are lucky, you may
       manage to find a file that either can't be sent across your network or
       that takes much longer to transfer than other similar length files. You
       can then examine this file for repeated patterns that you can test
       using the -p option of ping.

TTL DETAILS
       The TTL value of an IP packet represents the maximum number of IP
       routers that the packet can go through before being thrown away. In
       current practice you can expect each router in the Internet to
       decrement the TTL field by exactly one.

       The TCP/IP specification states that the TTL field for TCP packets
       should be set to 60, but many systems use smaller values (4.3 BSD uses
       30, 4.2 used 15).

       The maximum possible value of this field is 255, and most Unix systems
       set the TTL field of ICMP ECHO_REQUEST packets to 255. This is why you
       will find you can “ping” some hosts, but not reach them with telnet(1)
       or ftp(1).

       In normal operation ping prints the TTL value from the packet it
       receives. When a remote system receives a ping packet, it can do one of
       three things with the TTL field in its response:

           • Not change it; this is what Berkeley Unix systems did before the
           4.3BSD Tahoe release. In this case the TTL value in the received
           packet will be 255 minus the number of routers in the round-trip
           path.

           • Set it to 255; this is what current Berkeley Unix systems do. In
           this case the TTL value in the received packet will be 255 minus
           the number of routers in the path from the remote system to the
           pinging host.

           • Set it to some other value. Some machines use the same value for
           ICMP packets that they use for TCP packets, for example either 30
           or 60. Others may use completely wild values.

BUGS
           • Many Hosts and Gateways ignore the RECORD_ROUTE option.

           • The maximum IP header length is too small for options like
           RECORD_ROUTE to be completely useful. There's not much that can be
           done about this, however.

           • Flood pinging is not recommended in general, and flood pinging
           the broadcast address should only be done under very controlled
           conditions.

SEE ALSO
       ip(8), ss(8).

HISTORY
       The ping command appeared in 4.3BSD.

       The version described here is its descendant specific to Linux.

       As of version s20150815, the ping6 binary doesn't exist anymore. It has
       been merged into ping. Creating a symlink named ping6 pointing to ping
       will result in the same functionality as before.

SECURITY
       ping requires CAP_NET_RAW capability to be executed 1) if the program
       is used for non-echo queries (See -N option), or 2) if kernel does not
       support non-raw ICMP sockets, or 3) if the user is not allowed to
       create an ICMP echo socket. The program may be used as set-uid root.

AVAILABILITY
       ping is part of iputils package.

iputils 20211215                                                       PING(8)

18. Ejemplo de Cálculo de Red.

Consigna:

Supongamos que el Internet Service Provider nos da la IPv6 Unicast Global siguiente:  2001:db8:cad::/48.

Escribir las direcciones necesarias para la Red, Sub Red y de Interfaces de la LAN.

Resolución

El prefijo de Red me permite saber que parte de la dirección será utilizada para Red

1 2 3 4 5 6 7 8
2001 0db8 0cad 0000 000
0000 0000 0000

Si escribimos según la regla 3-1-4 se vería:
3 -> 2001:0db8:0cad   48 Bits pas RED
1 -> 0000   16 Bits para Subred
4 -> 0000:0000:000:0000  64 Bits para ID de Interfaces

Tomemos una como ID de Interface :0000:0000:0000:0009 a modo de ejemplo.
  • La IPv6 Unicast Global para una Interface sería:  2001:db8:cad::9/64
  • Dirección de Loopback: ::1/ 128
  • Dirección de local link : fe80::9/64
  • Dirección Unicast sin especificar:  ::/128  (todos ceros)


19. Ejempo de reglas de Simplificación


Reglas de Simplificación

20. Videos

IPv6 Introducción.

Migración

Seguridad


21. Ejercicios de IPv6

1) Identificar según tipo las siguientes direcciones IPv6
  1. • 0000:00AA:ABCD:0000:A1B2:EEEE:1111:2222
  2. • FE80:0001:0000:FEAD:0005:5555:87AC:3CE1
  3. • 2018:000A:DDED:4444:FF5E:00FE:0000:1245
  4. • FE80:0000:0000:0000:0005:4175:BBBB:0101
  5. • 000F:0000:0000:0000:0000:AAAA:BBBB:CCCC
  6. • 0FFF:0000:0000:FFFF:0000:1111:DCBA:0001
  7. • FFF1:0000:A000:B000:C000:D000:E000:F000
2) Identificar cuales de las direcciones IPv6 son correctas
  1. • FE80::CAFE
  2. • 4F00::0A01:1
  3. • ::1
  4. • FE80::AC04::0012
  5. • 2001:DB8:1:ACAD::FE55:0:0:0001
  6. • FEAA:0001:0:0:1:FFEA:1001:000E
  7. • 2001:101::ABC0
3) Comprimir las siguientes direcciones IPv6
  1. • FE80:0001:0000:FEAD:0500:5555:87AC:3CE1
  2. • 0000:0001:0000:0000:A000:0002:1111:BA01
  3. • 2001:0DB8:0004:ACAD:0000:0000:FE00:0002
  4. • 2001:0030:0001:ACAD:0000:330E:10C2:32BF
  5. • FE80:0000:0000:0001:0000:60BB:008E:7402
4) Obtener información a partir del prefijo de red de la siguiente dirección IPv6
2000:1111:aaaa:0:50a5:8a35:a5bb:66e1/64

Resolución:
De izquierda a derecha, la porción de red de una dirección IPv6 unicast global tiene una estructura  jerárquica que proporcionará la siguiente información:
  1. Número de enrutamiento global de IANA (los tres primeros bits binarios se fijan en 001)   200::/12
  2. Prefijo del registro regional de Internet (RIR) (bits del /12 al /23) 2001:0D::/23 (el carácter D hexadecimal es 1101 en sistema binario. Los bits del 21 al 23 son 110, y el último bit es parte del prefijo del ISP).
  3. Prefijo del proveedor de servicios de Internet (ISP) (bits hasta el /32) 2001:0DB8::/32
  4. Prefijo de sitio o agregador de nivel de sitio (SLA), que el ISP asigna al cliente (bits hasta el /48)  2001:0DB8:0001::/48
  5. Prefijo de subred (asignado por el cliente; bits hasta el /64) 2001:0DB8:0001:ACAD::/64
  6. ID de interfaz (el host se identifica por los últimos 64 bits en la dirección) 2001:DB8:0001:ACAD:8D4F:4F4D:3237:95E2/64

22. Preguntas y respuestas

Encontré varias preguntas sobre IPv6 en este sitio: http://www.6sos.org/index.php
Me parecieron que podrían se de su interés.


1. ¿Qué es el protocolo IP?


IP son las siglas de "Internet Protocol". El protocolo fue diseñado en los años 70 con el fin de interconectar ordenadores que estuviesen en redes separadas. Hasta entonces los equipos informáticos se conectaban entre sí mediante redes locales, pero éstas estaban separadas entre sí formando islas de información.

El nombre Internet para designar el protocolo, y posteriormente la red mundial de información, significa justamente "inter red", es decir, conexión entre redes. Al principio el protocolo tuvo un uso exclusivamente militar pero rápidamente se fueron añadiendo ordenadores de universidades y posteriormente usuarios particulares y empresas.

La Internet como red mundial de información es el resultado de la aplicación práctica del protocolo IP, es decir, el resultado de la interconexión de todas las redes de información que existen en el mundo.

 
2. ¿Qué son las direcciones IP? 
La dirección IP es un identificador único que se aplica a cada dispositivo que esté conectado a una red IP. De esa forma los distintos elementos participantes de la red (servidores, routers, ordenadores de usuarios, etc) se comunican entre si utilizando su dirección IP como identificación.

En la versión 4 del protocolo IP (la usada actualmente) las direcciones están formadas por 4 números de 8 bits (un número de 8 bits puede valer desde 0 hasta 255) que se suelen representar separados por puntos, por ejemplo: 155.54.210.63

En total, una dirección IP versión 4 tiene 32 bits, lo que equivale a 232 direcciones IP diferentes (unos 4 billones).

 
3. ¿Qué es IPv6?

IPv6 es la nomenclatura abreviada de "Internet Protocol Version 6". IPv6 es el protocolo de la próxima generación de Internet, a la que originalmente se denominó IPng que viene de "Internet Protocol Next Generation".

IPv6 es por tanto la actualización del protocolo de red de datos en el que se fundamenta Internet. El IETF (Internet Engineering Task Force) desarrolló las especificaciones básicas durante los 90 para sustituir la versión actual del protocolo de Internet, IP versión 4 (IPv4), que vio la luz a finales de los 70.

 4. ¿Qué pasó con IPv5?

La referencia "versión 5" se empleó para otro cometido distinto. Se diseñó un protocolo experimental de streaming en tiempo real. Para evitar confusiones, se optó por no usar ese nombre.

 
5. ¿Por qué es necesario un nuevo protocolo IPv6?

IPv4 ha demostrado por su duración un diseño flexible y poderoso, pero está empezando a tener problemas, siendo el más importante el crecimiento en poco tiempo de la necesidad de direcciones IP.

Nuevos usuarios en países tan poblados como China o la India, nuevas tecnologías con dispositivos conectados de forma permanente (xDSL, cable, PLC, PDAs, teléfonos móviles UMTS, etc) están provocando la rápida desaparición, de forma práctica, de las direcciones IP disponibles en la versión 4.

IPv6 resuelve este problema creando un nuevo formato de dirección IP con muchísimas más variaciones, de forma que el número de direcciones IP no se agote incluso contando con que cada dispositivo que podamos imaginar (incluyendo electrodomésticos) se termine conectando a la red Internet.

IPv6 añade también muchas mejoras en áreas como el routing y la autoconfiguración de red. Los nuevos dispositivos que se incorporen a la red serán plug and play. Con IPv6 no es preciso configurar las IP del DNS, la puerta de enlace predeterminada, la máscara de subred y demás parámetros. Simplemente hay que enchufar el equipo a la red y éste obtendrá de la misma todos los datos de configuración que necesita.

6. ¿Cuáles son las mayores ventajas de IPv6?

Las podemos resumir en las siguientes:

Escalabilidad: IPv6 tiene direcciones de 128 bits frente a las direcciones de 32 bits de IPv4. Por tanto el número de direcciones IP disponibles se multiplica por 7,9 * 1028. IPv6 nos ofrece un espacio de 2128 (340.282.366.920.938.463.463.374.607.431.768.211.456). Para hacernos a la idea de lo que esta cifra implica, basta con calcular el número de direcciones IP que podríamos tener por metro cuadrado de la superficie terrestre: Nada más y nada menos que 665.570.793.348.866.943.898.599.

Seguridad: IPv6 incluye seguridad en sus especificaciones como es la encriptación de la información y la autentificación del remitente de dicha información.

Aplicaciones en tiempo real: Para dar mejor soporte a tráfico en tiempo real (i.e. videoconferencia), IPv6 incluye etiquetado de flujos en sus especificaciones. Con este mecanismo los encaminadores o routers pueden reconocer a qué flujo extremo a extremo pertenecen los paquetes que se transmiten.

Plug and Play: IPv6 incluye en su estándar el mecanismo "plug and play", lo cual facilita a los usuarios la conexión de sus equipos a la red. La configuración se realiza automáticamente.

Movilidad: IPv6 incluye mecanismos de movilidad más eficientes y robustos.

Especificaciones más claras y optimizadas:
IPv6 seguirá las buenas prácticas de IPv4 y elimina las características no utilizadas u obsoletas de IPv4, con lo que se consigue una optimización del protocolo de Internet. La idea es quedarse con lo bueno y eliminar lo malo del protocolo actual.

Direccionamiento y encaminado: IPv6 mejora la jerarquía de direccionamiento y encaminamiento.

Extensibilidad: IPv6 ha sido diseñado para ser extensible y ofrece soporte optimizado para nuevas opciones y extensiones.

7. ¿Por qué faltan direcciones IP cuando en teoría el protocolo permite hasta 232
    direcciones?

El protocolo IP actual nos permite tener más de 4 mil millones de direcciones. El problema de falta de direcciones actual surge porque en la década de los 80, sin prever el auge futuro del uso de Internet, se asignaron una gran cantidad de direcciones innecesarias sin ningún tipo de control. Esto ha provocado que existan muchas organizaciones que cuentan con un número mucho mayor de direcciones de las que realmente necesitan, con la consecuente carencia actual, o la imposibilidad práctica de usar todas ellas, por la fragmentación producida.

 
8. ¿Hay otra solución más sencilla a IPv6? 

Hay una solución que podríamos considerar como evidente, como sería la renumeración, y reasignación del espacio de direccionamiento IPv4. Sin embargo, no es tan sencillo, es incluso impensable en algunas redes, ya que requiere unos esfuerzos de coordinación, a escala mundial, absolutamente inimaginables. Además, seguiría siendo limitado para la población y cantidad de dispositivos que se prevé estén conectados a Internet en pocos años.

 
9. ¿Cuál es la solución empleada actualmente?


Temporalmente, para paliar la falta de direcciones, se emplean mecanismos NAT (network address translation). Este mecanismo consiste, básicamente y a grandes rasgos, en usar una única dirección IPv4 para que una red completa pueda acceder a Internet. Desafortunadamente, de seguir con IPv4, este mecanismo no sería "temporal", sino "invariablemente permanente".


 
10. ¿Por qué no seguimos usando NAT para siempre? 

NAT implica la imposibilidad práctica de muchas aplicaciones, que quedan relegadas a su uso en Intranets, dado que muchos protocolos son incapaces de atravesar los dispositivos NAT:

Las aplicaciones multimedia como por ejemplo las aplicaciones de videoconferencia, telefonía por Internet, vídeo bajo demanda…, no funcionan bien mediante NAT. Esto es debido a que los protocolos RTP y RTCP ("Real-time Transport Protocol" y "Real Time Control Protocol") usan UDP con asignación dinámica de puertos (NAT no soporta esta traslación).
La autenticación Kerberos necesita la dirección fuente, que es modificada por NAT en la cabecera IP.
IPSec permite la autentificación, integridad y confidencialidad de los datos. Sin embargo, al utilizarse NAT, IPsec pierde integridad, debido a que NAT cambia la dirección en la cabecera IP.
Multicast, aunque es posible, técnicamente, su configuración es tan complicada con NAT, que en la práctica no se emplea.
La idea es que NAT desaparezca con IPv6.

 
11. ¿Cómo es el formato de las direcciones IPv6?

Veamos un ejemplo de dirección IP versión 6:

2001:0ba0:01e0:d001:0000:0000:d0f0:0010

La dirección en total está formada por 128 bits, frente a los 32 de las actuales (versión 4). Se representa en 8 grupos de 16 bits cada uno, separados por el carácter ":"

Cada grupo de 16 bits se representa a su vez mediante 4 cifras hexadecimales, es decir, que cada cifra va del 0 al 15 (0,1,2, ... a,b,c,d,e,f siendo a=10, b=11, etc hasta f=15)

Existe un formato abreviado para designar direcciones IP versión 6 cuando las terminaciones son todas 0, por ejemplo:

2001:0ba0::

Es la forma abreviada de la siguiente dirección:

2001:0ba0:0000:0000:0000:0000:0000:0000

Igualmente, se puede poner un solo 0, quitar los ceros a la izquierda y se pueden abreviar 4 ceros en medio de la dirección (una sola vez en cada dirección), así:

2001:ba0:0:0:0:0::1234

Es la forma abreviada de la dirección:

2001:0ba0:0000:0000:0000:0000:0000:1234

También existe un método para designar grupos de direcciones IP o subredes que consiste en especificar el número de bits que designan la subred, empezando de izquierda a derecha, utilizándose los bits restantes para designar equipos individuales dentro de la subred.

Por ejemplo la notación:

2001:0ba0:01a0::/48

Indica que la parte de la dirección IP utilizada para representar la subred tiene 48 bits. Como cada cifra hexadecimal son 4 bits, esto indica que la parte utilizada para representar la subred está formada por 12 cifras, es decir: "2001:0ba0:01a0". El resto de las cifras de la dirección IP (las que estén a su derecha cuando se escriba completa) se utilizarían para representar nodos dentro de la subred.

 
12. ¿Cuáles son las direcciones especiales en IPv6?
Dirección virtual de auto-retorno ó loopback. Esta dirección se especifica en IPv4 con la dirección 127.0.0.1. En IPv6 esta dirección se representa como ::1.
Dirección no especificada (::). Nunca debe ser asignada a ningún nodo, ya que se emplea para indicar la ausencia de dirección.
Túneles dinámicos/automáticos de IPv6 sobre IPv4. Se denominan direcciones IPv6 compatibles con IPv4, y permiten la retransmisión de tráfico IPv6 sobre redes IPv4, de forma transparente. Se indican como ::, por ejemplo ::156.55.23.5.
Representación automática de direcciones IPv4 sobre IPv6: nos permite que los nodos que sólo soportan IPv4 puedan seguir trabajando en redes IPv6. Se denominan "direcciones IPv6 mapeadas desde IPv4". Se indican como ::FFFF:, por ejemplo ::FFFF:156.55.43.3.
 
13. ¿Qué se entiende por "autoconfiguración" en IPv6?
Es una nueva característica del protocolo, que facilita la administración de las redes, y las tareas de instalación de los sistemas operativos por parte de los propios usuarios, en lo que a configuración de IP se refiere.

Frecuentemente se denomina esta característica como "plug & play" o "conectar y funcionar". Esto permite que al conectar una máquina a una red IPv6, se le asigne automáticamente una (ó varias) direcciones IPv6.

14. ¿En que consiste la "autoconfiguración"?

El proceso es variable y muy complejo, ya que la política decidida por el administrador de red es la que determina qué parámetros serán "asignados" automáticamente.

Al menos, y cuando no hay administrador de red, se suele incluir la asignación de una dirección de "enlace local". La dirección de "enlace local" permite la comunicación con los otros nodos situados en el mismo enlace físico, cuando por ejemplo, hablamos de una interfaz Ethernet.

 
15. ¿Hay varias formas de "autoconfiguración"? 

Si, efectivamente, se distinguen dos mecanismos básicos de autoconfiguración.

Por un lado existe la autoconfiguración "stateful" y por otro la "stateless". Lo más importante es entender que estos mecanismos pueden utilizarse de forma complementaria, para definir unos u otros parámetros de configuración por medio de uno u otro de los mecanismos, o de ambos simultáneamente.

 16. ¿En que consiste la autoconfiguración "stateless"?

Comúnmente se denomina autoconfiguración "serverless", y ello es casi una definición del mecanismo.

En la autoconfiguración "stateless", no se requiere ninguna configuración manual de equipos (hosts) y servidores, y tan sólo en ocasiones, mínima configuración de los routers.

Por tanto, para la autoconfiguración stateless, no se requiere la presencia de servidores.

En este mecanismo, el equipo (host), genera su propia dirección usando una combinación de la información que el mismo tiene (en su interfaz, o tarjeta de red), y la información que periódicamente suministran los routers.

Los routers indican el prefijo que identifica la(-s) subredes asociadas con el enlace.
 
17. ¿Qué es el "identificador de interfaz"? 

El "identificador de interfaz" es aquel que identifica de forma única una interfaz en una subred, y que a menudo, por defecto, es generado a partir de la dirección MAC de la tarjeta de red.

La dirección IPv6 se forma combinando los 64 bits del identificador de interfaz con los prefijos que los encaminadores (routers) indican como correspondientes a la subred.

 
18. ¿Qué ocurre si en una red no hay encaminadores? 

Si no hay encaminadores, el identificador de interfaz es autosuficiente para permitir al PC que genere la dirección de enlace local.

La dirección de enlace local es suficiente, lógicamente, para permitir la comunicación entre los diversos nodos conectados al mismo enlace (la misma red local).

 19. ¿En que consiste la autoconfiguración "stateful"?

Al contrario que en la configuración "stateless", en el caso de la "stateful", se requiere la existencia de algún tipo de servidor, a través del cual los nodos o host reciben la información y parámetros de su conexión a la red.

Los servidores mantienen, por tanto, una base de datos con todas las direcciones que han sido asignadas y a que hosts, al igual que todo lo relacionado con el resto de los parámetros.

Por lo general, este mecanismo se basa en el uso de DHCPv6.

 20. ¿Qué sentido tiene el uso de ambos mecanismos de autoconfiguración?

La autoconfiguración "stateful", a menudo se usa cuando se requiere un control más riguroso acerca de que dirección es asignada a que hosts, al contrario del caso de la autoconfiguración "stateless" (en la que la única preocupación es que la dirección no este duplicada).

Por tanto, en función de la política de administración de la red, se puede requerir que determinadas direcciones sean asignadas de forma fija a determinas máquinas, y por tanto ello requiere el mecanismo "stateful", pero el control del resto de los parámetros puede no ser necesariamente tan riguroso.

Por supuesto, el caso puede ser el de una política invertida respecto de este ejemplo, es decir, que no importe la dirección que se asigne, y por tanto se emplea "stateless", pero se desea que el resto de los parámetros sean asignados de forma "estática", con información almacenada en un servidor.


21. ¿Qué es la caducidad de las direcciones IPv6? 

Las direcciones IPv6 son "alquiladas" a una interfaz por un tiempo fijo si estas son asignadas por DHCPv6, y sea  probablemente infinito.

Cuando dicho "tiempo de vida" expira, la vinculación entre la interfaz y la dirección se invalida, y dicha dirección puede ser reasignada a otra interfaz en cualquier punto de Internet.

Para la adecuada gestión de la expiración de las direcciones, una dirección pasa por dos fases mientras esta asignada a una interfaz:

a) Inicialmente, una dirección es "preferida" ("prefered"), lo que implica que su uso en cualquier comunicación no está restringido.

b) Posteriormente, una dirección pasa a ser "desaprobada" ("deprecated"), anticipándose a que se va a invalidar su vínculo con la interfaz actual.

Mientras esta en estado "desaprobada", se desaconseja el uso de una dirección, aunque no estrictamente prohibido. Sin embargo, cuando sea posible, cualquier nueva comunicación (por ejemplo la apertura de una nueva conexión TCP), debe usar una dirección "preferida". Una dirección "desaprobada" sólo debería de ser utilizada por aquellas aplicaciones que ya la empleaban y a las que les es difícil cambiar a otra dirección sin causar una interrupción del servicio.
 
22. ¿Qué es la detección de direcciones duplicadas?

Para asegurarse de que las direcciones asignadas, tanto por procesos de autoconfiguración como por mecanismos manuales, son únicas en un determinado enlace, se emplea, antes de dicha asignación, el algoritmo de detección de direcciones duplicadas.

Recordemos que algunos SO asignan de manera aleatorio la parte de IP que corresponde a la interfase y se podría dar al caso que de hayan dos iguales.

Si se detecta una dirección duplicada, esta no puede ser asignada a la interfaz en cuestión.

La dirección en la que se está aplicando el algoritmo de detección de direcciones duplicadas, se dice que es "tentativa", hasta la completa finalización de dicho algoritmo.

En este caso, no se considera que dicha dirección ha sido asignada a una interfaz, y por tanto los paquetes recibidos son descartados.

23. ¿Cómo se forma una dirección IPv6?

Ya sabemos que una dirección IPv6 tiene 128 bits. De estos, los 64 bits inferiores o de menor peso, identifican a una determinada interfaz, como ya hemos comentado, y se denominan "identificador de interfaz".

Los 64 bits de orden superior, indican la "ruta" o "prefijo" de la red o del router en uno de cuyos enlaces se conecta dicha interfaz.

La dirección IPv6, se forma por tanto, combinando el prefijo con el identificador de interfaz.

 24. ¿Es posible tener direcciones IPv4 é IPv6 a la vez?

Sí. La mayoría de los sistemas operativos que soportan actualmente IPv6 permiten la utilización simultánea de ambos protocolos. De esta forma, es posible la comunicación tanto con redes que sólo soporten IPv4 como con aquellas redes que sólo soporten IPv6, así como la utilización de aplicaciones diseñadas para ambos protocolos.

 25. ¿Es posible la utilización de tráfico IPv6 sobre redes IPv4?

Sí. Para ello se utiliza una técnica que se denomina túnel. Consiste en introducir en un extremo el tráfico IPv6 como si fueran datos del protocolo IPv4 . De esta manera, el tráfico IPv6 viaja "encapsulado" dentro del tráfico IPv4 y en el otro extremo, este tráfico es separado e interpretado como tráfico IPv6. Para ello necesitas utilizar un servidor de túneles, como el que proporcionamos en la sección de conectividad.

 26. ¿Cómo se repartirán las nuevas direcciones IPv6? 

Los proveedores de servicios Internet (ISPs) que están ya en el proceso de implantación de la nueva versión del protocolo IP siguen las políticas de los registradores regionales de Internet o RIRs (Regional Internet Registries, l RIPE en el caso de Europa, LATNIC en Latinoamérica), respecto a cómo repartir el enorme espacio de direccionamiento IP versión 6 entre sus clientes.

Existe una diferencia muy grande entre las recomendaciones para la asignación de las direcciones IP versión 4, que busca ante todo la economía de direcciones, pues como es sabido es un recurso escaso y debe de ser administrado con precaución, y las de la versión 6 que busca la flexibilidad.

Los RIPE RIRs estará recomendando a los ISP y operadores que asignen a cada cliente de IPv6 una subred del tipo /48 con el fin de que el cliente pueda gestionar sus propias subredes sin tener que utilizar NAT. (La idea es que NAT desaparezca en IPv6).

27. ¿Qué es la siguiente cabecera?  

El protocolo IPv6, para permitir su máxima escalabilidad, ha optado por un sistema de una cabecera básica, con información mínima, a diferencia de IPv4, donde las diferentes opciones se van añadiendo a dicha cabecera básica.

En su lugar, IPv6 conlleva un mecanismo de "encadenamiento" de cabeceras, de tal forma que la cabecera básica indica cual es la siguiente, y así sucesivamente.

28. ¿Cuál es la ventaja del mecanismo de Siguiente Cabecera?  

Las ventajas son varias y bastante evidentes.

La primera es que permite que el tamaño de la cabecera básica sea siempre el mismo, y perfectamente conocido.

La segunda es que los routers situados entre una dirección origen y una dirección destino, es decir, en el camino que tiene que recorrer un determinado paquete, no necesiten procesar ni siquiera interpretar o entender las "siguientes cabeceras". Ello supone además, para IPv4, la desventaja de que los routers tienen que ser actualizados más frecuentemente para soportar cualquier nueva función del protocolo, ya que debía ser capaz de interpretarla, aún cuando no tuviera que realizar ninguna función al respecto.

La tercera ventaja es que no hay límite para el número de opciones que se soportan. En IPv4, sólo se pueden soportar opciones hasta un máximo de 40 bytes.

29. ¿Cuál es la longitud de la cabecera IPv6? 

La longitud de la cabecera IPv6 es de 40 bytes, a diferencia de la IPv4 que podría oscilar entre 20 y 60 bytes (según las opciones empleadas).

Sin embargo, se ha simplificado enormemente, dado que se ha pasado de 12 campos a tan solo 8, evitando redundancias.

30. ¿Porqué es más eficaz el proceso de cabeceras IPv6?

Como hemos dicho, la cabecera básica IPv6 es de longitud fija. Ello implica que es más fácil su procesado por parte de nodos y routers, e incluso simplifica el diseño de semiconductores dedicados a su procesado.

Por otro lado, su estructura esta alineada a 64 bits, lo que permite también el que los nuevos y futuros procesadores (como mínimo de 64 bits), puedan procesarla de forma más eficiente.

Pero también hemos mencionado que tiene menos campos, lo que de nuevo redunda en dicha eficacia.

Por último, en general, y salvo un par de excepciones, los puntos intermedios de la red (routers), sólo tienen que procesar la cabecera básica, mientras que en IPv4 se ven forzados a procesarlas todas.

31. ¿Qué es un "jumbogram"? 

Es una opción que permite que la longitud máxima de los datos transportados por IPv6 (16 bits, 65.535 bytes), se extienda hasta 64 bits.

Se prevé su uso especialmente para tráficos multimedia, sobre líneas de banda ancha. Sin embargo estos paquetes no pueden ser fragmentados.

32. ¿Para que se utiliza la cabecera de fragmentación? 

En IPv6, los routers intermedios no realizan la fragmentación de los paquetes, sino que en su lugar la fragmentación se realiza extremo a extremo.

Es decir, son los nodos origen y destino los que se ocupan, a través de la propia pila IPv6, de fragmentar un paquete, y en su caso reensamblarlo, respectivamente.

El proceso de fragmentación consiste, lógicamente, en dividir en paquetes más pequeños la parte "fragmentable" del paquete origen, y agregarle a cada uno de ellos la parte no fragmentable, que permitirá, al nodo destino, la re-composición de dicho paquete.
 
33. ¿Qué son los mecanismos de transición? 
Son los métodos ideados para que coexistan maquinas y redes con IPv4 y/o IPv6.

 
34. ¿Qué es un túnel IPv6-en-IPv4?

Es un mecanismo de transición que permite a maquinas con IPv6 instalado comunicarse entre si a través de una red IPv4.

El mecanismo consiste en crear los paquetes IPv6 de forma normal e introducirlos en un paquete IPv4. El proceso inverso se realiza en la maquina destino, que recibe un paquete IPv6

35. ¿Por que no se necesita campo de ID en IPv6 ?

Hay que empezar por preguntarse para que se usa el campo ID en IPv4, la respuesta es para poder re-ensamblar en origen los fragmentos. En IPv6,  los routers intermedios no fragmentan paquetes. Si el paquete es demasiado grande para una red intermedia, simplemente se descarta y se envía un mensaje ICMP ("Packet Too Big") al origen, para que el dispositivo que envía ajuste el tamaño de los paquetes. Esto elimina la necesidad de tener un campo de identificación en cada paquete, ya que los routers no necesitan fragmentarlos. Así que se elimina el campo por que  no se necesita identificar el Datagrama. En caso de que fuera necesario se debería poner en la extensión de encabezado de fragmentación solo cuando es necesario, algo que de debería evitar.

36. ¿Por que cree que en IPv6 el Header no necesita campo de Checksum?

El encabezado IPv6 no está protegido por una suma de comprobación (checksum); la protección de integridad se asume asegurada tanto por el checksum de capa de enlace y por un checksum de nivel superior (TCP, UDP, etc.). De esta forma los routers IPv6 no necesitan recalcular la suma de comprobación cada vez que algún campo del encabezado (como el contador de saltos o Tiempo de Vida).