Did all of the Requests for Comments directly affect the design of Unix networks?

Question

I want to know more about Linux must be one of my most enduring sentiments.

But I often find that I learn the most, or perhaps just feel the most satisfied with what I have learned, when I simply crack open the history books.

What's hiding in /etc and /dev that I don't know about? Well, files. Everything is a file.

But what put those files there?

History put them where they are, and history dictated how they were written, yadda yadda yadda.

According to man hosts

   Historical Notes
       RFC 952 gave the original format for the host table, though it has since changed.

       Before the advent of DNS, the host table was the only way of resolving hostnames on the fledgling Internet.  Indeed, this file could
       be created from the official host data base maintained at the Network Information Control Center (NIC), though  local  changes  were
       often  required to bring it up to date regarding unofficial aliases and/or unknown hosts.  The NIC no longer maintains the hosts.txt
       files, though looking around at the time of writing (circa 2000), there are historical hosts.txt files on the  WWW.   I  just  found
       three, from 92, 94, and 95.

Great. So that gives me something to chew on. I want to know how Linux works, and in particular I want to know why Linux networking looks the way it does, so I'll just go read RFC 952.

But, oh, wait... It's really short. And there are hundreds of RFC documents. Hmm...

Before trying to tackle these, I have to know, did all of the Request for Comments (RFC) documents directly impact the design of Unix and Linux? Should I be trying to get my head around all of them, or just a subset?

Answer 1

No, they didn't. Some don't even apply to Unix. When Unix was in its infancy, there were dozens of operating systems out there, and dozens more came after its release. Many of them were on the ARPANet and many of them made it to the Internet. Some RFCs describe global things like the right way to write IPv6 addresses (RFC 4291), how MD5 should be implemented (RFC 1321), or why not to admire pigs flying overhead (RFC 1925). Others are more OS-specific, like Windows Kerberos password change protocols (RFC 3244).

A lot of what you see now are empirical decisions that later became standardised.

If you want to learn about Unix networking, your best bet is probably one of the books about Unix. If you want to learn about why things are the way they are, reading the source code of early Unices is an interesting exercise. But not an easy one. :)

Answer 2

If you want to go back to the history of recent Unix-like systems, you'd better read The Design and Implementation of the 4.4 BSD Operating System. It's old but so are unix concepts. Networking especially was designed as part of the 4.3 BSD OS, which is of course discussed thoroughly in the book. GNU/Linux systems were born after, following this model but rewritten from scratch. The networking code made is later to many other OS.

As for the standards, everything must be defined in order to achieve interoperability. So in the regard, all RFCs potentially affected the design of Unix networks and much more. Some RFC were never implemented, people are free to implement the RFC they want and make their programs implementing them available to all.

Basically, POSIX dictates a lot when it comes to UNIX systems, you might want to check it... I supposed that's more what you are really looking for as it target unix systems and specify some requirements. Keep in mind that GNU/Linux systems don't always follow POSIX as it may be considered old and rusty, some alternative and non-standards ways have emerged. This is problematic for developers working on portable programs/systems.

Answer 3

RFC's probably aren't the best material to read up on how to understand how Unix (or any OS for that matter) works.

RFC's document standard ways of doing things such that disparate systems can interoperate and there is some sanity in the world.

The manner in which a Unix or Linux implements said RFC's will not always be the same.

From the RFC's you'll learn a great deal about standards and protocols, you won't necessarily learn a hell of a lot about OS specific implementations.

Answer 4

When I originally started learning about computing, the RFCs were also one of my points of contact. My theory was that if I could understand the underlying network rules (of TCP, DNS, HTTP, etc) then I would be much better prepared to fix things when they went wrong. Or at the very least be able to pin point why they went wrong.

An RFC is the rulebook that the programmers follow when writing a network stack (etc) to the point where there have been bugs introduced as a result of typos (I think SMTP had one for a long time)

Personally it has given me a good basis to understand the things that were built on top of it. Understanding the underlying rulebook makes understanding problems (sometimes) much easier.

Though it does mean that when I do run into issues, I'll very often be digging in to wireshark and RFCs while everyone else is poking around in logs.

It might not teach you about Unix specifically, or any other operating system, but understanding at least the core RFCs that the internet / networking is built on will certainly give you a box of knowledge that few others will have.