¿Por qué necesita la solicitud de vecino IPv6 para obtener la dirección MAC?


12

Soy desarrollador de software y acabo de recibir un libro gratuito sobre IPv6 en Techdays, que estoy leyendo por diversión. Lo regalaron porque es un libro un poco viejo (W2008), por lo que tal vez las cosas sean diferentes para otros sistemas operativos más nuevos, pero no entiendo la necesidad de Neighbor Discovery de obtener la dirección MAC.

Según el libro, cada nodo obtiene automáticamente una dirección IP local de enlace, que se construye a partir de la dirección MAC insertando FF-FEentre los bytes 3 y 4 y volteando el bit U / L, de modo que la IP local de enlace para un se 00-AA-00-3F-2A-1Cconvierte en un nodo con una dirección MAC de FE80::2AA:FF:FE:3F:2A1C.

Para determinar la dirección MAC de la capa de enlace, se envía un mensaje de Solicitud de vecino a la dirección IP local de enlace, que responde con un mensaje que contiene su dirección MAC ... Pero el remitente ya lo sabe, porque el MAC está codificado en el enlace- dirección IP local Por lo tanto, suena como enviar una postal a alguien que solicita su dirección.

Respuestas:


20

Cada nodo genera automáticamente una dirección local de enlace, pero:

  • Es posible que esa dirección no se genere con el formato EUI-64 especificado en RFC 2464 . Las direcciones IPv6 también pueden ser direcciones generadas criptográficamente ( RFC 3972 ), direcciones de privacidad temporales ( RFC 4941 ), o en sistemas operativos modernos, direcciones de privacidad estables ( RFC 7217 ).

  • Una dirección que parece tener una ID de interfaz EUI-64 podría no corresponder con la dirección MAC indicada debido a la configuración explícita de un administrador.

Como no puede simplemente "volver a convertir la dirección" a una dirección MAC, debe enviar una Solicitud de vecino para determinar la dirección MAC.

Hay otras razones por las cuales las Solicitudes de vecinos también son necesarias. Algunos de estos son:

  • Detección de direcciones duplicadas ( RFC 4862 ). Es posible que algún otro host haya reclamado (correcta o incorrectamente) una dirección que un host desea usar.
  • Detección de inalcanzabilidad de vecinos. La falta de respuesta a una solicitud de vecino es un indicador de que el vecino es inalcanzable.

Los libros están muy bien, pero los libros muy desactualizados pueden no ser tan útiles. Incluso IPv6 ha tenido revisiones significativas en los últimos diez años. La mejor fuente de verdad son las RFC relevantes, tanto las originales como las que están marcadas como actualizadas u obsoletas. Los RFC se especifican con suficiente detalle para permitir que se escriban implementaciones conformes. Puede aprender todos los detalles del descubrimiento de vecinos leyendo RFC 4861 .


Gracias por las correcciones; si no se utiliza un formato EUI-64, de hecho, es necesario descubrir el MAC de lo contrario. Pero en realidad, no entiendo las preocupaciones de privacidad con el formato EUI-64 para las direcciones locales de enlace, porque la dirección local de enlace está dentro del enlace y en ese enlace, la dirección MAC tendrá que ser (y puede ser ) conocido de todos modos (por Solicitud de vecinos) para la comunicación Ethernet, por lo que, por malas intenciones, la dirección MAC se puede guardar junto con la dirección de privacidad estable en el enlace local, ¿no es así?
Edwin

@Edwin, SLAAC se usó originalmente para todos los direccionamientos IPv6, no solo las direcciones Link-Local, por lo que se podía rastrear un host. SLAAC es solo un método para asignar direcciones Link-Local. También podrían asignarse manualmente, y eso no le daría la dirección MAC en la dirección Link-Local. Conozco a algunas personas que desean asignar manualmente todas las direcciones, incluido Link Local. Parece mucho trabajo por poco o ningún beneficio, pero los hace felices, y todos los IID de todas las direcciones en una interfaz son iguales, en el orden que prefieren.
Ron Maupin

@Edwin Y, cada host mantendrá una caché de destino (ver RFC 4861), que es análoga a la tabla IPv4 ARP que mantienen los hosts.
Michael Hampton

CGA podría haber sido más simple y más seguro si las direcciones hubieran sido dos veces más grandes. La mitad de las especificaciones son soluciones para tener solo 64 bits en el identificador de interfaz donde idealmente hubieran deseado alrededor de 162 bits. Es algo para recordar siempre que surge la idea de que 128 bits es demasiado.
kasperd

¿Qué considera no estándar sobre ese documento de Microsoft? Para mí, parece que solo resume los RFC a los que se ha vinculado.
Kasperd

9

Entonces, o malinterpretaste o te informaron mal sobre algunas cosas.

Al usar SLAAC, un host puede construir su propio direccionamiento IPv6 usando su dirección MAC, pero muchas personas pensaron que esto era peligroso, ya que proporcionaba demasiada información y permitía rastrear a un host en particular. En base a eso, se desarrollaron extensiones de privacidad y direccionamiento aleatorio, y los sistemas operativos los utilizan para proporcionar privacidad / seguridad. Eso significa que un host puede crear su propio direccionamiento, no basado en su dirección MAC.

Cuando un host necesita descubrir la dirección MAC de un vecino en IPv4, usa ARP. ARP transmite una solicitud, pero IPv6 no tiene difusión. En cambio, cada host debe unirse a un grupo de multidifusión de nodo solicitado. Este grupo se basa en los últimos 24 bits de su dirección IPv6. Dado que las interfaces IPv6 pueden tener cualquier número de direcciones IPv6, un host puede unirse a múltiples grupos de multidifusión de nodo solicitado. Un host IPv6 que busca la dirección MAC de otro host enviará una solicitud de multidifusión al grupo de multidifusión de nodo solicitado de la dirección IPv6 de destino.

Esto proporciona una ventaja sobre IPv4 ARP. Dado que ARP usa una transmisión para solicitudes, interrumpe cada host en el dominio de transmisión de capa 2. Debido a que el grupo de multidifusión de nodo solicitado usa los últimos 24 bits de la dirección IPv6 de destino, la solicitud de multidifusión de ND probablemente solo interrumpirá el host de destino, o posiblemente uno o dos hosts más en el dominio de difusión de capa 2.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.