Internet Standards — RFCs, IETF, IANA, ICANN

Summary#

Nobody owns the Internet. But somebody has to decide what an IP header looks like, who gets the address block 198.51.100.0/24, which TLDs exist, and what happens when TCP needs a new flag. That coordination work is done by a small number of voluntary, technically-focused bodies: the IETF (engineers writing the protocols), IANA (the registries those protocols depend on), ICANN (the contractual layer for the DNS root and IP allocation policy), and ISOC (the legal home for the IETF). The W3C is the analogous body for web standards (HTML, CSS, WAI), parallel to but distinct from the IETF.

The output of this ecosystem is the RFC — Request For Comments — a document type that ranges from binding standards (RFC 791 defines IPv4) to informational notes and April Fools’ jokes (RFC 1149: IP over avian carriers). The genius of the system is that protocols become standards through “rough consensus and running code,” not through corporate ratification.

Why it matters#

Three reasons engineers care about who runs which body:

• Reading the spec. When something is ambiguous or broken — your TCP stack disagrees with the kernel, a CDN serves a malformed Set-Cookie, a DNS resolver behaves oddly — the answer is in an RFC. Knowing which RFC and how to read it is a working skill, not academic trivia.
• Allocation matters. IP address blocks, AS numbers, port numbers, MIME types, URI schemes — all of these are coordinated by IANA. If you ship a protocol that needs a new port or a new media type, you go through IANA.
• Governance shows up in incidents. The 2016 IANA transition (NTIA → ICANN), the periodic ICANN board fights over TLD policy, the RPKI deployment debate at the regional internet registries (RIRs) — these affect operational realities like who can revoke a route.

The bigger pattern: the Internet’s governance is technical not political. The IETF has no enforcement power. Compliance is voluntary. Protocols win when implementers ship interoperable code, not when committees vote.

How it works#

The bodies and their lanes#

+-------------------------------------------------------------+
|                      ISOC (parent org)                       |
|  +----------------+   +----------------+   +-------------+   |
|  |   IETF         |   |   IAB          |   |   IRTF      |   |
|  | (protocol      |   | (architecture  |   | (long-term  |   |
|  |  standards)    |   |  oversight)    |   |  research)  |   |
|  +----------------+   +----------------+   +-------------+   |
+-------------------------------------------------------------+

      +---------------------+         +---------------------+
      |   IANA (registries) |<------->|   ICANN (policy,    |
      |   numbers, names,   |         |   root zone, RIRs)  |
      |   parameters        |         |                     |
      +---------------------+         +---------------------+

      +---------------------+         +---------------------+
      |   W3C (web stds)    |         |   IEEE 802 (LAN/    |
      |   HTML, CSS, WAI    |         |   PHY: Ethernet,    |
      |                     |         |   Wi-Fi)            |
      +---------------------+         +---------------------+

IETF (Internet Engineering Task Force) writes the protocols. It is organised into working groups (e.g. quic, httpbis, tls, dnsop) chaired by volunteer engineers. The IETF meets in person three times a year and on mailing lists continuously. Its output is RFCs.

IAB (Internet Architecture Board) provides architectural oversight and appoints the IESG (Internet Engineering Steering Group), which approves IETF documents for publication.

IRTF (Internet Research Task Force) is the IETF’s sibling for longer-term research. Output is informational, not binding.

IANA (Internet Assigned Numbers Authority) maintains the registries that protocols depend on. Examples:

• The port number registry (port 443 is HTTPS, port 53 is DNS).
• The TLD registry (which top-level domains exist).
• The media type registry (application/json, image/png).
• The protocol number registry (IP protocol 6 is TCP, 17 is UDP).
• The AS number and IP address block allocations to RIRs.

ICANN (Internet Corporation for Assigned Names and Numbers) holds the contract to run IANA on behalf of the global Internet community. It also sets policy for the DNS root (which TLDs are created, which registry runs each TLD) and for IP allocation through the RIRs.

RIRs — Regional Internet Registries — there are five: ARIN (North America), RIPE NCC (Europe / Middle East / Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America), AFRINIC (Africa). They allocate IP blocks and AS numbers to ISPs and large operators in their region.

W3C (World Wide Web Consortium) maintains the web platform standards: HTML, CSS, DOM, WAI accessibility specs. Founded by Tim Berners-Lee in 1994 at MIT. Process is more formal than the IETF’s — Working Draft → Candidate Recommendation → Recommendation.

IEEE 802 committees own the link-layer standards: 802.3 is Ethernet, 802.11 is Wi-Fi, 802.1 is bridging and VLANs.

The RFC process#

A document becomes an RFC through roughly these steps:

