1

This is a follow up of Why not put unicast address in IPv6 packet containing NDP neighbor solicitation instead of solicited-node multicast address?

The accepted answer makes no sense. It states the reason is that we do not have a function to convert 128 bit IPv6 unicast addresses to 48 bit mac address, while at the same time accepting there exists function

f:128 bit IPv6 unicast address -> 128 bit IPv6 multicast address.
g:128 bit IPv6 multicast address -> 48 bit Mac.

Why can't gof exist?

I also see that the question is updated with this as the answer: The IPv6 solicited-node multicast address is the basis for the multicast MAC address, therefore the destination field in the IPv6 packet needs to be the solicited-node multicast address. But did the protocol designers decide ND should work like this, or is there a technical necessity for ND to work like this?

So yea, is it this way just because ND designers decided that it should be this way without any logical necessity?

1
  • I re-read your question several times before understanding it. You might want to re-phrase it to include a clear description of how IPv6 SN packets are addressed, what your alternative idea is, and then re-state the question, why was the specified way selected over the alternative? Aug 28, 2020 at 13:14

2 Answers 2

1

Without a unicast layer-2 address, neither IPv4 ARP nor IPv6 NDP can use unicast. IPv4 ARP uses broadcast, but broadcast is inefficient and a security risk, so it was eliminated from IPv6. IPv6 makes heavy use of multicast.

At layer-2, NDP uses multicast based on the last 24 bits of the layer-3 address, so, unlike ARP broadcast that interrupts every host on the LAN, multicast NDP will interrupt very few (probably only one) hosts.

IPv6 will automatically subscribe to the solicited node multicast address for every unicast address configured on the interface, so if the interface ID on the interface for every unicast address is the same, it need only subscribe to a single solicited node multicast address.

In all probability, an NDP multicast will only interrupt a single host on the LAN. Contrast that with IPv4 ARP broadcast that interrupts every host on the LAN. Broadcast requires that every host inspect the broadcast to check to see if the broadcast is for it, while multicast can be dropped at the interface, not interrupting the host.


Edit:

While ARP is a separate process from IPv4, NDP is part of IPv6.

ARP uses broadcast that must be sent to all hosts on the LAN. ARP was designed before IPv4 multicast, so it uses broadcast. Broadcast is inefficient and a security risk because all broadcasts must be sent up into the network stack of all hosts for inspection, but modern network interfaces can stop multicast at the interface hardware before it gets sent to the network stack ("Modern Ethernet controllers filter received packets to reduce CPU load, by looking up the hash of a multicast destination address in a table, initialized by software, which controls whether a multicast packet is dropped or fully received.").

IPv6 has eliminated broadcast, and it makes heavy use of multicast. IPv4 multicast would have been ideal for ARP if IPv4 multicast had existed when ARP was defined, but also remember that ARP was bolted on as an afterthought, while NDP was designed into IPv6 from the start.

As a separate process, ARP does not use IP packets, but has its own EtherType and packet format that sends it to a separate process from IP, so ARP does not have an IP packet with a destination IPv4 address. NDP is part of IPv6, so it is an IP packet with a destination IPv6 address. This seems to be the crux of the confusion in the question.

IPv6 not only allows multiple unicast addresses on an interface, it will almost certainly have that. Each unicast address on an interface will subscribe to the solicited node multicast group that corresponds to the IPv6 unicast address. With the original idea of IPv6 that the various unicast addresses configured on an interface will normally have the same interface ID, you would really only have a single solicited node multicast group for the interface because the last 24 bits of every IPv6 unicast address would be the same. That has fallen apart with the default use of random addressing and privacy extensions.

In any case, IPv6, or some other process, must subscribe to a multicast group so that the interface card is configured to allow traffic destined to the corresponding layer-2 multicast group. If IPv6 does not subscribe to the solicited node multicast groups for its unicast IPv6 addresses, then the network interface will drop multicast frames destined for those unsubscribed solicited node multicast groups, and IPv6 will never see the NDP packets.

The destination address as the solicited node multicast group is in a special format, and it will allow IPv6 to send the packet directly to the NDP part of IPv6 that subscribed to that multicast group.

4
  • Hi, I accept the benefit of multicast, the basic question is, 1.) Can L2( ethernet ) dst be a Multicast addr while L3 dst being unicast. 2.) If no, could you provide a reason and rfc stating it. If yes, take a NS packet, change L3( IPv6 ) dst addr of ICMPv6(NS) packet from solicited node mutlicast address to that node's unicast address, will NDP not still work ?, and when I say I mean only device-device communication ( neighbor discovery ), not router detection or anything else. only neighbor discovery, will it work or not. If not, why not? Aug 31, 2020 at 6:38
  • "1.) Can L2( ethernet ) dst be a Multicast addr while L3 dst being unicast." That would take a lot of rigging to do, something custom using raw sockets, but the receivers would still need to subscribe to the layer-3 multicast group or the interface card will not get set properly, and it will drop the frame, as I explained.
    – Ron Maupin
    Aug 31, 2020 at 13:17
  • "2.) If no, could you provide a reason and rfc stating it. If yes, take a NS packet, change L3( IPv6 ) dst addr of ICMPv6(NS) packet from solicited node mutlicast address to that node's unicast address, will NDP not still work ?" That would really complicate things because with the layer-3 multicast group, IPv6 can automatically see it is for NDP and send the packet to that process. With a unicast address, IPv6 would need to dig deeper into the packet to determine that. It would waste resources and slow identification. As it is today, no, it will not work because IPv6 is efficient.
    – Ron Maupin
    Aug 31, 2020 at 13:20
  • "and when I say I mean only device-device communication ( neighbor discovery ), not router detection or anything else. only neighbor discovery, will it work or not. If not, why not?" Routers are hosts, too, and they need "device-device communication ( neighbor discovery )" just as any other host. Remember that NS is really about DAD (duplicate address detection) and neighbor reachability, too.
    – Ron Maupin
    Aug 31, 2020 at 13:23
2

Excellent question!

Having the L3 destination address be an mcast address allows implementation of NDP with less L2-specific code.

Consider in the mid-90s there were more L2 technologies in wide use -- ATM, Frame-Relay, and various metro switching technologies were still commonplace; Ethernet was not yet dominant except for LANs; in fact Ethernet WANs were extremely rare and usually implemented as overlays over the other L2 techs back then.

If you want to send a NS packet you just send an L3 multicast packet and let the same code which does L3-to-L2 address translation for every other IPv6 multicast packet handle the L2 addressing of the NS packet.

If NDP specified unicast L3 destination addresses but multicast (solicited-nodes group) L2 destination, the process for encapsulating an NS packet would be unique to these packet-types, and would increase the amount of L2-specific code, too.

2
  • 1
    So, what you are saying is to have a simpler interface and more independence between the L2 and L3 layers. Aug 29, 2020 at 12:23
  • That's correct! Aug 30, 2020 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.