RFC 791 · · Internet Standard
IPv4, the envelope every packet travels in.
The official title is "Internet Protocol." What it actually decides: the format of every packet that crosses the internet, where the addresses go, and what a router is allowed to do with it on the way.
Written by Noel Lang · IT trainer
TL;DR
RFC 791 is the specification for IPv4, the format of nearly every packet on the internet. It defines the 32-bit address, the packet (datagram) header, and the rules a router follows to forward and, when needed, fragment packets. By design it is unreliable: IP delivers on a best-effort basis and leaves guarantees to layers above, like TCP. Written by Jon Postel in 1981 and still STD 5, it quietly runs under most of the traffic you send today.
The problem it solves
Before 1981, networks could not talk to each other. The ARPANET, satellite links, packet radio: each moved data its own way, and none of them agreed on a common format. RFC 791 fixed this with one idea, and it is almost boringly simple: agree on a single envelope. Give it a fixed place for a destination address, a return address, and just enough bookkeeping for any machine along the way to make one decision, namely where to send it next.
Jon Postel, editing the spec for DARPA, wrote it so the machines in the middle stay dumb. A router reads the destination, forwards the packet toward it, and forgets it ever existed. It does not remember your connection, does not track whether the packet arrived, does not care what order things come in. That sounds like a flaw. It is the single most important design decision in the history of the internet, and the next section is about why.
Think of every packet as a postcard
Picture each IP packet as a postcard. On the front: a destination address and a return address, nothing the postal system does not strictly need. On the back: your message, up to what fits on one card.
Drop it in a mailbox and the postal system does its best. It reads the destination, hands the card to the next sorting office in the right direction, and moves on. Nobody signs for it. Nobody promises it arrives. If two cards take different routes and the second overtakes the first, nobody puts them back in order. And if a mailbag is full, your postcard is quietly dropped.
This is not the post office being lazy. It is the post office being fast and cheap at enormous scale, precisely because it refuses to make promises it would have to track. IP is the same. Every packet carries its own address and travels alone. Routers glance, forward, forget. The unreliability is the feature: it is what lets the network stay simple enough to span the planet.
If you need a real conversation, every word in order with nothing lost, you number your postcards yourself and ask the other side to re-request any that go missing. That numbering-and-resending layer is TCP, defined in RFC 793 , and it lives on the two endpoints, never in the network. This is the end-to-end principle: the network moves packets, the ends make them reliable.
What IP actually does
Strip away the folklore and IP has exactly three jobs. Two are real work, one is a promise it deliberately refuses to make:
-
Addressing 32 bits · ~4.3 billion
Every host gets a 32-bit address, written as four numbers like 203.0.113.7. Each packet carries a source and a destination, so any router can forward it without knowing anything about the conversation. The whole space is about 4.3 billion addresses, which felt infinite in 1981 and ran out around 2011.
-
Fragmentation 8-octet pieces
Different links accept different maximum sizes. If a packet is too big for the next hop, IP can split it into fragments that travel independently and get reassembled at the destination. Clever, and fragile: lose one piece and the whole packet is gone.
-
Best-effort delivery no guarantees
IP tries once and promises nothing: not delivery, not order, not that a packet arrives only once. This is the design choice, not a shortcoming. It keeps routers simple and stateless, and it is why the internet scaled. Guarantees live one layer up, in TCP.
The IPv4 header, one packet's cover sheet
Every IPv4 packet begins with this header, normally 20 bytes. Most of it is bookkeeping. The two rows that matter most to a router are at the bottom: where the packet is going, and where it came from. Later RFCs renamed a field or two (the type-of-service byte is now DiffServ, see RFC 2474 ), but the shape is Postel’s.
What the RFC actually says
The original is about 45 pages and, for a 1981 spec, quite readable. Here is the map if you want to visit:
| Section | In plain words |
|---|---|
| 1 · Introduction | Why a common protocol is needed and where IP sits: one thin layer that any network underneath can carry and any protocol above can use. |
| 2 · Overview | The mental model: hosts, gateways (routers), datagrams. Two real jobs are named here, addressing and fragmentation, plus one deliberate non-goal, reliability. |
| 3.1 · Header format | The heart of it: every field of the header drawn out bit by bit. This is the diagram everyone eventually memorizes. |
| 3.2 · Discussion | The reasoning behind the fields, including the famous robustness principle: be conservative in what you send, liberal in what you accept. |
| 3.3 · Interfaces | How the layer above (like TCP) and the layer below hand datagrams to IP and back. The seams between the layers. |
| Appendices A/B | Worked fragmentation examples and the exact byte and bit transmission order, the pedantic details implementers actually need. |
Things people get wrong
-
"IP makes sure your data arrives."
It never promised to. RFC 791 describes a best-effort service: it tries once, with no guarantee of delivery, order, or that a packet arrives only once. A router with a full queue simply drops the packet and moves on. Reliability is a different document's job: RFC 793 (TCP) runs on the two endpoints and re-sends whatever IP loses. Calling IP "unreliable" is not criticism, it is the specification.
-
"IPv4 is dead, everything is IPv6 now."
Not even close. IPv6 adoption keeps climbing, but well into the 2020s most of the traffic your devices send still rides on IPv4, the exact packet format RFC 791 defined in 1981. The address shortage was real and IPv6 is the long-term fix, yet IPv4 was kept alive by private addressing (RFC 1918) and NAT, and remains the default on a huge share of the internet.
-
"Postel's robustness principle is folklore, it isn't in the RFC."
It is, and you can point to the line. Section 3.2 of RFC 791 says an implementation "must be conservative in its sending behavior, and liberal in its receiving behavior." That sentence, usually shortened to "be liberal in what you accept," shaped decades of protocol design. It has since been criticized for letting sloppy implementations survive, but it genuinely sits in the 1981 text, not a later invention.
-
"Routers reassemble fragmented packets."
Usually not. When a packet is too big for the next link, an intermediate router may chop it into fragments, but reassembly happens at the destination host, which uses the identification field to match the pieces. A router in the middle forwards fragments like any other packet. This is also why fragmentation is fragile: lose one fragment and the whole original is unrecoverable.
Where you'll meet RFC 791
You run into this header every day without seeing it. A field guide to the tells:
| You see | You're looking at |
|---|---|
| TTL=64 or TTL=128 | A ping reply. Linux and macOS start the time-to-live counter at 64, Windows at 128. Each router hop subtracts one, so the leftover value hints at how far away the host is. |
| traceroute / tracert | The TTL field turned into a tool: send packets with TTL 1, 2, 3 ... and each router that discards an expired one reveals itself. The whole route, mapped with RFC 791's loop-protection counter. |
| "Fragmentation needed", MTU 1500 | The header's length and fragmentation fields at work. 1500 bytes is the classic Ethernet limit; a packet larger than the path allows must fragment or be rejected. |
| Protocol 6, 17, 1 | The header's protocol field, naming what rides inside: 6 is TCP, 17 is UDP, 1 is ICMP. It is how the receiving host knows which layer to hand the payload to. |
| Every line in Wireshark | Open any packet capture and the "Internet Protocol Version 4" block is RFC 791, field for field, still labelled exactly as the 1981 spec named them. |
Questions people actually ask
Is RFC 791 still used today? +
Yes. RFC 791 is the core IPv4 specification and still defines the packets behind most internet traffic. Later RFCs adjusted individual header fields (the type-of-service byte became DiffServ in RFC 2474), but the packet format is the one Jon Postel wrote in 1981, and it remains Internet Standard STD 5.
What is the difference between RFC 791 and IPv6? +
RFC 791 is IPv4, with 32-bit addresses, about 4.3 billion of them. IPv6 (RFC 8200) uses 128-bit addresses to escape that limit and simplifies the header. Same job, moving packets between hosts, far larger address space. IPv4 is not obsolete: both run side by side across most of the internet.
What does the IP header actually contain? +
A version and header length, a type-of-service byte, the total length, fragmentation fields (identification, flags, fragment offset), a time-to-live counter, a protocol field naming what is inside (TCP, UDP, ICMP), a header checksum, and the 32-bit source and destination addresses. RFC 791 lays out all fourteen fields bit by bit; the header is normally 20 bytes.
Why is IP called unreliable or best-effort? +
Because it makes no promises. IP forwards each packet once and does not guarantee it arrives, arrives in order, or arrives only once. This is deliberate: it keeps routers simple and stateless. Reliability is added on top by TCP (RFC 793), which runs on the endpoints and re-sends anything lost.
Is the robustness principle part of RFC 791? +
Yes. Section 3.2 states that an implementation "must be conservative in its sending behavior, and liberal in its receiving behavior." Often shortened to "be liberal in what you accept," this is Postel's robustness principle, and it really does originate in the 1981 IP spec, not in later folklore.
Has RFC 791 been obsoleted or replaced? +
No. RFC 791 is still current as Internet Standard STD 5. It replaced RFC 760 in 1981 and has since been updated (not replaced) by RFC 1349, RFC 2474 and RFC 6864, which refine individual fields. The core specification stands.
Referenced by
Other explainers on this site that point back to this RFC:
How RFC 791 connects
What came before
-
RFC 760 RFC 760 (1980) was the previous edition. RFC 791 obsoleted it a year later and became the stable specification that stuck for four decades.
What it works with
-
RFC 793 · reliable sibling
TCP, the layer that keeps promises
IP moves packets and shrugs if they vanish. RFC 793 adds ordering, acknowledgment and retransmission on top, turning that unreliable stream of packets into a dependable connection. The classic pairing, TCP/IP.
-
RFC 1918 · carves out
Private addresses inside IPv4
RFC 1918 reserves three blocks of the address space defined here for private networks that never appear on the public internet. It is a big part of why IPv4 lasted this long.
Part of a guided cluster: The networking basics, explained