3 ms·

> 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 d

by cyberax 18d 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 17d 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.

by cyberax 18d ago

zamadatix 17d 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.