IPv6 2024 v1

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 (= 2³² ).

¿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:

• Mala práctica de asignación
• Clases A a IBM, HP, AT&T, etc... Direcciones 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

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 (core)  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), sería el segundo anillo.

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, tercer anillo 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.

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

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.

 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.

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.

• 0:0:0:0:0:0:13.1.68.3
• 0:0:0:0:0:FFFF:129.144.52.38

• ::13.1.68.3
• ::FFFF:129.144.52.38

Nota sobre los dos puntos (:) :

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/

Nota sobre % :

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). En un Mikrotik esto es necesario si se desea forzar la conexión a través de una interfaz específica.

En la imagen se refiere a la interface 2.

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)
  

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

El ámbito de 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).

Sistemas Autónomos.

AS 263235 U.Na.M.

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.

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.

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 IP extendido (solo Informativo)

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?

9.4. Interface de red

Identificador de Interfase.

1) EUI-64

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:

Nota sobre el bit u (Informativo):

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.
   

1. Configuración automática de direcciones.
2. Descubrimiento de vecinos o cuando no hay enrutadores presentes.

Red AD HOC o peer-to-peer.

1. crear un Servidor de DHCP
2. rangos de IPs
3. un mecanismo para que se pongan de acuerdo cual de los dos va a ser servidor y cual cliente
4. finalmente se puedan comunicar en capa 3, 

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)

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 se enrutan Internet .
  
• 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 (informativo):

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 (informativo)

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 (dos protocolos IPv4 e IPv6) 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.

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

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.

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

13.1. Direcciones usadas en ND

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

13.2. Mensajes RS y RA de ND

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.

13.3. Mensajes NS y NA de ND

a) Resolución de direcciones:

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

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:

Paso 1) Mensaje NS

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

Paso 3) Mensaje NA

Paso 4) Router procesa lo que recibe.

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.

1. Prefijo de Red.
2. Longitud del Prefijo de red.
3. Dirección del Gateway.
4. Direcciones de Servidores DNS.
5. MAC de Gateway.
   

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:

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:

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

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.

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

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.

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.

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.

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.

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

• 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

22. Preguntas y respuestas

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