RFC:
`
`791
`
`INTERNET PROTOCOL
`
`DARPA INTERNET PROGRAM
`
`PROTOCOL SPECIFICATION
`
`September 1981
`
`prepared for
`
`Defense Advanced Research Projects Agency
`Information Processing Techniques Office
`1400 Wilson Boulevard
`
`Arlington, Virginia
`
`22209
`
`by
`
`Information Sciences Institute
`
`University of Southern California
`4676 Admiralty Way
`Marina del Rey, California
`
`90291
`
`Page 1 of 49
`
`Verizon Exhibit 1016
`
`

`
`September 1981
`
`Internet Protocol
`
`TABLE OF CONTENTS
`
`PREFACE .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .. iii
`
`.
`
`.
`
`. ..
`
`l
`
`1.
`
`INTRODUCTION .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. ..
`
`1
`
`1.1 Motivation .
`
`1.2
`1.3
`
`.
`.
`.
`.
`.
`Scope .
`Interfaces .
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`. ..
`. ..
`
`. ..
`
`1
`1
`
`2
`
`1.4 Operation .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. ..
`
`5
`
`2.
`
`OVERVIEW .
`
`.
`
`.
`
`.
`
`.
`
`2.1 Relation to Other Protocols .
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`. ..
`
`. ..
`. ..
`. ..
`
`9
`
`5
`7
`9
`
`.
`.
`2.2 Model of Operation .
`2.3 Function Description .
`2.4 Gateways .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`3.
`
`SPECIFICATION .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`. .. 11
`
`. .. 11
`. .. 23
`. .. 31
`
`Internet Header Format
`3.1
`3.2 Discussion .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`3.3
`Interfaces .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`Examples & Scenarios .
`APPENDIX A:
`APPENDIX B: Data Transmission Order .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`. .. 34
`. .. 39
`
`. .. 41
`
`GLOSSARY .
`
`.
`
`.
`
`REFERENCES .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .. 45
`
`Page 2 of 49
`
`[Page i]
`
`

`
`Internet Protocol
`
`September 1981
`
`[Page ii]
`
`Page 3 of 49
`
`

`
`September 1981
`
`Internet Protocol
`
`PREFACE
`
`This document specifies the DoD Standard Internet Protocol. This
`document is based on six 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 aspects of addressing, error
`handling, option codes, and the security, precedence, compartments, and
`handling restriction features of the internet protocol.
`
`Jon Postel
`
`Editor
`
`[Page iii]
`
`Page 4 of 49
`
`

`
`September 1981
`
`RFC:
`
`791
`
`RFC 760
`Replaces:
`IENs 128, 123, 111,
`80, 54, 44, 41, 28, 26
`
`INTERNET PROTOCOL
`
`DARPA INTERNET PROGRAM
`PROTOCOL SPECIFICATION
`
`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 augment end—to—end data
`reliability,
`flow control, sequencing, or other services commonly
`found in host—to—host protocols.
`The internet protocol can capitalize
`on the services of its supporting networks to provide various types
`and qualities of service.
`
`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
`
`[Page 1]
`
`Page 5 of 49
`
`

`
`Internet Protocol
`Introduction
`
`September 1981
`
`to the internet
`local net module which would add the 1822 leader [2]
`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.
`
`1.4. Operation
`
`The internet protocol
`fragmentation.
`
`implements two basic functions:
`
`addressing and
`
`The internet modules use the addresses carried in the internet header
`
`to transmit internet datagrams toward their destinations.
`selection of a path for transmission is called routing.
`
`The
`
`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) 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.
`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 an upper bound on 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.
`
`[Page 2]
`
`Page 6 of 49
`
`

`
`September 1981
`
`Internet Protocol
`Introduction
`
`The Options provide for control functions needed or useful in some
`situations but unnecessary for the most common communications.
`The
`options include provisions for timestamps, security, 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.
`
`Errors detected may be reported via the Internet Control Message
`Protocol
`(ICMP)
`[3] which is implemented in the internet protocol
`module.
`
`[Page 3]
`
`Page 7 of 49
`
`

`
`Internet Protocol
`
`September 1981
`
`[Page 4]
`
`Page 8 of 49
`
`

`
`September 1981
`
`Internet Protocol
`
`2.1. Relation to Other Protocols
`
`2.
`
`OVERVIEW
`
`The following diagram illustrates the place of the internet protocol
`in the protocol hierarchy:
`
`+ — — — — ——+ +—————+ +—————+
`
`+—————+
`
`| TFTP|
`| FTP |
`|Telnet|
`+ — — — — ——+ +—————+ +—————+
`
`I
`I
`+—————+
`
`I TCP I
`+—————+
`
`I
`+—————+
`
`I UDP I
`+—————+
`
`|
`|
`+—————+
`
`I
`+—————+
`
`I
`I
`+—————+
`
`I
`I
`I
`+ — — — — — — — — — — — — — — — — — — — — — — — — ——+————+
`
`|
`Internet Protocol & ICMP
`|
`+ — — — — — — — — — — — — — — — — — — — — — — — — ——+————+
`
`I
`+ — — — — — — — — — — — — — — — — — — — — — — — — — ——+
`
`|
`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.
`In this context a "local network" may be a small network in
`a building or a large network such as the ARPANET.
`
`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
`to it.
`The internet module determines a local network address for
`
`this internet address,
`
`in this case it is the address of a gateway.
`
`[Page 5]
`
`Page 9 of 49
`
`

`
`Internet Protocol
`Overview
`
`September 1981
`
`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 is to 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
`Program
`\
`Internet Module
`
`\
`LNI—l
`
`Internet Module
`
`/
`LNI—l
`
`\
`LNI—2
`
`Application
`Program
`/
`Internet Module
`
`/
`LNI—2
`
`/
`\
`Local Network 1
`
`/
`\
`Local Network 2
`
`Transmission Path
`
`Figure 2
`
`[Page 6]
`
`Page 10 of 49
`
`

