3 ms·

Sticking L2 into L3 means that L3 needs the ability to communicate with nodes with as-yet-unknown L2 addresses and that L3 nodes that don’t have an L3 address y

by amluto 16d ago

Sticking L2 into L3 means that L3 needs the ability to communicate with nodes with as-yet-unknown L2 addresses and that L3 nodes that don’t have an L3 address yet need to be able to transmit L3 packets. Both of these are quite messy, and APR completely avoids these problems. (I am not, however, defending DHCPv4 - that has some of the same problem.)

zamadatix 16d ago
ARP does not avoid this problem at all, it broadcasts until enough L2 information is exchanged to unicast (which usually happens to also be the point the L3 information is resolved). This is the same broadcast-then-unicast process ND uses, except ND can also start as a multicast forward if MLD is supported (naturally falling back to broadcast on the switch if not).
- amluto 16d ago
  You’re misunderstanding my point. ARP is a protocol that makes perfect sense even when spoken by hosts that only know their own MAC addresses and do not yet know their IPv4 addresses. IPv6 ND is IPv6 except it has the weird edge case in that it is spoken between hosts that may not know their own IPv6 addresses. So you end up with delights like the “unspecified address) built into IPv6.
  - zamadatix 15d ago
    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 15d 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 15d 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.
        15d ago

by amluto 16d ago

zamadatix 16d ago

ARP does not avoid this problem at all, it broadcasts until enough L2 information is exchanged to unicast (which usually happens to also be the point the L3 information is resolved). This is the same broadcast-then-unicast process ND uses, except ND can also start as a multicast forward if MLD is supported (naturally falling back to broadcast on the switch if not).

amluto 16d ago
You’re misunderstanding my point. ARP is a protocol that makes perfect sense even when spoken by hosts that only know their own MAC addresses and do not yet know their IPv4 addresses. IPv6 ND is IPv6 except it has the weird edge case in that it is spoken between hosts that may not know their own IPv6 addresses. So you end up with delights like the “unspecified address) built into IPv6.
- zamadatix 15d ago
  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 15d 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 15d 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.
      - 15d ago