1. Internet-Draft (I-D). Anybody can write one. Filename pattern draft-<author>-<wg>-<topic>-NN.txt. Expires after six months unless renewed.
2. Working group adoption. A WG chooses to take ownership of a draft. The filename changes to draft-ietf-<wg>-<topic>-NN. The author no longer fully controls it; the WG does.
3. WG Last Call. The WG declares the draft mature. The chairs check for consensus on the mailing list.
4. IETF Last Call. The IESG opens it to the broader IETF community for review.
5. IESG approval. The IESG reviews and either approves, returns for revisions, or rejects.
6. RFC Editor publication. The document is copy-edited and assigned an RFC number. RFC numbers are issued sequentially and never reused.

The Standards Track has three maturity levels:

• Proposed Standard — stable enough to implement, may have rough edges. Most “standards” stay here.
• Internet Standard — multiple interoperable implementations deployed at scale. The IETF promoted only ~80 RFCs to this level in its history.
• Best Current Practice (BCP) — operational guidance, not a protocol (e.g. BCP 38 on ingress filtering).

Other RFC types: Informational, Experimental, Historic (obsoleted), and the joke RFCs published on 1 April.

Reading an RFC like an engineer#

The conventions are dense but consistent:

• MUST / SHOULD / MAY — the requirement levels defined by RFC 2119 (and RFC 8174 clarifies that these only carry weight when capitalised).
• ABNF — Augmented Backus-Naur Form, the grammar notation used to specify wire formats. RFC 5234 defines it.
• “Updates” and “Obsoletes” — the relationships an RFC declares to earlier RFCs. An RFC can be Updated by later RFCs without being obsoleted (it gets supplemented, not replaced).
• Errata — published corrections to mistakes in approved RFCs. Don’t read an old RFC without checking its errata.

Classic RFCs to know#

• RFC 791 (1981) — Internet Protocol (IPv4).
• RFC 793 (1981) — Transmission Control Protocol. Obsoleted by RFC 9293 in 2022 — TCP got a single consolidated specification only forty years after first being deployed.
• RFC 822 (1982) — Standard for ARPA Internet Text Messages (email format). Obsoleted by RFC 5322.
• RFC 1034 / RFC 1035 (1987) — DNS concepts and implementation.
• RFC 2616 (1999) — HTTP/1.1. Obsoleted by RFC 7230–7235 (2014), themselves obsoleted by RFC 9110–9114 (2022) which reorganised the HTTP semantics across versions.
• RFC 2119 (1997) — Key words for use in RFCs to indicate requirement levels.
• RFC 8446 (2018) — TLS 1.3.
• RFC 9000–9002 (2021) — QUIC.

Variants and trade-offs#

Other axes:

• Open vs proprietary. The IETF requires patents on standards to be either unencumbered or available on RAND (reasonable and non-discriminatory) terms. Standards heavy with submarine patents (e.g. some video codecs at MPEG-LA) ship outside the IETF process. WebRTC, AV1, and HTTP/2 all worked through IETF-friendly licensing.
• IETF vs W3C. Roughly: bytes-on-the-wire is IETF, what-the-browser-does-with-those-bytes is W3C. The line blurs (HTML5 streaming, WebSockets, Server-Sent Events sit in both worlds), and the WHATWG fork in 2004 was about disagreements with W3C’s process.
• IANA’s neutrality. Until 2016, IANA was operated by ICANN under contract from NTIA (US Department of Commerce). The 2016 transition severed that contract and moved oversight to a multi-stakeholder community. Politically contested at the time; operationally invisible.

When this is asked in interviews#

In product loops, almost never directly. In SRE / networking / infrastructure loops, the question is usually a probe of “do you know how to read the spec when something breaks?”

Likely framings:

• “Walk me through how a new protocol becomes a standard.” — Internet-Draft → WG adoption → WG Last Call → IESG approval → RFC. Stress that running code matters as much as the document.
• “What does IANA do?” — Maintains the registries protocols depend on. Port numbers, media types, AS numbers, IP blocks (delegated to RIRs).
• “What is ICANN vs IANA?” — IANA is the registry function. ICANN is the corporation that performs that function and sets policy for the DNS root.
• “When was RFC X obsoleted?” — Trick question if you don’t know; right answer is “check the RFC Editor’s record; HTTP/1.1 has been respec’d three times since 1999.”
• “Which body would standardise [thing]?” — Wire format and protocols → IETF. Browser APIs and markup → W3C / WHATWG. Link-layer hardware → IEEE 802. Registries → IANA. Policy for names and numbers → ICANN.

The deeper signal is whether you treat RFCs as the canonical source when the documentation conflicts. A senior answer is “I’d check the RFC erratum first, then the working-group archive.”

Related concepts#

• What Is the Internet?
• A Brief History of the Internet
• The TCP/IP Model
• DNS Hierarchy and Records
• HTTP Fundamentals