`
`September 1981
`
`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
`
`The datagrams are routed from one
`gateways in the internet system.
`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 [4].
`name indicates what we seek. An address indicates where it is.
`
`A
`A
`
`The internet protocol deals
`route indicates how to get there.
`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 network number,
`followed by local address (called the
`"rest" field). There are three formats or classes of internet
`addresses:
`in class a,
`the high order bit is zero,
`the next 7 bits
`are the network, and the last 24 bits are the local address;
`in
`class b,
`the high order two bits are one—zero,
`the next 14 bits are
`the network and the last 16 bits are the local address;
`in class c,
`the high order three bits are one—one—zero,
`the next 21 bits are the
`network and the last 8 bits are the local address.
`
`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.
`Some hosts will also have several physical
`interfaces (multi—homing).
`
`That is, provision must be made for a host to have several physical
`interfaces to the network with each having several logical internet
`addresses.
`
`[Page 7]
`
`Page 11 of 49
`
`

`
`Internet Protocol
`Overview
`
`September 1981
`
`Examples of address mappings may be found in "Address Mappings"
`
`[5].
`
`Fragmentation
`
`Fragmentation of an internet datagram is necessary when it
`originates in a local net that allows a large packet size and must
`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.
`
`transmission and reassembly across a local network
`Fragmentation,
`which is invisible to the internet protocol module is called
`intranet fragmentation and may be used [6].
`
`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
`
`[Page 8]
`
`Page 12 of 49
`
`

`
`September 1981
`
`Internet Protocol
`Overview
`
`The second
`The more—fragments flag is set to one.
`datagram.
`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
`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 datagrams 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.
`
`2.4. Gateways
`
`Gateways implement internet protocol to forward datagrams between
`networks. Gateways also implement the Gateway to Gateway Protocol
`(GGP)
`[7]
`to coordinate routing and other internet control
`information.
`
`In a gateway the higher level protocols need not be implemented and
`the GGP functions are added to the IP module.
`
`+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — ——+
`
`| Internet Protocol & ICMP & GGP|
`+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — ——+
`
`I
`+ — — — — — — — — — — — — — ——+
`
`I
`+ — — — — — — — — — — — — — ——+
`
`|
`Local Net
`|
`+ — — — — — — — — — — — — — ——+
`
`|
`Local Net
`|
`+ — — — — — — — — — — — — — ——+
`
`Gateway Protocols
`
`Figure 3.
`
`[Page 9]
`
`Page 13 of 49
`
`

