¿Por qué la solicitud de vecinos IPv6 utiliza multidifusión en lugar de dirección de unidifusión?

¿Por qué la solicitud de vecinos IPv6 utiliza multidifusión en lugar de dirección de unidifusión?

Estoy en Linux y quiero hacer ping fe80::1234:56ff:fe12:3456%eth0al que está conectado al mismo conmutador Ethernet que mi eth0interfaz. Todavía no me he comunicado, fe80::1234:56ff:fe12:3456así que no tengo su dirección MAC almacenada en caché (no está en ip neigh list). cuando corro

ping fe80::1234:56ff:fe12:3456%eth0

envío

  • Paquete de solicitud de vecino ICMP en el interior
  • Datagrama IPv6 con dirección de destino de multidifusión ff02::1:ff12:3456en su interior
  • Trama Ethernet con dirección de destino de multidifusión 33:33:ff:12:34:56.

Entiendo que ff02::1:ff12:3456está construido a partir de 24 bits inferiores de dirección MAC y los nodos que comparten los mismos bits escuchan en esta dirección de multidifusión. ¿Pero por qué se especifica de esta manera? ¿Por qué no simplemente enviar el paquete ICMP a la dirección IPv6 de destino directamente dejando que la dirección MAC de multidifusión se encargue de distribuirlo a los posibles candidatos? Como esto:

  • Paquete de solicitud de vecino ICMP en el interior
  • Datagrama IPv6 con dirección de destino de unidifusión fe80::1234:56ff:fe12:3456dentro
  • Trama Ethernet con dirección de destino de multidifusión 33:33:ff:12:34:56.

Respuesta1

Ethernet, aunque está en todas partes, no es la única tecnología de capa 2.

Desplazarse por "Paquetes IPv6 terminados"RFCrevelará diversas capas de enlaces que incluyenBluetooth de baja energía Redes de área personal ITU-T G.9959,canal de fibra. También alternativas obsoletas como Token Ring o FDDI.

Las capas de enlace que implementan multidifusión asignan direcciones de multidifusión IPv6 a sus implementaciones. Aquellos que no solucionan eso. Quizás los enlaces punto a punto permitan que un enrutador rastree a los oyentes de multidifusión. O quizás una implementación de transmisión, aunque enviar a todos los nodos como ARP no es lo ideal.

Descubrimiento de vecinosen la pila de IP tiene la ventaja de una abstracción consistente y reutilización de código. Se puede crear un paquete IP específico para obtener la dirección de la capa de enlace. Incluyendo hardware inimaginable en el momento en que se escribió el código de capa 3.

Ver también: ¿Por qué necesita la Solicitud de Vecino IPv6 para obtener la dirección MAC?

Respuesta2

Creo que los que respondieron no entendieron tu pregunta :-). También tengo esta pregunta y creo que, como Stefan van den Akker (autor de la pregunta aquí -https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-containing-ndp-neighbor-solicitation) dijo, esto puede resolver el problema de enrutamiento no deseado:

(Un problema que se me ocurre con este enfoque es que los enrutadores pueden enrutar mi paquete fuera del enlace cuando solicito la dirección de unidifusión global de un dispositivo que no está en el mismo enlace, lo que sería un comportamiento no deseado).

Y también por uniformidad (la multidifusión ipv6 se convierte en multidifusión ethernet y una excepción a esta regla para la solicitud de vecinos rompería la uniformidad).

No tengo otras ideas excepto las mencionadas anteriormente, porque, por supuesto, la capa de red del kernel del sistema operativo puede construir cualquier paquete necesario que desee. Y también un paquete con dirección mac de multidifusión y dirección ipv6 de unidifusión.

información relacionada