An RFC is an official IETF document describing internet protocols and standards. RFCs are the authoritative specifications defining how the internet works.

RFC Quick Lookup

Search this curated collection of 50+ essential networking RFCs (Request for Comments) — the documents that define how the internet works. Each entry includes the RFC number, title, a brief summary, and a direct link to the full text at the IETF.

Search RFCs

RFC #	Title	Summary	Link

What Are RFCs?

RFCs (Requests for Comments) are the official technical documents that define the protocols and standards powering the internet. Published by the Internet Engineering Task Force (IETF), RFCs cover everything from how IP addresses work to how DNS resolves domain names. Every protocol you use daily — HTTP, TCP, DNS, SMTP — is specified in one or more RFCs.

Despite their modest name ("Request for Comments"), RFCs are the authoritative internet standards. RFC 791 defines IPv4, RFC 793 defines TCP, and RFC 1035 defines DNS. Understanding which RFC specifies a protocol helps you find the definitive documentation when configuring network equipment or troubleshooting complex issues.

Most Important RFCs by Category

Category	Key RFCs	What They Define
Core Internet	791, 793, 768	IPv4, TCP, UDP — the foundation of internet communication
DNS	1034, 1035	Domain Name System architecture and implementation
HTTP	9110, 9112, 9113, 9114	Web communication (HTTP semantics, 1.1, 2, 3)
Email	5321, 7208, 6376, 7489	SMTP, SPF, DKIM, DMARC
Security	8446, 4301, 8484	TLS 1.3, IPsec, DNS over HTTPS
Routing	4271, 2328, 2453	BGP, OSPF, RIP

Pro Tip: When troubleshooting protocol issues, the RFC is the definitive reference. If you're unsure how a specific DNS record type should behave, check RFC 1035. If you need to verify correct TCP behavior, refer to RFC 793. For email authentication (SPF, DKIM, DMARC), the RFCs define exactly how records should be formatted and validated.

How RFCs Are Numbered and Categorized

RFCs have specific status categories that indicate their authority:

Status	Meaning	Example
Internet Standard	Fully approved and stable; the definitive specification	RFC 793 (TCP)
Proposed Standard	Technically sound; may evolve with implementation experience	RFC 9110 (HTTP)
Informational	Provides useful information but not a standard	RFC 1918 (Private IPs)
Best Current Practice	Recommended operational practices	RFC 2119 (Key Words)
Experimental	For testing and evaluation purposes	Various research RFCs
Historic	Obsolete or no longer recommended	RFC 2616 (old HTTP)

Note: RFCs are never modified once published — instead, newer RFCs obsolete or update older ones. For example, RFC 9110 obsoletes RFC 7231 which obsoleted parts of RFC 2616. Always check if an RFC has been obsoleted before relying on it. The IETF Datatracker (datatracker.ietf.org) shows the current status and any updates.

RFCs Every Network Engineer Should Know

RFC 791 (IPv4) — The foundation of internet addressing. Understanding IP packet structure helps with subnetting and NAT.
RFC 1918 (Private Addresses) — Defines 10.x.x.x, 172.16-31.x.x, and 192.168.x.x ranges used in every home and office router.
RFC 1035 (DNS) — How DNS queries and responses work. Essential for understanding DNS troubleshooting.
RFC 793 (TCP) — How reliable data delivery works, including the three-way handshake and flow control.
RFC 5321 (SMTP) — How email is sent between servers. Important for mail server connectivity.
RFC 8446 (TLS 1.3) — Current encryption standard for HTTPS and secure communications.

Reading an RFC Effectively

RFCs can be dense and technical. Here's how to read them efficiently:

Start with the Abstract — Get the overview before diving into details.
Read the Introduction — Understand the problem being solved and the scope.
Focus on relevant sections — Use the table of contents to find the specific behavior you're researching.
Check MUST/SHOULD/MAY keywords — As defined in RFC 2119, these indicate requirement levels.
Look at examples — Many RFCs include protocol exchange examples that clarify behavior.
Check references — Related RFCs often provide additional context and updates.

This approach is similar to how you'd use our OSI Model Reference — start with the layer overview, then drill into specific protocols as needed.

Key Takeaways

RFCs are the authoritative documents defining internet protocols and standards.
Key RFCs include 791 (IPv4), 793 (TCP), 768 (UDP), 1035 (DNS), and 8446 (TLS 1.3).
RFCs are never modified — newer RFCs obsolete or update older ones.
Check an RFC's status on the IETF Datatracker before relying on it.
Focus on MUST/SHOULD/MAY keywords to understand requirement levels.
Understanding relevant RFCs helps with DNS, port, and protocol troubleshooting.

Video: What Are RFCs?

Related Tools and Guides

Frequently Asked Questions

What is an RFC?

An RFC (Request for Comments) is an official document published by the IETF (Internet Engineering Task Force) that describes internet protocols, standards, and best practices. Despite the informal name, RFCs are the authoritative technical specifications that define how the internet works.

How many RFCs are there?

As of 2025, over 9,500 RFCs have been published since the series began in 1969. However, many are obsoleted by newer versions or are informational/historical. The currently active standards represent a smaller subset of the total.

Where can I read RFCs?

The official source is the IETF Datatracker at datatracker.ietf.org. RFCs are also available at rfc-editor.org. Both sites are free and provide the full text of every RFC along with its current status and any updates or errata.

What is the most important RFC?

RFC 791 (IPv4) and RFC 793 (TCP) are arguably the most important because they define the core protocols that the entire internet runs on. However, RFCs like 1035 (DNS), 5321 (SMTP), and 8446 (TLS 1.3) are equally critical for specific internet services.

How do I cite an RFC?

Cite RFCs by number and title: "RFC 791: Internet Protocol" or simply "as specified in RFC 791." In academic writing, include the author(s), title, RFC number, IETF, date, and URL from the IETF Datatracker.

About Tommy N.

Tommy is the founder of RouterHax and a network engineer with 10+ years of experience in home and enterprise networking. He specializes in router configuration, WiFi optimization, and network security. When not writing guides, he's testing the latest mesh WiFi systems and helping readers troubleshoot their home networks.