4

I'm on Linux and I want to ping fe80::1234:56ff:fe12:3456%eth0 which is connected to the same Ethernet switch as my eth0 interface. I haven't yet communicated with fe80::1234:56ff:fe12:3456 so I don't have its MAC address cached (it's not in ip neigh list). When I run

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

I send

  • ICMP neighbor solicitation packet inside
  • IPv6 datagram with multicast destination address ff02::1:ff12:3456 inside
  • Ethernet frame with multicast destination address 33:33:ff:12:34:56.

I get that ff02::1:ff12:3456 is constructed from lower 24 bits of MAC address and nodes sharing the same bits all listen on this multicast address. But why is it specified this way? Why not just send the ICMP packet to the destination IPv6 address directly letting the multicast MAC address take care of distributing it to possible candidates? Like this:

  • ICMP neighbor solicitation packet inside
  • IPv6 datagram with unicast destination address fe80::1234:56ff:fe12:3456 inside
  • Ethernet frame with multicast destination address 33:33:ff:12:34:56.
woky
  • 275

2 Answers2

3

Ethernet, while everywhere, is not the only layer 2 technology.

Scrolling through "IPv6 Packets over" RFCs will reveal diverse link layers including Bluetooth low energy ITU-T G.9959 personal area networks, fibre channel. Also obsolete alternatives like Token Ring or FDDI.

Link layers that implement multicast map IPv6 multicast addresses to their implementations. Those that do not work around that. Perhaps point to point links let a router track of multicast listeners. Or perhaps a broadcast implementation, although sending to all nodes like ARP is not ideal.

Neighbor discovery in the IP stack has the advantage of a consistent abstraction and code reuse. A targeted IP packet can be created to get the link layer address. Including over hardware unimagined at the time the layer 3 code was written.

See also: Why do you need IPv6 Neighbor Solicitation to get the MAC address?

John Mahowald
  • 36,071
0

I think repliers didn't understand your question :-). I also have this question and think that, as Stefan van den Akker (author of the question here - https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-containing-ndp-neighbor-solicitation) said, this can solve the unwanted routing problem:

(One problem that I can think of with this approach is that routers may route my packet off the link when I request the global unicast address of a device that is not on the same link, which would be unwanted behavior.)

And also for uniformity (ipv6 multicast converts to ethernet multicast and exception to this rule for neighbor solicitation would break uniformity).

I have no other ideas except noted above, because, of course, the network layer of OS kernel can construct any needed packet they want. And also a packet with multicast mac address and unicast ipv6 address.

Oleg Nemanov
  • 1