Почему запрос соседей IPv6 использует многоадресную рассылку вместо одноадресной?

Почему запрос соседей IPv6 использует многоадресную рассылку вместо одноадресной?

Я работаю на Linux и хочу пинговать fe80::1234:56ff:fe12:3456%eth0, который подключен к тому же коммутатору Ethernet, что и мой eth0интерфейс. Я еще не общался с fe80::1234:56ff:fe12:3456, поэтому его MAC-адрес не кэширован (его нет в ip neigh list). Когда я запускаю

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

Я отправляю

  • Пакет запроса соседа ICMP внутри
  • IPv6-датаграмма с многоадресным адресом назначения ff02::1:ff12:3456внутри
  • Кадр Ethernet с многоадресным адресом назначения 33:33:ff:12:34:56.

Я понимаю, что это ff02::1:ff12:3456составлено из нижних 24 бит MAC-адреса, и узлы, разделяющие те же биты, все слушают этот адрес многоадресной рассылки. Но почему он указан именно так? Почему бы просто не отправить пакет ICMP на целевой адрес IPv6 напрямую, позволив многоадресному MAC-адресу позаботиться о его распространении среди возможных кандидатов? Вот так:

  • Пакет запроса соседа ICMP внутри
  • IPv6-датаграмма с индивидуальным адресом назначения fe80::1234:56ff:fe12:3456внутри
  • Кадр Ethernet с многоадресным адресом назначения 33:33:ff:12:34:56.

решение1

Ethernet, хотя и распространен повсеместно, не является единственной технологией второго уровня.

Прокручиваем «Пакеты IPv6 перешли»RFCраскроет различные слои связей, включаяBluetooth с низким энергопотреблением Персональные сети ITU-T G.9959,оптоволоконный канал. Также устаревшие альтернативы, такие как Token Ring или FDDI.

Уровни связи, реализующие многоадресную рассылку, сопоставляют многоадресные адреса IPv6 со своими реализациями. Те, которые не работают с этим. Возможно, соединения точка-точка позволяют маршрутизатору отслеживать многоадресных слушателей. Или, возможно, реализация широковещательной рассылки, хотя отправка на все узлы, как ARP, не идеальна.

Открытие соседейв стеке IP имеет преимущество последовательной абстракции и повторного использования кода. Целевой пакет IP может быть создан для получения адреса канального уровня. Включая невообразимое на момент написания кода уровня 3 оборудование.

Смотрите также: Зачем вам нужен запрос соседей IPv6 для получения MAC-адреса?

решение2

Я думаю, что ответчики не поняли ваш вопрос :-). У меня тоже есть этот вопрос, и я думаю, что, как Стефан ван ден Аккер (автор вопроса здесь -https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-content-ndp-neighbor-solicitation) сказал, что это может решить проблему нежелательной маршрутизации:

(Одна из проблем, которая, как мне кажется, может возникнуть при таком подходе, заключается в том, что маршрутизаторы могут направить мой пакет за пределы канала, когда я запрашиваю глобальный адрес одноадресной рассылки устройства, которое не находится на том же канале, что является нежелательным поведением.)

А также для единообразия (многоадресная рассылка IPv6 преобразуется в многоадресную рассылку Ethernet, и исключение из этого правила для запроса соседей нарушит единообразие).

У меня нет других идей, кроме указанных выше, потому что, конечно, сетевой уровень ядра ОС может сконструировать любой нужный ему пакет. А также пакет с multicast mac адресом и unicast ipv6 адресом.

Связанный контент