3 ms·

If I'm 192.168.129.10 and I want to resolve who 192.168.129.17 is, I make an ARP with the destination as ff:ff:ff:ff:ff:ff. This is a placeholder L2 destination

If I'm 192.168.129.10 and I want to resolve who 192.168.129.17 is, I make an ARP with the destination as ff:ff:ff:ff:ff:ff. This is a placeholder L2 destination which just means "everyone". I likely need to do something completely different when not on Ethernet (which is surprisingly common when you get beyond PCs on a LAN) and that may or may not involve ARP but we'll stick with ARP on Ethernet for now. If I'm 2600::10 and I want to resolve who 2600::17 is, the IPv6 destination for the ND packet is set to FF02::1:FF00:17. This is a union of the multicast range with part of the destination address (so the request can almost always only go straight to the 2600::17 node rather than using a placeholder to blast to everyone). If Ethernet is in use, the L2 destination is derived and set to 33:33:FF:00:00:17 by and for the same reasoning. Different addresses will be derived e.g. for 2600::18 If I don't know my address yet (say, for DAD in this example), ARP actually uses a second made up address "0.0.0.0" for the source IP which just means unspecified. In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff. As a bonus, since ND only uses the link local address as the source for ND, DAD for the link local address is the only time the source address can be unknown. DAD for any number of unicast addresses will always have the link local to put as the source, even if they are not in the same subnet in the L2.

cyberax 10d ago
> In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff There is no real difference. All Ethernet packets that have bit 7 set in the first octet are broadcast. A packet to 33:33:FF:00:00:17 will be broadcasted across the LAN. In practice, ND will flood the network just like ARP unless switches are configured to snoop on higher-level protocols (proxy ARP/ND).
- zamadatix 9d ago
  Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:ff:ff:ff:ff:ff? You're correct about fallback replication behavior matching that of broadcast (though that has to do with participating in or snooping IGMP/MLD rather than proxy ARP/ND), I'm just not sure you are considering any implications beyond a single aspect of that one scenario in the above. That bit is the I/G (individual/group) bit, not the broadcast bit. In switches/routers participating in multicast (IGMP/MLD or snooping of), it is used as the hardware key for the L2 multicast replication lookup. In switches/routers not participating in multicast, unique multicast groups still allow a dedicated MAC entry hardware trap to send the packet to the CPU for processing (VRRP, LLDP, STP, NDP, LACP, and more). Because ARP uses ff:ff:ff:ff:ff:ff you either need to use an ACL on the protocol type in the ingress pipeline or trap all broadcasts to the CPU (both are inefficient in their own ways). The same is true of the host NICs, regardless what the network gear is doing, who can filter all ND requests not to their address(es) by have a match on the ND multicast MACs relevant to the device be processed and then a larger deny matcher for 33:33:FF:xx:xx:xx just drop all others. Also, an ff:ff:ff:ff:ff:ff destination can never be eligible for multicast lookup (even if the switch/router is participating in multicast), so even it's still needed even if a given node might treat it similar to ff:ff:ff:ff:ff:ff. But yes, if you ignore all of those other things and are in a network without MLD support it'll all fall back to ARP forwarding behavior with just a less generic placeholder address filling the bits. One of the great failings of IPv6 - its approach can be as inefficient as IPv4 in pathological scenarios.
  - cyberax 9d ago
    > Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:ff:ff:ff:ff:ff? Mostly because of a historic accident. > Because ARP uses ff:ff:ff:ff:ff:ff you either need to use an ACL on the protocol type in the ingress pipeline or trap all broadcasts to the CPU (both are inefficient in their own ways). Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. Some switches do that. And the last time I checked, multicast on most (all?) modern switches is also implemented by punting packets to the CPU.
    - zamadatix 9d ago
      > Mostly because of a historic accident. This is where assumption fails, in the original formulation it was even called the multicast bit (instead of the I/G bit) and broadcast was considered a special subset of the multicast use case. Quite the opposite of how you have framed things as an accident of having so many broadcast addresses. (pdf warning) https://archive.computerhistory.org/resources/text/DEC/ethernet/dec_intel_xerox.ethernet.the_ethernet_a_local_area_network.1980.102630389.pdf https://archive.computerhistory.org/resources/text/DEC/ether... ironically, this is > Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. ARP broadcast suppression is definitely a thing but it requires more than just snoop, you still need some form of replication of the information to the other switches in the network and you need the actual suppression+generation functionality (ARP snoop alone just lets an L2 switch build an ARP table, it doesn't define what to do with it). In the best case this is itself done via multicast, in a middle case it's thrown into BGP or similar and distributed that way (if all of your nodes are routers), and in the worst case it falls back to broadcast across the network for anything not known on a local port. ARP broadcast suppression is also harder than with the multicast address for the reason above. Snooping also does nothing for the NICs connected to "basic" L2 switches not doing ARP broadcast suppression while the multicast MAC still does (even when not actually forwarded via multicast).