`
`Internet Protocol
`
`September 1981
`
`[Page 10]
`
`Page 14 of 49
`
`

`
`September 1981
`
`Internet Protocol
`
`3.1.
`
`Internet Header Format
`
`3.
`
`SPECIFICATION
`
`A summary of the contents of the internet header follows:
`
`3
`2
`l
`0
`0 l
`8 9
`9 0 l 2 3 4 5 6 7
`0 l 2 3 4 5 6 7 8 9 0 l 2 3 4 5 6 7 8
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`Total Length
`|Type of Service|
`IHL
`|Version|
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`|
`Fragment Offset
`|Flags|
`Identification
`|
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`Header Checksum
`|
`Protocol
`Time to Live |
`|
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`Source Address
`|
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`Destination Address
`|
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`|
`Padding
`|
`Options
`|
`+—+‘+-+-+-+—+—+—+—+—+‘+-+—+—+—+—+-+—+-+—+—+—+—+—+—+—+—+—+—+—+—+—+
`
`Example Internet Datagram Header
`
`Figure 4.
`
`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]
`
`Page 15 of 49
`
`

`
`Internet Protocol
`
`Specification
`
`Type of Service:
`
`8 bits
`
`September 1981
`
`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 (generally
`by accepting only traffic above a certain precedence at time of high
`load).
`The major choice is a three way tradeoff between low—delay,
`high—reliability, and high—throughput.
`
`Bits 0-2:
`
`Precedence.
`
`Bit
`Bits
`Bits
`Bit
`
`1 = Low Delay.
`0 = Normal Delay,
`3:
`1 = High Throughput.
`0 = Normal Throughput,
`4:
`1 = High Relibility.
`0 = Normal Relibility,
`5:
`6-7: Reserved for Future Use.
`
`7
`6
`5
`4
`3
`2
`l
`0
`+—————+—--——+—————+—————+—————+—————+—————+—————+
`
`I
`I
`I
`I
`I
`I
`I
`|
`|
`|
`|
`|
`|
`|
`I
`I
`I
`I
`I
`I
`I
`+—————+—--——+—————+—————+—————+—————+—————+—————+
`
`PRECEDENCE
`
`D
`
`T
`
`R
`
`0
`
`0
`
`Precedence
`
`111 — Network Control
`110 — Internetwork Control
`
`— CRITIC/ECP
`lOl
`100 — Flash Override
`011 — Flash
`010 — Immediate
`
`001 — Priority
`O00 — Routine
`
`The use of the Delay, Throughput, and Reliability indications may
`increase the cost
`(in some sense) of the service.
`In many networks
`better performance for one of these parameters is coupled with worse
`performance on another. Except for very unusual cases at most
`two
`of these three indications should be set.
`
`The type of service is used to specify the treatment of the datagram
`during its transmission through the internet system.
`Example
`mappings of the internet type of service to the actual service
`provided on networks such as AUTODIN II, ARPANET, SATNET, and PRNET
`is given in "Service Mappings"
`[8].
`
`[Page 12]
`
`Page 16 of 49
`
`

`
`September 1981
`
`Internet Protocol
`
`Specification
`
`The Network Control precedence designation is intended to be used
`within a network only.
`The actual use and control of that
`designation is up to each network. The Internetwork Control
`designation is intended for use by gateway control originators only.
`If the actual use of these precedence designations is of concern to
`a particular network, it is the responsibility of that network to
`control the access to, and use of,
`those precedence designations.
`
`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
`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
`
`For
`be transmitted in addition to the required header information.
`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:
`(DF)
`0 = May Fragment,
`Bit 2:
`(MF)
`0 = Last Fragment,
`
`1 = Don't Fragment.
`1 More Fragments.
`
`012
`+———+———+———+
`
`IDIMI
`I
`|0|F|F|
`+———+———+———+
`
`Fragment Offset:
`
`13 bits
`
`This field indicates where in the datagram this fragment belongs.
`
`[Page 13]
`
`Page 17 of 49
`
`

