RFC Reference
Free reference guide: RFC Reference
About RFC Reference
The RFC Reference is a curated, searchable guide to the most important Request for Comments documents that define how the internet works. It covers 25 foundational RFCs across six categories: Network, Security, Web, Email, DNS, and Routing. Each entry includes the RFC number, a concise description of what the standard defines, the publication year, and key technical highlights — so you can quickly understand a protocol without reading the full specification document.
This reference is designed for network engineers, security professionals, web developers, and computer science students who need to look up the history, purpose, and key technical details of internet standards. It covers the full HTTP evolution from HTTP/1.1 semantics (RFC 7231) through HTTP/2 (RFC 7540) to HTTP/3 over QUIC (RFC 9114), the TLS security stack from TLS 1.2 (RFC 5246) to the improved TLS 1.3 (RFC 8446), authentication standards including JWT (RFC 7519) and OAuth 2.0 (RFC 6749), and email infrastructure with SMTP (RFC 5321), IMAP (RFC 9051), SPF (RFC 7208), and DKIM (RFC 6376).
Network-layer entries cover IPv4 (RFC 791), IPv6 (RFC 8200), TCP (RFC 793), UDP (RFC 768), and ARP (RFC 826), while the DNS section addresses the original DNS specification (RFC 1035), DNS over HTTPS (RFC 8484), and DNS over TLS (RFC 7858). The Routing category includes BGP-4 (RFC 4271), OSPFv2 (RFC 2328), RIPv2 (RFC 2453), and the private address space definition (RFC 1918) — giving a complete picture of how IP traffic is directed across both private and public networks.
Key Features
- Network layer RFCs: IPv4 (RFC 791), IPv6 (RFC 8200), TCP (RFC 793), UDP (RFC 768), ARP (RFC 826)
- Security protocol RFCs: TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446), JWT (RFC 7519), OAuth 2.0 (RFC 6749)
- Web protocol RFCs: HTTP/1.1 semantics (RFC 7231), HTTP/2 (RFC 7540), HTTP/3 (RFC 9114), WebSocket (RFC 6455), URI (RFC 3986)
- Email infrastructure RFCs: SMTP (RFC 5321), IMAP4rev2 (RFC 9051), SPF (RFC 7208), DKIM (RFC 6376)
- DNS protocol RFCs: DNS specification (RFC 1035), DNS over HTTPS (RFC 8484), DNS over TLS (RFC 7858)
- Routing protocol RFCs: BGP-4 (RFC 4271), OSPFv2 (RFC 2328), RIPv2 (RFC 2453), private IP space (RFC 1918)
- Publication year and key technical highlights for each RFC to understand the historical context
- Category-based navigation to jump directly to Network, Security, Web, Email, DNS, or Routing standards
Frequently Asked Questions
What is an RFC and who publishes them?
RFC stands for Request for Comments — a series of technical and organizational documents published by the Internet Engineering Task Force (IETF) and the Internet Society. RFCs define the protocols, procedures, and policies that make up the internet. Some RFCs are informational or experimental, while others become mandatory internet standards (STDs). Every internet protocol like TCP, HTTP, TLS, and DNS has at least one defining RFC.
What is the difference between HTTP/2 (RFC 7540) and HTTP/3 (RFC 9114)?
HTTP/2 (RFC 7540, published 2015) uses binary framing and multiplexing over a single TCP connection to eliminate head-of-line blocking at the application layer. However, TCP's own head-of-line blocking at the transport layer still causes latency when packets are lost. HTTP/3 (RFC 9114, published 2022) solves this by running over QUIC (a UDP-based transport) instead of TCP, enabling independent stream multiplexing and faster connection establishment.
What does TLS 1.3 (RFC 8446) improve over TLS 1.2?
TLS 1.3 (RFC 8446, published 2018) introduces a 1-RTT handshake (down from 2-RTT in TLS 1.2) and optional 0-RTT resumption for returning clients, significantly reducing connection latency. It also removes insecure cipher suites (RC4, DES, 3DES, MD5, SHA-1, RSA key exchange) and mandates forward secrecy on all connections, making the protocol more secure and efficient than TLS 1.2 (RFC 5246).
How do JWT (RFC 7519) and OAuth 2.0 (RFC 6749) relate to each other?
OAuth 2.0 (RFC 6749) is an authorization framework that defines how a client application can obtain limited access to a resource on behalf of a user, using grant types like Authorization Code, Implicit, Client Credentials, and Resource Owner Password. JWT (RFC 7519) is a compact token format (Header.Payload.Signature) often used to represent the access tokens and ID tokens that OAuth 2.0 and OpenID Connect issue. OAuth 2.0 defines the workflow; JWT is a common format for the tokens it issues.
What do SPF (RFC 7208) and DKIM (RFC 6376) protect against?
Both protect against email spoofing and phishing. SPF (Sender Policy Framework, RFC 7208) allows a domain owner to publish a DNS TXT record listing which mail servers are authorized to send email for that domain. Receiving servers check this record to reject unauthorized senders. DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic digital signature to outgoing emails so receiving servers can verify the message was not tampered with in transit and originated from the claimed domain.
What private IP address ranges are defined by RFC 1918?
RFC 1918 (Address Allocation for Private Internets, published 1996) reserves three address blocks for private use: 10.0.0.0/8 (Class A, 16 million addresses), 172.16.0.0/12 (Class B, about 1 million addresses), and 192.168.0.0/16 (Class C, 65,536 addresses). These addresses are not routable on the public internet and are used for internal networks, requiring NAT to communicate with public IP addresses.
What is the difference between OSPFv2 (RFC 2328) and BGP-4 (RFC 4271)?
OSPFv2 (RFC 2328) is an Interior Gateway Protocol (IGP) that uses the Dijkstra Shortest Path First algorithm and link-state advertisements to find the optimal route within a single autonomous system (AS). BGP-4 (RFC 4271) is the Exterior Gateway Protocol (EGP) of the internet, used to exchange routing information between different autonomous systems (ISPs, enterprises). BGP makes policy-based routing decisions based on path attributes rather than just shortest path.
What is DNS over HTTPS (RFC 8484) and why does it matter for privacy?
DNS over HTTPS (DoH, RFC 8484, published 2018) sends DNS queries as HTTPS requests to a DoH-capable resolver, encrypting the DNS traffic. Traditional DNS queries are sent in plaintext over UDP port 53, allowing ISPs, network operators, or attackers on the same network to observe which domain names you are looking up. DoH prevents this surveillance by encapsulating DNS queries inside encrypted HTTPS, making them indistinguishable from regular web traffic.