summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc760.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc760.txt')
-rw-r--r--doc/rfc/rfc760.txt2707
1 files changed, 2707 insertions, 0 deletions
diff --git a/doc/rfc/rfc760.txt b/doc/rfc/rfc760.txt
new file mode 100644
index 0000000..e20fbf0
--- /dev/null
+++ b/doc/rfc/rfc760.txt
@@ -0,0 +1,2707 @@
+
+
+RFC: 760
+IEN: 128
+
+
+
+
+
+
+
+ DOD STANDARD
+
+ INTERNET PROTOCOL
+
+
+
+ January 1980
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ prepared for
+
+ Defense Advanced Research Projects Agency
+ Information Processing Techniques Office
+ 1400 Wilson Boulevard
+ Arlington, Virginia 22209
+
+
+
+
+
+
+
+ by
+
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, California 90291
+
+January 1980
+ Internet Protocol
+
+
+
+ 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 .......................................................... 41
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page i]
+
+
+ January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page ii]
+
+
+January 1980
+ Internet Protocol
+
+
+
+ PREFACE
+
+
+
+This document specifies the DoD Standard Internet Protocol. This
+document is based on five earlier editions of the ARPA Internet Protocol
+Specification, and the present text draws heavily from them. There have
+been many contributors to this work both in terms of concepts and in
+terms of text. This edition revises the details security,
+compartmentation, and precedence features of the internet protocol.
+
+ Jon Postel
+
+ Editor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page iii]
+
+
+January 1980
+RFC: 760
+IEN: 128
+Replaces: IENs 123, 111,
+80, 54, 44, 41, 28, 26
+
+ DOD STANDARD
+
+ INTERNET PROTOCOL
+
+
+
+ 1. INTRODUCTION
+
+1.1. Motivation
+
+ The Internet Protocol is designed for use in interconnected systems of
+ packet-switched computer communication networks. Such a system has
+ been called a "catenet" [1]. The internet protocol provides for
+ transmitting blocks of data called datagrams from sources to
+ destinations, where sources and destinations are hosts identified by
+ fixed length addresses. The internet protocol also provides for
+ fragmentation and reassembly of long datagrams, if necessary, for
+ transmission through "small packet" networks.
+
+1.2. Scope
+
+ The internet protocol is specifically limited in scope to provide the
+ functions necessary to deliver a package of bits (an internet
+ datagram) from a source to a destination over an interconnected system
+ of networks. There are no mechanisms to promote data reliability,
+ flow control, sequencing, or other services commonly found in
+ host-to-host protocols.
+
+1.3. Interfaces
+
+ This protocol is called on by host-to-host protocols in an internet
+ environment. This protocol 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 to take a
+ TCP segment (including the TCP header and user data) as the data
+ portion of an internet datagram. The TCP module would provide the
+ addresses and other parameters in the internet header to the internet
+ module as arguments of the call. The internet module would then
+ create an internet datagram and call on the local network interface to
+ transmit the internet datagram.
+
+ In the ARPANET case, for example, the internet module would call on a
+ local net module which would add the 1822 leader [2] to the internet
+ datagram creating an ARPANET message to transmit to the IMP. The
+ ARPANET address would be derived from the internet address by the
+ local network interface and would be the address of some host in the
+ ARPANET, that host might be a gateway to other networks.
+
+
+ [Page 1]
+
+
+ January 1980
+Internet Protocol
+Introduction
+
+
+
+1.4. Operation
+
+ The internet protocol implements two basic functions: addressing and
+ fragmentation.
+
+ The internet modules use the addresses carried in the internet header
+ to transmit internet datagrams toward their destinations. The
+ selection of a path for transmission is called routing.
+
+ The internet modules use fields in the internet header to fragment and
+ reassemble internet datagrams when necessary for transmission through
+ "small packet" networks.
+
+ The model of operation is that an internet module resides in each host
+ engaged in internet communication and in each gateway that
+ interconnects networks. These modules share common rules for
+ interpreting address fields and for fragmenting and assembling
+ internet datagrams. In addition, these modules (especially in
+ gateways) may have procedures for making routing decisions and other
+ functions.
+
+ The internet protocol treats each internet datagram as an independent
+ entity unrelated to any other internet datagram. There are no
+ connections or logical circuits (virtual or otherwise).
+
+ The internet protocol uses four key mechanisms in providing its
+ service: Type of Service, Time to Live, Options, and Header Checksum.
+
+ The Type of Service is used to indicate the quality of the service
+ desired; this may be thought of as selecting among Interactive, Bulk,
+ or Real Time, for example. The type of service is an abstract or
+ generalized set of parameters which characterize the service choices
+ provided in the networks that make up the internet. This type of
+ service indication is to be used by gateways to select the actual
+ transmission parameters for a particular network, the network to be
+ used for the next hop, or the next gateway when routing an internet
+ datagram.
+
+ The Time to Live is an indication of the lifetime of an internet
+ datagram. It is set by the sender of the datagram and reduced at the
+ points along the route where it is processed. If the time to live
+ reaches zero before the internet datagram reaches its destination, the
+ internet datagram is destroyed. The time to live can be thought of as
+ a self destruct time limit.
+
+ The Options provide for control functions needed or useful in some
+ situations but unnecessary for the most common communications. The
+
+
+
+[Page 2]
+
+
+January 1980
+ Internet Protocol
+ Introduction
+
+
+
+ options include provisions for timestamps, error reports, and special
+ routing.
+
+ The Header Checksum provides a verification that the information used
+ in processing internet datagram has been transmitted correctly. The
+ data may contain errors. If the header checksum fails, the internet
+ datagram is discarded at once by the entity which detects the error.
+
+ The internet protocol does not provide a reliable communication
+ facility. There are no acknowledgments either end-to-end or
+ hop-by-hop. There is no error control for data, only a header
+ checksum. There are no retransmissions. There is no flow control.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 3]
+
+
+ January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 4]
+
+
+January 1980
+ Internet Protocol
+
+
+
+ 2. OVERVIEW
+
+2.1. Relation to Other Protocols
+
+ The following diagram illustrates the place of the internet protocol
+ in the protocol hierarchy:
+
+
+ +------+ +-----+ +-----+ +-----+
+ |Telnet| | FTP | |Voice| ... | |
+ +------+ +-----+ +-----+ +-----+
+ | | | |
+ +-----+ +-----+ +-----+
+ | TCP | | RTP | ... | |
+ +-----+ +-----+ +-----+
+ | | |
+ +-------------------------------+
+ | Internet Protocol |
+ +-------------------------------+
+ |
+ +---------------------------+
+ | Local Network Protocol |
+ +---------------------------+
+ |
+
+
+
+ Protocol Relationships
+
+ Figure 1.
+
+ Internet protocol interfaces on one side to the higher level
+ host-to-host protocols and on the other side to the local network
+ protocol.
+
+2.2. Model of Operation
+
+ The model of operation for transmitting a datagram from one
+ application program to another is illustrated by the following
+ scenario:
+
+ We suppose that this transmission will involve one intermediate
+ gateway.
+
+ The sending application program prepares its data and calls on its
+ local internet module to send that data as a datagram and passes the
+ destination address and other parameters as arguments of the call.
+
+ The internet module prepares a datagram header and attaches the data
+
+
+ [Page 5]
+
+
+ January 1980
+Internet Protocol
+Overview
+
+
+
+ to it. The internet module determines a local network address for
+ this internet address, in this case it is the address of a gateway.
+ It sends this datagram and the local network address to the local
+ network interface.
+
+ The local network interface creates a local network header, and
+ attaches the datagram to it, then sends the result via the local
+ network.
+
+ The datagram arrives at a gateway host wrapped in the local network
+ header, the local network interface strips off this header, and
+ turns the datagram over to the internet module. The internet module
+ determines from the internet address that the datagram should be
+ forwarded to another host in a second network. The internet module
+ determines a local net address for the destination host. It calls
+ on the local network interface for that network to send the
+ datagram.
+
+ This local network interface creates a local network header and
+ attaches the datagram sending the result to the destination host.
+
+ At this destination host the datagram is stripped of the local net
+ header by the local network interface and handed to the internet
+ module.
+
+ The internet module determines that the datagram is for an
+ application program in this host. It passes the data to the
+ application program in response to a system call, passing 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 2
+
+
+
+ Transmission Path
+
+ Figure 2
+
+
+
+
+
+[Page 6]
+
+
+January 1980
+ Internet Protocol
+ Overview
+
+
+
+2.3. Function Description
+
+ The function or purpose of Internet Protocol is to move datagrams
+ through an interconnected set of networks. This is done by passing
+ the datagrams from one internet module to another until the
+ destination is reached. The internet modules reside in hosts and
+ gateways in the internet system. The datagrams are routed from one
+ internet module to another through individual networks based on the
+ interpretation of an internet address. Thus, one important mechanism
+ 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 is
+ smaller than the size of the datagram. To overcome this difficulty, a
+ fragmentation mechanism is provided in the internet protocol.
+
+ Addressing
+
+ A distinction is made between names, addresses, and routes [3]. A
+ name indicates what we seek. An address indicates where it is. A
+ route indicates how to get there. The internet protocol deals
+ primarily with addresses. It is the task of higher level (i.e.,
+ host-to-host or application) protocols to make the mapping from
+ names to addresses. The internet module maps internet addresses to
+ local net addresses. It is the task of lower level (i.e., local net
+ or gateways) procedures to make the mapping from local net
+ addresses to routes.
+
+ Addresses are fixed length of four octets (32 bits). An address
+ begins with a one octet network number, followed by a three octet
+ local address. This 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 to the extent of using several distinct
+ internet addresses. A host should also be able to have several
+ physical interfaces (multi-homing).
+
+ That is, a host should be allowed several physical interfaces to the
+ network with each 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
+ originates in a local net that allows a large packet size and must
+
+
+
+ [Page 7]
+
+
+ January 1980
+Internet Protocol
+Overview
+
+
+
+ traverse a local net that limits packets to a smaller size to reach
+ its destination.
+
+ An internet datagram can be marked "don't fragment." Any internet
+ datagram so marked is not to be internet fragmented under any
+ circumstances. If internet datagram marked don't fragment cannot be
+ delivered to its destination without fragmenting it, it is to be
+ discarded instead.
+
+ Fragmentation, transmission and reassembly across a local network
+ which is invisible to the internet protocol module is called
+ intranet fragmentation and 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 later reassembled. The receiver of the fragments uses the
+ identification field to ensure that fragments of different datagrams
+ are not mixed. The fragment offset field tells the receiver the
+ position of a fragment in the original datagram. The fragment
+ offset and length determine the portion of the original datagram
+ covered by this fragment. The more-fragments flag indicates (by
+ being reset) the last fragment. These fields provide sufficient
+ information to reassemble datagrams.
+
+ The identification field is used to distinguish the fragments of one
+ datagram from those of another. The originating protocol module of
+ an internet datagram sets the identification field to a value that
+ must be unique for that source-destination pair and protocol for the
+ time the datagram will be 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), creates two new internet datagrams and
+ copies the contents of the internet header fields from the long
+ datagram into both new internet headers. The data of the long
+ datagram is divided into two portions on a 8 octet (64 bit) boundary
+ (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 the
+ first portion NFB (for Number of Fragment Blocks). The first
+ portion of the data is placed in the first new internet datagram,
+ and the total length field is set to the length of the first
+ datagram. The more-fragments flag is set to one. The second
+ portion of the data is placed in the second new internet datagram,
+ and the total length field is set to the length of the second
+ datagram. The more-fragments flag carries the same value as the
+ long datagram. The fragment offset field of the second new internet
+
+
+
+[Page 8]
+
+
+January 1980
+ Internet Protocol
+ Overview
+
+
+
+ datagram is set to the value of that field in the long datagram plus
+ NFB.
+
+ This procedure can be generalized for an n-way split, rather than
+ the two-way split described.
+
+ To assemble the fragments of an internet datagram, an internet
+ protocol module (for example at a destination host) combines
+ internet datagram that all have the same value for the four fields:
+ identification, source, destination, and protocol. The combination
+ is done by placing the data portion of each fragment in the relative
+ position indicated by the fragment offset in that fragment's
+ internet header. The first fragment will have the fragment offset
+ zero, and the last fragment will have the more-fragments flag reset
+ to zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 9]
+
+
+ January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10]
+
+
+January 1980
+ Internet Protocol
+
+
+
+ 3. SPECIFICATION
+
+3.1. Internet Header Format
+
+ 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 Header
+
+ Figure 3.
+
+ Note that each tick mark represents one bit position.
+
+ Version: 4 bits
+
+ The Version field indicates 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, and thus points to the beginning of the data. Note that
+ the minimum value for a correct header is 5.
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 11]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Type of Service: 8 bits
+
+ The Type of Service provides an indication of the abstract
+ parameters of the quality of service desired. These parameters are
+ to be used to guide the selection of the actual service parameters
+ when transmitting a datagram through a particular network. Several
+ networks offer service precedence, which somehow treats high
+ precedence traffic as more important than other traffic. A few
+ networks offer a Stream service, whereby one can achieve a smoother
+ service at some cost. Typically this involves the reservation of
+ resources within the network. Another choice involves a low-delay
+ vs. high-reliability trade off. Typically networks invoke more
+ complex (and delay producing) mechanisms as the need for reliability
+ 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 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-Routine
+
+ The type of service is used to specify the treatment of the datagram
+ during its transmission through the internet system. In the
+ discussion (section 3.2) below, a chart shows the relationship of
+ the internet type of service 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, measured in octets,
+ including internet header and data. This field allows the length of
+ a datagram to be up to 65,535 octets. Such long datagrams are
+ impractical for most hosts and networks. All hosts must be prepared
+ to accept datagrams of up to 576 octets (whether they arrive whole
+
+
+[Page 12]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ or in fragments). It is recommended that hosts only send datagrams
+ larger than 576 octets if they have assurance that the destination
+ is prepared to accept the larger datagrams.
+
+ The number 576 is selected to allow a reasonable sized data block to
+ be transmitted in addition to the required header information. For
+ example, this size allows a data block of 512 octets plus 64 header
+ octets to fit in a datagram. The maximal internet header is 60
+ octets, and a typical internet header is 20 octets, allowing a
+ margin for headers of higher level protocols.
+
+ Identification: 16 bits
+
+ An identifying value assigned by the sender to aid in assembling 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 indicates where in the datagram this fragment belongs.
+ The fragment offset is measured in units of 8 octets (64 bits). The
+ first fragment has offset zero.
+
+ Time to Live: 8 bits
+
+ This field indicates the maximum time the datagram is allowed to
+ remain the internet system. If this field contains the value zero,
+ then the datagram should be destroyed. This field is modified in
+ internet header processing. The time is measured in units of
+ seconds. The intention is to cause undeliverable datagrams to be
+ discarded.
+
+
+
+
+
+
+ [Page 13]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Protocol: 8 bits
+
+ This field indicates the next level protocol used in the data
+ portion of the internet datagram. The values for various protocols
+ are specified in reference [6].
+
+ Header Checksum: 16 bits
+
+ A checksum on the header only. Since some header fields may change
+ (e.g., time to live), this is recomputed and verified at each point
+ that 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. For purposes of
+ computing the checksum, the value of the checksum field is zero.
+
+ This is a simple to compute checksum and experimental evidence
+ indicates it is adequate, but it is provisional and may be replaced
+ by a CRC procedure, depending on further experience.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 14]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ 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 use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 15]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ The 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=0
+
+ This 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.
+
+
+
+
+
+
+
+
+[Page 16]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ No Operation
+
+ +--------+
+ |00000001|
+ +--------+
+ Type=1
+
+ This 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=4
+
+ Security: 2 bits
+
+ Specifies one of 4 levels of security
+
+ 11-top secret
+ 10-secret
+ 01-confidential
+ 00-unclassified
+
+ Transmission 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.
+
+
+
+
+ [Page 17]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Source Route
+
+ +--------+--------+--------+---------//--------+
+ |00000011| length | source route |
+ +--------+--------+--------+---------//--------+
+ Type=3
+
+ The 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=7
+
+ The 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.
+
+
+
+[Page 18]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ 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=4
+
+ This 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=33
+
+ The 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
+
+
+ [Page 19]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ 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.
+
+ 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=6
+
+ The data of the timestamp is a 32 bit time measured in
+ milliseconds.
+
+
+
+[Page 20]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ Not copied on fragmentation, goes with first fragment
+
+ Satellite Timestamp
+
+ +--------+--------+--------+--------+--------+--------+
+ |01000101|00000100| time in milliseconds |
+ +--------+--------+--------+--------+--------+--------+
+ Type=69 Length=6
+
+ The 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. Each implementation
+ must expect to interoperate with others created by different
+ individuals. While the goal of this specification is to be explicit
+ about the protocol there is the possibility of differing
+ interpretations. In general, an implementation should be conservative
+ in its sending behavior, and liberal in its receiving behavior. That
+ is, it should be careful to send well-formed datagrams, but should
+ accept any datagram that it can interpret (e.g., not object to
+ technical errors where the meaning is still clear).
+
+ The basic internet service is datagram oriented and provides for the
+ fragmentation of datagrams at gateways, with reassembly taking place
+ at the destination internet protocol module in the destination host.
+ Of course, fragmentation and reassembly of datagrams within a network
+ or by private agreement between the gateways of a network is also
+ allowed since this is transparent to the internet protocols and the
+ higher-level protocols. This transparent type of fragmentation and
+ reassembly is termed "network-dependent" (or intranet) fragmentation
+ and is not discussed further here.
+
+ Internet addresses distinguish sources and destinations to the host
+ level and provide a protocol field as well. It is assumed that each
+ protocol will provide for whatever multiplexing is necessary within a
+ host.
+
+
+
+
+
+ [Page 21]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Addressing
+
+ 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, should
+ allow for a single physical host to act as several distinct internet
+ hosts. That is, there should be mapping between internet host
+ addresses and network/host interfaces that allows several internet
+ addresses to correspond to one interface. It should also be allowed
+ for a host to have several physical interfaces and to treat the
+ datagrams from several of them as if they were all addressed to a
+ single host. 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 and destination address, and the protocol fields, to identify
+ datagram fragments for reassembly.
+
+ The More Fragments flag bit (MF) is set if the datagram is not the
+ last fragment. The Fragment Offset field identifies the fragment
+ location, relative to the beginning of the original unfragmented
+ datagram. Fragments are counted in units of 8 octets. The
+ fragmentation strategy is designed so than an unfragmented datagram
+ has all zero fragmentation information (MF = 0, fragment offset =
+ 0). If an internet datagram is fragmented, its data portion must be
+ broken on 8 octet boundaries.
+
+ This format allows 2**13 = 8192 fragments of 8 octets each for a
+ total of 65,536 octets. Note that this is consistent with the the
+ datagram total length field.
+
+ When fragmentation occurs, some options are copied, but others
+ remain with the first fragment only.
+
+ Every internet module must be able to forward a datagram of 68
+ octets without further fragmentation. This is because an internet
+ header may be up to 60 octets, and the minimum fragment is 8 octets.
+
+ 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 Protocol
+ Specification
+
+
+
+ The fields which may be affected by fragmentation include:
+
+ (1) options field
+ (2) more fragments flag
+ (3) fragment offset
+ (4) internet header length field
+ (5) total length field
+ (6) header checksum
+
+ If the Don't Fragment flag (DF) bit is set, then internet
+ fragmentation of this datagram is NOT permitted, although it may be
+ discarded. This can be used to prohibit fragmentation in cases
+ where the receiving host does not have sufficient resources to
+ reassemble internet fragments.
+
+ General notation in the following pseudo programs: "=<" means "less
+ than or equal", "#" means "not equal", "=" means "equal", "<-" means
+ "is set to". Also, "x to y" includes x and excludes y; for example,
+ "4 to 7" would include 4, 5, and 6 (but not 7).
+
+ Fragmentation Procedure
+
+ The maximum sized datagram that can be transmitted through the
+ next network is called the maximum transmission unit (MTU).
+
+ If the total length is less than or equal the maximum transmission
+ unit then submit this datagram to the next step in datagram
+ processing; otherwise cut the datagram into two fragments, the
+ first fragment being the maximum size, and the second fragment
+ being the rest of the datagram. The first fragment is submitted
+ to the next step in datagram processing, while the second fragment
+ is submitted to this procedure in case it 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 Unit
+
+
+
+
+
+ [Page 23]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Procedure:
+
+ 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 computed as the
+ concatenation of the source, destination, protocol, and
+ identification fields. If this is a whole datagram (that is both
+ the fragment offset and the more fragments fields are zero), then
+ any reassembly resources associated with this buffer identifier
+ are released and the datagram is forwarded to the next step in
+ datagram processing.
+
+ If no other fragment with this buffer identifier is on hand then
+ reassembly resources are allocated. The reassembly resources
+ consist of a data buffer, a header buffer, a fragment block bit
+ table, a total data length field, and a timer. The data from the
+ fragment is placed in the data buffer according to its fragment
+ offset and length, and bits are set in the fragment block bit
+ table corresponding to the fragment blocks received.
+
+ If this is the first fragment (that is the fragment offset is
+ zero) this header is placed in the header buffer. If this is the
+ last fragment ( that is the more fragments field is zero) the
+ total data length is computed. If this fragment completes the
+ datagram (tested by checking the bits set in the fragment block
+ table), then the datagram is sent to the next step in datagram
+
+
+[Page 24]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ processing; otherwise the timer is set to the maximum of the
+ current timer value and the value of the time to live field from
+ this fragment; and the reassembly routine gives up control.
+
+ If the timer runs out, the all reassembly resources for this
+ buffer identifier are released. The initial setting of the timer
+ is a lower bound on the reassembly waiting time. This is because
+ the waiting time will be increased if the Time to Live in the
+ arriving fragment is greater than the current timer value but will
+ not be decreased if it is less. The maximum this timer value
+ could reach is the maximum time to live (approximately 4.25
+ minutes). The current recommendation for the initial timer
+ setting is 15 seconds. This may be changed as experience with
+ this protocol accumulates. Note that the choice of this parameter
+ value is related to the buffer capacity available and the data
+ rate of the transmission medium; that is, data rate times timer
+ value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).
+
+ Notation:
+
+ FO - Fragment Offset
+ IHL - Internet Header Length
+ MF - More Fragments flag
+ TTL - Time To Live
+ NFB - Number of Fragment Blocks
+ TL - Total Length
+ TDL - Total Data Length
+ BUFID - Buffer Identifier
+ RCVBT - Fragment Received Bit Table
+ TLB - Timer Lower Bound
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 25]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Procedure:
+
+ (1) BUFID <- source|destination|protocol|identification;
+ (2) IF FO = 0 AND MF = 0
+ (3) THEN IF buffer with BUFID is allocated
+ (4) THEN flush all reassembly for this BUFID;
+ (5) Submit datagram to next step; DONE.
+ (6) ELSE IF no buffer with BUFID is allocated
+ (7) THEN allocate reassembly resources
+ with BUFID;
+ TIMER <- TLB; TDL <- 0;
+ (8) put data from fragment into data buffer with
+ BUFID from octet FO*8 to
+ octet (TL-(IHL*4))+FO*8;
+ (9) set RCVBT bits from FO
+ to FO+((TL-(IHL*4)+7)/8);
+ (10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
+ (11) IF FO = 0 THEN put header in header buffer
+ (12) IF TDL # 0
+ (13) AND all RCVBT bits from 0
+ to (TDL+7)/8 are set
+ (14) THEN TL <- TDL+(IHL*4)
+ (15) Submit datagram to next step;
+ (16) free all reassembly resources
+ for this BUFID; DONE.
+ (17) TIMER <- MAX(TIMER,TTL);
+ (18) give up until next fragment or timer expires;
+ (19) timer expires: flush all reassembly with this BUFID; DONE.
+
+ In the case that two or more fragments contain the same data
+ either identically or through a partial overlap, this procedure
+ will use the more recently arrived copy in the data buffer and
+ datagram delivered.
+
+ Identification
+
+ The choice of the Identifier for a datagram is based on the need to
+ provide a way to uniquely identify the fragments of a particular
+ datagram. The protocol module assembling fragments judges fragments
+ to belong to the same datagram if they have the same source,
+ destination, protocol, and Identifier. Thus, the sender must choose
+ the Identifier to be unique for this source, destination pair and
+ protocol for the time the datagram (or any fragment of it) could be
+ alive in the internet.
+
+ It seems then that a sending protocol module needs to keep a table
+ of Identifiers, one entry for each destination it has communicated
+ with in the last maximum packet lifetime for the internet.
+
+
+[Page 26]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ However, since the Identifier field allows 65,536 different values,
+ some host may be able to simply use unique identifiers independent
+ of destination.
+
+ It is appropriate for some higher level protocols to choose the
+ identifier. For example, TCP protocol modules may retransmit an
+ identical TCP segment, and the probability for correct reception
+ would be enhanced if the retransmission carried the same identifier
+ as the original transmission since fragments of either datagram
+ could be used to construct a correct TCP segment.
+
+ Type of Service
+
+ The type of service (TOS) is for internet service quality selection.
+ The type of service is specified along the abstract parameters
+ precedence, reliability, and speed. A further concern is the
+ possibility of efficient handling of streams of datagrams. These
+ abstract parameters are to be mapped into the actual service
+ parameters of the particular networks the datagram traverses.
+
+ Precedence. An independent measure of the importance of this
+ datagram.
+
+ Stream or Datagram. Indicates if there will be other datagrams from
+ this source to this destination at regular frequent intervals
+ justifying the maintenance of stream processing information.
+
+ Reliability. A measure of the level of effort desired to ensure
+ delivery of this datagram.
+
+ Speed over Reliability. Indicates the relative importance of speed
+ and reliability when a conflict arises in meeting the pair of
+ requests.
+
+ Speed. A measure of the importance of prompt delivery of this
+ datagram.
+
+ For example, the ARPANET has a priority bit, and a choice between
+ "standard" messages (type 0) and "uncontrolled" messages (type 3),
+ (the choice between single packet and multipacket messages can also
+ be considered a service parameter). The uncontrolled messages tend
+ to be less reliably delivered and suffer less delay. Suppose an
+ internet datagram is to be sent through the ARPANET. Let the
+ internet type of service be given as:
+
+
+
+
+
+
+ [Page 27]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Precedence: 5
+ Stream: 0
+ Reliability: 1
+ S/R: 1
+ Speed: 1
+
+ The mapping of these parameters to those available for the ARPANET
+ would be to set the ARPANET priority bit on since the Internet
+ priority is in the upper half of its range, to select uncontrolled
+ messages since the speed and reliability requirements are equal and
+ speed is preferred.
+
+ The following chart presents the recommended mappings from the
+ internet protocol type of service into the service parameters
+ 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=type
+ R=reliability S=size A=ack D=delay
+ S/R=speed/rlblt H=holding time
+ S=speed R=reliability
+ *=requires stream set up
+
+
+
+
+
+
+[Page 28]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ Time to Live
+
+ The time to live is set by the sender to the maximum time the
+ datagram is allowed to be in the internet system. If the datagram
+ is in the internet system longer than the time to live, then the
+ datagram should be destroyed. This field should be decreased at
+ each point that the internet header is processed to reflect the time
+ spent processing the datagram. Even if no local information is
+ available on the time actually spent, the field should be
+ 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 is
+ 255 seconds or 4.25 minutes.
+
+ Options
+
+ The options are just that, optional. That is, the presence or
+ absence of an option is the choice of the sender, but each internet
+ module must be able to parse every option. There can be several
+ options present in the option field.
+
+ The options might not end on a 32-bit boundary. The internet header
+ should be filled out with octets of zeros. The first of these would
+ be interpreted as the end-of-options option, and the remainder 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 to be passed.
+
+ Checksum
+
+ The internet header checksum is recomputed if the internet header is
+ changed. For example, a reduction of the time to live, additions or
+ changes to internet options, or due to fragmentation. This checksum
+ at the internet level is intended to protect the internet header
+ fields from transmission errors.
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 29]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+3.3. Examples & Scenarios
+
+ Example 1:
+
+ This is an example of the minimal data carrying internet datagram:
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=0| Fragment Offset = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 123 | Protocol = 1 | header checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+
+
+ Example Internet Datagram
+
+ Figure 4.
+
+ Note that each tick mark represents one bit position.
+
+ This is a internet datagram in version 4 of internet protocol; the
+ internet header consists of five 32 bit words, and the total length
+ of the datagram is 21 octets. This datagram is a complete datagram
+ (not a fragment).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 30]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ Example 2:
+
+ In this example, we show first a moderate size internet datagram
+ (552 data octets), then two internet fragments that might result
+ from the fragmentation of this datagram if the maximum sized
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 31]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ Now the first fragment that results from splitting the datagram
+ after 256 data octets.
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=1| Fragment Offset = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 119 | Protocol = 6 | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ \ \
+ \ \
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Example Internet Fragment
+
+ Figure 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 32]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 33]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ 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 | 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
+
+ Internet protocol interfaces on one side to the local network and on
+ the other side to either a higher level protocol or an application
+ program. In the following, the higher level protocol or application
+ program (or even a gateway program) will be called the "user" since it
+ is using the internet module. Since internet protocol is a datagram
+ protocol, there is minimal memory or state maintained between datagram
+ transmissions, and each call on the internet protocol module by the
+ user supplies all the necessary information.
+
+
+
+
+[Page 34]
+
+
+January 1980
+ Internet Protocol
+ Specification
+
+
+
+ For example, the following two calls satisfy the requirements for the
+ user to internet protocol module communication ("=>" 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 buffer
+
+ When the user sends a datagram, it executes the SEND call supplying
+ all the arguments. The internet protocol module, on receiving this
+ call, checks the arguments and prepares and sends the message. If the
+ arguments are good and the datagram is accepted by the local network,
+ the call returns successfully. If either the arguments are bad, or
+ the datagram is not accepted by the local network, the call returns
+ unsuccessfully. On unsuccessful returns, a reasonable report should
+ be made as to the cause of the problem, but the details of such
+ reports are up to individual implementations.
+
+ When a datagram arrives at the internet protocol module from the local
+ network, either there is a pending RECV call from the user addressed
+ or there is not. In the first case, the pending call is satisfied by
+ passing the information from the datagram to the user. In the second
+ case, the user addressed is notified of a pending datagram. If the
+
+
+ [Page 35]
+
+
+ January 1980
+Internet Protocol
+Specification
+
+
+
+ user addressed does not exist, an error datagram is returned to the
+ sender, and the data is discarded.
+
+ The notification of a user may be via a pseudo interrupt or similar
+ mechanism, as appropriate in the particular operating system
+ environment of the implementation.
+
+ A user's RECV call may then either be immediately satisfied by a
+ pending datagram, or the call may be pending until a datagram arrives.
+
+ An implementation may also allow or require a call to the internet
+ module to indicate interest in or reserve exclusive use of a class of
+ datagrams (e.g., all those with a certain value in the protocol
+ field).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 36]
+
+
+January 1980
+ Internet Protocol
+
+
+
+ GLOSSARY
+
+
+
+1822
+ BBN Report 1822, "The Specification of the Interconnection of
+ a Host and an IMP". The specification of 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 internally in the ARPANET between
+ IMPs. The maximum size is about 126 octets (1008 bits).
+
+Destination
+ The destination address, an internet header field.
+
+DF
+ The Don't Fragment bit carried in the flags field.
+
+Flags
+ An internet header field carrying various control flags.
+
+Fragment Offset
+ This internet header field indicates 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
+ assigned by the sender to aid in assembling the fragments of a
+ datagram.
+
+IHL
+ The internet header field Internet Header Length is the length
+ of the internet header measured in 32 bit words.
+
+IMP
+ The Interface Message Processor, the packet switch of the
+ ARPANET.
+
+
+
+
+
+ [Page 37]
+
+
+ January 1980
+Internet Protocol
+Glossary
+
+
+
+Internet Address
+ A four octet (32 bit) source or destination address consisting
+ 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
+ (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 on to the host addresses in a
+ network is quite general, allowing for many to one mappings.
+
+MF
+ The More-Fragments Flag carried in the internet header flags
+ field.
+
+module
+ An implementation, usually in software, of a protocol or other
+ procedure.
+
+more-fragments flag
+ A flag indicating whether or not this internet datagram
+ contains the end of an internet datagram, carried in the
+ internet header Flags field.
+
+NFB
+ The Number of Fragment Blocks in a the data portion of an
+ internet fragment. That is, 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 in length. The options
+ are used primarily in testing situations, for example to carry
+ timestamps.
+
+
+
+[Page 38]
+
+
+January 1980
+ Internet Protocol
+ Glossary
+
+
+
+Padding
+ The internet header Padding field is used to ensure that the
+ data begins on 32 bit word boundary. The padding is zero.
+
+Protocol
+ In this document, the next higher level protocol identifier,
+ 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 communication
+ of time critical information.
+
+Source
+ The source address, 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 Total Length is the length of the
+ datagram in octets including internet header and data.
+
+Type of Service
+ An internet header field which indicates the type (or quality)
+ of service for this internet datagram.
+
+User
+ The user of the internet protocol. This may be a higher level
+ protocol module, an application program, or a gateway program.
+
+Version
+ The Version field indicates the format of the internet header.
+
+
+
+
+
+
+
+
+
+ [Page 39]
+
+
+ January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 40]
+
+
+January 1980
+ Internet Protocol
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 41]
+
+
+ January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 42]
+