`
`Internet Protocol
`
`Specification
`
`September 1981
`
`The fragment offset is measured in units of 8 octets (64 bits).
`first fragment has offset zero.
`
`The
`
`Time to Live:
`
`8 bits
`
`This field indicates the maximum time the datagram is allowed to
`remain in the internet system.
`If this field contains the value
`zero,
`then the datagram must be destroyed. This field is modified
`in internet header processing.
`The time is measured in units of
`seconds, but since every module that processes a datagram must
`decrease the TTL by at least one even if it process the datagram in
`less than a second,
`the TTL must be thought of only as an upper
`bound on the time a datagram may exist.
`The intention is to cause
`undeliverable datagrams to be discarded, and to bound the maximum
`datagram lifetime.
`
`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 "Assigned Numbers"
`[9].
`
`Header Checksum:
`
`16 bits
`
`Since some header fields change
`A checksum on the header only.
`(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.
`
`See section 3.2.
`
`Destination Address:
`
`32 bits
`
`The destination address.
`
`See section 3.2.
`
`[Page 14]
`
`Page 18 of 49
`
`

`
`September 1981
`
`Options: variable
`
`Internet Protocol
`
`Specification
`
`They must be
`The options may appear or not in datagrams.
`implemented by all IP modules (host and gateways). What is optional
`is their transmission in any particular datagram, not their
`implementation.
`
`In some environments the security option may be required in all
`datagrams.
`
`The option field 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:
`
`copied flag,
`1 bit
`2 bits option class,
`5 bits option number.
`
`The copied flag indicates that this option is copied into all
`fragments on fragmentat ion .
`
`not copied
`copied
`
`0 1
`
`The option classes are:
`
`control
`reserved for future use
`
`debugging and measurement
`reserved for future use
`
`UJ[\J|—'O
`
`||||
`
`[Page 15]
`
`Page 19 of 49
`
`

`
`Internet Protocol
`
`Specification
`
`September 1981
`
`The following internet options are defined:
`
`CLASS NUMBER LENGTH DESCRIPTION
`
`0
`
`0
`
`0
`
`0
`
`0
`
`0
`
`0
`
`2
`
`0
`
`1
`
`2
`
`3
`
`9
`
`7
`
`8
`
`4
`
`—
`
`—
`
`11
`
`var.
`
`End of Option list. This option occupies only
`1 octet; it has no length octet.
`No Operation. This option occupies only 1
`octet; it has no length octet.
`Security. Used to carry Security,
`Compartmentation, User Group (TCC), and
`Handling Restriction Codes compatible with DOD
`requirements.
`Loose Source Routing. Used to route the
`internet datagram based on information
`supplied by the source.
`var. Strict Source Routing. Used to route the
`internet datagram based on information
`supplied by the source.
`var. Record Route. Used to trace the route an
`
`4
`
`internet datagram takes .
`Stream ID. Used to carry the stream
`identifier.
`
`var.
`
`Internet Timestamp.
`
`Specific Option Definitions
`
`End of Option List
`
`+ — — — — — — — —+
`
`|oooooooo|
`+ — — — — — — — —+
`
`Type=0
`
`This might
`This option indicates the end of the option list.
`not coincide with the end of
`the internet header according to
`This is used at the end of all
`
`the internet header length.
`not the end of each
`options,
`the end of the options would
`of the internet header.
`
`option, and need only be used if
`not otherwise coincide with the end
`
`introduced, or deleted on fragmentation, or for
`May be copied,
`any other reason.
`
`[Page 16]
`
`Page 20 of 49
`
`

`
`September 1981
`
`No Operation
`
`+ — — — — — — ——+
`
`|ooooooo1|
`
`Internet Protocol
`
`Specification
`
`to align
`This option may be used between options, for example,
`the beginning of a subsequent option on a 32 bit boundary.
`
`introduced, or deleted on fragmentation, or for
`May be copied,
`any other reason.
`
`Security
`
`This option provides a way for hosts to send security,
`compartmentation, handling restrictions, and TCC (closed user
`group) parameters.
`The format for this option is as follows:
`
`+ —————— ——+ —————— --+--—//———+———//———+———//———+———//—--+
`|1ooooo1o|oooo1o11|sss
`sss|ccc CCC|HHH HHH|
`TCC
`|
`+ —————— ——+ —————— --+--—//———+———//———+———//———+———//—--+
`Type=130 Length=11
`
`Security (S field):
`
`16 bits
`
`Specifies one of 16 levels of security (eight of which are
`reserved for future use).
`
`00000000 00000000 — Unclassified
`llll000l 00ll0l0l — Confidential
`0llll000 l00ll0l0 — EFTO
`l0llll00 0l00ll0l — MMM
`0l0llll0 00l00ll0 — PROG
`l0l0llll 000l00ll
`— Restricted
`11010111 10001000 — Secret
`
`0ll0l0ll ll000l0l — Top Secret
`00110101 11100010 — Reserved for future use)
`10011010 11110001 — Reserved for future use)
`01001101 01111000 — Reserved for future use)
`00100100 10111101 — Reserved for future use)
`00010011 01011110 — Reserved for future use)
`10001001 10101111 — Reserved for future use)
`11000100 11010110 — Reserved for future use)
`11100010 01101011 — Reserved for future use)
`
`[Page 17]
`
`Page 21 of 49
`
`

`
`Internet Protocol
`
`Specification
`
`September 1981
`
`Compartments
`
`(C field):
`
`16 bits
`
`An all zero value is used when the information transmitted is
`
`not compartmented. Other values for the compartments field
`may be obtained from the Defense Intelligence Agency.
`
`Handling Restrictions (H field):
`
`16 bits
`
`The values for the control and release markings are
`alphanumeric digraphs and are defined in the Defense
`Intelligence Agency Manual DIAM 65-19, "Standard Security
`Markings".
`
`Transmission Control Code (TCC field):
`
`24 bits
`
`Provides a means to segregate traffic and define controlled
`communities of interest among subscribers. The TCC values are
`trigraphs, and are available from HQ DCA Code 530.
`
`Must be copied on fragmentation. This option appears at most
`once in a datagram.
`
`Loose Source and Record Route
`
`+ — — — — — — ——+ — — — — — — ——+ — — — — — — ——+ — — — — — — — ——// — — — — — — ——+
`|10000O11|
`length | pointer|
`route data
`+ — — — — — — ——+ — — — — — — ——+ — — — — — — ——+ — — — — — — — ——// — — — — — — ——+
`Type=131
`
`The loose source and record route (LSRR) 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, and to record the route
`information.
`
`The second octet
`The option begins with the option type code.
`is the option length which includes the option type code and the
`length octet,
`the pointer octet, and length—3 octets of route
`data.
`The third octet is the pointer into the route data
`indicating the octet which begins the next source address to be
`processed.
`The pointer is relative to this option, and the
`smallest legal value for the pointer is 4.
`
`A route data is composed of a series of internet addresses.
`Each internet address is 32 bits or 4 octets.
`If the pointer is
`greater than the length,
`the source route is empty (and the
`recorded route full) and the routing is to be based on the
`destination address field.
`
`[Page 18]
`
`Page 22 of 49
`
`

`
`September 1981
`
`Internet Protocol
`
`Specification
`
`If the address in destination address field has been reached and
`
`the next address in
`the pointer is not greater than the length,
`the source route replaces the address in the destination address
`field, and the recorded route address replaces the source
`address just used, and pointer is increased by four.
`
`The recorded route address is the internet module's own internet
`
`address as known in the environment into which this datagram is
`being forwarded.
`
`This procedure of replacing the source route with the recorded
`route (though it is in the reverse of the order it must be in to
`be used as a source route) means the option (and the IP header
`as a whole)
`remains a constant