RFC 791
Internet Protocol
INTERNET PROTOCOL 🎀
RFC 791: Internet Protocol, the DARPA Internet Program Protocol Specification 💖
- Date: September 1981
- Prepared for: Defense Advanced Research Projects Agency, Information Processing Techniques Office, 1400 Wilson Boulevard, Arlington, Virginia 22209
- By: Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291
- Editor: Jon Postel
- Replaces: RFC 760, plus IENs 128, 123, 111, 80, 54, 44, 41, 28, 26
- Updates: nothing listed
- Category or status: the title block doesn't say
okay bestie, this is the doc that defines the Internet Protocol itself 🌈 the title block's whole vibe is "I replace RFC 760 and I'm built on a bunch of IENs," and the table of contents is below so you can see the full lineup ✨
TABLE OF CONTENTS
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1 Motivation .................................................... 1
1.2 Scope ......................................................... 1
1.3 Interfaces .................................................... 1
1.4 Operation ..................................................... 2
2. OVERVIEW ......................................................... 5
2.1 Relation to Other Protocols ................................... 9
2.2 Model of Operation ............................................ 5
2.3 Function Description .......................................... 7
2.4 Gateways ...................................................... 9
3. SPECIFICATION ................................................... 11
3.1 Internet Header Format ....................................... 11
3.2 Discussion ................................................... 23
3.3 Interfaces ................................................... 31
APPENDIX A: Examples & Scenarios ................................... 34
APPENDIX B: Data Transmission Order ................................ 39
GLOSSARY ............................................................ 41
REFERENCES .......................................................... 45Preface 💌
this doc specifies the DoD Standard Internet Protocol 🫶 it's built on six earlier editions of the ARPA Internet Protocol Specification, and this text borrows a LOT from them. so many people contributed here, both to the ideas and to the wording ✨
this edition updates a few things: addressing, error handling, option codes, and the security, precedence, compartments, and handling restriction features of the internet protocol 💅
— Jon Postel, Editor 🖋️
1. Introduction 🦋
1.1. Motivation
the Internet Protocol is made for interconnected systems of packet-switched computer communication networks 🌸 people call that kind of system a "catenet" [1]. the internet protocol moves blocks of data called datagrams from sources to destinations. sources and destinations are hosts, and each one is identified by a fixed length address 💜 if a datagram is too long for a "small packet" network, the protocol can also fragment it and reassemble it, as needed 🧩
1.2. Scope
the internet protocol is intentionally narrow 😌 its only job is to get a package of bits (an internet datagram) from a source to a destination across an interconnected system of networks. it does NOT add extra end-to-end data reliability, flow control, sequencing, or the other services you'd usually find in host-to-host protocols 🙈 it can lean on its supporting networks for different types and qualities of service, though 🍓
1.3. Interfaces
this protocol gets called by host-to-host protocols in an internet environment 📞 and it calls on local network protocols to carry the internet datagram to the next gateway or destination host 🚚
for example, a TCP module calls the internet module and hands it a TCP segment (the TCP header plus user data) to use as the data part of an internet datagram. the TCP module also passes along the addresses and other parameters for the internet header as arguments to the call 🎁 then the internet module builds the internet datagram and calls the local network interface to send it out 🚀
on the ARPANET, for instance, the internet module calls a local net module. that module attaches the 1822 leader [2] to the internet datagram, which makes an ARPANET message to send to the IMP 🛰️ the ARPANET address comes from the internet address via the local network interface, and it's the address of some host on the ARPANET. that host might be a gateway to other networks 🌐
1.4. Operation
the internet protocol does two basic jobs: addressing and fragmentation 🔥
the internet modules use the addresses in the internet header to send internet datagrams toward their destinations 🧭 picking a path for transmission is called routing 🗺️
the internet modules also use fields in the internet header to fragment and reassemble internet datagrams when that's needed for "small packet" networks 🧩
the model is that an internet module lives in every host doing internet communication and in every gateway that connects networks 🏠 these modules all follow the same rules for reading address fields and for fragmenting and assembling internet datagrams 🤝 gateways in particular have procedures for making routing decisions and handling other functions 🛣️
the internet protocol treats each internet datagram as its own independent thing, with no link to any other datagram 🦄 there are no connections or logical circuits (virtual or otherwise) 🙅♀️
the internet protocol uses four key mechanisms to deliver its service: Type of Service, Time to Live, Options, and Header Checksum 👑
Type of Service tells you the quality of service you want 💅 it's an abstract, generalized set of parameters that describe the service choices offered by the networks in the internet. gateways use this indication to pick the actual transmission parameters for a particular network, the network for the next hop, or the next gateway when routing a datagram 🎯
Time to Live is an upper bound on how long an internet datagram can live ⏳ the sender sets it, and it gets reduced at each point along the route where the datagram is processed 📉 if the time to live hits zero before the datagram reaches its destination, the datagram is destroyed 💀 think of it as a self destruct timer 💣
Options handle control functions that are useful or needed in some situations but aren't necessary for most communication 🧰 they include timestamps, security, and special routing 🛤️
Header Checksum checks that the information used to process the datagram was transmitted correctly 🔍 the data itself might still have errors 😬 if the header checksum fails, whichever entity detects the error throws the datagram away right away 🗑️
the internet protocol does NOT provide a reliable communication facility 🚨 there are no acknowledgments, end-to-end or hop-by-hop. the only error control for data is the header checksum. there are no retransmissions and there's no flow control. this is the "fire and forget" energy of the whole protocol 💀
errors that get detected may be reported through the Internet Control Message Protocol (ICMP) [3], which is implemented in the internet protocol module 📣
2. Overview 🌷
2.1. Relation to Other Protocols
this diagram shows where the internet protocol sits in the protocol hierarchy 🪜
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+--------------------------+----+
| Internet Protocol & ICMP |
+--------------------------+----+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
Protocol Relationships
Figure 1.the internet protocol is the middle layer 💞 on one side it talks to the higher level host-to-host protocols, and on the other side it talks to the local network protocol 🥰 in this context, a "local network" can be a small network inside a building or a big one like the ARPANET 🏢✨
2.2. Model of Operation ✨
okay so this is the big picture of how a datagram actually travels from one app to another 🦋 Let's say the trip goes through one middle-person gateway 🌉
- The sending application program prepares its data and calls its local internet module to send it as a datagram. It passes the destination address and other parameters as arguments of the call. 💌
- The internet module prepares a datagram header and attaches the data to it. It figures out a local network address for this internet address, which in this case is the address of a gateway. 🗺️
- It sends this datagram and the local network address to the local network interface. 📦
- The local network interface creates a local network header, attaches the datagram to it, then sends the result over the local network. 🚀
- The datagram lands at a gateway host still wrapped in the local network header. The local network interface strips that header off and hands the datagram to the internet module. The internet module reads the internet address and sees the datagram needs to be forwarded to another host on a second network. It works out a local net address for the destination host, then calls the local network interface for that network to send the datagram. 🌉✨
- That local network interface creates a local network header and attaches the datagram, sending the result to the destination host. 🎀
- At the destination host, the local network interface strips off the local net header and hands the datagram to the internet module. 🧚
- The internet module sees the datagram is meant for an application program on this host. It passes the data to that program in response to a system call, and passes the source address and other parameters back as results of the call. 👑
Application Application
Program Program
\ /
Internet Module Internet Module Internet Module
\ / \ /
LNI-1 LNI-1 LNI-2 LNI-2
\ / \ /
Local Network 1 Local Network 2
Transmission Path
Figure 22.3. Function Description 💅
okay the whole point of the Internet Protocol is moving datagrams across a bunch of connected networks 🌐 It does this by passing each datagram from one internet module to the next until it reaches the destination. Internet modules live in hosts and gateways across the internet system. Datagrams get routed from one internet module to another through individual networks, and the routing is based on reading an internet address. So the internet address is one of the most important mechanisms in this whole protocol 🔑
When datagrams hop between internet modules, a datagram might need to cross a network whose maximum packet size is smaller than the datagram itself. To handle that, the internet protocol has a fragmentation mechanism 🧩
Addressing
bestie, this part is lowkey important 🙈 The RFC makes a distinction between names, addresses, and routes [4]. A name says what you're looking for. An address says where it is. A route says how to get there. The internet protocol mostly deals with addresses. Higher level protocols (the host-to-host or application ones) are the ones that map names to addresses. The internet module maps internet addresses to local net addresses. Lower level procedures (the local net or gateway ones) map local net addresses to routes 🗺️
Addresses are a fixed four octets (32 bits) long. Each address starts with a network number, followed by a local address (called the "rest" field). There are three formats, or classes, of internet addresses:
- In class a, the high order bit is zero, the next 7 bits are the network, and the last 24 bits are the local address.
- In class b, the high order two bits are one-zero, the next 14 bits are the network, and the last 16 bits are the local address.
- In class c, the high order three bits are one-one-zero, the next 21 bits are the network, and the last 8 bits are the local address.
Mapping internet addresses to local net addresses needs care 💖 A single physical host has to be able to act like several distinct hosts, meaning it can use several distinct internet addresses. Some hosts also have several physical interfaces (that's called multi-homing 🏠). So provision has to be made for a host to have several physical interfaces to the network, with each one having several logical internet addresses. Examples of address mappings can be found in "Address Mappings" [5] ✨
Fragmentation
so fragmentation is needed when a datagram starts in a local net that allows a big packet size, and then has to cross a local net that only allows smaller ones to reach its destination 📏
An internet datagram can be marked "don't fragment." Any datagram marked that way is never to be internet fragmented, no matter what 🚫 If a "don't fragment" datagram can't reach its destination without being fragmented, it gets discarded instead 💀
Fragmenting, transmitting, and reassembling across a local network that the internet protocol module can't see is called intranet fragmentation, and it may be used [6] 🫶
The internet fragmentation and reassembly procedure has to be able to break a datagram into almost any number of pieces that can be put back together later. The receiver of the fragments uses the identification field to make sure fragments from different datagrams don't get mixed up 🙅♀️ The fragment offset field tells the receiver where a fragment sits in the original datagram. The fragment offset and length together show which part of the original datagram this fragment covers. The more-fragments flag, when it's reset (set to zero), tells the receiver it's the last fragment. Together these fields carry enough info to reassemble everything 🧃
The identification field is what tells one datagram's fragments apart from another's. The module that originates an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol, for as long as the datagram is active in the internet system ⏳ The originating module of a complete datagram sets the more-fragments flag to zero and the fragment offset to zero 🎀
To fragment a long internet datagram, an internet protocol module (for example, one in a gateway) creates two new internet datagrams. It copies the contents of the internet header fields from the long datagram into both new internet headers. The data of the long datagram gets split into two portions on an 8 octet (64 bit) boundary. The second portion might not be an integral multiple of 8 octets, but the first one must be. Call the number of 8 octet blocks in the first portion NFB (for Number of Fragment Blocks) 🔢 The first portion goes into the first new internet datagram, and that datagram's total length field is set to its own length. Its more-fragments flag is set to one. The second portion goes into the second new internet datagram, and its total length field is set to that datagram's length. Its more-fragments flag carries the same value as the long datagram's. And the fragment offset field of the second new internet datagram is set to the long datagram's fragment offset value plus NFB 🧠
This procedure can be generalized to an n-way split instead of the two-way split described here 🌈
To assemble the fragments of an internet datagram, an internet protocol module (for example, one at a destination host) combines internet datagrams that all share the same values for four fields: identification, source, destination, and protocol. The combining is done by placing each fragment's data portion in the relative position indicated by the fragment offset in that fragment's internet header. The first fragment has fragment offset zero, and the last fragment has the more-fragments flag reset to zero 💜
2.4. Gateways 🌉
gateways are the ones that implement the internet protocol to forward datagrams between networks 🚪 They also implement the Gateway to Gateway Protocol (GGP) [7], which coordinates routing and other internet control information.
In a gateway, the higher level protocols don't need to be implemented. The GGP functions get added to the IP module instead 🧚
+-------------------------------+
| Internet Protocol & ICMP & GGP|
+-------------------------------+
| |
+---------------+ +---------------+
| Local Net | | Local Net |
+---------------+ +---------------+
Gateway Protocols
Figure 3.3. SPECIFICATION 📜
3.1. Internet Header Format 🎀
here's a summary of what's inside the internet header 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram Header
Figure 4.Note that each tick mark represents one bit position 🔍
Version: 4 bits
the Version field tells you the format of the internet header 🪪 This document describes version 4 💅
IHL: 4 bits
IHL stands for Internet Header Length. It's the length of the internet header in 32 bit words, which means it points to where the data begins ✨ Note that the minimum value for a correct header is 5 🙈
Type of Service: 8 bits
the Type of Service gives an indication of the abstract parameters of the quality of service you want 🎯 Those parameters are used to guide which actual service parameters get picked when a datagram is sent through a particular network. Several networks offer service precedence, which basically treats high precedence traffic as more important than the rest (usually by only accepting traffic above a certain precedence when things get really busy 🚦). The big choice here is a three way tradeoff between low-delay, high-reliability, and high-throughput 🏎️💨
Okay so the bits in this byte are doing a LOT 💅 Here's the layout, bestie:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+- Bits 0-2: Precedence. 🌸
- Bit 3:
0= Normal Delay,1= Low Delay. 🚀 - Bit 4:
0= Normal Throughput,1= High Throughput. 📦 - Bit 5:
0= Normal Reliability,1= High Reliability. 🛡️ - Bits 6-7: Reserved for Future Use. 🔮
Here are the precedence levels, from the most important down to the most chill:
Precedence
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - RoutineNow the tea ☕ Setting the Delay, Throughput, and Reliability indications can make the service cost more (in some sense) ✨ In lots of networks, getting better performance on one of these means getting worse performance on another, so it's a whole balancing act 🤹 Except for very unusual cases, at most two of these three indications SHOULD be set. Iconic restraint, honestly 💖
The type of service is basically how the datagram gets treated while it's traveling through the internet system 🦋 There are example mappings of internet type of service to what actually happens on networks like AUTODIN II, ARPANET, SATNET, and PRNET in "Service Mappings" [8]. Go read it if you're curious 📚
The Network Control precedence is meant to be used within a network only 🔒 How it gets used and controlled is up to each network. The Internetwork Control designation is meant for gateway control originators only 🚧 And if a particular network cares how these precedence designations get used, that network is responsible for controlling who can access and use them. Boundaries, babe 🫶
Total Length: 16 bits 📏
Total Length is the length of the datagram in octets, counting both the internet header and the data 💅 That gives you room for up to 65,535 octets. Honestly those long datagrams are impractical for most hosts and networks 💀 All hosts MUST be prepared to accept datagrams of up to 576 octets, whether they arrive whole or in fragments. It is RECOMMENDED that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams 🌈
The number 576 is picked so there's room for a reasonable data block plus the required header info ✨ For example, it fits a 512-octet data block plus 64 header octets in one datagram. The maximal internet header is 60 octets, and a typical one is 20 octets, which leaves some margin for the headers of higher-level protocols 🧚
Identification: 16 bits 🪪
An identifying value assigned by the sender to help put the fragments of a datagram back together 🧩
Flags: 3 bits 🚩
These are the various control flags:
- Bit 0: reserved, MUST be zero. 🙅♀️
- Bit 1 (DF):
0= May Fragment,1= Don't Fragment. - Bit 2 (MF):
0= Last Fragment,1= More Fragments.
0 1 2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+Fragment Offset: 13 bits 🍰
This field tells you where in the datagram this fragment belongs 🗺️ The fragment offset is measured in units of 8 octets (64 bits), and the first fragment has offset zero 👑
Time to Live: 8 bits ⏳
This field is the maximum time the datagram is allowed to stay in the internet system 💀 If it contains the value zero, then the datagram MUST be destroyed. Every module that processes a datagram also modifies it during internet header processing 🔄 The time is measured in seconds, BUT every module that processes a datagram MUST decrease the TTL by at least one, even if it processes the datagram in less than a second. So the TTL MUST be thought of only as an upper bound on how long a datagram may exist ⏰ The whole point is to get undeliverable datagrams thrown out and to cap how long a datagram can live, iykyk 🙈
Protocol: 8 bits 🎀
This field tells you the next-level protocol used in the data portion of the datagram. The values for the various protocols are specified in "Assigned Numbers" [9] 📖
Header Checksum: 16 bits 🔐
This is a checksum on the header only. Some header fields change (time to live, for example), so it gets recomputed and verified at each point where the internet header is processed 🔁
The checksum algorithm goes like this:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
This is a simple checksum to compute, and experimental evidence says it's adequate 🥹 It's provisional though, and it MAY be replaced by a CRC procedure, depending on further experience. Stay tuned, bestie 🔮
Source Address: 32 bits 📍
The source address. See section 3.2.
Destination Address: 32 bits 🎯
The destination address. See section 3.2.
Options: variable 🧃
The options MAY appear or not in datagrams. They MUST be implemented by all IP modules, both hosts and gateways. What's optional is their transmission in any particular datagram, NOT their implementation ✨ In some environments the security option MAY be required in all datagrams 🔐
The option field has variable length, and there MAY be zero or more options. There are two cases for the format of an option:
- Case 1: A single octet of option-type.
- Case 2: An option-type octet, an option-length octet, and the actual option-data octets.
The option-length octet counts the option-type octet, the option-length octet, and the option-data octets 🧮
The option-type octet is viewed as having 3 fields:
- 1 bit: copied flag
- 2 bits: option class
- 5 bits: option number
The copied flag tells you whether this option gets copied into all fragments on fragmentation 🧬
0= not copied1= copied
The option classes are:
0= control1= reserved for future use2= debugging and measurement3= reserved for future use
These are the internet options that are defined 🌟
CLASS NUMBER LENGTH DESCRIPTION
----- ------ ------ -----------
0 0 - End of Option list. This option occupies only
1 octet; it has no length octet.
0 1 - No Operation. This option occupies only 1
octet; it has no length octet.
0 2 11 Security. Used to carry Security,
Compartmentation, User Group (TCC), and
Handling Restriction Codes compatible with DOD
requirements.
0 3 var. Loose Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 9 var. Strict Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 7 var. Record Route. Used to trace the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
2 4 var. Internet Timestamp.Specific Option Definitions 🔍
End of Option List 🛑
+--------+
|00000000|
+--------+
Type=0This option marks the end of the option list. It might not line up with the end of the internet header based on the header length 🤷♀️ It's used at the end of ALL the options, not the end of each one, and it only needs to be used if the end of the options wouldn't otherwise line up with the end of the internet header.
MAY be copied, introduced, or deleted on fragmentation, or for any other reason. 🌀
No Operation 😴
+--------+
|00000001|
+--------+
Type=1This option MAY be used between options, for example to align the start of a later option on a 32 bit boundary 📐
MAY be copied, introduced, or deleted on fragmentation, or for any other reason. 🌀
Security 🕵️♀️
This option gives hosts a way to send security, compartmentation, handling restrictions, and TCC (closed user group) parameters 🔒 Here's the format:
+--------+--------+---//---+---//---+---//---+---//---+
|10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |
+--------+--------+---//---+---//---+---//---+---//---+
Type=130 Length=11Security (S field): 16 bits 🎖️
This specifies one of 16 levels of security, and eight of those are reserved for future use 🫣
00000000 00000000 - Unclassified
11110001 00110101 - Confidential
01111000 10011010 - EFTO
10111100 01001101 - MMMM
01011110 00100110 - PROG
10101111 00010011 - Restricted
11010111 10001000 - Secret
01101011 11000101 - Top Secret
00110101 11100010 - (Reserved for future use)
10011010 11110001 - (Reserved for future use)
01001101 01111000 - (Reserved for future use)
00100100 10111101 - (Reserved for future use)
00010011 01011110 - (Reserved for future use)
10001001 10101111 - (Reserved for future use)
11000100 11010110 - (Reserved for future use)
11100010 01101011 - (Reserved for future use)Compartments (C field): 16 bits 🗂️
An all-zero value is used when the information isn't compartmented. Other values for the compartments field MAY be obtained from the Defense Intelligence Agency 🏛️
Handling Restrictions (H field): 16 bits 🚫
The values for the control and release markings are alphanumeric digraphs, and they're defined in the Defense Intelligence Agency Manual DIAM 65-19, "Standard Security Markings" 📕
Transmission Control Code (TCC field): 24 bits 🚦
This provides a way to segregate traffic and define controlled communities of interest among subscribers 👯♀️ The TCC values are trigraphs, and they're available from HQ DCA Code 530.
MUST be copied on fragmentation. This option appears at most once in a datagram. 💜
Loose Source and Record Route 🗺️
+--------+--------+--------+---------//--------+
|10000011| length | pointer| route data |
+--------+--------+--------+---------//--------+
Type=131The loose source and record route (LSRR) option gives the source of an internet datagram a way to supply routing information for the gateways to use when forwarding the datagram to the destination, and it also records the route information 🛤️
The option starts with the option type code 🌱 The second octet is the option length, which includes the option type code, the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data, pointing at the octet that begins the next source address to be processed 👉 The pointer is relative to this option, and the smallest legal value for the pointer is 4 🎀
A route data is composed of a series of internet addresses 🛣️ Each one is 32 bits, or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route is full), so routing is based on the destination address field 🎯
If the destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the one in the destination address field. The recorded route address replaces the source address that was just used, and the pointer goes up by four ✨
The recorded route address is the internet module's own internet address, as known in the environment the datagram is being forwarded into 🏠
Swapping the source route for the recorded route is kind of backwards (it's the reverse of the order you'd need to use it as a source route), but it's genius because the option, and the IP header as a whole, stays the same length the whole way through the internet 📏💅
This option is a loose source route, which means the gateway or host IP is allowed to take any route through any number of other intermediate gateways to reach the next address in the route 🗺️
Must be copied on fragmentation. Appears at most once in a datagram. 🫶
Strict Source and Record Route
+--------+--------+--------+---------//--------+
|10001001| length | pointer| route data |
+--------+--------+--------+---------//--------+
Type=137The strict source and record route (SSRR) option gives the source of an internet datagram a way to supply routing information for the gateways to use when forwarding the datagram to its destination, and to record the route information too 🦋
The option starts with the option type code. The second octet is the option length, which counts the option type code, the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data, pointing to the octet that begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4 🎀
A route data is composed of a series of internet addresses. Each one is 32 bits, or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route is full), so routing is based on the destination address field 🎯
If the destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the one in the destination address field. The recorded route address replaces the source address that was just used, and the pointer goes up by four ✨
The recorded route address is the internet module's own internet address, as known in the environment the datagram is being forwarded into 🏠
Swapping the source route for the recorded route is kind of backwards (it's the reverse of the order you'd need to use it as a source route), but it's genius because the option, and the IP header as a whole, stays the same length the whole way through the internet 📏💅
This option is a strict source route, which means the gateway or host IP must send the datagram directly to the next address in the source route, through only the directly connected network indicated in that next address, to reach the next gateway or host specified in the route 🚦
Must be copied on fragmentation. Appears at most once in a datagram. 🫶
Record Route
+--------+--------+--------+---------//--------+
|00000111| length | pointer| route data |
+--------+--------+--------+---------//--------+
Type=7The record route option is how you record the route an internet datagram takes 📝🌸
The option starts with the option type code. The second octet is the option length, which counts the option type code, the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data, pointing to the octet that begins the next area to store a route address. The pointer is relative to this option, and the smallest legal value for the pointer is 4 🎀
A recorded route is composed of a series of internet addresses. Each one is 32 bits, or 4 octets. If the pointer is greater than the length, the recorded route data area is full. The originating host must compose this option with a route data area that's big enough to hold all the addresses it expects. The size of the option does not change when addresses get added. The initial contents of the route data area must be zero 🧸
When an internet module routes a datagram, it checks whether the record route option is present. If it is, the module inserts its own internet address (as known in the environment the datagram is being forwarded into) into the recorded route, starting at the octet the pointer indicates, and then increments the pointer by four 💁♀️
If the route data area is already full (the pointer exceeds the length), the datagram is forwarded without inserting the address into the recorded route. If there's some room but not enough room for a full address, the original datagram is considered to be in error and is discarded 🗑️ In either case, an ICMP parameter problem message may be sent to the source host [3].
Not copied on fragmentation, goes in first fragment only. Appears at most once in a datagram. 🧚
Stream Identifier
+--------+--------+--------+--------+
|10001000|00000010| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4This option gives a way to carry the 16-bit SATNET stream identifier through networks that don't support the stream concept 🛰️💫
Must be copied on fragmentation. Appears at most once in a datagram. 🫶
Internet Timestamp
+--------+--------+--------+--------+
|01000100| length | pointer|oflw|flg|
+--------+--------+--------+--------+
| internet address |
+--------+--------+--------+--------+
| timestamp |
+--------+--------+--------+--------+
| . |
.
.
Type = 68The Option Length is the number of octets in the option, counting the type, length, pointer, and overflow/flag octets (maximum length 40) 🔢
The Pointer is the number of octets from the beginning of this option to the end of the timestamps, plus one. In other words, it points to the octet that begins the space for the next timestamp. The smallest legal value is 5. The timestamp area is full when the pointer is greater than the length 📍
The Overflow (oflw) [4 bits] is the number of IP modules that can't register timestamps because there isn't enough space 😭
The Flag (flg) [4 bits] values are:
- 0 -- time stamps only, stored in consecutive 32-bit words,
- 1 -- each timestamp is preceded with the internet address of the registering entity,
- 3 -- the internet address fields are prespecified. An IP module only registers its timestamp if it matches its own address with the next specified internet address.
The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight UT. If the time isn't available in milliseconds, or can't be provided with respect to midnight UT, then any time may be inserted as a timestamp, as long as the high order bit of the timestamp field is set to one to indicate a non-standard value 🕛🌈
The originating host must compose this option with a timestamp data area that's big enough to hold all the timestamp information it expects. The size of the option does not change when timestamps get added. The initial contents of the timestamp data area must be zero or internet address/zero pairs 🧮
If the timestamp data area is already full (the pointer exceeds the length), the datagram is forwarded without inserting the timestamp, but the overflow count goes up by one 📈
If there's some room but not enough room for a full timestamp, or the overflow count itself overflows, the original datagram is considered to be in error and is discarded. In either case, an ICMP parameter problem message may be sent to the source host [4]. Wait, correction: the original cites [3] there, so it is [3]. 💀
The timestamp option is not copied upon fragmentation. It is carried in the first fragment. Appears at most once in a datagram. 🧚♀️
Padding: variable
The internet header padding is used to make sure the internet header ends on a 32 bit boundary. The padding is zero 🩷
3.2. Discussion
The implementation of a protocol must be robust 💪 Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol, there is always a possibility of differing interpretations 🤷♀️ In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That means it must be careful to send well-formed datagrams, but must accept any datagram it can interpret (for example, it shouldn't object to technical errors where the meaning is still clear) 🫶
The basic internet service is datagram oriented, and it provides for the fragmentation of datagrams at gateways, with reassembly happening at the destination internet protocol module in the destination host 📦 Of course, fragmentation and reassembly of datagrams within a network, or by private agreement between the gateways of a network, is also allowed, since it's transparent to the internet protocols and the higher-level protocols. This transparent type of fragmentation and reassembly is termed "network-dependent" (or intranet) fragmentation, and it isn't discussed further here 🙈
Internet addresses distinguish sources and destinations down to the host level, and they provide a protocol field as well. It's assumed that each protocol will provide whatever multiplexing is necessary within a host 🧩
Addressing
To give flexibility in assigning addresses to networks, and to allow for the large number of small to intermediate sized networks, the interpretation of the address field is coded to specify a small number of networks with a large number of hosts, a moderate number of networks with a moderate number of hosts, and a large number of networks with a small number of hosts. There's also an escape code for extended addressing mode 🌈
Address Formats:
High Order Bits Format Class
--------------- ------------------------------- -----
0 7 bits of net, 24 bits of host a
10 14 bits of net, 16 bits of host b
110 21 bits of net, 8 bits of host c
111 escape to extended addressing modeA value of zero in the network field means this network. 🌸 This is only used in certain ICMP messages. The extended addressing mode is undefined. Both of these features are reserved for future use. 💅
The actual values assigned for network addresses are given in "Assigned Numbers" [9]. 📖
The local address, assigned by the local network, must allow for a single physical host to act as several distinct internet hosts. 🦋 That is, there must be a mapping between internet host addresses and network/host interfaces that allows several internet addresses to correspond to one interface. It must also be allowed for a host to have several physical interfaces and to treat the datagrams from several of them as if they were all addressed to a single host. Iconic multitasking, honestly. ✨
Address mappings between internet addresses and addresses for ARPANET, SATNET, PRNET, and other networks are described in "Address Mappings" [5]. 🗺️
Fragmentation and Reassembly
Okay, so the internet identification field (ID) is used together with the source and destination address, and the protocol fields, to identify datagram fragments for reassembly. 🧩 It's giving puzzle pieces, bestie. 💜
The More Fragments flag bit (MF) is set if the datagram is not the last fragment. The Fragment Offset field identifies the fragment location, relative to the beginning of the original unfragmented datagram. Fragments are counted in units of 8 octets. The fragmentation strategy is designed so that an unfragmented datagram has all zero fragmentation information (MF = 0, fragment offset = 0). 🎀 If an internet datagram is fragmented, its data portion must be broken on 8 octet boundaries. Lowkey the most important rule in this whole section. 👑
This format allows 2**13 = 8192 fragments of 8 octets each for a total of 65,536 octets. 🌈 Note that this is consistent with the datagram total length field (of course, the header is counted in the total length and not in the fragments). Math checks out, periodt. 💅
When fragmentation occurs, some options are copied, but others remain with the first fragment only. 🍓
Every internet module must be able to forward a datagram of 68 octets without further fragmentation. 🧚 This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Honestly so smart. 🥹
Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. 🫶
The fields which may be affected by fragmentation include:
- options field
- more fragments flag
- fragment offset
- internet header length field
- total length field
- header checksum
If the Don't Fragment flag (DF) bit is set, then internet fragmentation of this datagram is NOT permitted, although it may be discarded. ⚠️ This can be used to prohibit fragmentation in cases where the receiving host does not have sufficient resources to reassemble internet fragments. Boundaries, bestie. 🙅♀️
One example of use of the Don't Fragment feature is to down line load a small host. A small host could have a boot strap program that accepts a datagram, stores it in memory, and then executes it. 🦋
The fragmentation and reassembly procedures are most easily described by examples. 🍭 The following procedures are example implementations.
General notation in the following pseudo programs: "=<" means "less than or equal", "#" means "not equal", "=" means "equal", "<-" means "is set to". Also, "x to y" includes x and excludes y; for example, "4 to 7" would include 4, 5, and 6 (but not 7). 📝
An Example Fragmentation Procedure
The maximum sized datagram that can be transmitted through the next network is called the maximum transmission unit (MTU). 🌷
If the total length is less than or equal the maximum transmission unit, then submit this datagram to the next step in datagram processing. Otherwise, cut the datagram into two fragments: the first fragment being the maximum size, and the second fragment being the rest of the datagram. The first fragment is submitted to the next step in datagram processing, while the second fragment is submitted to this procedure in case it is still too large. It's like a loop of "is this still too big? cut again" 🔁
Notation:
FO - Fragment Offset
IHL - Internet Header Length
DF - Don't Fragment flag
MF - More Fragments flag
TL - Total Length
OFO - Old Fragment Offset
OIHL - Old Internet Header Length
OMF - Old More Fragments flag
OTL - Old Total Length
NFB - Number of Fragment Blocks
MTU - Maximum Transmission UnitProcedure:
IF TL =< MTU THEN Submit this datagram to the next step
in datagram processing ELSE IF DF = 1 THEN discard the
datagram ELSE
To produce the first fragment:
(1) Copy the original internet header;
(2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
(3) NFB <- (MTU-IHL*4)/8;
(4) Attach the first NFB*8 data octets;
(5) Correct the header:
MF <- 1; TL <- (IHL*4)+(NFB*8);
Recompute Checksum;
(6) Submit this fragment to the next step in
datagram processing;
To produce the second fragment:
(7) Selectively copy the internet header (some options
are not copied, see option definitions);
(8) Append the remaining data;
(9) Correct the header:
IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
TL <- OTL - NFB*8 - (OIHL-IHL)*4);
FO <- OFO + NFB; MF <- OMF; Recompute Checksum;
(10) Submit this fragment to the fragmentation test; DONE.In the above procedure, each fragment (except the last) was made the maximum allowable size. 🧁 An alternative might produce less than the maximum size datagrams. For example, one could implement a fragmentation procedure that repeatedly divides large datagrams in half until the resulting fragments are less than the maximum transmission unit size. Divide and conquer, but make it a vibe. ✂️💖
An Example Reassembly Procedure
For each datagram, the buffer identifier is computed as the concatenation of the source, destination, protocol, and identification fields. 🪪 If this is a whole datagram (that is, both the fragment offset and the more fragments fields are zero), then any reassembly resources associated with this buffer identifier are released and the datagram is forwarded to the next step in datagram processing. ✅
If no other fragment with this buffer identifier is on hand, then reassembly resources are allocated. The reassembly resources consist of a data buffer, a header buffer, a fragment block bit table, a total data length field, and a timer. ⏰ The data from the fragment is placed in the data buffer according to its fragment offset and length, and bits are set in the fragment block bit table corresponding to the fragment blocks received.
If this is the first fragment (that is, the fragment offset is zero), this header is placed in the header buffer. If this is the last fragment (that is, the more fragments field is zero), the total data length is computed. If this fragment completes the datagram (tested by checking the bits set in the fragment block table), then the datagram is sent to the next step in datagram processing. Otherwise, the timer is set to the maximum of the current timer value and the value of the time to live field from this fragment, and the reassembly routine gives up control. 🫠
If the timer runs out, all reassembly resources for this buffer identifier are released. The initial setting of the timer is a lower bound on the reassembly waiting time. This is because the waiting time will be increased if the Time to Live in the arriving fragment is greater than the current timer value, but will not be decreased if it is less. The maximum this timer value could reach is the maximum time to live (approximately 4.25 minutes). ⌛ The current recommendation for the initial timer setting is 15 seconds. This may be changed as experience with this protocol accumulates. Note that the choice of this parameter value is related to the buffer capacity available and the data rate of the transmission medium; that is, data rate times timer value equals buffer size (e.g., 10Kb/s X 15s = 150Kb). 🧮
Notation:
FO - Fragment Offset
IHL - Internet Header Length
MF - More Fragments flag
TTL - Time To Live
NFB - Number of Fragment Blocks
TL - Total Length
TDL - Total Data Length
BUFID - Buffer Identifier
RCVBT - Fragment Received Bit Table
TLB - Timer Lower BoundProcedure:
(1) BUFID <- source|destination|protocol|identification;
(2) IF FO = 0 AND MF = 0
(3) THEN IF buffer with BUFID is allocated
(4) THEN flush all reassembly for this BUFID;
(5) Submit datagram to next step; DONE.
(6) ELSE IF no buffer with BUFID is allocated
(7) THEN allocate reassembly resources
with BUFID;
TIMER <- TLB; TDL <- 0;
(8) put data from fragment into data buffer with
BUFID from octet FO*8 to
octet (TL-(IHL*4))+FO*8;
(9) set RCVBT bits from FO
to FO+((TL-(IHL*4)+7)/8);
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN put header in header buffer
(12) IF TDL # 0
(13) AND all RCVBT bits from 0
to (TDL+7)/8 are set
(14) THEN TL <- TDL+(IHL*4)
(15) Submit datagram to next step;
(16) free all reassembly resources
for this BUFID; DONE.
(17) TIMER <- MAX(TIMER,TTL);
(18) give up until next fragment or timer expires;
(19) timer expires: flush all reassembly with this BUFID; DONE.In the case that two or more fragments contain the same data, either identically or through a partial overlap, this procedure will use the more recently arrived copy in the data buffer, and the datagram is delivered. 🕵️♀️ Newest copy wins, that's the rule. 💅
Identification
The choice of the Identifier for a datagram is based on the need to provide a way to uniquely identify the fragments of a particular datagram. 🆔 The protocol module assembling fragments judges fragments to belong to the same datagram if they have the same source, destination, protocol, and Identifier. Thus, the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet. ⏳ Like, unique name, unique timeline. 🌈
It seems then that a sending protocol module needs to keep a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the internet. 📒
However, since the Identifier field allows 65,536 different values, some hosts may be able to simply use unique identifiers independent of destination. 🦄 Plot twist, a big enough field makes life easier. 🫶✨
It's giving "built for the long haul," so let's get into it. Some higher level protocols can pick the identifier themselves 💅. Like, TCP modules might retransmit an identical TCP segment, and the odds of a clean reception go up if that retransmission carries the same identifier as the original, because fragments from either datagram could be used to rebuild a correct TCP segment 🧩. Iconic behavior, honestly.
Type of Service 🎀
Okay so the type of service (TOS) is how the internet picks its service quality ✨. It's described with four abstract parameters: precedence, delay, throughput, and reliability. Those get mapped onto the actual service parameters of whatever networks the datagram travels through 🌐.
- Precedence. An independent measure of how important this datagram is 👑.
- Delay. Prompt delivery matters for datagrams with this setting ⏩.
- Throughput. A high data rate matters for datagrams with this setting 🚀.
- Reliability. A higher level of effort to make sure delivery happens matters for datagrams with this setting 🫶.
Now the example, which is so fun 🦋. The ARPANET has a priority bit, and a choice between "standard" messages (type 0) and "uncontrolled" messages (type 3). (Choosing between single packet and multipacket messages can also count as a service parameter.) Uncontrolled messages tend to be less reliably delivered, but they suffer less delay 🐢. Say an internet datagram is going through the ARPANET with this TOS:
Precedence: 5
Delay: 0
Throughput: 1
Reliability: 1So the mapping works like this: set the ARPANET priority bit on, since the Internet precedence is in the upper half of its range. Select standard messages, since throughput and reliability are asked for and delay isn't 🎯. More details on service mappings are in "Service Mappings" [8] 📚.
Time to Live ⏳
The sender sets the time to live to the maximum time the datagram is allowed to be in the internet system. If the datagram sticks around longer than its TTL, the datagram MUST be destroyed 💀.
This field MUST be decreased at each point where the internet header gets processed, to reflect the time spent processing the datagram. Even if there's no local info on how long it actually took, the field MUST be decremented by 1 ⏱️. The time is measured in seconds (so a value of 1 means one second). That makes the maximum TTL 255 seconds, or 4.25 minutes. Every module that processes a datagram MUST decrease the TTL by at least one, even if it handles the datagram in less than a second. So the TTL MUST be thought of only as an upper bound on how long a datagram can exist 🫧. The whole point is to get undeliverable datagrams discarded and to cap the maximum datagram lifetime 🗑️.
Some higher level reliable connection protocols are built on the assumption that old duplicate datagrams won't arrive after a certain amount of time has passed. The TTL gives those protocols an assurance that their assumption holds 🔐.
Options 🧩
The options are OPTIONAL in each datagram, but REQUIRED in implementations. So the presence or absence of an option is the sender's choice, but each internet module MUST be able to parse every option. Several options can be present in the option field at the same time 📦.
Options might not end on a 32-bit boundary. In that case the internet header MUST be filled out with octets of zeros. The first of those zeros gets read as the end-of-options option, and the rest are internet header padding 🛁.
Every internet module MUST be able to act on every option. The Security Option is REQUIRED if classified, restricted, or compartmented traffic is going to be passed 🔒.
Checksum 🧮
The internet header checksum gets recomputed if the internet header changes. For example, that happens when the time to live is reduced, when options are added or changed, or because of fragmentation. This checksum at the internet level is there to protect the internet header fields from transmission errors 🛡️.
Some applications are fine with a few data bit errors, but can't handle retransmission delays. If the internet protocol enforced data correctness, those applications couldn't be supported at all 🎮.
Errors 🚨
Internet protocol errors MAY be reported via the ICMP messages [3] 💌.
3.3. Interfaces 🔌
Real talk: the functional description of user interfaces to the IP is, at best, fictional, since every operating system has different facilities 🙈. So we have to warn you that different IP implementations can have different user interfaces. Still, all IPs MUST provide a certain minimum set of services, so that every IP implementation can support the same protocol hierarchy. This section specifies the functional interfaces REQUIRED of all IP implementations 🧱.
The internet protocol has an interface on one side to the local network and on the other side to either a higher level protocol or an application program. From here on, the higher level protocol, application program (or even a gateway program) gets called the "user," since it's the one using the internet module 💁♀️. IP is a datagram protocol, so there's minimal memory or state kept between datagram transmissions. Each call the user makes to the internet protocol module supplies all the information IP needs to perform the requested service 🎁.
An Example Upper Level Interface 💜
The following two example calls satisfy the requirements for user-to-internet-protocol module communication ("=>" means returns) ✨:
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
where:
src = source address
dst = destination address
prot = protocol
TOS = type of service
TTL = time to live
BufPTR = buffer pointer
len = length of buffer
Id = Identifier
DF = Don't Fragment
opt = option data
result = response
OK = datagram sent ok
Error = error in arguments or local network errorNote that the precedence is included in the TOS, and the security/compartment is passed as an option 🔐.
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
where:
BufPTR = buffer pointer
prot = protocol
result = response
OK = datagram received ok
Error = error in arguments
len = length of buffer
src = source address
dst = destination address
TOS = type of service
opt = option dataSo when the user sends a datagram, it runs the SEND call and supplies all the arguments 📤. The internet protocol module checks the arguments, then prepares and sends the message. If the arguments are good and the local network accepts the datagram, the call returns successfully ✅. If the arguments are bad, or the local network doesn't accept the datagram, the call returns unsuccessfully ❌. On unsuccessful returns, a reasonable report MUST be made about the cause of the problem, but the details of those reports are up to each implementation 📝.
When a datagram arrives at the internet protocol module from the local network, there's either a pending RECV call from the addressed user or there isn't 📬. If there is, that pending call gets satisfied by passing the datagram's information to the user. If there isn't, the addressed user gets notified of a pending datagram. If the addressed user doesn't exist, an ICMP error message gets returned to the sender, and the data is discarded 🗑️.
The notification of a user MAY be via a pseudo interrupt or a similar mechanism, depending on what fits the operating system environment of the implementation ⚡.
A user's RECV call might be satisfied right away by a pending datagram. Or the call might sit pending until a datagram arrives ⏸️.
The source address is included in the send call in case the sending host has several addresses (multiple physical connections or logical addresses) 🌈. The internet module MUST check that the source address is one of the legal addresses for this host 🕵️.
An implementation MAY also allow or require a call to the internet module to indicate interest in, or reserve exclusive use of, a class of datagrams (for example, all those with a certain value in the protocol field) 🎯.
This section functionally characterizes a USER/IP interface. The notation is similar to most procedure or function calls in high level languages, but this usage is not meant to rule out trap type service calls (e.g., SVCs, UUOs, EMTs), or any other form of interprocess communication 🧚.
APPENDIX A: Examples & Scenarios 📚
Example 1:
This is an example of the minimal data carrying internet datagram 🍓:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 1 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 5.Note that each tick mark represents one bit position 📏.
This is an internet datagram in version 4 of internet protocol. The internet header consists of five 32 bit words, and the total length of the datagram is 21 octets. This datagram is a complete datagram (not a fragment) 💖.
Example 2: 🎀 Fragmentation Time
okay bestie, this one is giving fragmentation 🦋 we start with a moderate size internet datagram (452 data octets), and then we look at the two internet fragments that could come out of splitting it if the maximum sized transmission allowed is 280 octets 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Example Internet Datagram 💜
Figure 6.
now the first fragment, which comes from splitting the datagram after 256 data octets ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Example Internet Fragment 🌸
Figure 7.
and the second fragment, the final slay 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Example Internet Fragment 🌸
Figure 8.
Example 3: 🧚 Datagram With Options
and last but not least, a datagram that carries options 🍓 these are the extras stuffed into the header, and you can see them packed into the rows below 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Len. = 4 | option value | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Example Internet Datagram 💜
Figure 9.
APPENDIX B: ✨ Data Transmission Order
okay so here's the vibe for how bits and bytes actually leave the building 🚀 the order of transmission for the header and data in this document is figured out all the way down to the octet level 🫶 whenever a diagram shows a group of octets, they go out in the normal order you'd read them in English, so the one below goes out in the order the numbers show 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Transmission Order of Bytes 🦋
Figure 10.
now for bits. whenever an octet holds a numeric quantity, the leftmost bit in the diagram is the high order bit, aka the most significant bit 💅 so the bit labeled 0 is the most significant one. the diagram below stands for the decimal value 170 ✨
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+Significance of Bits 🌈
Figure 11.
same energy for bigger numbers 🔥 when a multi-octet field holds a numeric quantity, the leftmost bit of the whole field is the most significant bit, and the most significant octet is the one that gets transmitted first 👑
GLOSSARY 📖
okay bestie, the glossary is where we lock in the vocab 🧠 here's the tea on each term:
1822 BBN Report 1822, "The Specification of the Interconnection of a Host and an IMP". This is the spec for the interface between a host and the ARPANET 🛸
ARPANET leader The control info on an ARPANET message, sitting at the host-IMP interface 🎀
ARPANET message The unit of transmission between a host and an IMP in the ARPANET. The max size is about 1012 octets (8096 bits) 💖
ARPANET packet A unit of transmission used inside the ARPANET between IMPs. The max size is about 126 octets (1008 bits) ✨
Destination The destination address, which is an internet header field 🦋
DF The Don't Fragment bit, carried in the flags field 🙈
Flags An internet header field that carries various control flags 🚩
Fragment Offset This internet header field shows where in the internet datagram a fragment belongs 🧩
GGP Gateway to Gateway Protocol. It's the protocol mostly used between gateways to handle routing and other gateway functions 🌐
header The control info at the very beginning of a message, segment, datagram, packet or block of data 🫶
ICMP Internet Control Message Protocol. It's implemented in the internet module, and it's what gateways use to talk to hosts (and hosts use between each other) to report errors and make routing suggestions 📣
Identification An internet header field holding the identifying value the sender assigned, which helps put the fragments of a datagram back together 🧷
IHL The internet header field Internet Header Length. It's the length of the internet header, measured in 32 bit words 📏
IMP The Interface Message Processor, which is the packet switch of the ARPANET 🔌
Internet Address A four octet (32 bit) source or destination address made up of a Network field and a Local Address field 🏠
internet datagram The unit of data exchanged between a pair of internet modules. It includes the internet header 📦
internet fragment A portion of the data from an internet datagram, along with an internet header 🧩
Local Address The address of a host within a network. The actual mapping of an internet local address onto the host addresses in a network is pretty general, and it allows for many to one mappings 🗺️
MF The More-Fragments Flag, carried in the internet header flags field 🚩
module An implementation, usually in software, of a protocol or other procedure 💻
more-fragments flag A flag that says whether or not this internet datagram contains the end of an internet datagram. It's carried in the internet header Flags field 🏁
NFB The Number of Fragment Blocks in the data portion of an internet fragment. In other words, it's the length of a portion of data measured in 8 octet units 🍰
octet An eight bit byte 💜
Options 🎀 The internet header Options field can hold several options, and each option can be several octets long. Options are a whole mini-collection, bestie. 🧚
Padding 🫶 The internet header Padding field makes sure the data starts on a 32 bit word boundary. The padding is zero, so it's basically just a cozy little pillow of zeros. 🌸
Protocol 💜 In this document, this is the next higher level protocol identifier, which is an internet header field. Think of it as the header saying "hey, who's the next protocol I should hand this to?" 💅
Rest 🦋 This is the local address portion of an Internet Address. It's the part that's left over after the network bit, so it's giving local. ✨
Source 🍓 The source address is an internet header field. It tells everyone where the datagram came from, no cap. 🔥
TCP 🌈 Transmission Control Protocol is a host-to-host protocol for reliable communication in internet environments. It's the one that's always making sure nothing gets lost, iconic behavior. 👑
TCP Segment 🧚 This is the unit of data exchanged between TCP modules, and it includes the TCP header. The header is part of the segment, so it's literally one whole package. 🎀
TFTP 🌸 Trivial File Transfer Protocol is a simple file transfer protocol built on UDP. It's small and simple, and honestly that's the vibe. 🦋
Time to Live ⏳ This is an internet header field that shows the upper bound on how long this internet datagram may exist. It's a limit, bestie, so it can't just wander forever. 💀
TOS 💖 This stands for Type of Service. ✨
Total Length 🍓 The internet header field Total Length is the length of the datagram in octets, counting both the internet header and the data. So it's the full size of the whole thing, lowkey the most important number in the header. 📏
TTL 🌈 This stands for Time to Live. Same field, same energy. 🫶
Type of Service 💅 This is an internet header field that indicates the type (or quality) of service for this internet datagram. It's basically how this datagram wants to be treated, and it's giving main character. 👑
UDP 🦋 User Datagram Protocol is a user level protocol for transaction oriented applications. It's the quick and lightweight one, periodt. 🔥
User 🧚 This is the user of the internet protocol. It might be a higher level protocol module, an application program, or a gateway program. Basically whoever is calling the shots. 💜
Version 🌸 The Version field shows the format of the internet header. It's how you know what kind of header you're looking at, so it's super important, no cap. 🎀
References 📚
- [1] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
- [2] Bolt Beranek and Newman, "Specification for the Interconnection of a Host and an IMP," BBN Technical Report 1822, Revised May 1978.
- [3] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981.
- [4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON, IEEE Computer Society, Fall 1978.
- [5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences Institute, September 1981.
- [6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer Networks, v. 3, n. 1, February 1979.
- [7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.
- [8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences Institute, September 1981.
- [9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences Institute, September 1981.
Bestie, that's the whole RFC! We did it. 🥹🌈✨
📦 where this page comes from
- ietf: rfc791 1981-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms