As per Relevance of the word datagram, we have this rfc below:
RFC: 760
IEN: 128
DOD
INTERNET
January 1980
prepared
Defense Advanced Research Projects
Information Processing Techniques
1400 Wilson
Arlington, Virginia 22209
Information Sciences
University of Southern
4676 Admiralty
Marina del Rey, California 90291
January 1980
Internet
TABLE OF
PREFACE ........................................................
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 .......................................................... 41
[Page i
January 1980
Internet
[Page ii]
January 1980
Internet
This document specifies the DoD Standard Internet Protocol.
document is based on five earlier editions of the ARPA Internet
Specification, and the present text draws heavily from them. There
been many contributors to this work both in terms of concepts and
terms of text. This edition revises the details security
compartmentation, and precedence features of the internet protocol
Jon
[Page iii
January 1980
RFC: 760
IEN: 128
Replaces: IENs 123, 111,
80, 54, 44, 41, 28, 26
DOD
INTERNET
1.
1.1.
The Internet Protocol is designed for use in interconnected systems
packet-switched computer communication networks. Such a system
been called a "catenet" [1]. The internet protocol provides
transmitting blocks of data called datagrams from sources
destinations, where sources and destinations are hosts identified
fixed length addresses. The internet protocol also provides
fragmentation and reassembly of long datagrams, if necessary,
transmission through "small packet" networks
1.2.
The internet protocol is specifically limited in scope to provide
functions necessary to deliver a package of bits (an
datagram) from a source to a destination over an interconnected
of networks. There are no mechanisms to promote data reliability
flow control, sequencing, or other services commonly found
host-to-host protocols
1.3.
This protocol is called on by host-to-host protocols in an
environment. This protocol calls on local network protocols to
the internet datagram to the next gateway or destination host
For example, a TCP module would call on the internet module to take
TCP segment (including the TCP header and user data) as the
portion of an internet datagram. The TCP module would provide
addresses and other parameters in the internet header to the
module as arguments of the call. The internet module would
create an internet datagram and call on the local network interface
transmit the internet datagram
In the ARPANET case, for example, the internet module would call on
local net module which would add the 1822 leader [2] to the
datagram creating an ARPANET message to transmit to the IMP.
ARPANET address would be derived from the internet address by
local network interface and would be the address of some host in
ARPANET, that host might be a gateway to other networks
[Page 1]
January 1980
Internet
1.4.
The internet protocol implements two basic functions: addressing
fragmentation
The internet modules use the addresses carried in the internet
to transmit internet datagrams toward their destinations.
selection of a path for transmission is called routing
The internet modules use fields in the internet header to fragment
reassemble internet datagrams when necessary for transmission
"small packet" networks
The model of operation is that an internet module resides in each
engaged in internet communication and in each gateway
interconnects networks. These modules share common rules
interpreting address fields and for fragmenting and
internet datagrams. In addition, these modules (especially
gateways) may have procedures for making routing decisions and
functions
The internet protocol treats each internet datagram as an
entity unrelated to any other internet datagram. There are
connections or logical circuits (virtual or otherwise).
The internet protocol uses four key mechanisms in providing
service: Type of Service, Time to Live, Options, and Header Checksum
The Type of Service is used to indicate the quality of the
desired; this may be thought of as selecting among Interactive, Bulk
or Real Time, for example. The type of service is an abstract
generalized set of parameters which characterize the service
provided in the networks that make up the internet. This type
service indication is to be used by gateways to select the
transmission parameters for a particular network, the network to
used for the next hop, or the next gateway when routing an
datagram
The Time to Live is an indication of the lifetime of an
datagram. It is set by the sender of the datagram and reduced at
points along the route where it is processed. If the time to
reaches zero before the internet datagram reaches its destination,
internet datagram is destroyed. The time to live can be thought of
a self destruct time limit
The Options provide for control functions needed or useful in
situations but unnecessary for the most common communications.
[Page 2]
January 1980
Internet
options include provisions for timestamps, error reports, and
routing
The Header Checksum provides a verification that the information
in processing internet datagram has been transmitted correctly.
data may contain errors. If the header checksum fails, the
datagram is discarded at once by the entity which detects the error
The internet protocol does not provide a reliable
facility. There are no acknowledgments either end-to-end
hop-by-hop. There is no error control for data, only a
checksum. There are no retransmissions. There is no flow control
[Page 3]
January 1980
Internet
[Page 4]
January 1980
Internet
2.
2.1. Relation to Other
The following diagram illustrates the place of the internet
in the protocol hierarchy
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | |
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol |
+-------------------------------+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
|
Protocol
Figure 1.
Internet protocol interfaces on one side to the higher
host-to-host protocols and on the other side to the local
protocol
2.2. Model of
The model of operation for transmitting a datagram from
application program to another is illustrated by the
scenario
We suppose that this transmission will involve one
gateway
The sending application program prepares its data and calls on
local internet module to send that data as a datagram and passes
destination address and other parameters as arguments of the call
The internet module prepares a datagram header and attaches the
[Page 5]
January 1980
Internet
to it. The internet module determines a local network address
this internet address, in this case it is the address of a gateway
It sends this datagram and the local network address to the
network interface
The local network interface creates a local network header,
attaches the datagram to it, then sends the result via the
network
The datagram arrives at a gateway host wrapped in the local
header, the local network interface strips off this header,
turns the datagram over to the internet module. The internet
determines from the internet address that the datagram should
forwarded to another host in a second network. The internet
determines a local net address for the destination host. It
on the local network interface for that network to send
datagram
This local network interface creates a local network header
attaches the datagram sending the result to the destination host
At this destination host the datagram is stripped of the local
header by the local network interface and handed to the
module
The internet module determines that the datagram is for
application program in this host. It passes the data to
application program in response to a system call, passing the
address and other parameters as results of the call
Application
Program
\ /
Internet Module Internet Module Internet Module
\ / \ /
LNI-1 LNI-1 LNI-2 LNI-2
\ / \ /
Local Network 1 Local Network 2
Transmission
Figure 2
[Page 6]
January 1980
Internet
2.3. Function
The function or purpose of Internet Protocol is to move
through an interconnected set of networks. This is done by
the datagrams from one internet module to another until
destination is reached. The internet modules reside in hosts
gateways in the internet system. The datagrams are routed from
internet module to another through individual networks based on
interpretation of an internet address. Thus, one important
of the internet protocol is the internet address
In the routing of messages from one internet module to another
datagrams may need to traverse a network whose maximum packet size
smaller than the size of the datagram. To overcome this difficulty,
fragmentation mechanism is provided in the internet protocol
A distinction is made between names, addresses, and routes [3].
name indicates what we seek. An address indicates where it is.
route indicates how to get there. The internet protocol
primarily with addresses. It is the task of higher level (i.e.,
host-to-host or application) protocols to make the mapping
names to addresses. The internet module maps internet addresses
local net addresses. It is the task of lower level (i.e., local
or gateways) procedures to make the mapping from local net
addresses to routes
Addresses are fixed length of four octets (32 bits). An
begins with a one octet network number, followed by a three
local address. This three octet field is called the "rest" field
Care must be taken in mapping internet addresses to local
addresses; a single physical host must be able to act as if it
several distinct hosts to the extent of using several
internet addresses. A host should also be able to have
physical interfaces (multi-homing).
That is, a host should be allowed several physical interfaces to
network with each having several logical internet addresses
Examples of address mappings may be found in reference [4].
Fragmentation of an internet datagram may be necessary when
originates in a local net that allows a large packet size and
[Page 7]
January 1980
Internet
traverse a local net that limits packets to a smaller size to
its destination
An internet datagram can be marked "don't fragment." Any
datagram so marked is not to be internet fragmented under
circumstances. If internet datagram marked don't fragment cannot
delivered to its destination without fragmenting it, it is to
discarded instead
Fragmentation, transmission and reassembly across a local
which is invisible to the internet protocol module is
intranet fragmentation and may be used [5].
The internet fragmentation and reassembly procedure needs to be
to break a datagram into an almost arbitrary number of pieces
can be later reassembled. The receiver of the fragments uses
identification field to ensure that fragments of different
are not mixed. The fragment offset field tells the receiver
position of a fragment in the original datagram. The
offset and length determine the portion of the original
covered by this fragment. The more-fragments flag indicates (
being reset) the last fragment. These fields provide
information to reassemble datagrams
The identification field is used to distinguish the fragments of
datagram from those of another. The originating protocol module
an internet datagram sets the identification field to a value
must be unique for that source-destination pair and protocol for
time the datagram will be active in the internet system.
originating protocol module of a complete datagram sets
more-fragments flag to zero and the fragment offset to zero
To fragment a long internet datagram, an internet protocol
(for example, in a gateway), creates two new internet datagrams
copies the contents of the internet header fields from the
datagram into both new internet headers. The data of the
datagram is divided into two portions on a 8 octet (64 bit)
(the second portion might not be an integral multiple of 8 octets
but the first must be). Call the number of 8 octet blocks in
first portion NFB (for Number of Fragment Blocks). The
portion of the data is placed in the first new internet datagram
and the total length field is set to the length of the
datagram. The more-fragments flag is set to one. The
portion of the data is placed in the second new internet datagram
and the total length field is set to the length of the
datagram. The more-fragments flag carries the same value as
long datagram. The fragment offset field of the second new
[Page 8]
January 1980
Internet
datagram is set to the value of that field in the long datagram
NFB
This procedure can be generalized for an n-way split, rather
the two-way split described
To assemble the fragments of an internet datagram, an
protocol module (for example at a destination host)
internet datagram that all have the same value for the four fields
identification, source, destination, and protocol. The
is done by placing the data portion of each fragment in the
position indicated by the fragment offset in that fragment'
internet header. The first fragment will have the fragment
zero, and the last fragment will have the more-fragments flag
to zero
[Page 9]
January 1980
Internet
[Page 10]
January 1980
Internet
3.
3.1. Internet Header
A summary of the contents of the internet header follows
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
Figure 3.
Note that each tick mark represents one bit position
Version: 4
The Version field indicates the format of the internet header.
document describes version 4.
IHL: 4
Internet Header Length is the length of the internet header in 32
bit words, and thus points to the beginning of the data. Note
the minimum value for a correct header is 5.
[Page 11]
January 1980
Internet
Type of Service: 8
The Type of Service provides an indication of the
parameters of the quality of service desired. These parameters
to be used to guide the selection of the actual service
when transmitting a datagram through a particular network.
networks offer service precedence, which somehow treats
precedence traffic as more important than other traffic. A
networks offer a Stream service, whereby one can achieve a
service at some cost. Typically this involves the reservation
resources within the network. Another choice involves a low-
vs. high-reliability trade off. Typically networks invoke
complex (and delay producing) mechanisms as the need for
increases
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
111-Flash Override 1-STREAM 11-highest 1-speed 1-
110-Flash 0-DTGRM 10-higher 0-rlblt 0-
11X-Immediate 01-
01X-Priority 00-
00X-
The type of service is used to specify the treatment of the
during its transmission through the internet system. In
discussion (section 3.2) below, a chart shows the relationship
the internet type of service to the actual service provided on
ARPANET, the SATNET, and the PRNET
Total Length: 16
Total Length is the length of the datagram, measured in octets
including internet header and data. This field allows the length
a datagram to be up to 65,535 octets. Such long datagrams
impractical for most hosts and networks. All hosts must be
to accept datagrams of up to 576 octets (whether they arrive
[Page 12]
January 1980
Internet
or in fragments). It is recommended that hosts only send
larger than 576 octets if they have assurance that the
is prepared to accept the larger datagrams
The number 576 is selected to allow a reasonable sized data block
be transmitted in addition to the required header information.
example, this size allows a data block of 512 octets plus 64
octets to fit in a datagram. The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing
margin for headers of higher level protocols
Identification: 16
An identifying value assigned by the sender to aid in assembling
fragments of a datagram
Flags: 3
Various Control Flags
Bit 0: reserved, must be
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
This field indicates where in the datagram this fragment belongs
The fragment offset is measured in units of 8 octets (64 bits).
first fragment has offset zero
Time to Live: 8
This field indicates the maximum time the datagram is allowed
remain the internet system. If this field contains the value zero
then the datagram should be destroyed. This field is modified
internet header processing. The time is measured in units
seconds. The intention is to cause undeliverable datagrams to
discarded
[Page 13]
January 1980
Internet
Protocol: 8
This field indicates the next level protocol used in the
portion of the internet datagram. The values for various
are specified in reference [6].
Header Checksum: 16
A checksum on the header only. Since some header fields may
(e.g., time to live), this is recomputed and verified at each
that the internet header is processed
The checksum algorithm is
The checksum field is the 16 bit one's complement of the one'
complement sum of all 16 bit words in the header. For purposes
computing the checksum, the value of the checksum field is zero
This is a simple to compute checksum and experimental
indicates it is adequate, but it is provisional and may be
by a CRC procedure, depending on further experience
Source Address: 32
The source address. The first octet is the Source Network, and
following three octets are the Source Local Address
Destination Address: 32
The destination address. The first octet is the
Network, and the following three octets are the Destination
Address
[Page 14]
January 1980
Internet
Options:
The option field is variable in length. There may be zero or
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
actual option-data octets
The option-length octet counts the option-type octet and
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
2 bits option class
5 bits option number
The option classes are
0 =
1 = internet
2 = experimental debugging and
3 = reserved for future
[Page 15]
January 1980
Internet
The following internet options are defined
CLASS NUMBER LENGTH
----- ------ ------ -----------
0 0 - End of Option list. This option occupies
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
group (TCC) information compatible with
requirements
0 3 var. Source Routing. Used to route the
datagram based on information supplied by
source
0 7 var. Return Route. Used to record the route
internet datagram takes
0 8 4 Stream ID. Used to carry the
identifier
1 1 var. General Error Report. Used to report
in internet datagram processing
2 4 6 Internet Timestamp
2 5 6 Satellite Timestamp
Specific Option
End of Option
+--------+
|00000000|
+--------+
Type=0
This option indicates the end of the option list. This
not coincide with the end of the internet header according
the internet header length. This is used at the end of
options, not the end of each option, and need only be used
the end of the options would not otherwise coincide with the
of the internet header
May be copied, introduced, or deleted on fragmentation
[Page 16]
January 1980
Internet
No
+--------+
|00000001|
+--------+
Type=1
This option may be used between options, for example, to
the beginning of a subsequent option on a 32 bit boundary
May be copied, introduced, or deleted on fragmentation
This option provides a way for DOD hosts to send security
TCC (closed user groups) parameters through networks
transport leader does not contain fields for this information
The format for this option is as follows
+--------+--------+---------+--------+
|00000010|00000100|000000SS | TCC |
+--------+--------+---------+--------+
Type=2 Length=4
Security: 2
Specifies one of 4 levels of
11-top
10-
01-
00-
Transmission Control Code: 8
Provides a means to compartmentalize traffic and
controlled communities of interest among subscribers
Note that this option does not require processing by
internet module but does require that this information be
to higher level protocol modules. The security and
information might be used to supply class level and
information for transmitting datagrams into or
AUTODIN II
Must be copied on fragmentation
[Page 17]
January 1980
Internet
Source
+--------+--------+--------+---------//--------+
|00000011| length | source route |
+--------+--------+--------+---------//--------+
Type=3
The source route option provides a means for the source of
internet datagram to supply routing information to be used
the gateways in forwarding the datagram to the destination
The option begins with the option type code. The second
is the option length which includes the option type code and
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
defaults to two, which indicates the source route is empty
the remaining routing is to be based on the destination
field
If the address in destination address field has been reached
this option's length is not two, the next address in the
route replaces the address in the destination address field,
is deleted from the source route and this option's length
reduced by four. (The Internet Header Length Field must
changed also.)
Must be copied on fragmentation
Return
+--------+--------+--------+---------//--------+
|00000111| length | return route |
+--------+--------+--------+---------//--------+
Type=7
The return route option provides a means to record the route
an internet datagram
The option begins with the option type code. The second
is the option length which includes the option type code and
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
empty
[Page 18]
January 1980
Internet
When an internet module routes a datagram it checks to see
the return route option is present. If it is, it inserts
own internet address as known in the environment into which
datagram is being forwarded into the return route at the
of the address string and increments the length by four
Not copied on fragmentation, goes in first fragment only
Stream
+--------+--------+---------+--------+
|00001000|00000010| Stream ID |
+--------+--------+---------+--------+
Type=8 Length=4
This option provides a way for the 16-bit SATNET
identifier to be carried through networks that do not
the stream concept
Must be copied on fragmentation
General Error
+--------+--------+--------+--------+--------+----//----+
|00100001| length |err code| id | |
+--------+--------+--------+--------+--------+----//----+
Type=33
The general error report is used to report an error detected
processing an internet datagram to the source internet module
that datagram. The "err code" indicates the type of
detected, and the "id" is copied from the identification
of the datagram in error, additional octets of error
may be present depending on the err code
If an internet datagram containing the general error
option is found to be in error or must be discarded, no
report is sent
ERR CODE
0 - Undetermined Error, used when no information is
about the type of error or the error does not fit any
class. Following the id should be as much of the
(starting with the internet header) as fits in the
space
1 - Datagram Discarded, used when specific information
[Page 19]
January 1980
Internet
available about the reason for discarding the datagram can
reported. Following the id should be the original (4-octets
destination address, and the (1-octet) reason
Reason
------ -----------
0 No
1 No One Wants It - No higher level protocol
application program at destination wants
datagram
2 Fragmentation Needed & DF - Cannot deliver with
fragmenting and has don't fragment bit set
3 Reassembly Problem - Destination could
reassemble due to missing fragments when time
live expired
4 Gateway Congestion - Gateway discarded datagram
to congestion
The error report is placed in a datagram with the
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
+--------+--------+--------+--------+--------+--------+
|01000100|00000100| time in milliseconds |
+--------+--------+--------+--------+--------+--------+
Type=68 Length=6
The data of the timestamp is a 32 bit time measured
milliseconds
[Page 20]
January 1980
Internet
Not copied on fragmentation, goes with first
Satellite
+--------+--------+--------+--------+--------+--------+
|01000101|00000100| time in milliseconds |
+--------+--------+--------+--------+--------+--------+
Type=69 Length=6
The data of the timestamp is a 32 bit time measured
milliseconds
Not copied on fragmentation, goes with first
Padding:
The internet header padding is used to ensure that the
header ends on a 32 bit boundary. The padding is zero
3.2.
The implementation of a protocol must be robust. Each
must expect to interoperate with others created by
individuals. While the goal of this specification is to be
about the protocol there is the possibility of
interpretations. In general, an implementation should be
in its sending behavior, and liberal in its receiving behavior.
is, it should be careful to send well-formed datagrams, but
accept any datagram that it can interpret (e.g., not object
technical errors where the meaning is still clear).
The basic internet service is datagram oriented and provides for
fragmentation of datagrams at gateways, with reassembly taking
at the destination internet protocol module in the destination host
Of course, fragmentation and reassembly of datagrams within a
or by private agreement between the gateways of a network is
allowed since this is transparent to the internet protocols and
higher-level protocols. This transparent type of fragmentation
reassembly is termed "network-dependent" (or intranet)
and is not discussed further here
Internet addresses distinguish sources and destinations to the
level and provide a protocol field as well. It is assumed that
protocol will provide for whatever multiplexing is necessary within
host
[Page 21]
January 1980
Internet
The 8 bit network number, which is the first octet of the address
has a value as specified in reference [6].
The 24 bit local address, assigned by the local network,
allow for a single physical host to act as several distinct
hosts. That is, there should be mapping between internet
addresses and network/host interfaces that allows several
addresses to correspond to one interface. It should also be
for a host to have several physical interfaces and to treat
datagrams from several of them as if they were all addressed to
single host. Address mappings between internet addresses
addresses for ARPANET, SATNET, PRNET, and other networks
described in reference [4].
Fragmentation and Reassembly
The internet identification field (ID) is used together with
source and destination address, and the protocol fields, to
datagram fragments for reassembly
The More Fragments flag bit (MF) is set if the datagram is not
last fragment. The Fragment Offset field identifies the
location, relative to the beginning of the original
datagram. Fragments are counted in units of 8 octets.
fragmentation strategy is designed so than an unfragmented
has all zero fragmentation information (MF = 0, fragment offset =
0). If an internet datagram is fragmented, its data portion must
broken on 8 octet boundaries
This format allows 2**13 = 8192 fragments of 8 octets each for
total of 65,536 octets. Note that this is consistent with the
datagram total length field
When fragmentation occurs, some options are copied, but
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
header may be up to 60 octets, and the minimum fragment is 8 octets
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled
[Page 22]
January 1980
Internet
The fields which may be affected by fragmentation include
(1) options
(2) more fragments
(3) fragment
(4) internet header length
(5) total length
(6) header
If the Don't Fragment flag (DF) bit is set, then
fragmentation of this datagram is NOT permitted, although it may
discarded. This can be used to prohibit fragmentation in
where the receiving host does not have sufficient resources
reassemble internet fragments
General notation in the following pseudo programs: "=<" means "
than or equal", "#" means "not equal", "=" means "equal", "<-"
"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).
Fragmentation
The maximum sized datagram that can be transmitted through
next network is called the maximum transmission unit (MTU).
If the total length is less than or equal the maximum
unit then submit this datagram to the next step in
processing; otherwise cut the datagram into two fragments,
first fragment being the maximum size, and the second
being the rest of the datagram. The first fragment is
to the next step in datagram processing, while the second
is submitted to this procedure in case it still too large
Notation
FO - Fragment
IHL - Internet Header
MF - More Fragments
TL - Total
OFO - Old Fragment
OIHL - Old Internet Header
OMF - Old More Fragments
OTL - Old Total
NFB - Number of Fragment
MTU - Maximum Transmission
[Page 23]
January 1980
Internet
Procedure
IF TL =< MTU THEN Submit this datagram to the next
in datagram processing
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
datagram processing
To produce the second fragment
(7) Selectively copy the internet header (some
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
For each datagram the buffer identifier is computed as
concatenation of the source, destination, protocol,
identification fields. If this is a whole datagram (that is
the fragment offset and the more fragments fields are zero),
any reassembly resources associated with this buffer
are released and the datagram is forwarded to the next step
datagram processing
If no other fragment with this buffer identifier is on hand
reassembly resources are allocated. The reassembly
consist of a data buffer, a header buffer, a fragment block
table, a total data length field, and a timer. The data from
fragment is placed in the data buffer according to its
offset and length, and bits are set in the fragment block
table corresponding to the fragment blocks received
If this is the first fragment (that is the fragment offset
zero) this header is placed in the header buffer. If this is
last fragment ( that is the more fragments field is zero)
total data length is computed. If this fragment completes
datagram (tested by checking the bits set in the fragment
table), then the datagram is sent to the next step in
[Page 24]
January 1980
Internet
processing; otherwise the timer is set to the maximum of
current timer value and the value of the time to live field
this fragment; and the reassembly routine gives up control
If the timer runs out, the all reassembly resources for
buffer identifier are released. The initial setting of the
is a lower bound on the reassembly waiting time. This is
the waiting time will be increased if the Time to Live in
arriving fragment is greater than the current timer value but
not be decreased if it is less. The maximum this timer
could reach is the maximum time to live (approximately 4.25
minutes). The current recommendation for the initial
setting is 15 seconds. This may be changed as experience
this protocol accumulates. Note that the choice of this
value is related to the buffer capacity available and the
rate of the transmission medium; that is, data rate times
value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).
Notation
FO - Fragment
IHL - Internet Header
MF - More Fragments
TTL - Time To
NFB - Number of Fragment
TL - Total
TDL - Total Data
BUFID - Buffer
RCVBT - Fragment Received Bit
TLB - Timer Lower
[Page 25]
January 1980
Internet
Procedure
(1) BUFID <- source|destination|protocol|identification
(2) IF FO = 0 AND MF = 0
(3) THEN IF buffer with BUFID is
(4) THEN flush all reassembly for this BUFID
(5) Submit datagram to next step; DONE
(6) ELSE IF no buffer with BUFID is
(7) THEN allocate reassembly
with BUFID
TIMER <- TLB; TDL <- 0;
(8) put data from fragment into data buffer
BUFID from octet FO*8
octet (TL-(IHL*4))+FO*8;
(9) set RCVBT bits from
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
(12) IF TDL # 0
(13) AND all RCVBT bits from 0
to (TDL+7)/8 are
(14) THEN TL <- TDL+(IHL*4)
(15) Submit datagram to next step
(16) free all reassembly
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
either identically or through a partial overlap, this
will use the more recently arrived copy in the data buffer
datagram delivered
The choice of the Identifier for a datagram is based on the need
provide a way to uniquely identify the fragments of a
datagram. The protocol module assembling fragments judges
to belong to the same datagram if they have the same source
destination, protocol, and Identifier. Thus, the sender must
the Identifier to be unique for this source, destination pair
protocol for the time the datagram (or any fragment of it) could
alive in the internet
It seems then that a sending protocol module needs to keep a
of Identifiers, one entry for each destination it has
with in the last maximum packet lifetime for the internet
[Page 26]
January 1980
Internet
However, since the Identifier field allows 65,536 different values
some host may be able to simply use unique identifiers
of destination
It is appropriate for some higher level protocols to choose
identifier. For example, TCP protocol modules may retransmit
identical TCP segment, and the probability for correct
would be enhanced if the retransmission carried the same
as the original transmission since fragments of either
could be used to construct a correct TCP segment
Type of
The type of service (TOS) is for internet service quality selection
The type of service is specified along the abstract
precedence, reliability, and speed. A further concern is
possibility of efficient handling of streams of datagrams.
abstract parameters are to be mapped into the actual
parameters of the particular networks the datagram traverses
Precedence. An independent measure of the importance of
datagram
Stream or Datagram. Indicates if there will be other datagrams
this source to this destination at regular frequent
justifying the maintenance of stream processing information
Reliability. A measure of the level of effort desired to
delivery of this datagram
Speed over Reliability. Indicates the relative importance of
and reliability when a conflict arises in meeting the pair
requests
Speed. A measure of the importance of prompt delivery of
datagram
For example, the ARPANET has a priority bit, and a choice
"standard" messages (type 0) and "uncontrolled" messages (type 3),
(the choice between single packet and multipacket messages can
be considered a service parameter). The uncontrolled messages
to be less reliably delivered and suffer less delay. Suppose
internet datagram is to be sent through the ARPANET. Let
internet type of service be given as
[Page 27]
January 1980
Internet
Precedence: 5
Stream: 0
Reliability: 1
S/R: 1
Speed: 1
The mapping of these parameters to those available for the
would be to set the ARPANET priority bit on since the
priority is in the upper half of its range, to select
messages since the speed and reliability requirements are equal
speed is preferred
The following chart presents the recommended mappings from
internet protocol type of service into the service
actually available on the ARPANET, the PRNET, and the SATNET
+------------+----------+----------+----------+----------+
|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=
R=reliability S=size A=ack D=
S/R=speed/rlblt H=holding
S=speed R=
*=requires stream set
[Page 28]
January 1980
Internet
Time to
The time to live is set by the sender to the maximum time
datagram is allowed to be in the internet system. If the
is in the internet system longer than the time to live, then
datagram should be destroyed. This field should be decreased
each point that the internet header is processed to reflect the
spent processing the datagram. Even if no local information
available on the time actually spent, the field should
decremented by 1. The time is measured in units of seconds (i.e
the value 1 means one second). Thus, the maximum time to live
255 seconds or 4.25 minutes
The options are just that, optional. That is, the presence
absence of an option is the choice of the sender, but each
module must be able to parse every option. There can be
options present in the option field
The options might not end on a 32-bit boundary. The internet
should be filled out with octets of zeros. The first of these
be interpreted as the end-of-options option, and the remainder
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),
Route (7), General Error Report (33), and Internet Timestamp (68).
The Security Option (2) is required only if classified
compartmented traffic is to be passed
The internet header checksum is recomputed if the internet header
changed. For example, a reduction of the time to live, additions
changes to internet options, or due to fragmentation. This
at the internet level is intended to protect the internet
fields from transmission errors
[Page 29]
January 1980
Internet
3.3. Examples &
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
Figure 4.
Note that each tick mark represents one bit position
This is a internet datagram in version 4 of internet protocol;
internet header consists of five 32 bit words, and the total
of the datagram is 21 octets. This datagram is a complete
(not a fragment).
[Page 30]
January 1980
Internet
Example 2:
In this example, we show first a moderate size internet
(552 data octets), then two internet fragments that might
from the fragmentation of this datagram if the maximum
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
Figure 5.
[Page 31]
January 1980
Internet
Now the first fragment that results from splitting the
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
Figure 6.
[Page 32]
January 1980
Internet
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
Figure 7.
[Page 33]
January 1980
Internet
Example 3:
Here, we show an example of a datagram containing 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 