Yet again working on my network stack implementation, and just..

I do not enjoy that Layer 2 has to care about stuff from Layer 3

Or that Layer 3 and 4 are/can be entangled with each other,

instead of all of them being able to just work independent of every other layer

 WEH

@k4m1 wdym with l2 caring about l3? packet snooping for building ARP/switching tables?

hugs

@domi

That's whole another can of worms,

this complaint was just provoked by remembering that EtherType field in Ethernet frame is used to indicate type of protocol that'll follow x-x

So 0800 for ipv4, 0806 for arp, and so forth

@k4m1 @domi oh god
@alina @k4m1 you kinda don’t have any other way around this problem tho, it needs to be self-descriptive because as far as Ethernet is concerned, the frame can contain anything. if not for this ID field, you’d need to snoop and try to detect what each packet is x.x
@domi @k4m1 @alina it's a pattern that repeats at every layer tbh. You need a dispatch point to select which of the next layer protocols will process the rest of the packet.

Now if you want to talk about ugly layering violations, meet my dishonourable friend IGMP/MLD snooping

@erincandescent @k4m1 @alina the funny thing is that we designed systems to support a multitude of protocols. then we proceeded to only ever (commonly) use three of them (ARP, IPv4, IPv6)

but fear not! we designed IP to support a multitude of protocols too! and then we proceeded to only really use TCP and UDP. For an unwritten reason everything else has to match one of those now :))))

but fear not! we designed TCP/UDP to support a multitude of protocols too!!! and then we proceeded to block every port other than 80, 443 and 53, because everything is HTTP(S) or DNS now

but fear not! we designed^W slapped websockets on top of HTTP because THERE IS NO GOD

@domi @k4m1 @alina if I got to redesign IP with the benefit of hindsight I'd delete the next protocol header and just fuse UDP in. Alas.
@erincandescent @k4m1 @alina UDP has some design problems around packet forwarding. and yes, with the benefit of hindsight we could have larger address space and make NAT never happen. but even from a perspective of a flat network, stateful connections have some operational benefits
@domi @k4m1 @alina eh I'm not sure it needs to be a separate router-visible protocol though

The boxes which need to know about state can be configured with ports

@erincandescent @k4m1 @alina in an imaginary world it probably doesn’t need to be, that’s true. moreover, if you built automatic keepalive (pings) into the network stack itself, you’d solve most of the problems of its async nature, and then you’d truly only need one proto.

unfortunately…

@erincandescent @alina @k4m1 i love networking. it’s one of my favorite things in this world. but the more I think about the state of how everything interworks, the more I come to the painful conclusion that we’re building on top of something that had 40+ years of misuse and bad decisions solidified into a status quo