Why do we need this RFC?

RFCs are the laws of the internet. They explain how protocols like the Internet Protocol, DNS and Ethernet work. They are a valuable source of information for anyone seeking to understand networking. However, a big gap for me as a self-taught software engineer is that I did not have the context to understand what a given RFC was trying to achieve. The RFC would either seem too technical to possibly understand, or alternatively seem like it was stating the obvious (usually a sign that my understanding was deeply flawed).

Therefore this article is an experiment in trying to write a concise problem statement for someone not already well-versed in the field. I have started with four RFCs, picked somewhat arbitrarily from a comment left by my colleague on an unrelated post:

• https://tools.ietf.org/html/rfc894
• https://tools.ietf.org/html/rfc791
• https://tools.ietf.org/html/rfc2328
• https://tools.ietf.org/html/rfc4271

RFC 791 - Internet Protocol

Suppose you have some computers connected locally (e.g. Ethernet), and you also want that network to be connected to other networks controlled by other people. It's not easy (or even desirable) to merge it all into one big network. You need a way to "inter-network" through gateways between distinct networks. So the Internet Protocol ("IP") provides for a virtual network (the IP network) which sits over the top of local networks, carrying packets all the way from a node on one network to a node on another. Each node has an "IP address" which can be a source or destination on the IP network.

IP's approach can be contrasted with X.25 (a standard issued by the ITU and used principally by banks and telecommunications companies). IP has no concept of a "connection" between two hosts; each packet has a source address and destination address, and is sent independently from sender to recipient. X.25 requires the creation of a "virtual circuit" over which two parties can communicate, which is tunneled over one or more underlying "dedicated circuits" such as physical cables or local networks; therefore each packet in X.25 specifies a "logical channel number" rather than a destination address. IP therefore relies on higher-layer protocols (such as TCP) to provide the concept of a "connection" or "stream" within which data can be delivered reliably and/or in a particular order.

RFC 894 - A Standard for the Transmission of IP Datagrams over Ethernet Networks

To implement the general principle that "IP runs on top of Ethernet", it is necessary to discuss (1) how IP packets should be encapsulated in Ethernet frames, and (2) when sending an IP packet to a given IP address, which Ethernet addresses should the underlying Ethernet frame be directed to.

This is an example of an RFC that I could not understand the purpose of at first. It seemed redundant. There is already an RFC for IP and an RFC for Ethernet. Ethernet provides a generic service for conveying data, and IP requires a generic service for conveying data. The match seems obvious. But it is only obvious now because somebody got everyone together decades ago to agree on exactly how to do it.

RFC 2328 - OSPF Version 2 ("Open Shortest Path First")

Suppose you want to set up an IP network with various routers, each connected to one or more other hosts (including other routers). When an IP packet arrives at a router, where should the router send it? The destination might not be directly reachable. Maybe you have to go through one or more intermediate routers to get to the destination IP address. But how do you know where to send the packet? You need to know (1) that there is a path to the destination and (2) ideally you use the shortest or cheapest path.

Broadly it is necessary to have some kind of database of which hosts are connected to which (the "network topology"). OSPF solves this problem by having each router maintain a "link state" database, share information with the other routers, and use a particular algorithm to determine where to send each packet.

RFC 4271 - A Border Gateway Protocol 4 (BGP-4)

Suppose you have several networks under separate control (each an "autonomous system" or "AS"). As in RFC 2328, it is necessary to work out how routers decide where to send packets for any given destination IP address. You can't use something like OSPF which relies on a database containing all routes, because (1) it would be too big and (2) the internal workings of each AS are private and should not be exposed outside of that AS. Therefore BGP requires each AS to be represented by a system which advertises its routing table (for reaching other AS's) to representatives of other AS's.

One of the key features of BGP-4, over previous versions, is "classless" routing. In previous versions, the destination for each route was a "network" identified by its "IP network number", which included leading bits for the network's "class" (size) and then some bits to identify the network within that class. Classless routing allows the destination to be a range of addresses, with a prefix of arbitrary length, rather than a "network" of a particular class.

Is this useful?

This article was an experiment. Please let me know if this is a helpful way to understand technical topics, or if you have any other questions or comments. I can be reached here or at [email protected].