4 ms·

> Are you a bot? Beep boop :). No, at least not last I checked. I'm just a guy who's day job was developing a NOS which targets both ASICs and a custom softwar

> Are you a bot? Beep boop :). No, at least not last I checked. I'm just a guy who's day job was developing a NOS which targets both ASICs and a custom software-based forwarding pipelines at one of the main enterprise network vendors. Nowadays I'm PLM for it but kinda miss getting to spend years working with every single bit of these kinds of protocols. > "Layering violation" has a pretty clear meaning in CS. It means that a layer needs information from an upper layer for the system to work Maybe you're used to layering in areas of CS outside of networking? E.g. page 476 of TCP IP Illustrated by Fall and Stevens gives an example in the opposite direction than what you just said: The careful reader will note that this causes a so-called layering violation. That is, the UDP protocol (transport layer) is directly processing bits “owned” by IP (network layer). That said, you're correct NAT is still also another network layering violation driven by IPv4's limitations. > The details of SLAAC that are driven by 64-bit MACs of the Ethernet layer. MACs of the Ethernet layer are 48 bits. > They make it impossible to use masks larger than 64 bits. The largest installed base of devices (Android) does NOT support DHCP, which is the only non-manual way to configure such addresses. Android does not use the MAC address derivation mode of SLAAC, it uses randomized addresses mode of SLAAC for privacy. There are several such standardized modes for SLAAC which are not based on the link layer identifier. This should follow because Android's most common IPv6 interface is the cellular radio which does not even have an Ethernet MAC to derive from. > And? What is your point? The part you cut off: is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction. This point will only make or not make sense once we agree what a layering violation in networking is, until then there's not really sense trying to debate it.

cyberax 9d ago
> Maybe you're used to layering in areas of CS outside of networking? E.g. page 476 of TCP IP Illustrated by Fall and Stevens gives an example in the opposite direction than what you just said Yes. The interaction of UDP and IP _is_ a layering violation, just like NATs or even VPNs. IP and ARP are not. > MACs of the Ethernet layer are 48 bits. Bluetooth MACs are 64-bit. > Android does not use the MAC address derivation mode of SLAAC, it uses randomized addresses mode of SLAAC for privacy. Yep. So it wastes 64 bits of the address space essentially for no reason. There is literally no advantage of IPv6 ND over stateless IPv4 autoconfiguration, except that stateless IPv4 autoconfiguration doesn't waste half of the address bits. > The part you cut off: is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction. You probably misunderstand what "abstraction" _is_, then.
- zamadatix 9d ago
  > Yes. The interaction of UDP and IP _is_ a layering violation, just like NATs or even VPNs. IP and ARP are not. Are you saying L4<->L3 mixing is a layering violation but L3<->L2 mixing is not or is there a more detailed reason you're trying to give? VPNs are not usually considered a layering violation in networking. They do encapsulate lower layers but they place no expectation protocols in other layers rely on the encapsulated data or vice versa. Again, the key being whether or not there is cross reliance on data between layers in the protocols, not whether or not the bits exist in the packet. > Bluetooth MACs are 64-bit. Sure, but Bluetooth is not Ethernet and work on any form of Ethernet or IP over Bluetooth (or even Bluetooth as an IEEE standard) was not started until several years after the IPv6 standards we're discussing were already finalized. > Yep. So it wastes 64 bits of the address space essentially for no reason. There is literally no advantage of IPv6 ND over stateless IPv4 autoconfiguration, except that stateless IPv4 autoconfiguration doesn't waste half of the address bits. I'd be glad to explain some of the actual reasons why we keep chasing a 64/64 split if you'd care to know. It has nothing to do with an alternate history where embedding MACs was a requirement, it has to do with other reasons which are still relevant today. Keep in mind it's very much supported by IPv6 (and even many networks out there) to use something other than /64s. We just keep choosing to do so and use assignment methods which require so because it makes sense for other reasons more important than how densely populated the host bit portion is in a given subnet. > You probably misunderstand what "abstraction" _is_, then. Always a possibility :), I hope you keep the same possibility open as well.

cyberax 9d ago

> Maybe you're used to layering in areas of CS outside of networking? E.g. page 476 of TCP IP Illustrated by Fall and Stevens gives an example in the opposite direction than what you just said Yes. The interaction of UDP and IP _is_ a layering violation, just like NATs or even VPNs. IP and ARP are not. > MACs of the Ethernet layer are 48 bits. Bluetooth MACs are 64-bit. > Android does not use the MAC address derivation mode of SLAAC, it uses randomized addresses mode of SLAAC for privacy. Yep. So it wastes 64 bits of the address space essentially for no reason. There is literally no advantage of IPv6 ND over stateless IPv4 autoconfiguration, except that stateless IPv4 autoconfiguration doesn't waste half of the address bits. > The part you cut off: is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction. You probably misunderstand what "abstraction" _is_, then.

zamadatix 9d ago
> Yes. The interaction of UDP and IP _is_ a layering violation, just like NATs or even VPNs. IP and ARP are not. Are you saying L4<->L3 mixing is a layering violation but L3<->L2 mixing is not or is there a more detailed reason you're trying to give? VPNs are not usually considered a layering violation in networking. They do encapsulate lower layers but they place no expectation protocols in other layers rely on the encapsulated data or vice versa. Again, the key being whether or not there is cross reliance on data between layers in the protocols, not whether or not the bits exist in the packet. > Bluetooth MACs are 64-bit. Sure, but Bluetooth is not Ethernet and work on any form of Ethernet or IP over Bluetooth (or even Bluetooth as an IEEE standard) was not started until several years after the IPv6 standards we're discussing were already finalized. > Yep. So it wastes 64 bits of the address space essentially for no reason. There is literally no advantage of IPv6 ND over stateless IPv4 autoconfiguration, except that stateless IPv4 autoconfiguration doesn't waste half of the address bits. I'd be glad to explain some of the actual reasons why we keep chasing a 64/64 split if you'd care to know. It has nothing to do with an alternate history where embedding MACs was a requirement, it has to do with other reasons which are still relevant today. Keep in mind it's very much supported by IPv6 (and even many networks out there) to use something other than /64s. We just keep choosing to do so and use assignment methods which require so because it makes sense for other reasons more important than how densely populated the host bit portion is in a given subnet. > You probably misunderstand what "abstraction" _is_, then. Always a possibility :), I hope you keep the same possibility open as well.