RFC 1118
Hitchhikers guide to the Internet
The Hitchhikers Guide to the Internet 🧚✨
okay bestie, this is RFC 1118 🎀 It's titled The Hitchhikers Guide to the Internet, and it was written by E. Krol at the University of Illinois Urbana. The date on it is September 1989. The header doesn't list anything it obsoletes or updates 🙈 Its category isn't printed in the header either, but the memo itself says no standards are defined or specified in it, so think of it as a friendly guide, not a spec 💅
Status of this Memo 📬
this RFC went out to the Internet community to share some "hints" 🌸 The goal is to help new network people get the big picture: how the direction of the Internet gets set, how to find online information, and how to be a good Internet neighbor 🫶 The info might not be relevant to the research problems of the Internet, but researchers and implementors might find it interesting. No standards are defined or specified in this memo. Distribution is unlimited ✨
NOTICE 🚨
ngl this guide is very unevenly edited 💀 It's full of passages that its editors thought were a good idea at the time 😭 It's still an indispensable companion for anyone trying to make sense of life in an infinitely complex, confusing Internet. It can't be useful or informative on every single matter, BUT it makes a reassuring claim: where it's inaccurate, it's at least definitively inaccurate 💖 And if there's a major discrepancy, it's always reality that's got it wrong 🙃 So remember, DON'T PANIC. 🌈 (Apologies to Douglas Adams.)
Purpose and Audience 🎀
this doc assumes you already know how a simple, non-connected IP network works. Think a few 4.3 BSD systems on an Ethernet that isn't plugged into anything else 🖥️ Appendix A has remedial info to get you to that point 📚 The whole purpose is to get that person, who's comfy with a simple net, versed in the "oral tradition" of the Internet. Then their net can connect to the Internet with little danger to either one 🦋
It is not a tutorial 🙅♀️ It's more like a collection of pointers to other places and literature, plus hints that aren't normally documented anywhere. The Internet is super dynamic, so this doc gets updated regularly 🔄 The author welcomes comments and suggestions, especially new terms for the glossary. Definitions aren't necessary, just the terms 💜
What is the Internet? 🌍
okay so, in the beginning there was the ARPANET 🛰️ It was a wide area experimental network that connected hosts and terminal servers together. People set up procedures to handle address allocation and to create voluntary standards for the network 📋 As local area networks got more and more pervasive, lots of hosts became gateways to local networks 🚪 Then a network layer was developed so all these networks could interoperate, and it's called Internet Protocol (IP) 🔥 Over time other groups built long haul IP based networks too (NASA, NSF, states...) 🌸 These nets also interoperate, all because of IP 🫶 The whole collection of these interoperating networks is the Internet ✨
A few groups provide most of the information services on the Internet 💅 The Information Sciences Institute (ISI) handles much of the standardization and allocation work, acting as the Internet Assigned Numbers Authority (IANA) 👑 SRI International runs the principal information services by operating the Network Information Center (NIC) 🧚 Once you're connected to the Internet, you can grab most of the info in this doc from the SRI-NIC, so it's giving very useful 🎀 Bolt Beranek and Newman (BBN) provides info services for CSNET (the CIC) and NSFNET (the NNSC), and Merit provides info services for NSFNET (the NIS) 💜
Operating the Internet ⚙️
every network has its own operations center: the ARPANET, NSFNET, or a regional network 🏢 The ARPANET is run by BBN, Inc. under contract from DCA (on behalf of DARPA). Their facility is called the Network Operations Center, or NOC 🛠️ Merit, Inc. runs NSFNET from yet another completely separate NOC 🌈 The regionals have similar facilities to monitor and keep watch over their portion of the Internet 👀 On top of that, they should all have some knowledge of what's happening to the Internet as a whole 🧠
If a problem comes up, a campus network liaison should contact the network operator they're directly connected to 📞 So if you're on a regional network, which is gatewayed to the NSFNET, which is connected to the ARPANET... and you have a problem, you should contact your regional network operations center 😭 That's the chain of command, bestie 💅
RFCs 📝
the internal workings of the Internet are defined by a set of documents called RFCs (Request for Comments) 🦋 The general process for creating one is that someone who wants something formalized writes a document describing the issue and mails it to Jon Postel (Postel@ISI.EDU) 💌 He acts as a referee for the proposal 🧑⚖️ Then everyone who wants to take part in the discussion comments on it, electronically of course 💻 It may go through multiple revisions 🔁 If it's generally accepted as a good idea, it gets a number and gets filed with the RFCs 🎉
there are two independent ways to categorize protocols, and this part is kind of a lot but it's so good 🤌 The first is the state of standardization, which is one of "standard", "draft standard", "proposed", "experimental", or "historic" 📊 The second is the status of the protocol, which is one of "required", "recommended", "elective", or "not recommended" 🎯 You could expect a particular protocol to move from elective to required at the same time it moves from proposed to standard 🚀
A Required Standard protocol (e.g., RFC-791, The Internet Protocol) must be implemented on any host connected to the Internet 🔒 Recommended Standard protocols are generally implemented by network hosts 🖥️ If you don't have them, you can still access the Internet, but your usability might take a hit 🥲 RFC-793 (Transmission Control Protocol) is a Recommended Standard protocol 💖
Elective Proposed protocols were discussed and agreed to, but they've never really come into wide use 🙈 That might be because there isn't wide need for the specific application (RFC-937, The Post Office Protocol), or because the protocol was technically superior but ran against other pervasive approaches 🥊 If a particular site needs the facility, it's suggested that they implement it in accordance with the RFC 🛠️ That way, if the idea's time comes, the implementation will follow some standard and will be generally usable 🌟
Informational RFCs contain factual information about the Internet and how it operates (RFC-1010, Assigned Numbers) 📖 And as the Internet and technology have grown, some RFCs have become unnecessary 🕰️ These obsolete RFCs can't just be ignored though ⚠️ Often, when a change is made that causes a new RFC to be issued that obsoletes others, the new RFC may only contain explanations and motivations for the change 💭 To understand the model the whole facility is based on, you may need to read the original and subsequent RFCs on the topic 📚 (Appendix B contains a list of what are considered the major RFCs necessary for understanding the Internet 💜)
only a few RFCs actually specify standards, and most RFCs are for information or discussion purposes 🫧 To find out what the current standards are, look for the RFC titled "IAB Official Protocol Standards" (most recently published as RFC-1100) 🏆
Part 1 of 6 · more coming up, bestie 🎀💖
Mail Reflectors ✨
okay so the way most people keep up with network news is by subscribing to a bunch of mail reflectors (also called mail exploders) 📬 A mail reflector is a special electronic mailbox that, the second it gets a message, resends it to a whole list of other mailboxes. Basically that's a discussion group on one topic 💬 Everyone on the list sees everything the reflector forwards, and if you wanna put in your two cents, you just send your comments to the reflector 🫶
the general way to subscribe is to find the address of the reflector and add -REQUEST to the mailbox name (not the host name). so if you wanted in on the NSFNET list reflected by NSFNET-INFO@MERIT.EDU, you'd send a request to NSFNET-INFO-REQUEST@MERIT.EDU 💖 the catch is you have to know the list exists in the first place 😭 the suggested move is to read the mail from one list (like NSFNET-INFO), because you'll probably start finding out about the others that way 🔍 the NIC also runs a registration service for mail reflectors in the files NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT, NETINFO:INTEREST-GROUPS-3.TXT, through NETINFO:INTEREST-GROUPS-9.TXT 📁
the NSFNET-INFO reflector is aimed at people who care about NSFNET news every single day (backbone folks, regional network people, and the workers at Internet interconnection sites) 🧚 the messages get reflected from one central spot and sent as separate messages to every subscriber. that creates hundreds of messages on the wide area networks, where bandwidth is the scarcest 🥲
there are two ways a campus can spread the news without flooding the wide area networks 🌸 option one is to re-reflect the message on campus. you set up a reflector on a local machine that forwards each message to a campus distribution list. option two is to make an alias on a campus machine that drops the messages into a notesfile on the topic. campus users can open the notesfile and see everything sent since their last visit 📝 you could also have the campus wide area network liaison screen the messages either way and only forward the ones that are considered of merit ✨ either scheme lets one message come into campus while still reaching everyone inside 🎀
Address Allocation ✨
okay so before a local network can connect to the Internet, it must be allocated a unique IP address 🌐 these addresses are allocated by SRI-NIC. the process starts with getting an application form: send a message to Hostmaster@NIC.DDN.MIL and ask for the template for a connected address. you fill that template out and mail it back to the hostmaster, and then an address is allocated and e-mailed back to you 💌 you can also do this by postal mail (Appendix B) 📮
IP addresses are 32 bits long 🔢 they're usually written as four decimal numbers separated by periods (e.g., 192.17.5.100), and each number is the value of one octet of those 32 bits. some networks might be super flat (one net with a ton of nodes), and some might be hierarchical (lots of interconnected nets with fewer nodes each, plus a backbone) 🌳 to cover both cases, addresses got split into class A, B, and C networks. this classification had to do with how the octets get interpreted 🧩 class A networks use the first octet as the network address and the remaining three as the host address on that network. class C addresses have three octets of network address and one of host. class B is split two and two 👯 so there's room for a few large nets, a reasonable number of medium nets, and a large number of small nets 🥰 the high order bits in the first octet are coded to tell you which address format you've got. there are very few unallocated class A nets, so a very good case has to be made for one. as a practical matter, you have to pick between Class B and Class C when you place an order 🙈 (there are also class D (Multicast) and E (Experimental) formats. multicast addresses will likely get more use in the near future, but they aren't frequently used yet 🦋)
in the past, sites that needed multiple network addresses asked for multiple discrete addresses (usually Class C). that's because a lot of the software around (notably 4.2BSD) couldn't deal with subnetted addresses 💀 information on how to reach a particular network (routing information) has to be stored in Internet gateways and packet switches. some of those nodes can only store and exchange a limited amount of routing information (limited to about 700 networks). so it's suggested that any campus announce (make known to the Internet) no more than two discrete network numbers 🙏
if a campus expects to run into this, it should consider subnetting. subnetting (RFC-950) lets you announce one address to the Internet and use a set of addresses on campus 🍓 basically, you define a mask that lets the network tell apart the network portion and the host portion of an address. by using a different mask on the Internet and on campus, the same address can be read in multiple ways 🪄 for example, say a campus needs two networks internally and has the 32,000 addresses beginning 128.174.X.X (a Class B address) allocated to it. the campus could give 128.174.5.X to one part of campus and 128.174.10.X to another. by advertising 128.174 to the Internet with a subnet mask of FF.FF.00.00, the Internet would treat those two addresses as one 👀 inside the campus, a mask of FF.FF.FF.00 gets used, so the campus can treat them as separate entities 💅 (in reality, you don't pass the subnet mask of FF.FF.00.00 to the Internet, because the octet meaning is implicit in it being a class B address)
a word of warning, babe: not all systems know how to do subnetting 🚨 some 4.2BSD systems need additional software. 4.3BSD systems subnet as released. other devices and operating systems vary in how much trouble they have with subnets. a lot of the time these machines can work as a leaf on a network but can't be a gateway inside the subnetted part of the network 😬 as more systems become 4.3BSD based, these problems should disappear ✨
there's been some confusion in the past over the format of an IP broadcast address 🤯 some machines used an address of all zeros to mean broadcast, and some used all ones. that was really confusing when both kinds of machine were on the same network. the broadcast address of all ones was adopted to end the grief 🫶 some systems (e.g., 4.3 BSD) let you choose the format of the broadcast address. if a system does let you choose, care should be taken that the all ones format gets picked 💜 (this is explained in RFC-1009 and RFC-1010) 📚
Internet Problems ✨
okay real talk, there are a bunch of problems with the Internet 😤 the solutions range from quick software changes all the way up to long-term research projects. here are some of the major ones 👑
Number of Networks
when the Internet was designed, it was supposed to have about 50 connected networks 🌱 with the explosion of networking, the number is now approaching 1000 📈 the software in a group of critical gateways (called the core gateways) can't pass or store much more than that number 😭 in the short term, core reallocation and recoding has bumped the number up a little bit 🧡
Routing Issues
on top of the sheer mass of data needed to route packets to a huge number of networks, there are a lot of problems with the updating, stability, and optimality of the routing algorithms 🌀 people are doing tons of research in the area, but the optimal solution to these routing problems is still years away ⏳ in most cases, the routing we have today works, just sub-optimally and sometimes unpredictably 🫠 the current best hope for a good routing protocol is something called OSPFIGP, which should be generally available from many router manufacturers within a year 🔮
Trust Issues
gateways exchange network routing information, and right now most of them just accept on faith that the info about the state of the network is correct 🙃 back when most gateways belonged to a single administrative entity (DARPA), that wasn't a big deal. but now there are multiple wide area networks under different administrations, so a rogue gateway somewhere in the net could cripple the Internet 💀 there's design work going on to fix both problems: a gateway doing unreasonable things, and giving enough info to route data reasonably between multiply connected networks (multi-homed networks) 🛠️
Capacity & Congestion
some parts of the Internet are super congested during the busy part of the day 🚦 the growth is dramatic, with some networks seeing traffic grow by more than 20% per month 📊 more bandwidth is planned, but delivery and budgets might not let supply keep up 🥺
Setting Direction and Priority 🎀
okay so the Internet Activities Board (IAB), currently chaired by Vint Cerf of NRI, is the group in charge of setting the technical direction, establishing standards, and resolving problems on the Internet. they're literally the main character of the whole governance situation 👑
here's who's on the board 💅
Vinton Cerf - Chairman
David Clark - IRTF Chairman
Phillip Gross - IETF Chairman
Jon Postel - RFC Editor
Robert Braden - Executive Director
Hans-Werner Braun - NSFNET Liaison
Barry Leiner - CCIRN Liaison
Daniel Lynch - Vendor Liaison
Stephen Kent - Internet Securitythe board gets backup from two task forces. the Research Task Force is chaired by Dave Clark of MIT, and the Engineering Task Force is chaired by Phill Gross of NRI. the bestie duo of research and engineering 🫶
the Internet Research Task Force has these Research Groups 🔬
Autonomous Networks Deborah Estrin
End-to-End Services Bob Braden
Privacy Steve Kent
User Interfaces Keith Lantzand the Internet Engineering Task Force has these technical areas 🛠️
Applications TBD
Host Protocols Craig Partridge
Internet Protocols Noel Chiappa
Routing Robert Hinden
Network Management David Crocker
OSI Interoperability Ross Callon, Robert Hagen
Operations TBD
Security TBDthe IETF also runs a bunch of Working Groups 🧚 this list is giving "so many projects, so little time" energy
ALERTMAN Louis Steinberg
Authentication Jeff Schiller
CMIP over TCP Lee LaBarre
Domain Names Paul Mockapetris
Dynamic Host Config Ralph Droms
Host Requirements Bob Braden
Interconnectivity Guy Almes
Internet MIB Craig Partridge
Joint Management Susan Hares
LAN Mgr MIB Amatzia Ben-Artzi
NISI Karen Bowers
NM Serial Interface Jeff Case
NOC Tools Bob Enger
OSPF Mike Petry
Open Systems Routing Marianne Lepp
OSI Interoperability Ross Callon
PDN Routing Group CH Rokitansky
Performance and CC Allison Mankin
Point - Point IP Drew Perkins
ST and CO-IP Claudio Topolcic
Telnet Dave Borman
User Documents Karen Roubicek
User Services Karen BowersRouting 🗺️
okay, routing is the algorithm a network uses to steer a packet from its source to its destination, and it's way more chaotic than it looks ngl. think about a little kid trying to find a table in a restaurant 🍓 an adult looks at the dining room, sees the whole layout, and picks the best route in two seconds. the kid just sees a bunch of paths between tables, and a good path (let alone the optimal one) is not even visible to them. it's the same problem, just with more snacks
a bit more background 🧚 IP gateways (or, more correctly, routers) are boxes with connections to several networks, and they pass traffic between those networks. they decide how to send each packet based on the information in the IP header and the current state of the network. every interface on a router has a unique address that fits the network it's plugged into. the piece of the IP header they mostly use is the destination address. other stuff, like type of service, is mostly ignored for now. the state of the network comes from routers swapping information with each other. what really defines a routing protocol is how the database is distributed (what each node knows), what the updates look like, and which metrics are used to measure how good a connection is 💅
some algorithms give every node complete knowledge of the network (the "adult algorithm" 👑). that's a lot of stuff to ask of a node. it needs a big chunk of local storage and enough CPU to search those big tables fast enough, because this has to happen for every single packet. also, updates usually only include changes to what's already known, because otherwise you'd burn a huge amount of network capacity shipping around megabyte-sized routing updates. but this type of algorithm has some issues. the routing info can only travel across the network itself, and that takes non-trivial time. so each node's view is a correct historical view of the network at some point in the past. it's like looking at a photograph of the dining room instead of the dining room itself 📸 you'd pick the optimal route, and then a bus-cart rolls in and blocks the path right after the photo was taken. these inconsistencies can create routing loops, where a packet gets trapped in a closed path until its time to live (TTL) field runs out and it gets discarded. ugh, no thanks 💀
other algorithms only know about a subset of the network. to avoid loops, these are usually used in a hierarchical network. each node knows everything about its own area, but to leave that area it heads to one specific place, the default gateway. these are typically used in smaller networks, like campus or regional ones 🏫
here are the routing protocols in current use 🎀
Static (no protocol-table/default routing)
don't laugh 😤 static routing is probably the most reliable, the easiest to implement, and the least likely to get you into trouble on a small network or a leaf on the Internet. it's also the only method available on some CPU and operating system combos. if a host is connected to an Ethernet with just one gateway on it, make that gateway the host's default gateway and do no other routing. (of course, that gateway might pass the reachability info along somehow on its other side 🫶)
one word of warning: only use static routes in the middle of a network that's also using dynamic routing with extreme caution 🚨 the routers passing dynamic info can get confused by conflicting dynamic and static routes. if your host is on an Ethernet with several routers leading to other networks, and those routers are doing dynamic routing with each other, it's usually better to join in on the dynamic routing than to use static routes.
RIP
RIP is a routing protocol based on XNS (Xerox Network System) that's been adapted for IP networks. lots of routers use it (Proteon, cisco, UB...), and so do many BSD Unix systems. BSD systems typically run a program called "routed" to swap information with other systems running RIP 🔄 RIP works best on nets of small diameter (few hops) where all the links are the same speed. the reason is that the metric used to pick the best path is the hop-count, and a hop is a traversal across a gateway. so every machine on the same Ethernet is zero hops away. if a router connects two networks directly, a machine on the other side of it is one hop away. as routing info passes through a gateway, the gateway adds one to the hop counts so everything stays consistent across the network. the diameter of a network is the largest hop-count possible inside it. unfortunately, RIP defines a hop count of 16 as infinity, which means the link is down. so RIP won't let hosts that are separated by more than 15 gateways in the RIP space talk to each other 😭
the other problem with hop-count metrics is that they don't reflect link speed. so a one-hop satellite link (with a .5 sec delay) running at 56kb would get picked over a two-hop T1 connection 🛰️ congestion can be thought of as a drop in a link's efficacy. so as a link gets more congested, RIP still thinks it's the best hop-count route, and it congests the link even more by throwing more packets onto its queue. the audacity 🙄
RIP wasn't very well documented in the community at first, so people read the BSD code to figure out how RIP really worked. eventually it got documented in RFC-1058 📚
Routed
the routed program, which does RIP for 4.2BSD systems, has lots of options. one of the most popular is routed -q (quiet mode), which means it listens to RIP info but never broadcasts it. this is used by a machine on a network with several RIP-speaking gateways. it lets the host figure out which gateway is the best (hopwise) for reaching a distant network. (you might still want a default gateway so you don't have to pass every address the Internet knows about around with RIP 🙈)
there are two ways to add static routes into routed: the /etc/gateways file, and the route add command. static routes are handy if you know how to reach a distant network but aren't getting that route through RIP. for the most part, route add is the one to use. the reason is that the command adds the route to that machine's routing table without exporting it through RIP. the /etc/gateways file takes precedence over any routing info received through a RIP update. it also gets broadcast as fact in the RIP updates the host produces, no questions asked. so if there's a mistake in /etc/gateways, that mistake will spread through the RIP space super fast and may bring the whole network to its knees 🫠
one of routed's problems is that you have very little control over what gets broadcast. in bigger networks, where different parts are under different administrative controls, you'd really like to pass on through RIP only the nets you received from RIP that you know are reasonable. that stops people from adding IP addresses to the network that might be illegal, while you're the one stuck being responsible for passing them on to the Internet 😬 this kind of reasonability check isn't available in routed. so it's usable, but it's not good enough for large networks.
Hello (RFC-891)
Hello is a routing protocol that was designed and implemented in an experimental software router called a "Fuzzball", which runs on a PDP-11 🧪 it isn't widely used, but it was the routing protocol that used to run on the initial NSFNET backbone. the data sent between nodes is similar to RIP (a list of networks and their metrics). the metric, though, is milliseconds of delay ⏱️ that lets Hello work over nets with different link speeds, and it performs better when things get congested. honestly iconic 👑✨
One of the most interesting side effects of Hello based networks is how amazing they are at keeping time ⏰✨ Like, lowkey genius. Measuring the delay on a link for the metric is actually really hard 😭. You can't just measure round trip time, because the return link might be more congested, a different speed, or not there at all 💀. It's also not realistic for every node to have a builtin WWV (nationwide radio time standard) receiver 🙈. So you have to design an algorithm that passes time around between nodes over the network links, where the transmission delay can only be approximated 🧠. Hello routers do exactly this, and in a nationwide network they keep synchronized time within milliseconds 🔥. (See also the Network Time Protocol, RFC-1059.)
Gateway Gateway Protocol (GGP RFC-823)
The core gateways originally used GGP to swap info among themselves 🫶. It's a "distance-vector" algorithm. The new core gateways use a "link-state" algorithm instead 💅.
NSFNET SPF (RFC-1074)
The current NSFNET Backbone routers use a version of the ANSI IS-IS and ISO ES-IS routing protocol 🦋. It's a "shortest path first" (SPF) algorithm, which puts it in the class of "link-state" algorithms. SPF is giving main character energy 👑.
Exterior Gateway Protocol (EGP RFC-904)
EGP is not strictly a routing protocol. It's a reachability protocol 🫠. It tells you what nets can be reached through what gateway, but not how good the connection is. It's the standard that gateways use to swap network reachability info with the core gateways, and it's generally used between autonomous systems. There is a metric passed around by EGP, but its usage is not formally standardized. The metric ranges from 0 to 255, with smaller values considered "better" ✨. Some implementations treat 255 as unreachable 💀. Many routers talk EGP, so they can interface with routers from different manufacturers or run by different administrations 🌸. For example, when a router of the NSFNET Backbone swaps routing or reachability info with a gateway of a regional network, EGP is what gets used 🎀.
Gated
So we've got regional and campus networks talking RIP among themselves, and the DDN and NSFNET speaking EGP. How do they interoperate? 🤔 In the beginning there was static routing. The problem with static routing in the middle of the network is that it gets broadcast to the Internet whether it's usable or not 😬. So if a net becomes unreachable and you try to get there, dynamic routing will immediately issue a net unreachable to you. Under static routing, the routers would think the net could still be reached and keep trying until the application gave up (in 2 or more minutes) 😭. Mark Fedor, then of Cornell, tried to solve these problems with a replacement for routed called gated 🧚.
Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and Hello to Hello'ers. These speakers often all live on one Ethernet, but luckily (or unluckily 🙈) they can't understand each other's ruminations. Under configuration file control, it can also filter the chatter between them. For example, you can set up a configuration that says to announce RIP nets via Hello only if they are specified in a list and are reachable by way of a RIP broadcast as well. This means that if a rogue network appears in your local site's RIP space, it won't be passed through to the Hello side of the world 🛡️. There are also configuration options to do static routing and name trusted gateways.
This may sound like the greatest thing since sliced bread 🍞, but there's a catch called metric conversion. You have RIP measuring in hops, Hello measuring in milliseconds, and EGP using arbitrary small numbers. The big questions are how many hops to a millisecond, and how many milliseconds in the EGP number 3.... Also, remember that infinity (unreachability) is 16 to RIP, 30000 or so to Hello, and 8 to the DDN with EGP. Getting all these metrics to work well together is no small feat 😵💫. If it's done incorrectly and you translate an RIP of 16 into an EGP of 6, everyone in the ARPANET will still think your gateway can reach the unreachable, and they'll send every packet in the world your way 💀. Gated is available via anonymous FTP from devvax.tn.cornell.edu in directory pub/gated 📂.
Names ✨
All routing across the network is done by means of the IP address associated with a packet. Humans find addresses like 128.174.5.50 hard to remember 🙃, so a symbolic name register was set up at the NIC, where people would say, "I would like my host to be named uiucuxc." Machines connected to the Internet across the nation would connect to the NIC in the middle of the night, check the modification dates on the hosts file, and if it had been modified, move it to their local machine. With the advent of workstations and micros, changes to the hosts file would have to be made nightly. That would be super labor intensive and eat up a lot of network bandwidth 😩. RFC-1034 and a number of others describe Domain Name Service (DNS), a distributed data base system for mapping names into addresses 🗺️.
We must look a little more closely into what's in a name. First, note that an address specifies a particular connection on a specific network. If the machine moves, the address changes. Second, a machine can have one or more names and one or more network addresses (connections) to different networks. Names point to a something which does useful work (i.e., the machine), and IP addresses point to an interface on that provider. A name is a purely symbolic representation of a list of addresses on the network. If a machine moves to a different network, the addresses will change, but the name could remain the same 🎀.
Domain names are tree structured names with the root of the tree at the right. For example:
uxc.cso.uiuc.eduis a machine called "uxc" (purely arbitrary), within the subdomains of the U of I, and "uiuc" (the University of Illinois at Urbana), registered with "edu" (the set of educational institutions) 🌳.
A simplified model of how a name is resolved goes like this. On the user's machine there is a resolver. The resolver knows how to contact a root name server across the network. Root servers are the base of the tree structured data retrieval system. They know who is responsible for handling first level domains (e.g., 'edu'). What root servers to use is an installation parameter. From the root server, the resolver finds out who provides 'edu' service. It contacts the 'edu' name server, which supplies it with a list of addresses of servers for the subdomains (like 'uiuc'). This action is repeated with the sub-domain servers until the final subdomain returns a list of addresses of interfaces on the host in question. The user's machine then gets to choose which of these addresses to use for communication 💅.
A group may apply for its own domain name (like 'uiuc' above). This is done in a manner similar to the IP address allocation. The only requirements are that the requestor have two machines reachable from the Internet, which will act as name servers for that domain. Those servers could also act as servers for subdomains, or other servers could be designated as such. The servers don't need to be in any particular place, as long as they're reachable for name resolution. (U of I could ask Michigan State to act on its behalf, and that would be fine 🫶.) The biggest problem is that someone must do maintenance on the database. If the machine isn't convenient, that might not get done in a timely fashion 😬. The other thing to note is that once the domain is allocated to an administrative entity, that entity can freely allocate subdomains using whatever manner it sees fit.
The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. The name server is a distributed data base system that allows clients to name resources and to share that information with other network hosts. BIND is integrated with 4.3BSD and is used to look up and store host names, addresses, mail agents, host information, and more. It replaces the /etc/hosts file or host name lookup. BIND is still an evolving program. To keep up with reports on operational problems, future design decisions, etc., join the BIND mailing list by sending a request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also be obtained via anonymous FTP from ucbarpa.berkeley.edu 🧚.
There are several advantages in using BIND. One of the most important is that it frees a host from relying on /etc/hosts being up to date and complete. Within the .uiuc.edu domain, only a few hosts are included in the host table distributed by SRI. The remainder are listed locally within the BIND tables on uxc.cso.uiuc.edu (the server machine for most of the .uiuc.edu domain). All are equally reachable from any other Internet host running BIND, or any DNS resolver 🌈.
BIND can also provide mail forwarding information for interior hosts not directly reachable from the Internet. These hosts can either be on non-advertised networks, or not connected to an IP network at all, as in the case of UUCP-reachable hosts (see RFC-974). More information on BIND is available in the "Name Server Operations Guide for BIND" in UNIX System Manager's Manual, 4.3BSD release 📚.
There are a few special domains on the network, like NIC.DDN.MIL, the hosts database at the NIC. There are others of the form NNSC.NSF.NET. These special domains are used sparingly and require ample justification 🙅♀️. They refer to servers under the administrative control of the network rather than any single organization. This allows the actual server to be moved around the net while the user interface to that machine stays constant. That is, should BBN relinquish control of the NNSC, the new provider would be pointed to by that name 🔁.
In actuality, the domain system is a much more general and complex system than has been described here 🤯. Resolvers and some servers cache information to allow steps in the resolution to be skipped. Information provided by the servers can be arbitrary, not merely IP addresses. This allows the system to be used both by non-IP networks and for mail, where it may be necessary to give information on intermediate mail bridges 💜 the domain system is honestly so underrated
What's wrong with Berkeley Unix ✨
okay bestie, so the University of California at Berkeley got funded by DARPA to glow up the Unix system in a bunch of ways 💅. One of those upgrades is support for the Internet protocols 🌐. In the earlier versions (like BSD 4.2) the basic Internet protocols were giving (TCP, IP, SMTP, ARP), and it performed nicely on IP Ethernets and smaller Internets 🦋. But once it got hooked up to complicated networks? Not it 😭. There were deficiencies. Most of these problems got resolved in the newest release, BSD 4.3 🎀.
Here's the tea though. BSD 4.2 was the springboard that a lot of vendors launched their Unix implementations from, either by porting the existing code or by using it as a model. So implementations like Ultrix are still based on BSD 4.2 🙈, which means a lot of machines still have the BSD 4.2 problems. As time goes on and BSD 4.3 trickles through vendors as a new release, many of the problems will get resolved ✨. Below is a list of some problem scenarios and how they're handled under each of these releases 💜.
ICMP redirects
Under the Internet model, all a system needs to know to get anywhere is its own address, the address of where it wants to go, and how to reach a gateway that knows about the Internet 🧚. It doesn't have to be the best gateway, bestie! If the system is on a network with multiple gateways, and a host sends a packet to a gateway that feels another directly connected gateway is more appropriate, the gateway sends the sender a message. This message is an ICMP redirect, and it politely says, "I'll deliver this message for you, but you really ought to use that gateway over there to reach this host" 🫶.
BSD 4.2 ignores these messages, and that's giving stress 💀. The gateways and the local network get extra load, since for every packet sent, the gateway sends a packet back to the originator. BSD 4.3 uses the redirect to update its routing tables, uses that route until it times out, then reverts to the route it thinks it should use. The whole process then repeats, but it's way better than one per packet 🌈.
Trailers
An application (like FTP) sends a string of octets to TCP, which breaks it into chunks and adds a TCP header. TCP then sends blocks of data to IP, which adds its own headers and ships the packets over the network 🚀. All this prepending of data with headers causes memory moves in both the sending and receiving machines 😩. Then someone got the bright idea: what if packets were long and they stuck the headers on the end? Those became trailers! The receiving machine could put the packet on the beginning of a page boundary, and if the trailer was OK, merely delete it and transfer control of the page with no memory moves involved 🧠.
The problem? Trailers were never standardized, and most gateways don't know to look for the routing information at the end of the block 😬. When trailers are used, the machine typically works fine on the local network (no gateways involved) and for short blocks through gateways (where trailers aren't used). So TELNET and FTP of very short files work just fine, but FTP of long files seems to hang 💔. On BSD 4.2, trailers are a boot option, and one should make sure they are off when using the Internet. BSD 4.3 negotiates trailers, so it uses them on its local net and doesn't use them when going across the network 🎀.
Retransmissions
TCP fires off blocks to its partner at the far end of the connection. If it doesn't receive an acknowledgement in a reasonable amount of time, it retransmits the blocks. What counts as "reasonable" is decided by TCP's retransmission algorithm ⏰.
There is no correct algorithm, but some are better than others, where "worse" is measured by the number of retransmissions done unnecessarily 🤓. BSD 4.2 had a retransmission algorithm that retransmitted quickly and often. This is exactly what you'd want if you had a bunch of machines on an Ethernet (a low delay network of large bandwidth) 🌸. But if you have a network of relatively longer delay and scarce bandwidth (like 56kb lines), it tends to retransmit too aggressively. That makes the networks and gateways pass more traffic than is really necessary for a given conversation 😵💫. Retransmission algorithms do adapt to the delay of the network after a few packets, but 4.2's adapts slowly in delay situations.
BSD 4.3 does a lot better and tries to do the best for both worlds ✨. It fires off a few retransmissions really quickly, assuming it is on a low delay network, and then backs off very quickly. It also allows the delay to be about 4 minutes before it gives up and declares the connection broken 🕰️.
Even better than the original 4.3 code is a version of TCP with a retransmission algorithm developed by Van Jacobson of LBL. He did a lot of research into how the algorithm works on real networks, and he modified it to get both better throughput and to be friendlier to the network 👑. This code has been integrated into the later releases of BSD 4.3, and it can be fetched anonymously from ucbarpa.berkeley.edu in directory 4.3 📥.
Time to Live
The IP packet header contains a field called the time to live (TTL) field. It is decremented each time the packet traverses a gateway ⏳. TTL was designed to stop packets caught in routing loops from being passed forever with no hope of delivery 🔁. Since the definition bears some likeness to the RIP hop count, some misguided systems have set the TTL field to 15, because the unreachable flag in RIP is 16 🙃. Obviously, no networks could have more than 15 hops.
The RIP space where hops are limited ends when RIP is not used as a routing protocol any more (e.g., when NSFnet starts transporting the packet). So it is quite easy for a packet to require more than 15 hops. These machines will show the behavior of reaching some places but not others, even though the routing information appears correct 💀.
Solving the problem typically requires kernel patches, so it may be difficult if source is not available 🛠️.
Appendix A - References to Remedial Information 📚
[1] Quarterman and Hoskins, "Notable Computer Networks",
Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October
1986.
[2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
[3] Hedrick, C., "Introduction to the Internet Protocols", Via
Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,
file tcp-ip-intro.doc.
[4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
and Architecture", Copyright 1988, by Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.Appendix B - List of Major RFCs 🗂️
This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds. This is the 30 August 1989 edition of the list 💜.
RFC-768 User Datagram Protocol (UDP)
RFC-791 Internet Protocol (IP)
RFC-792 Internet Control Message Protocol (ICMP)
RFC-793 Transmission Control Protocol (TCP)
RFC-821 Simple Mail Transfer Protocol (SMTP)
RFC-822 Standard for the Format of ARPA Internet Text Messages
RFC-826 Ethernet Address Resolution Protocol
RFC-854 Telnet Protocol
RFC-862 Echo Protocol
RFC-894 A Standard for the Transmission of IP
Datagrams over Ethernet Networks
RFC-904 Exterior Gateway Protocol
RFC-919 Broadcasting Internet Datagrams
RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets
RFC-950 Internet Standard Subnetting Procedure
RFC-951 Bootstrap Protocol (BOOTP)
RFC-959 File Transfer Protocol (FTP)
RFC-966 Host Groups: A Multicast Extension to the Internet Protocol
RFC-974 Mail Routing and the Domain System
RFC-1000 The Request for Comments Reference Guide
RFC-1009 Requirements for Internet Gateways
RFC-1010 Assigned Numbers
RFC-1011 Official Internet Protocols
RFC-1012 Bibliography of Request for Comments 1 through 999
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation
RFC-1042 A Standard for the Transmission of IP
Datagrams over IEEE 802 Networks
RFC-1048 BOOTP Vendor Information Extensions
RFC-1058 Routing Information Protocol
RFC-1059 Network Time Protocol (NTP)
RFC-1065 Structure and Identification of
Management Information for TCP/IP-based internets
RFC-1066 Management Information Base for Network
Management of TCP/IP-based internets
RFC-1084 BOOTP Vendor Information Extensions
RFC-1087 Ethics and the Internet
RFC-1095 The Common Management Information
Services and Protocol over TCP/IP (CMOT)
RFC-1098 A Simple Network Management Protocol (SNMP)
RFC-1100 IAB Official Protocol Standards
RFC-1101 DNS Encoding of Network Names and Other Types
RFC-1112 Host Extensions for IP Multicasting
RFC-1117 Internet NumbersNote: This list is a portion of a list of RFC's by topic that may be retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of course) 🌷.
The following list is not necessary for connection to the Internet, but it is useful in understanding the domain system, mail system, and gateways 🧚:
RFC-974 Mail Routing and the Domain System
RFC-1009 Requirements for Internet Gateways
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation and Specification
RFC-1101 DNS Encoding of Network Names and Other TypesAppendix C - Contact Points for Network Information 📞
Network Information Center (NIC)
DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025
(800) 235-3155 or (415) 859-3695
NIC@NIC.DDN.MILNSF Network Service Center (NNSC)
NNSC
BBN Systems and Technology Corporation
10 Moulton St.
Cambridge, MA 02238
(617) 873-3400
NNSC@NNSC.NSF.NETNSF Network Information Service (NIS)
NIS
Merit Inc.
University of Michigan
1075 Beal Avenue
Ann Arbor, MI 48109
(313) 763-4897
INFO@NIS.NSF.NETCIC
CSNET Coordination and Information Center
Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02238
(617) 873-2777
INFO@SH.CS.NETGlossary 💖
autonomous system 🏰
A set of gateways under a single administrative control and using compatible and consistent routing procedures. 💅 Generally speaking, it's the gateways run by one particular organization. Since a gateway is connected to two (or more) networks, it's not usually correct to say that a gateway is in a network 🙈 It's giving "belongs to multiple friend groups." For example, the gateways that connect regional networks to the NSF Backbone network are run by Merit and form an autonomous system ✨ Another example: the gateways that connect campuses to NYSERNET are run by NYSER and form an autonomous system 🎀
core gateway 👑
The innermost gateways of the Internet 🧚 These gateways have a total picture of the reachability to all networks known to the Internet, so they're the ones with the full tea ☕ They then redistribute reachability information to their neighbor gateways speaking EGP. It's from them that your EGP agent (there is one acting for you somewhere if you can reach the core of the Internet) finds out it can reach all the nets on the Internet 🌈 Which is then passed to you via Hello, gated, RIP. The core gateways mostly connect campuses to the ARPANET, or interconnect the ARPANET and the MILNET, and they're run by BBN 💜 Iconic infrastructure, no notes 😭
count to infinity 🌀
The symptom of a routing problem where routing information gets passed in a circular manner through multiple gateways 😵💫 Each gateway increments the metric appropriately and passes it on. As the metric gets passed around the loop, it keeps climbing to ever increasing values until it reaches the maximum for the routing protocol being used, which typically denotes a link outage 💀 Not a good look, honestly.
hold down ⏳
When a router discovers a path in the network has gone down, it announces that the path is down for a minimum amount of time (usually at least two minutes) 🫶 This gives the routing information time to propagate across the network, and it prevents the formation of routing loops. Patience is a whole aesthetic 🌸
split horizon 🦋
When a router (or a group of routers working in consort) accepts routing information from multiple external networks, but does not pass on information learned from one external network to any of the others 💅 It's an attempt to stop bogus routes to a network from spreading because of gossip or counting to infinity. Main character energy: "I heard it from one source, and I'm keeping it there" 🤫
DDN 🎀
Defense Data Network, the collective name for the ARPANET and MILNET. It's used frequently because, although they're separate networks, the operational and informational foci are the same. Two networks, one vibe ✨ iykyk
Security Considerations 🔐
Security and privacy protection is a serious matter, and way too often nothing is done about it 😤 There are some known security bugs (especially in access control) in BSD Unix and in some implementations of network services. The hitchhikers guide does not discuss these issues (too bad) 🙈
Bestie, this part is not a vibe-check to skip. Security and privacy are serious, and the known access control bugs in BSD Unix and in some network service implementations are real. Take them seriously. 🔥
Author's Address 🖋️
Ed Krol
University of Illinois
195 DCL
1304 West Springfield Avenue
Urbana, IL 61801-4399
Phone: (217) 333-7886
EMail: Krol@UXC.CSO.UIUC.EDU📦 where this page comes from
- ietf: rfc1118 1989-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms