RFC 760
DoD standard Internet Protocol
RFC 760: DoD Standard Internet Protocol 💖
- RFC: 760
- IEN: 128
- Date: January 1980
- Author and editor: Jon Postel 🫶
- Prepared for: Defense Advanced Research Projects Agency, Information Processing Techniques Office, 1400 Wilson Boulevard, Arlington, Virginia 22209
- Prepared by: Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291
- Replaces: IENs 123, 111, 80, 54, 44, 41, 28, 26
- Category/status: not stated in this document
- Obsoletes/updates: this document doesn't name any RFC it obsoletes or updates, so the only replacement listed is the set of IENs above
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 ................................... 5
2.2 Model of Operation ............................................ 5
2.3 Function Description .......................................... 7
3. SPECIFICATION ................................................... 11
3.1 Internet Header Format ....................................... 11
3.2 Discussion ................................................... 21
3.3 Examples & Scenarios ......................................... 30
3.4 Interfaces ................................................... 34
GLOSSARY ............................................................ 37
REFERENCES .......................................................... 41PREFACE 🎀
okay so this document specifies the DoD Standard Internet Protocol 🌸 It's based on five earlier editions of the ARPA Internet Protocol Specification, and the present text draws heavily from them. Tons of people contributed to this work, both to the concepts and to the text, so big love to all of them 💕 This edition revises the details security, compartmentation, and precedence features of the internet protocol. The preface is signed by Jon Postel, Editor ✍️
1. Introduction ✨
1.1. Motivation
so the Internet Protocol is designed for interconnected systems of packet-switched computer communication networks 🌐 That kind of system is called a "catenet" [1]. The 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 🧚 The internet protocol also handles fragmentation and reassembly of long datagrams, when that's needed, so they can travel through "small packet" networks 🦋
1.2. Scope
this one is lowkey very focused 🎯 The internet protocol only does what's needed to deliver a package of bits (an internet datagram) from a source to a destination across an interconnected system of networks. It does not have mechanisms for data reliability, flow control, sequencing, or the other services you'd usually find in host-to-host protocols. That's not a flaw, it's just the job description 💅
1.3. Interfaces
this protocol gets called on by host-to-host protocols in an internet environment 📞 In turn, it calls on local network protocols to carry the internet datagram to the next gateway or destination host.
for example, a TCP module would call on the internet module and hand it a TCP segment (the TCP header plus user data) as the data portion of an internet datagram 🍓 The TCP module also gives the internet module the addresses and other parameters for the internet header, as arguments of the call. Then the internet module builds the internet datagram and calls on the local network interface to transmit it 🚀
in the ARPANET case, the internet module would call on a local net module. That module adds the 1822 leader [2] to the internet datagram, which makes an ARPANET message to send to the IMP 📦 The local network interface derives the ARPANET address from the internet address. That address belongs to some host in the ARPANET, and 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 needed for transmission through "small packet" networks 🧩
the model of operation is that an internet module lives in every host doing internet communication, and in every gateway that connects networks 🏠 These modules share common rules for interpreting address fields and for fragmenting and assembling internet datagrams. The modules, especially in gateways, may also have procedures for making routing decisions and handling other functions 👑
the internet protocol treats each internet datagram as an independent entity that isn't related to any other internet datagram. There are no connections or logical circuits, virtual or otherwise 🦄
the internet protocol uses four key mechanisms to provide its service: Type of Service, Time to Live, Options, and Header Checksum ⭐
Type of Service is how you say what quality of service you want. You can think of it as picking between Interactive, Bulk, or Real Time, for example. It's an abstract, generalized set of parameters that describe the service choices offered by the networks making up the internet. Gateways use this indication to choose the actual transmission parameters for a particular network, the network for the next hop, or the next gateway when routing an internet datagram 🎀
Time to Live tells you how long an internet datagram can live 💀 The sender sets it, and it gets reduced at each point on the route where the datagram is processed. If the time to live hits zero before the datagram reaches its destination, the datagram is destroyed. Honestly, think of it as a self destruct timer ⏳
Options provide control functions that are needed or useful in some situations, but not necessary for the most common communications 🧰 The options include timestamps, error reports, and special routing.
Header Checksum verifies that the information used in processing an internet datagram was transmitted correctly 🔍 The data itself may contain errors. If the header checksum fails, the entity that detects the error throws the internet 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. There's no error control for data, just the header checksum. There are no retransmissions, and there's no flow control. It's giving minimalist, and honestly that's the point 💅
2. Overview 🌷
2.1. Relation to Other Protocols
this diagram shows where the internet protocol sits in the protocol hierarchy 🪜
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | |
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol |
+-------------------------------+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
|
Protocol Relationships
Figure 1.the internet protocol talks upward to the higher level host-to-host protocols, and downward to the local network protocol 🥰
2.2. Model of Operation
okay so here's the model for sending a datagram from one application program to another, as a little scenario 🎬 We suppose this transmission will involve one intermediate gateway 🌉
the sending application program prepares its data and calls its local internet module to send that data 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. In this case, that's the address of a gateway. Then it sends the 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, and sends the result over the local network 📡
the datagram arrives 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 that the datagram should be forwarded to another host on a second network 🔀 It works out a local net address for the destination host, then calls on the local network interface for that network to send the datagram.
that local network interface creates a local network header and attaches the datagram to it, then sends 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 that the datagram is for an application program on this host. It passes the data to that application program in response to a system call, and passes the source address and other parameters 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 2Transmission Path
Figure 2
2.3. Function Description ✨
okay so the whole point of Internet Protocol 💖 is moving datagrams through a bunch of interconnected networks. It does that by passing each datagram from one internet module to the next until it reaches its destination. Internet modules live in hosts and gateways, and datagrams get routed from one module to another through individual networks based on how an internet address is interpreted. So the internet address is literally the key mechanism 🔑
Sometimes a datagram has to cross a network whose maximum packet size is smaller than the datagram itself 😬 to fix that, IP has a fragmentation mechanism 🧩
Addressing
okay the spec makes a distinction between names, addresses, and routes [3] 🗺️ a name says what we're looking for, an address says where it is, and a route says how to get there. IP mostly deals with addresses. Higher level (host-to-host or application) protocols do the name-to-address mapping, and the internet module maps internet addresses to local net addresses. Then lower level (local net or gateway) procedures handle mapping local net addresses to routes.
Addresses are a fixed length of four octets (32 bits) 💅 an address starts with a one octet network number, followed by a three octet local address. That three octet field is called the "rest" field.
Care MUST be taken in mapping internet addresses to local net addresses 🫶 a single physical host MUST be able to act as if it were several distinct hosts, using several distinct internet addresses. A host SHOULD also be able to have several physical interfaces (multi-homing) 🌸
Basically, a host SHOULD be allowed several physical interfaces to the network, with each one having several logical internet addresses 🦋
Examples of address mappings MAY be found in reference [4] 📚
Fragmentation
Fragmentation of an internet datagram MAY be necessary when it starts in a local net that allows a large packet size and has to cross a local net that limits packets to a smaller size to get to its destination 🥹
An internet datagram can be marked "don't fragment." Any internet datagram marked that way is not to be internet fragmented under any circumstances 🙅♀️ and if a don't fragment datagram can't reach its destination without being fragmented, it gets discarded instead. Periodt 💀
Fragmenting, transmitting, and reassembling across a local network that's invisible to the internet protocol module is called intranet fragmentation, and it MAY be used [5] ✨
The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be reassembled later 🧩 the receiver uses the identification field so 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 determine which portion of the original datagram that fragment covers. The more-fragments flag, when it's reset (set to zero), marks the last fragment. Those fields give the receiver enough info to reassemble everything 💜
The identification field is how the fragments of one datagram get told apart from another's 🎀 the originating protocol module sets it 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 protocol 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, in a gateway) makes two new internet datagrams and copies the internet header fields from the long datagram into both new headers 👑 the long datagram's data gets split into two portions on an 8 octet (64 bit) boundary. The second portion might not be a multiple of 8 octets, but the first one has to 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 datagram, and its total length field is set to that datagram's length. Its more-fragments flag is set to one. The second portion goes into the second new datagram, its total length field is set to that datagram's length, and its more-fragments flag carries the same value as the long datagram. The fragment offset of the second new datagram is set to the long datagram's fragment offset 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, at a destination host) combines the internet datagrams that all share the same values for the four fields: identification, source, destination, and protocol 🫧 each fragment's data portion goes into the relative position indicated by that fragment's fragment offset in its internet header. The first fragment has fragment offset zero, and the last fragment has its more-fragments flag reset to zero 🏁
3. SPECIFICATION
3.1. Internet Header Format
okay here's the header summary, and it's giving structure 🎀
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 3.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
Internet Header Length is the length of the internet header in 32 bit words, so 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 guide the choice of the actual service parameters when a datagram is transmitted through a particular network. Several networks offer service precedence, which basically treats high precedence traffic as more important than everything else. A few networks offer a Stream service, where you can get a smoother service at some cost, which typically means reserving resources within the network. Another option is a low-delay vs. high-reliability trade off. Networks usually invoke more complex (and delay-producing) mechanisms as the need for reliability goes up 🫠
Bits 0-2: Precedence.
Bit 3: Stream or Datagram.
Bits 4-5: Reliability.
Bit 6: Speed over Reliability.
Bits 7: Speed.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | |
| PRECEDENCE | STRM|RELIABILITY| S/R |SPEED|
| | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
PRECEDENCE STRM RELIABILITY S/R SPEED
111-Flash Override 1-STREAM 11-highest 1-speed 1-high
110-Flash 0-DTGRM 10-higher 0-rlblt 0-low
11X-Immediate 01-lower
01X-Priority 00-lowest
00X-RoutineThe type of service is used to specify how a datagram gets treated while it's moving through the internet system 🚀 in the discussion below (section 3.2), a chart shows how the internet type of service relates to the actual service provided on the ARPANET, the SATNET, and the PRNET ✨
Total Length: 16 bits
Total Length is the length of the datagram in octets, counting both the internet header and the data 📦 this field lets a datagram be up to 65,535 octets. Honestly, datagrams that long 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 was picked to allow a reasonable sized data block to be sent along with the required header info 🧁 for example, this size lets a data block of 512 octets plus 64 header octets fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, which leaves a margin for the headers of higher level protocols 🌷
Identification: 16 bits
An identifying value assigned by the sender to help assemble the fragments of a datagram 🧩
Flags: 3 bits
Various Control Flags 🚩
Bit 0: reserved, MUST be zero
Bit 1: Don't Fragment This Datagram (DF).
Bit 2: More Fragments Flag (MF).
0 1 2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+Fragment Offset: 13 bits
This field shows 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 shows the maximum time the datagram is allowed to remain in the internet system ⏳ if this field contains the value zero, then the datagram SHOULD be destroyed. This field gets modified during internet header processing, and the time is measured in units of seconds. The whole point is to make sure undeliverable datagrams get discarded 🗑️
Heads up: the Time to Live field is how undeliverable datagrams are kept from floating around forever, so don't skip it 💀
Protocol: 8 bits
This field shows the next level protocol used in the data portion of the internet datagram. The values for the various protocols are specified in reference [6] 🎁
Header Checksum: 16 bits
A checksum on the header only. Since some header fields may change (like time to live), this gets recomputed and verified at each point where the internet header is processed 🔐
The checksum algorithm is: 💖
The checksum field 🧮 is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. When you're computing it, the checksum field itself counts as zero 🫶
Lowkey it's a super simple checksum to compute, and experimental evidence says it's adequate 🙌. But it's provisional, so it might get swapped out for a CRC procedure depending on what we learn later 🔮
Source Address: 32 bits 🌸
The source address. The first octet is the Source Network, and the following three octets are the Source Local Address.
Destination Address: 32 bits 🦋
The destination address. The first octet is the Destination Network, and the following three octets are the Destination Local Address.
Options: variable 💅
The option field is variable in length. 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 and the option-length octet as well as the option-data octets.
The option-type octet is viewed as having 3 fields:
1 bit reserved, must be zero
2 bits option class,
5 bits option number.The option classes are:
0 = control
1 = internet error
2 = experimental debugging and measurement
3 = reserved for future useThe following internet options 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 4 Security. Used to carry Security, and user
group (TCC) information compatible with DOD
requirements.
0 3 var. Source Routing. Used to route the internet
datagram based on information supplied by the
source.
0 7 var. Return Route. Used to record the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
1 1 var. General Error Report. Used to report errors
in internet datagram processing.
2 4 6 Internet Timestamp.
2 5 6 Satellite Timestamp.Specific Option Definitions 🧚
End of Option List
+--------+
|00000000|
+--------+
Type=0This option indicates the end of the option list. This might not coincide with the end of the internet header according to the internet header length. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the internet header.
May be copied, introduced, or deleted on fragmentation.
No Operation
+--------+
|00000001|
+--------+
Type=1This option may be used between options, for example, to align the beginning of a subsequent option on a 32 bit boundary.
May be copied, introduced, or deleted on fragmentation.
Security 🔐
This option provides a way for DOD hosts to send security and TCC (closed user groups) parameters through networks whose transport leader does not contain fields for this information. The format for this option is as follows:
+--------+--------+---------+--------+
|00000010|00000100|000000SS | TCC |
+--------+--------+---------+--------+
Type=2 Length=4Security: 2 bits
Specifies one of 4 levels of security:
11-top secret
10-secret
01-confidential
00-unclassifiedTransmission Control Code: 8 bits
Provides a means to compartmentalize traffic and define controlled communities of interest among subscribers.
Note that this option does not require processing by the internet module but does require that this information be passed to higher level protocol modules. The security and TCC information might be used to supply class level and compartment information for transmitting datagrams into or through AUTODIN II.
Must be copied on fragmentation.
Source Route 🗺️
+--------+--------+--------+---------//--------+
|00000011| length | source route |
+--------+--------+--------+---------//--------+
Type=3The source route option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination.
The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, as well as length-2 octets of source route data.
A source route is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. The length defaults to two, which indicates the source route is empty and the remaining routing is to be based on the destination address field.
If the address in destination address field has been reached and this option's length is not two, the next address in the source route replaces the address in the destination address field, and is deleted from the source route and this option's length is reduced by four. (The Internet Header Length Field must be changed also.)
Must be copied on fragmentation.
Return Route 🔁
+--------+--------+--------+---------//--------+
|00000111| length | return route |
+--------+--------+--------+---------//--------+
Type=7The return route option provides a means to record the route of an internet datagram.
The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, as well as length-2 octets of return route data.
A return route is composed of a series of internet addresses. The length defaults to two, which indicates the return route is empty.
When an internet module routes a datagram it checks to see if the return route option is present. If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the return route at the front of the address string and increments the length by four.
Not copied on fragmentation, goes in first fragment only.
Stream Identifier 🌊
+--------+--------+---------+--------+
|00001000|00000010| Stream ID |
+--------+--------+---------+--------+
Type=8 Length=4This option provides a way for the 16-bit SATNET stream identifier to be carried through networks that do not support the stream concept.
Must be copied on fragmentation.
General Error Report 🚨
+--------+--------+--------+--------+--------+----//----+
|00100001| length |err code| id | |
+--------+--------+--------+--------+--------+----//----+
Type=33The general error report is used to report an error detected in processing an internet datagram to the source internet module of that datagram. The "err code" indicates the type of error detected, and the "id" is copied from the identification field of the datagram in error, additional octets of error information may be present depending on the err code.
If an internet datagram containing the general error report option is found to be in error or must be discarded, no error report is sent.
ERR CODE:
- 0 - Undetermined Error, used when no information is available about the type of error or the error does not fit any defined class. Following the id should be as much of the datagram (starting with the internet header) as fits in the option space.
- 1 - Datagram Discarded, used when specific information is available about the reason for discarding the datagram can be reported. Following the id should be the original (4-octets) destination address, and the (1-octet) reason.
The reasons for err code 1 are:
Reason Description
------ -----------
0 No Reason
1 No One Wants It - No higher level protocol or
application program at destination wants this
datagram.
2 Fragmentation Needed & DF - Cannot deliver with out
fragmenting and has don't fragment bit set.
3 Reassembly Problem - Destination could not
reassemble due to missing fragments when time to
live expired.
4 Gateway Congestion - Gateway discarded datagram due
to congestion.The error report is placed in a datagram with the following values in the internet header fields:
Version: Same as the datagram in error.
IHL: As computed.
Type of Service: Zero.
Total Length: As computed.
Identification: A new identification is selected.
Flags: Zero.
Fragment Offset: Zero.
Time to Live: Sixty.
Protocol: Same as the datagram in error.
Header Checksum: As computed.
Source Address: Address of the error reporting module.
Destination Address: Source address of the datagram in error.
Options: The General Error Report Option.
Padding: As needed.Not copied on fragmentation, goes with first fragment.
Internet Timestamp ⏱️
+--------+--------+--------+--------+--------+--------+
|01000100|00000100| time in milliseconds |
+--------+--------+--------+--------+--------+--------+
Type=68 Length=6The data of the timestamp is a 32 bit time measured in milliseconds.
Not copied on fragmentation, goes with first fragment
Satellite Timestamp 🛰️
+--------+--------+--------+--------+--------+--------+
|01000101|00000100| time in milliseconds |
+--------+--------+--------+--------+--------+--------+
Type=69 Length=6The data of the timestamp is a 32 bit time measured in milliseconds.
Not copied on fragmentation, goes with first fragment
Padding: variable 🧸
The internet header padding is used to ensure that the internet header ends on a 32 bit boundary. The padding is zero.
3.2. Discussion
The implementation of a protocol MUST be robust, bestie 💅 Each implementation MUST expect to interoperate with others made by different people 🫶 The spec tries to be super explicit, but there's always room for different readings 🧐 So the vibe is: be careful and conservative when you send (send well-formed datagrams!), but be liberal when you receive. If you can understand a datagram, accept it, even if there's a small technical error where the meaning is still totally clear 🦋 An implementation SHOULD be conservative in its sending behavior, and it SHOULD be careful to send well-formed datagrams, but it SHOULD accept any datagram it can interpret 🌸
The basic internet service is datagram oriented, and it lets gateways fragment datagrams, with the reassembly happening at the destination internet protocol module in the destination host 🎀 Fragmenting and reassembling inside a single network, or by private deal between a network's gateways, is also allowed, since the internet protocols and the higher-level protocols can't even see it 👀 That transparent kind is called "network-dependent" (or intranet) fragmentation, and we're not going to dig into it here 🙈
Internet addresses tell you the source and destination all the way down to the host level, and they also carry a protocol field 💜 Each protocol is responsible for whatever multiplexing it needs inside a host ✨
Addressing
The 8 bit network number is the first octet of the address, and its value is as specified in reference [6] 🌈
The 24 bit local address is assigned by the local network, and it SHOULD allow a single physical host to act like several separate internet hosts 💖 That means there SHOULD be a mapping between internet host addresses and network/host interfaces, so several internet addresses can point at one interface 🧚 It SHOULD also be allowed for a host to have several physical interfaces and treat datagrams from all of them as if they were addressed to one single host 👑 The address mappings between internet addresses and addresses for ARPANET, SATNET, PRNET, and other networks are described in reference [4] 🍓
Fragmentation and Reassembly
The internet identification field (ID) is used together with the source address, destination address, and protocol fields to figure out which datagram fragments belong together for reassembly 🧩
The More Fragments flag bit (MF) is set if the datagram is not the last fragment 🎯 The Fragment Offset field tells you where the fragment sits, relative to the start of the original unfragmented datagram 📍 Fragments are counted in units of 8 octets 🔢 Fragmentation is designed so that an unfragmented datagram has all-zero fragmentation info (MF = 0, fragment offset = 0) ✨ If an internet datagram gets fragmented, its data portion MUST be broken on 8 octet boundaries 🫶
This format allows 2**13 = 8192 fragments of 8 octets each, which adds up to 65,536 octets total 💅 That lines up with the datagram total length field, so it's all consistent 🦋
When fragmentation happens, some options get copied, but others stay with the first fragment only 🎀
Every internet module MUST be able to forward a datagram of 68 octets without further fragmentation 🚀 That's because an internet header MAY be up to 60 octets, and the smallest fragment is 8 octets 🤓
Every internet destination MUST be able to receive a datagram of 576 octets, either in one piece or in fragments that get reassembled 🌸
These are the fields that fragmentation can affect:
- 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 that datagram is NOT permitted, although it MAY be discarded 🚫 This is handy for blocking fragmentation when the receiving host doesn't have enough resources to reassemble fragments 🥺
Heads up: DF = set means no fragmenting, and the datagram can still get dropped. Don't be surprised by that one 🙈
Here's how the pseudo programs read. =< means "less than or equal", # means "not equal", = means "equal", and <- means "is set to" 🧠 Also, "x to y" includes x and excludes y. So "4 to 7" would include 4, 5, and 6, but not 7 🔢
Fragmentation Procedure
The maximum sized datagram that can be sent through the next network is called the maximum transmission unit (MTU) 📏
If the total length is less than or equal to the MTU, then you just submit the datagram to the next step in datagram processing 🙌 Otherwise you cut the datagram into two fragments. The first fragment is the maximum size, and the second fragment is whatever's left. The first fragment goes to the next step in datagram processing, and the second fragment goes back into this procedure in case it's still too large 🔁
Notation:
FO - Fragment Offset
IHL - Internet Header Length
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
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.Reassembly Procedure
For each datagram, the buffer identifier is the concatenation of the source, destination, protocol, and identification fields 🧵 If this is a whole datagram (meaning both the fragment offset and the more fragments fields are zero), then any reassembly resources tied to that buffer identifier get 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 get allocated 🧺 Those resources are a data buffer, a header buffer, a fragment block bit table, a total data length field, and a timer ⏱️ The fragment's data goes into the data buffer according to its fragment offset and length, and bits get set in the fragment block bit table for each fragment block received 🧠
If this is the first fragment (fragment offset is zero), its header goes in the header buffer 🥇 If this is the last fragment (more fragments field is zero), the total data length gets computed 🏁 If this fragment completes the datagram (checked by looking at the bits set in the fragment block table), the datagram goes to the next step in datagram processing 🎊 Otherwise, the timer is set to the maximum of its current value and the time to live field from this fragment, and then the reassembly routine gives up control 😤
If the timer runs out, all the reassembly resources for this buffer identifier get released 💀 The initial timer setting is a lower bound on the reassembly waiting time. The waiting time goes up if the Time to Live in an arriving fragment is greater than the current timer value, but it never goes down if the TTL is smaller ⏳ The biggest this timer value could get is the maximum time to live, which is approximately 4.25 minutes 🕰️ The current recommendation for the initial timer setting is 15 seconds, and that MAY be changed as experience with this protocol builds up 📈 The choice of this value depends on the buffer capacity available and the data rate of the transmission medium. In other words, 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.If two or more fragments contain the same data, either identically or through a partial overlap, this procedure uses the more recently arrived copy in the data buffer, and that's the one that gets delivered 🔄
Identification
The Identifier for a datagram exists so that the fragments of one particular datagram can be uniquely identified 🪪 The protocol module assembling fragments decides that fragments belong to the same datagram if they have the same source, destination, protocol, and Identifier 🧷 So the sender MUST choose the Identifier to be unique for that source, destination pair and protocol, for as long as the datagram (or any fragment of it) could still be alive in the internet ⏳
It seems like a sending protocol module would need a table of Identifiers, with one entry for each destination it has talked to in the last maximum packet lifetime for the internet 📒
However, since the Identifier field allows 65,536 different values, some host MAY be able to just use unique identifiers that don't depend on the destination at all 🌟
It's giving cooperation 🫶 Some higher level protocols are actually allowed to choose the identifier themselves! Like, TCP protocol modules MAY retransmit an identical TCP segment 🔁, and the chance of a correct reception goes UP if that retransmission carries the same identifier as the original, because fragments from either datagram could be used to build a correct TCP segment ✨ teamwork makes the dream work 💖
Type of Service
okay so the type of service (TOS) 🎀 is how you pick your internet service quality. It's specified along three abstract parameters: precedence, reliability, and speed. There's also a concern about handling streams of datagrams efficiently 🌊 These abstract parameters then get mapped into the actual service parameters of whatever networks the datagram travels through, so it's like a translation situation 💅
- Precedence. An independent measure of how important this datagram is 👑
- Stream or Datagram. Tells you whether there will be other datagrams from this source to this destination at regular, frequent intervals, which justifies keeping stream processing info around 🧚
- Reliability. A measure of how much effort is desired to make sure this datagram gets delivered 🫶
- Speed over Reliability. Shows how much speed vs. reliability matters when the two requests clash 🔥
- Speed. A measure of how important it is that this datagram arrives promptly ⭐
For example, the ARPANET has a priority bit, plus a choice between "standard" messages (type 0) and "uncontrolled" messages (type 3). (The choice between single packet and multipacket messages can also count as a service parameter 🍓) Uncontrolled messages tend to be less reliably delivered but suffer less delay, so they're the speedy girls 🦋 Say an internet datagram is going through the ARPANET, and its internet type of service looks like this:
Precedence: 5
Stream: 0
Reliability: 1
S/R: 1
Speed: 1So the mapping goes like this: the ARPANET priority bit gets turned on, since the internet priority sits in the upper half of its range. And uncontrolled messages get selected, since speed and reliability are equally needed and speed is preferred 🏎️💨
The following chart shows the RECOMMENDED mappings from the internet protocol type of service into the service parameters actually available on the ARPANET, the PRNET, and the SATNET. Bestie, this chart is a LOT 😭 but it's worth it:
+------------+----------+----------+----------+----------+
|Application | INTERNET | ARPANET | PRNET | SATNET |
+------------+----------+----------+----------+----------+
|TELNET |S/D:stream| T: 3 | R: ptp | T: block |
| on | R:normal| S: S | A: no | D: min |
| TCP |S/R:speed | | | H: inf |
| | S:fast | | | R: no |
+------------+----------+----------+----------+----------+
|FTP |S/D:stream| T: 0 | R: ptp | T: block |
| on | R:normal| S: M | A: no | D: normal|
| TCP |S/R:rlblt | | | H: inf |
| | S:normal| | | R: no |
+------------+----------+----------+----------+----------+
|interactive |S/D:strm* | T: 3 | R: ptp | T: stream|
|narrow band | R:least | S: S | A: no | D: min |
| speech | P:speed | | | H: short |
| | S:asap | | | R: no |
+------------+----------+----------+----------+----------+
|datagram |S/D:dtgrm | T: 3 or 0| R:station| T: block |
| | R:normal| S: S or M| A: no | D: min |
| |S/R:speed | | | H: short |
| | S:fast | | | R: no |
+------------+----------+----------+----------+----------+
key: S/D=strm/dtgrm T=type R=route T=type
R=reliability S=size A=ack D=delay
S/R=speed/rlblt H=holding time
S=speed R=reliability
*=requires stream set upTime to Live
the time to live is set by the sender 💌 and it's the maximum time the datagram is allowed to hang around in the internet system. If the datagram has been in the internet system longer than its time to live, the datagram SHOULD be destroyed 💀 This field SHOULD be decreased at each point where the internet header gets processed, so it reflects the time spent processing the datagram. Even if there's no local info on the time actually spent, the field SHOULD be decremented by 1 🙈
The time is measured in seconds (i.e. the value 1 means one second), so the maximum time to live is 255 seconds or 4.25 minutes ⏳ that's not very long, honestly, so be quick, bestie 🏃♀️
Options
the options are just that: OPTIONAL 🎀 The presence or absence of an option is the sender's choice, BUT each internet module MUST be able to parse every option. There can be several options in the option field, so it can get busy in there 🐝
The options might not end on a 32-bit boundary. In that case, the internet header SHOULD be filled out with octets of zeros 🧸 The first of these zeros gets interpreted as the end-of-options option, and the rest count as internet header padding.
Every internet module MUST be able to act on the following options: End of Option List (0), No Operation (1), Source Route (3), Return Route (7), General Error Report (33), and Internet Timestamp (68) 👑 The Security Option (2) is REQUIRED only if classified or compartmented traffic is going to be passed 🔐
Checksum
the internet header checksum gets recomputed whenever the internet header changes 🔄 For example: the time to live gets reduced, internet options get added or changed, or fragmentation happens. This checksum at the internet level exists to protect the internet header fields from transmission errors 🛡️ it's literally the bodyguard of the header 💜
3.3. Examples & Scenarios ✨
Example 1:
okay so first up, the tiniest datagram that still carries data 🦋 Here's the layout (each tick mark is one bit 💅):
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 4.so this is a version 4 internet datagram 💖 The internet header is five 32 bit words, and the total length is 21 octets. It's a complete datagram, not a fragment ✨
Example 2:
this one is a moderately sized datagram with 552 data octets 🎀 Then we'll see the two fragments that could come out of it if the biggest transmission allowed were 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 5.first fragment 🧚 this is the datagram split 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 6.and the second fragment 🌈
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 7.Example 3:
here's a datagram that carries options 🍓
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 8.3.4. Interfaces 🎀
okay this part is about how the internet protocol module talks to stuff on both sides 💜 One side faces the local network, and the other faces either a higher level protocol or an application program. From here on, that higher level protocol, application program, or even a gateway program is called the "user" 🫶 Since internet protocol is a datagram protocol, there's barely any memory or state kept between datagram transmissions, so every call the user makes to the module has to bring all the info it needs ✨
For example, these two calls cover what the user needs to do to talk to the module ("=>" means returns) 💅
SEND (dest, TOS, TTL, BufPTR, len, Id, DF, options => result)
where:
dest = destination address
TOS = type of service
TTL = time to live
BufPTR = buffer pointer
len = length of buffer
Id = Identifier
DF = Don't Fragment
options = option data
result = response
OK = datagram sent ok
Error = error in arguments or local network error
RECV (BufPTR => result, source, dest, prot, TOS, len)
where:
BufPTR = buffer pointer
result = response
OK = datagram received ok
Error = error in arguments
source = source address
dest = destination address
prot = protocol
TOS = type of service
len = length of bufferwhen the user wants to send a datagram, it runs SEND and hands over all the arguments 🚀 The module checks the arguments, then prepares and sends the message. If the arguments are fine and the local network accepts the datagram, the call returns successfully. If the arguments are bad, or the local network won't accept the datagram, the call returns unsuccessfully. after an unsuccessful return, a reasonable report should be made about what caused the problem, but how those reports look is up to each implementation 🙈
when a datagram shows up at the module from the local network, there's either a pending RECV call from the addressed user or there isn't 💖 If there is one, that call gets satisfied by passing the datagram's info to the user. If there isn't, the addressed user gets notified that a datagram is waiting. If the addressed user doesn't exist, an error datagram goes back to the sender and the data gets thrown away 💀
the notification to a user can come through a pseudo interrupt or a similar mechanism, depending on the operating system environment of the implementation ⭐
a user's RECV call can either be satisfied right away by a waiting datagram, or it can stay pending until a datagram arrives 🌸
last thing: an implementation may also allow, or require, a call to the internet module to show interest in a class of datagrams or reserve exclusive use of one. For example, all datagrams with a certain value in the protocol field 👑
GLOSSARY ✨
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 message The unit of transmission between a host and an IMP in the ARPANET. The maximum size is about 1012 octets (8096 bits) 📦
ARPANET packet 🦋 A unit of transmission used inside the ARPANET between IMPs. The maximum 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 tells you where in the internet datagram a fragment belongs.
header ✨ Control information at the beginning of a message, segment, datagram, packet or block of data.
Identification 🔥 An internet header field carrying the identifying value the sender assigns, which helps put the fragments of a datagram back together.
IHL 💅 The 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 fragment 🍓 A portion of the data of an internet datagram, with an internet header.
internet datagram 💜 The unit of data exchanged between a pair of internet modules. It includes the internet header.
ARPANET leader 🙈 The control information on an ARPANET message at the host-IMP interface.
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. So many different things can map to the same spot, which is giving flexible vibes 🫶
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 shows whether or not this internet datagram contains the end of an internet datagram. It lives 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 may contain several options, and each option may be several octets long. The options are mainly used in testing situations, for example to carry timestamps ⏱️
Padding 👑 The internet header Padding field makes sure the data starts on a 32 bit word boundary. The padding is zero.
Protocol 🌈 In this document, this is the next higher level protocol identifier, which is an internet header field.
Rest 🍓 The 3 octet (24 bit) local address portion of an Internet Address.
RTP 💜 Real Time Protocol: a host-to-host protocol for communicating time critical information.
Source 🙈 The source address, which is an internet header field.
TCP 🦋 Transmission Control Protocol: a host-to-host protocol for reliable communication in internet environments.
TCP Segment 💖 The unit of data exchanged between TCP modules, including the TCP header.
Total Length 🌸 The internet header field that gives the length of the datagram in octets, including the internet header and the data.
Type of Service ✨ An internet header field that shows the type (or quality) of service for this internet datagram.
User 🔥 The user of the internet protocol. This could be a higher level protocol module, an application program, or a gateway program.
Version 💅 The Version field shows the format of the internet header.
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, May 1978 (Revised).
[3] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON, IEEE Computer Society, Fall 1978.
[4] Postel, J., "Address Mappings," IEN 115, USC/Information Sciences Institute, August 1979.
[5] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer Networks, v. 3, n. 1, February 1979.
[6] Postel, J., "Assigned Numbers," RFC 762, IEN 127, USC/Information Sciences Institute, January 1980.
📦 where this page comes from
- ietf: rfc760 1980-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms