IPv6

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 agotarían.

Agotamiento de IPV4

Las direcciones IPv4 , permite identificar la interfaz de red en todo internet. Estas IP deben ser únicas, para que funcione.
Sabemos que para IP v.4 la cantidad de Direcciones posibles se forman con 32 bits.
Por lo tanto IPv4 = 4.294.967.296 ( = 2³² ).

¿ Es esta afirmación totalmente cierta ?

Esto a priori parecía una cantidad extremadamente alta, pero no fue así. Algunas decisiones 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. 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 IP´s.

ICANN ( Internet Corporation for Assigned Names and Numbers -  Corporación de Internet para la Asignación de Nombres y Números), es el organismo que distribuye las IP´s 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 IP`s entre los RIRS ( Regional Internet Registry - Registro Regional de Internet) y estos a su vez a los ISP (Internet Service Provider - Proveedor de Servicios de Internet ) y estos a los usuarios finales.

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 RIR´s a nivel mundial, cada uno ubicado en una zona geográfica. Cada RIR tiene sus propias políticas de asiganción de IP´s.

Figura 1: Distintas Regiones de IANA

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

Acerca de IANA:

La entidad Internet Assigned Numbers Authority (Autoridad de Asignación de Números de Internet) 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 organisations) 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, ultimas IPS 15 de Abril del 2011.
•RIPS NCC, ultimas Ips 14 de Septiembre de 2012
•ARIN, ultimas Ips 23 de Abril del 2014.
•LACNIC ultimas 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 Gerarquí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 ingles significa nivel

Cuestiones como:

• Mala practica de asignación
• Clases A a IBM, HP, AT&T, etcDirecciones reservadas que no se usaron.
• Crecimiento de Rutas BGP IPV4 ( http://www.routeviews.org/dynamics/)

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

Figura: 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 (Internet Of the Things)

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 (al límite).

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 , es el mayor desafío y oportunidad para Internet en la actualidad. Se compone de dispositivos integrados habilitados para IP conectados a Internet, incluidos 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 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.

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 (Internet Engineering Task Force - Grupo de Trabajo de Ingeniería de Internet)  crea el Grupo ROAD (ROuting and ADdressing) comienza a estudiar posibles soluciones.
• 2) CIDR ( Classless Inter-Domain Routing - Enrutamiento entre dominios sin Clases - RFC 4632)  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ó:
    • Un uso más eficiente de las cada vez más escasas direcciones IPv4.
    • 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.
    • Bloques de direcciones de tamaño apropiado a las necesidades y usos.
    • Dirección de red = prefijo/longitud.

• 3. 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:

4. IPV6 Direcciones y Subredes

En 1992, el IETF crea el grupo IPng (IP Next Generation ) que sería el IP v6. Diseñado por Steve Deering de Xerox PARC y Craig Mudge.

IPv4 tiene 2³² direcciones distintas, esto da  4.294.967.296 de IPs dsitintas ( esto no 100% cierto).
En cambio, IPv6 admite 340.282.366.920.938.463.463.374.607.431.768.211.456 (2¹²⁸ o 340 sextillones de direcciones) cerca de 6,7 ×1017 (670 mil billones) de direcciones por cada milímetro cuadrado de la superficie de la Tierra.

Presentemos esto en potencias de 10, para intentar dar magnitud a estos números.

Observación: 670.000.000.000 direcciones por milímetro cuadrado de la sup. de la tierra!!

El gobierno de los Estados Unidos ordenó el despliegue de IPv6 por todas sus agencias federales en el año 2008, nuestro país está bastante lejos de esto, ( al parecer tenemos otras cosas para preocuparnos... ).

ACTIVIDAD EN CLASES:

Se pide al alumno calcular cuantas direcciones posibles se podrían tener en :

• una oficina de 10 x 20,
• un edificio de 10 pisos con oficinas de 10m x 20m.

4.1. Datagrama

• 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.

4.2. Notación de direcciones IPV6

En IPv6 no se usa la notación como en IPv4, aqui se usan la base numérica Hexadecimal 0,1, ...9, A,B,C,D,E,F. ( 16 en total)

• Un dígito Hexadecimal está formado por 4 bits.
• La dirección IPv6 está formado por 8 Segmentos (partes) de 4 Dígitos Hexadecimales ( 8  segmentos *4 digitos hexadecimales *4 bits cada dígito hexadecimal =128 bits). Gráficamente sería:
• 

• A los 16 bits se los llama Hextetos (no es un término formal), hay 8 hextetos.
  Representación recomendada x:x:x:x:x:x:x:x , x es de uno a cuatro dígitos hexadecimales de las ocho partes de 16 bits de la dirección.
  
  • Ejemplo:
    
    • ABCD:EF01:2345:6789:ABCD:EF01:2345:6789.
    • 2001:DB8:0:0:8:800:200C:417A.

<-----Regla de los ceros Iniciales!

 0:0:0:0:0:ffff:192.1.56.10 y ::ffff:192.1.56.10/96 (formato abreviado).
Se permite la siguiente forma: x:x:x:x:x:x:d.d.d.d
Mas ejemplos:

1. 0:0:0:0:0:0:13.1.68.3
2. 0:0:0:0:0:FFFF:129.144.52.38

en su forma comprimida:

1. ::13.1.68.3
2. ::FFFF:129.144.52.38

Prefijo de Red

Debido a la extensión de una dir. IPv6 no se tiene una máscara de subred en formato de dirección IPv6,  solamente se emplea la longitud o duración de prefijo para delimitar la porción de red y de host en este tipo de direcciones. La longitud de prefijo pude ir desde /0 hasta /128, siendo la longitud de prefijo típica en un host /64.

Ejemplo:

5. Tipos de Direcciones

En IPv6 tenemos 3 tipos de Direcciones.

1-Direcciones Unicast

Sería una dirección de Unidifusión, es decir un solo host.

2-Direcciones Multicast

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.

Para poder hacer esto el Nodo DEBE tener la dirección de multidifusión del grupo.

3-Direcciones Anycast ( este tipo NO existe en IPv4 )

Las direcciones Anycast permiten esta forma de funcionamiento. Cuando un host envía un datagrama a una dirección anycast, la infraestructura de red buscará el camino más corto hasta uno, y preferiblemente solo uno, de los equipos que aceptan datagramas dirigidos a la dirección anycast utilizada. Podríamos decir que es una dirección dirigida a un Sub grupo.

Podemos ver que Direcciones de Broadcast NO existen en IPv6!!

5.1. Direcciones Unicast

Unidifusión (unicast): un identificador para una interfaz individual. Un paquete enviado a una dirección de este tipo se entrega a la interfaz identificada por esa dirección. Este tipo ya existía en IPv4

Tipos de Dirección Unicast.

1 de 6: Unicast Global:

Las direcciones unicast globales son similares a las direcciones IPv4 públicas. Estas son direcciones enrutables de Internet globalmente exclusivas. Las direcciones unicast globales pueden configurarse estáticamente o asignarse de forma dinámica. Existen algunas diferencias importantes con respecto a la forma en que un dispositivo recibe su dirección IPv6 dinámicamente en comparación con DHCP para IPv4. 

La IANA ( http://www.iana.org/) dividió todo el rango de direcciones IPv6 en 8 partes.
Para ello utilizó los 3 primeros bits , 2³ = 8.
Por el momento usa 1⁄8 parte de las Direcciones totales con los tres primeros bits en 001.

• => 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)
• 3FFF = 0011 1111 1111 1111(ultima)

 Direcciones usadas actualmente

3 bits => 2³ =8 , por el momento solo la los tres primeros se usan y estan en 001 =>resta 7/8 del total sin usar:

000,010,011,100,101,110,111

El cuarto bit puede ser 0 ó 1 de las direcciones IPv6 actuamente asignadas. Esto nos da en este momento de una parte del total de direcciones IPv6 Unicast.

1/8 Cantidad de Direcciones Unicast Globales Distribuidas al momento.

Las demás direcciones restantes  (7/8 ) se van a habilitar en el Futuro.

Es por eso que las  Únicas y Enrutables al día de hoy están en Rango :  2000::/3 hasta 3FFF::/3

Campos de una Dirección Unicast Global.

Estas direcciones Unicast Globales se pueden expresar de forma comprimida, veamos unos ejemplos.

Dirección Unicast Global Completa :  2001:0DB8:ACAD:0001:0000:0000:0000:0010

Notación Regla 3-1-4

3 Segmentos de Red: 2001:0DB8:ACAD  (16*3 = 48 bits ID de Red)
1 Segmento de Subred: 0001 (16 bits , ID de Subred )
4 Segmentos de Intercace: 0000:0000:0000:0010 (16 *4 = 64 Bits, ID de Interface )

2 de 6: Link Local

Las direcciones link-local se utilizan para comunicarse con otros dispositivos en el mismo enlace local.

Con IPv6, el término “enlace” hace referencia a una subred.

Las direcciones link-local se limitan a un único enlace.

Su exclusividad se debe confirmar solo para ese enlace, ya que no se pueden enrutar más allá del enlace.

En otras palabras, los routers no reenvían paquetes con una dirección de origen o de destino link-local. 

Si queremos hacer una analogía con IPv4 podríamos decir que son como IPs privadas.

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

Si lo escribimos de una manera NO Comprimida sería:

• FE80::/10 = FE80: 0000:0000:0000:0000:0000:0000 /10

/10 indica que los primeros 10 bits son 1111 1110 10xx xxxx. El primer hexteto tiene un rango de: 1111 1110 1000 0000 (FE80) ...etc. hasta .. 1111 1110 1011 1111 (FEBF).

Dirección Link-local (no ruteable)

Dirección Link-local NO pasa Router

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

Si lo escribimos de una manera NO Comprimida sería:

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

Ver que los tres primeros bits son 111!!! esto no estan dentro de los distribuidos hasta el momento.

Si lo escribimos de una manera NO Comprimida sería:

FE80::/10 = FE80: 0000:0000:0000:0000:0000:0000 /10

• 1111 1110 1000 0000 (FE80)
• ...
• ..
• 1111 1110 1011 1111 (FEBF).

4 de 6: Dirección Unicast sin especificar.

Una dirección sin especificar es una dirección compuesta solo por ceros representada como ::/128 o, simplemente, :: en formato comprimido.

No puede asignarse a una interfaz y solo se utiliza como dirección de origen en un paquete IPv6.

Las direcciones sin especificar se utilizan como direcciones de origen cuando el dispositivo aún no tiene una dirección IPv6 permanente o cuando el origen del paquete es irrelevante para el destino.

5 de 6: Dirección Unicast Local Única (ULA)

Las direcciones IPv6 locales únicas tienen cierta similitud con las direcciones privadas para IPv4 definidas en RFC 1918, pero también existen diferencias importantes.

Las direcciones locales únicas se utilizan para el direccionamiento local dentro de un sitio o entre una cantidad limitada de sitios. Estas direcciones no deben ser enrutables en la IPv6 global.

Las direcciones locales únicas están en el rango de FC00::/7 a FDFF::/7.

Con IPv4, las direcciones privadas se combinan con NAT/PAT para proporcionar una traducción de varios a uno de direcciones privadas a públicas. Esto se hace debido a la disponibilidad limitada de espacio de direcciones IPv4. Muchos sitios también utilizan la naturaleza privada de las direcciones definidas en RFC 1918 para ayudar a proteger u ocultar su red de posibles riesgos de seguridad. Sin embargo, este nunca fue el uso que se pretendió dar a estas tecnologías, y el IETF siempre recomendó que los sitios tomen las precauciones de seguridad adecuadas en el router con conexión a Internet.

Como IPv6 proporciona direccionamiento de sitio específico, no tiene por propósito ser utilizado para contribuir a ocultar dispositivos internos con IPv6 habilitado de Internet IPv6. El IETF recomienda que la limitación del acceso a los dispositivos se logre implementando medidas de seguridad adecuadas y recomendadas.

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.

¿Para qué sirven las direcciones ULA?

Las direcciones ULA son útiles en el establecimiento de un esquema de direccionamiento propio que no dependa de los bloques asignados por algún ISP; como consecuencia, sólo los nodos de la organización pueden tener acceso los dispositivos internos de la red pero no a internet; para que un host que utilice una dirección ULA pueda acceder a Internet, debe utilizarse NAT en los dispositivos de borde. Siendo así, las direcciones ULA serían perfectas en aquellos equipos o dispositivos que requieren ser accedidos a través de la red local, pero no se espera que tengan visibilidad a nivel de Internet.

Entre los usos de este tipo de direcciones podemos nombrar:

• El direccionamiento para los clientes VPN

• Las redes de gestión fuera de banda

• Las redes de laboratorios

• Las redes de alta seguridad.

6 de 6: Dirección IPv4 Integrada.

5.2. Direcciones Anycast

Direcciones Anycast

Las direcciones de Anycast  identifican  a una o más interfaces de la Red Global que perteneces a un grupo , el grupo de Anycast.

Los paquetes enviados a esa dirección IP se reenvían al servidor más cercano según sea  el mejor destino desde el punto de vista del punto de vista de la Topología de Red, lógicamente los servidores de esa red Anycast proveen el mismo servicio, por ejemplo un servidor Web o DNS.

Las direcciones anycast se asignan desde el espacio de direcciones unicast, utilizando  cualquiera de los formatos de dirección de unidifusión definidos. Por lo tanto, las direcciones anycast  son sintácticamente indistinguibles de las direcciones unicast. Cuando una  dirección de unidifusión se asigna a más de una interfaz, lo que convierte   en una dirección anycast, los nodos a los que se envía la dirección   asignado debe configurarse explícitamente para saber que es una dirección de  anycast.

El "prefijo de subred" en una dirección anycast es el prefijo que  identifica un enlace específico. Esta dirección anycast es sintácticamente la misma que una dirección unicast para una interfaz en el enlace con el   identificador de interfaz establecido en cero.

Usos de Anycast.

Algunos servidores raíz del sistema DNS están distribuidos geográficamente para repartir la carga y evitar que la caída de un servidor afecte ostensiblemente a la navegación por internet.

El uso de anycast en Internet ayuda a contener un ataque distribuido de denegación de servicio DDOS y reducir su efectividad.

Anycast se suele usar con protocolos no orientados a la conexión (como UDP en internet), dado que los protocolos orientados a la conexión (como TCP) necesitan mantener información del estado de la comunicación y en anycast, la máquina destino puede variar sin previo aviso y si se usar TCP se debería crear una nueva sesión.

Características:

• En networking hay ocasiones en las que un servicio se ofrece por medio de varios hosts o routers.

• De este modo se consigue:

• 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).

• Cuando un usuario, aplicación o host quiere acceder al servicio, no le importa cuál de los múltiples servidores que lo ofrecen le está atendiendo.

• Las direcciones Anycast permiten esta forma de funcionamiento. Cuando un host envía un datagrama a una dirección anycast, la infraestructura de red buscará el camino más corto hasta uno, y preferiblemente solo uno, de los equipos que aceptan datagramas dirigidos a la dirección anycast utilizada.

• Realmente Anycast se planteó en la RFC 1546 (1993) como especificación experimental para IPv4 y estaba destinado a ser utilizado para servicios tales como DNS y HTTP.
  

• Una forma de implementar el Anycast es usando el método llamado "Dirección Unicast Compartida", que consiste en asignar direcciones unicast “normales” a múltiples interfaces. Esto es lo que se usa, por ejemplo, en los servidores DNS raíz en Internet.
  

• Dentro de una red donde un grupo de routers puede proporcionar acceso a un dominio de enrutamiento común, se puede asignar una dirección única a todos los routers y cuando un cliente envía un paquete a esta dirección, será enviado al siguiente router disponible.

• Esto se utiliza en 6to4 (RFC 3068) y en Mobile IPv6.

• También hay que ser conscientes de que al utilizar direcciones anycast, el emisor no tiene control sobre cuál será la interfaz a la que se entregará el paquete, ya que esta decisión se toma sobre el nivel del protocolo de enrutamiento.

• Debido a esto pueden darse errores si un emisor envía varios paquetes a una dirección anycast y los paquetes llegan a diferentes destinos. Lo mismo ocurre si hay que establecer un diálogo con una serie de peticiones y respuestas o si hay que fragmentar el paquete.

• Como extensión a lo explicado, y ya en IPv6, la dirección anycast es una dirección que se asigna a más de una interfaz (normalmente pertenecientes a distintos nodos).

• Se sigue manteniendo que un paquete enviado a una dirección anycast es enrutado a la interfaz más cercana con esa dirección anycast.
  La distancia es medida por los protocolos de enrutado.
  

• Las direcciones anycast están dentro del espacio de las direcciones unicast, por lo que, sintacticamente, no se puede distinguir una dirección anycast de una unicast.

• Cuando se convierte una dirección unicast en dirección anycast, asignando la dirección unicast a más de una interfaz, los nodos que han recibido la dirección deben ser configurados de modo que reconozcan la dirección anycast.

• A modo de ejemplo, se muestra el formato de la "dirección anycast del router de la subred" (subnet-router anycast address), que está predefinido y tiene el aspecto indicado en la siguiente figura:

5.3. Direcciones Multicast

Una dirección de multidifusión IPv6 es un identificador para un grupo de interfaces  (típicamente en diferentes nodos). Una interfaz puede pertenecer a cualquier número de grupos de multidifusión. Las direcciones de multidifusión tienen el siguiente  formato:

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

•     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
•     En la siguiente figura se muestra el formato de las direcciones multicast:

5.4. Asignación IPv6 Globales

Al igual que con IPv4, la configuración de direcciones estáticas en clientes no se extiende a entornos más
grandes. Por este motivo, la mayoría de los administradores de red en una red IPv6 habilitan la asignación
dinámica de direcciones IPv6.
Los dispositivos pueden obtener automáticamente una dirección IPv6 unicast global de dos maneras:

• Configuración automática de dirección sin estado (SLAAC)
• DHCPv6

Veamos cada uno de ellos.

SLAAC :Configuración automática de dirección sin estado

La configuración automática de dirección sin estado (SLAAC) es un método que permite que un dispositivo obtenga su prefijo e información de la dirección de gateway predeterminado de un router IPv6 sin utilizar un servidor de DHCPv6.

Mediante SLAAC, los dispositivos dependen de los mensajes de :

• anuncio de router (RA) de ICMPv6 del router local para obtener la información necesaria.

Los routers IPv6 envían mensajes de anuncio de router (RA) de ICMPv6 a todos los dispositivos en la red con IPv6 habilitado de forma periódica. De manera predeterminada, los routers Cisco envían mensajes de RA cada 200 segundos a la dirección IPv6 de grupo multicast de todos los nodos.

Los dispositivos IPv6 en la red no tienen que esperar estos mensajes periódicos de RA. Un dispositivo puede enviar un mensaje de solicitud de router (RS) utilizando la dirección IPv6 de grupo multicast de todos los routers. Cuando un router IPv6 recibe un mensaje de RS, responde inmediatamente con un anuncio de router.

Si bien es posible configurar una interfaz en un router con una dirección IPv6, esto no lo convierte en un “router IPv6”. Un router IPv6 es un router que presenta las siguientes características:

• Reenvía paquetes IPv6 entre redes.
• Puede configurarse con rutas estáticas IPv6 o con un protocolo de enrutamiento dinámico IPv6.
• Envía mensajes RA ICMPv6.

El mensaje de RA de ICMPv6 contiene el prefijo, la duración de prefijo y otra información para el dispositivo
IPv6. El mensaje de RA también informa al dispositivo IPv6 cómo obtener la información de direccionamiento.

El mensaje de RA puede contener una de las siguientes tres opciones, como se muestra en la figura

Observación:

• RA: Anuncio de Router.
• RS: Solicitud de Router.

5.5. Identificador de Interfaz de Red

EUI-64

• MAC-48
• EUI-48
• EUI-6

Que se diseñan para ser globalmente únicos. Un equipo en la red se puede identificar mediante sus direcciones MAC e IP.

Las direcciones MAC son únicas a nivel mundial, puesto que son escritas directamente, en forma binaria, en el hardware en su momento de fabricación. Debido a esto, las direcciones MAC son a veces llamadas burned-in addresses, en inglés.

Todas las direcciones que utilizan los prefijos comprendidos entre 001 y 111 deben utilizar también un identificador de interfaz de 64 bits que está derivado de la dirección EUI-64.

La dirección EUI-64 de 64 bits fue definida por el Instituto de ingeniería eléctrica y electrónica (IEEE, Institute of Electrical and Electronic Engineers). Las direcciones EUI-64 se asignan a una tarjeta adaptadora de red o se derivan de direcciones IEEE 802.

En este documento se trata la derivación de los identificadores de interfaz de IPv6 según RFC 2373. Para tratar cuestiones relativas a la privacidad, se describe una derivación alternativa del identificador de interfaz de IPv6 que cambia con el tiempo en el borrador para Internet titulado "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (Extensiones de privacidad para la configuración automática de direcciones sin estado en IPv6).

Uno de los beneficios clave de IPv6 sobre IPv4 es su capacidad para abordar interfaz automática. Al implementar el formato de la IEEE de 64 bits extendido Identificador Único (EUI-64), un host puede asignar automáticamente sí mismo un identificador de interfaz IPv6 de 64 bits única sin necesidad de configuración manual o DHCP. Esto se logra en las interfaces Ethernet haciendo referencia a la dirección de 48 bits ya MAC única, y reformatear ese valor para que coincida con la especificación EUI-64.

RFC 2373 dicta el proceso de conversión, que se puede describir como que tiene dos pasos.

El primer paso es convertir la dirección MAC de 48 bits a un valor de 64 bits. Para ello, partimos de la dirección MAC en sus dos mitades de 24 bits: el punto de vista organizativo Unique Identifier (OUI) y la parte específica del NIC. Luego se inserta el 0xFFFE valor hexadecimal de 16 bits entre estas dos mitades para formar una dirección de 64 bits.

Dirección MAC EUI de 48 bits + 0xFFFE 16bits = 64 bits !

Figura 1: Proceso EUI-64

¿Por 0xFFFE?

Como se explica en las Directrices de la IEEE para EUI-64 autoridad de registro, este es un valor reservado que los fabricantes de equipos no pueden incluir en EUI-64 asignaciones de direcciones "reales". En otras palabras, cualquier dirección EUI-64 que tiene 0xFFFE inmediatamente después de su porción OUI puede ser reconocido por haber sido generado a partir de una dirección EUI-48 (conocida como MAC).
El segundo paso es invertir la bandera universales / local (U / L) (bit 7) en la porción OUI de la dirección.

OUI: Identificador único organizacional.

Globalmente direcciones únicas asignadas por el IEEE tienen originalmente este bit puesto a cero, lo que indica la singularidad mundial. Del mismo modo, direcciones creadas a nivel local, tales como los utilizados para las interfaces virtuales o una EUI-48,  configurada manualmente por un administrador, tendrán este bit puesto a uno.

El bit U / L se invierte cuando se utiliza una dirección EUI-64 como una interfaz ID IPv6.

En el formato EUI-64 modificado resultante, el bit "u" se establece en uno (1) para indicar alcance universal, y se establece en cero (0) para indicar  ámbito local.

Figura 2: Cambio de Bit.

Con esto tenemos 64 bits que sumados a los 64 bits que corresponden a la parte de Red de IPV6 forman los 128 bits de Direccionamiento de IPV6.

¿Por que se invierte el 7mo bit? . La justificación que se da en RFC4291 indica que esto tiene que ver con el caso que NO hay MAC por ejemplo para enlaces sobre vínculos seriales.

Veamos en un solo dibujo como es el proceso completo.

Veamos como se ve esto en una PC con Windows haciendo ipconfig /all

En la figura previa se pueden observar:

1) Reglas de simplificación de IPv6.

2) El agregado de FFFE entre medio de los 6 Hextetos de la MAC para EUI-64.

3) La inversión del 7mo bit para generar la ID de interfaz en IPV6 con EUI-64.

A modo de comentario, este procedimiento de asignación o creación de una dirección IEEE EUI-64, se usa en otros ambitos de manera similar.
Por ejemplo, en Sensores Inalámbricos de una red de Area Personal (WPAN)  sin posibiliad de correr IPv6 uitilizan un estandar conocido como 6LoWPAN, en este estandar los primeros 24 bits de la dirección de capa de enlace lógico se forman de la manera mencionada dejando algunos bits para casos especiales.

Figura 3: EUI-64 en 6LoWPN

En el caso de 6LoWPAN, los bits L se usan para diferenciar de dirección Local o Universal al igual que lo visto para IPV6.. y el M para Multicast.
Para el caso de 6LoWPAN, los 40 bits que se agregan son establecidos por el fabricante para cada dispositivo como una especie de nro. de serie, en este caso a diferencia de la implementación para IPV6/Ethernet no se precisa incluir 0xFFFE.
A modo de referencia el precio de los 24 bit de OUI eran de 1650u$ en 2009, esto sería el precio de los primeros 24 bits que corresponde a la organización.

Windows: ID de interfaz generadas aleatoriamente

Según el sistema operativo, un dispositivo puede utilizar una ID de interfaz generada aleatoriamente en lugar de utilizar la dirección MAC y el proceso EUI-64. 

Por ejemplo, comenzando con Windows Vista, Windows utiliza una ID de interfaz generada aleatoriamente en lugar de una ID de interfaz creada mediante EUI-64. Windows XP y sistemas operativos Windows anteriores utilizaban EUI-64.

La configuración automática de direcciones IPv6 en Windows 7/8/10 no se utiliza de la forma estándar, a partir de la dirección MAC en formato EUI-64, Microsoft ha decidido asignar direcciones temporales mediante la generación aleatoria. Esto decisión puede convertirse en una pesadilla para los administradores, y resulta bastante engorroso al asignar servidores de DNS.

Podemos cambiar este comportamiento con los siguientes comandos, deberán ser ejecutados en una ventana de consola en modo administrador:

netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

También en alguna documentación se indica que se puede  cambiar para que utilice el proceso EUI-64  con

netsh interface ipv6 set global randomizeidentifiers=disabled

ipconfig /renew6

¿Y despues?

Después de que se establece una ID de interfaz, ya sea mediante el proceso EUI-64 o mediante la generación aleatoria, se puede combinar con un prefijo IPv6 para crear una dirección unicast global o una dirección link-local.

• Dirección unicast global: al utilizar SLAAC, el dispositivo recibe su prefijo del mensaje de RA de ICMPv6 y lo combina con la ID de interfaz.
• Dirección link-local: los prefijos link-local comienzan con FE80::/10. Los dispositivos suelen utilizar FE80::/64 como prefijo o duración de prefijo, seguido de la ID de interfaz.

• Los hosts utilizan la dirección link-local del router local para obtener la dirección IPv6 de gateway predeterminado.
• Los routers intercambian mensajes de protocolo de enrutamiento dinámico mediante direcciones link-local.
• Las tablas de enrutamiento de los routers utilizan la dirección link-local para identificar el router del siguiente salto al reenviar paquetes IPv6.

Las direcciones link-local se pueden establecer dinámicamente o se pueden configurar de forma manual como direcciones linklocal estáticas.

• Dirección link-local asignada dinámicamente
• La dirección link-local se crea dinámicamente mediante el prefijo FE80::/10 y la ID de interfaz.

De manera predeterminada, los routers en los que se utiliza Cisco IOS utilizan EUI-64 para generar la ID de interfaz para todas las direcciones link-local en las interfaces IPv6. Para las interfaces seriales, el router utiliza la dirección MAC de una interfaz Ethernet. Recuerde que una dirección link-local debe ser única solo en ese enlace o red. Sin embargo, una desventaja de utilizar direcciones link-local asignadas dinámicamente es su longitud, que dificulta identificar y recordar las direcciones asignadas.

Figura 4:ID gen. aleatoriamente

5.6. NO ARP en IPv6

6. 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.

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

6.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.

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

1. Entre 2 routers.
2. Entre un host y un router.
3. Entre 2 hosts.

6.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.

6.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)

6.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 interes dejo el link de la fuente.

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

7. 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).

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.

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:

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

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

8. ping6

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)

9. Neighbor Discovery ND

• Mensaje de Router (  Solicitud y Anuncio )

• Mensaje de Dispositivo ( Solicitud y Anuncio )

• Resolución de Direcciones: parecido de ARP IPv4, pero usa ICMPv6
• Detección de inaccesibilidad de vecinos.  Esta función, que no existe en IPv4, permite eliminar de las tablas de configuración de un equipo, los vecinos que se han vuelto inaccesible.
  
• Configuración. La configuración automática de los dispositivos es uno de los principales atractivos de IPv6.
  • Descubrimiento de enrutadores
  • Descubrimiento de prefijos.
  • Detección de direcciones duplicadas.
  • Descubrimiento de parámetros
• Indicación de redirección: Este mensaje se utiliza cuando un enrutador conoce una trayectoria mejor (medida en número de saltos) para alcanzar un destino.
  

9.1. RS-RA

Origen Routers

Mensaje RA:

Los mensajes RA son enviados por routers habilitados para IPv6.

Este mensaje es emitido periódicamente por los routers:

• cada 200 segundos para proporcionar información de direccionamiento a los hosts habilitados para IPv6 
• o bien, en respuesta a un mensaje de solicitud de enrutador generado por un dispositivo. 

El campo dirección

• origen contiene la dirección de enlace local del router
• destino contiene la dirección del dispositivo que generó la solicitud, o la dirección de todas las estaciones (ff02::01).

también el mensaje puede transportar las siguientes opciones:

•     MTU,
•     información sobre el prefijo (uno o varios).

Configuración Automática.

Tradicionalmente, la configuración de una interfaz de red de una máquina se hacía manualmente. 

Esto suele ser un trabajo lento y propenso a errores. Con IPv6, se automatiza el proceso de configuración y se introducen, al mismo tiempo, mecanismos de funcionamiento inmediato (plug and play) a la interfaz de red. 

La configuración automática significa que un dispositivo obtendrá toda la información necesaria para su conexión a una red local IP sin ninguna intervención humana.

La configuración automática o auto-configuración busca:

1. La adquisición de una dirección cuando un dispositivo está conectado a una red por primera vez
2. la posibilidad de asignar otros prefijos, o de renumerar un dispositivo.

En detalle este proceso de configuración automática de direcciones IPv6 permite:

• la creación de una dirección local al enlace
• la agregación a grupos multicast solicitados
• la verificación de la unicidad de la dirección local al enlace
•  la creación de direcciones unicast global.

El algoritmo para el proceso de configuración automática de direcciones se desglosa de la siguiente manera:

1 Creación de Enlace Local.

Durante la inicialización de la interfaz, el dispositivo construye un identificador de interfaz que debe ser único en el enlace. Este identificador se utiliza la dirección de EUI-64. 

El principio básico para crear la direcciónIPv6 consiste en unir un prefijo con el identificador de la EUI-64. 

La dirección local al enlace se crea tomando el prefijo de Enlace_local (FE80::/64).

2 Unicidad

La dirección creada de esa manera, todavía no puede ser utilizada; tiene un estado temporal pues el dispositivo debe comprobar la exclusividad de esta dirección en el enlace mediante el procedimiento de detección de direcciones duplicadas. Para ello envían mensajes con del tipo NA y NS.

Si se encuentra que la dirección local al enlace no es única, se suspende la autoconfiguración y será necesario proceder a una configuración manual.

Una vez que se ha asegurado la unicidad de la dirección local al enlace, ésta se considera una dirección válida para la interfaz, con lo que termina la prima fase del proceso de auto-configuración.

Para comprobar la exclusividad de direcciones locales al enlace o de direcciones unicast, los dispositivos deben ejecutar un algoritmo de detección de direcciones duplicadas (DAD) antes poder utilizarlas. El algoritmo usa los mensajes ICMPv6 solicitud de un vecino NS  y anuncio de un vecino NA.

Así se presentan tres casos:

1. Se recibe un mensaje de anuncio de un vecino: Significa que la dirección provisional está siendo utilizada como válida por otro dispositivo, por lo que ésta no es única y no puede ser retenida por el dispositivo. 🙄.
   
2. Se recibe un mensaje de solicitud de un vecino como parte del algoritmo DAD. La dirección provisional también es provisional para otra máquina. En este caso, la dirección provisional no puede ser utilizada por ninguna de ellas.🙄
3. No se recibe ningún mensaje durante un segundo (valor por omisión). La dirección provisional es única, por lo que su estado pasa de provisional a válida y se le asigna a la interfaz. 😀 ( el escenario deseado)
   

9.2. NS-NA

Origen Dispositivos

Mensaje NA:

La resolución de dirección se utiliza cuando un dispositivo en la LAN conoce la dirección de unidifusión IPv6 de un destino pero no conoce su dirección MAC Ethernet. 

Este mensaje se emite en respuesta a una solicitud, aunque también puede ser emitido de forma espontánea para propagar la información de cambio de dirección física, o del estado de "enrutador". Para el caso de la determinación de la dirección física, es equivalente a la respuesta ARP en IPv4. 

Para determinar la dirección MAC para el destino, el dispositivo enviará un mensaje NS a la dirección de nodo solicitada. El mensaje incluirá la dirección IPv6 conocida (dirigida). El dispositivo que tiene la dirección IPv6 objetivo responderá con un mensaje de NA que contiene su dirección MAC Ethernet, con esto reemplazamos lo que hacía ARP.

Resumiendo , las estaciones envían un Neighbor Advertisement con:

•     MAC de la estación
•     IPv6 de la estación
•     otros datos.

Toda la información de los Neighbor Advertisements va a la Neighbor Table que es algo parecido a la Tabla ARP de IPv4. La Neighbor Table también hay que refrescarla de vez en cuando, así que para ello se envían unos Neighbor Solicitation, que hace la función del ARP Request

Fuente::

https://ccnadesdecero.es/mensajes-icmp/

10. Ejemplo de Cálculo de Red.

Consigna:

Supongamos que el Internet Servive Provide 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

• La IPv6 Unicast Global para una Inteface 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)
  

11. Ejempo de reglas de Simplificación

Reglas de Simplificación