But I can't find any reference to this now. Does anyone else remember this?
Is this true? Can you interoperate with the Internet by just implementing the spec?
But I can't find any reference to this now. Does anyone else remember this?
Is this true? Can you interoperate with the Internet by just implementing the spec?
The real problem is that every step toward 100% gets progressively harder to find and debug. See e.g. [0] for a middle box that would mangle connections if it received two identical SYN packets, or [1] for a way in which almost all servers anyone currently runs are accidentally resilient to a certain kind of connection-killing packet corruption, but S3 isn't.
[0] https://www.snellman.net/blog/archive/2014-11-11-tcp-is-hard... [1] https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/
As an alternative perspective... while the RFCs are great, it's taken me weeks (maybe months now) to hack together a not-yet-functional TCP/IP stack. I've never dug below the application layer before. I'm still working through it. I cannot even say if the RFCs are sufficient, but I'll take your word.
You can probably get interoperability at least part of the time. You may have deteriorated throughput and more broken connections with some stack and not with others. But you have introduced a new species. If your brand new stack has a tiny bug or new kind of misconfiguration and you start spreading it fast, the hell can break loose and you may ruin the day of many people before they find you and cut you off.
By using this collection of TCP/IP RFCs that grew over the years, it is indeed possible to implement a stack from first principles and have it interoperate with other existing stacks without much trouble. (At least so long as you don't put the same bugs in your test suite as you do in your stack... which you will.)
However, being able to transmit some bytes reliably, and having a high-performance stack that works well in real world conditions are different. You might be able to do the former from RFCs, but the latter absolutely requires a nontrivial amount of tribal knowledge that you have to collect crumb by crumb, and often quite painfully, too.
Smoltcp is somewhere halfway between. It's pretty reliable, but I am sure there is much to be improved in its operation in adverse conditions, with obscure peers, and so on.
I've never implemented the entire stack. Few people have. But from the protocols I've implemented, that's only a slight exaggeration.
As soon as a popular implementation has a bug or decides not to behave according to spec, everyone has to adapt. You can typically use the spec to get 95% of the way to full interoperability.
Also, one of the RFCs has wrong functions for calculating or adjusting checksums. I think there's also some convention on tcp option ordering that may be important but not well documented.
Either way, I would keep a couple other implementations close -- if not to peek at their code ocassionaly, at least to inspect their output.