cyberax 10d ago

> In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff There is no real difference. All Ethernet packets that have bit 7 set in the first octet are broadcast. A packet to 33:33:FF:00:00:17 will be broadcasted across the LAN. In practice, ND will flood the network just like ARP unless switches are configured to snoop on higher-level protocols (proxy ARP/ND).

zamadatix 9d ago
Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:ff:ff:ff:ff:ff? You're correct about fallback replication behavior matching that of broadcast (though that has to do with participating in or snooping IGMP/MLD rather than proxy ARP/ND), I'm just not sure you are considering any implications beyond a single aspect of that one scenario in the above. That bit is the I/G (individual/group) bit, not the broadcast bit. In switches/routers participating in multicast (IGMP/MLD or snooping of), it is used as the hardware key for the L2 multicast replication lookup. In switches/routers not participating in multicast, unique multicast groups still allow a dedicated MAC entry hardware trap to send the packet to the CPU for processing (VRRP, LLDP, STP, NDP, LACP, and more). Because ARP uses ff:ff:ff:ff:ff:ff you either need to use an ACL on the protocol type in the ingress pipeline or trap all broadcasts to the CPU (both are inefficient in their own ways). The same is true of the host NICs, regardless what the network gear is doing, who can filter all ND requests not to their address(es) by have a match on the ND multicast MACs relevant to the device be processed and then a larger deny matcher for 33:33:FF:xx:xx:xx just drop all others. Also, an ff:ff:ff:ff:ff:ff destination can never be eligible for multicast lookup (even if the switch/router is participating in multicast), so even it's still needed even if a given node might treat it similar to ff:ff:ff:ff:ff:ff. But yes, if you ignore all of those other things and are in a network without MLD support it'll all fall back to ARP forwarding behavior with just a less generic placeholder address filling the bits. One of the great failings of IPv6 - its approach can be as inefficient as IPv4 in pathological scenarios.
- cyberax 9d ago
  > Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:ff:ff:ff:ff:ff? Mostly because of a historic accident. > Because ARP uses ff:ff:ff:ff:ff:ff you either need to use an ACL on the protocol type in the ingress pipeline or trap all broadcasts to the CPU (both are inefficient in their own ways). Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. Some switches do that. And the last time I checked, multicast on most (all?) modern switches is also implemented by punting packets to the CPU.
  - zamadatix 9d ago
    > Mostly because of a historic accident. This is where assumption fails, in the original formulation it was even called the multicast bit (instead of the I/G bit) and broadcast was considered a special subset of the multicast use case. Quite the opposite of how you have framed things as an accident of having so many broadcast addresses. (pdf warning) https://archive.computerhistory.org/resources/text/DEC/ethernet/dec_intel_xerox.ethernet.the_ethernet_a_local_area_network.1980.102630389.pdf https://archive.computerhistory.org/resources/text/DEC/ether... ironically, this is > Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. ARP broadcast suppression is definitely a thing but it requires more than just snoop, you still need some form of replication of the information to the other switches in the network and you need the actual suppression+generation functionality (ARP snoop alone just lets an L2 switch build an ARP table, it doesn't define what to do with it). In the best case this is itself done via multicast, in a middle case it's thrown into BGP or similar and distributed that way (if all of your nodes are routers), and in the worst case it falls back to broadcast across the network for anything not known on a local port. ARP broadcast suppression is also harder than with the multicast address for the reason above. Snooping also does nothing for the NICs connected to "basic" L2 switches not doing ARP broadcast suppression while the multicast MAC still does (even when not actually forwarded via multicast).