4 ms·

Im mildly confused as well, there is an even more immediate shortcut that I've certainly implemented before. in arp its not unusual to to just create a ip->mac

Im mildly confused as well, there is an even more immediate shortcut that I've certainly implemented before. in arp its not unusual to to just create a ip->mac binding from the source information in the ethernet header. where this potentially breaks down if we start looking at issues of trust. but its already the case in ND that we trust the endpoint to have executed the state machine to search for duplicates. so what's preventing us from doing the same thing here? maybe just layering concerns?

amluto 11d ago
I’ve always thought that IPv6 has dramatically worse layering than IPv4. In IPv4 over Ethernet, there’s ARP, which layers over plain Ethernet, and IPv4 sits on top of the combination of ARP+Ethernet. In the IPv6 world, neighbor discovery is IPv6, but only sort of, because the participants don’t necessarily have real addresses. So it’s a mess.
- zamadatix 11d ago
  IPv6 link local layers over Ethernet the same way Arp does. Both contain a source/dest MAC which is used for forwarding, both contain the relevant neighbor info. If anything, keeping the protocol's self-discovery messages wrapped in the protocol itself is actually cleaner layering at the cost of complexity (the extra link local signalling addresses).
  - cyberax 11d ago
    It really is not. There's a whole morass with possibly overlapping "on link" networks that nobody can implement correctly on the first try. Then there's this whole pretend "it's not broadcast but multicast" song-and-dance with ND in IPv6. In IPv4/ARP the separation is clean, and no lower protocol details leak into the IP layer. Link-local addresses were also meant to be used for LAN-only apps. Except that it quickly turned out that you can't actually use them reliably because some interfaces (like PPP tunnels) do not _have_ MACs. It's a mess.
    - zamadatix 11d ago
      Morass, mess, broadcast/multicast, etc aside (seems more like complaints of complexity than layering), IPv4+ARP is the textbook example of a layering violation. When you do want to violate, having the L2 info in the L3 packet is still cleaner than L3 info in L2. One is a protocol carrying its own glue in itself, the other is a protocol using different protocols (per L2) to discover the glue the same way it could have itself anyways. It's certainly convenient of course, but that doesn't make it cleaner layering. It also gives a consistent answer for different L2s e.g. cellular links because of this.
      - cyberax 11d ago
        Whut? IPv4 is an example of _correct_ layering. The hardware address is a detail that does not leak into upper layers. It's confined purely to the network layer. In contrast, with IPv6 the whole 64/64 separation is a result of leaking the MAC address into upper protocols. Indeed, MAC was supposed to be a part of the publicly visible IPv6 addresses for hosts!
        Dagger2 11d ago
        Huh? No, the MAC was never a part of the publicly-visible v6 address. I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
        cyberax 11d ago
        > Huh? No, the MAC was never a part of the publicly-visible v6 address. Yes, it was: https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 The 64/64-bit split was in fact a result of (then planned) Bluetooth having 64 bit MACs. Moreover, the initial IPv6 RFCs did not have privacy extensions for SLAAC: https://www.rfc-editor.org/info/rfc2464/#section-4 https://www.rfc-editor.org/info/rfc2464/#section-4 > Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address. It doesn't.
mayhemducks 11d ago
This was my immediate thought as well. Though I have not thought through any of the details, it did occur to me that the information needed would be in the "source" section of the header. I wonder if it is too much work to validate it somehow before using it? I haven't ever done any programming at this layer of the stack, so I'm purely spitballing.
cyberax 11d ago
Ah, one of the recursive WTFs in the IPv6 design. Technically, there's no broadcast in IPv6, so the host is supposed to join the local multicast group and do the neighbor discovery flow to find the "on link" address. And it's not guaranteed that the network is "symmetric". Technically, this is also true for IPv4. You can have a proxy-ARP host impersonating the sender, but since it had never been fully specced, nobody cares about this scenario.

amluto 11d ago

I’ve always thought that IPv6 has dramatically worse layering than IPv4. In IPv4 over Ethernet, there’s ARP, which layers over plain Ethernet, and IPv4 sits on top of the combination of ARP+Ethernet. In the IPv6 world, neighbor discovery is IPv6, but only sort of, because the participants don’t necessarily have real addresses. So it’s a mess.

zamadatix 11d ago
IPv6 link local layers over Ethernet the same way Arp does. Both contain a source/dest MAC which is used for forwarding, both contain the relevant neighbor info. If anything, keeping the protocol's self-discovery messages wrapped in the protocol itself is actually cleaner layering at the cost of complexity (the extra link local signalling addresses).
- cyberax 11d ago
  It really is not. There's a whole morass with possibly overlapping "on link" networks that nobody can implement correctly on the first try. Then there's this whole pretend "it's not broadcast but multicast" song-and-dance with ND in IPv6. In IPv4/ARP the separation is clean, and no lower protocol details leak into the IP layer. Link-local addresses were also meant to be used for LAN-only apps. Except that it quickly turned out that you can't actually use them reliably because some interfaces (like PPP tunnels) do not _have_ MACs. It's a mess.
  - zamadatix 11d ago
    Morass, mess, broadcast/multicast, etc aside (seems more like complaints of complexity than layering), IPv4+ARP is the textbook example of a layering violation. When you do want to violate, having the L2 info in the L3 packet is still cleaner than L3 info in L2. One is a protocol carrying its own glue in itself, the other is a protocol using different protocols (per L2) to discover the glue the same way it could have itself anyways. It's certainly convenient of course, but that doesn't make it cleaner layering. It also gives a consistent answer for different L2s e.g. cellular links because of this.
    - cyberax 11d ago
      Whut? IPv4 is an example of _correct_ layering. The hardware address is a detail that does not leak into upper layers. It's confined purely to the network layer. In contrast, with IPv6 the whole 64/64 separation is a result of leaking the MAC address into upper protocols. Indeed, MAC was supposed to be a part of the publicly visible IPv6 addresses for hosts!
      - Dagger2 11d ago
        Huh? No, the MAC was never a part of the publicly-visible v6 address. I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
        cyberax 11d ago
        > Huh? No, the MAC was never a part of the publicly-visible v6 address. Yes, it was: https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 The 64/64-bit split was in fact a result of (then planned) Bluetooth having 64 bit MACs. Moreover, the initial IPv6 RFCs did not have privacy extensions for SLAAC: https://www.rfc-editor.org/info/rfc2464/#section-4 https://www.rfc-editor.org/info/rfc2464/#section-4 > Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address. It doesn't.

mayhemducks 11d ago

This was my immediate thought as well. Though I have not thought through any of the details, it did occur to me that the information needed would be in the "source" section of the header. I wonder if it is too much work to validate it somehow before using it? I haven't ever done any programming at this layer of the stack, so I'm purely spitballing.

cyberax 11d ago

Ah, one of the recursive WTFs in the IPv6 design. Technically, there's no broadcast in IPv6, so the host is supposed to join the local multicast group and do the neighbor discovery flow to find the "on link" address. And it's not guaranteed that the network is "symmetric". Technically, this is also true for IPv4. You can have a proxy-ARP host impersonating the sender, but since it had never been fully specced, nobody cares about this scenario.