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
`
`September 1981
`
`Internet Protocol
`
` PREFACE ........................................................ iii
`
`TABLE OF CONTENTS
`
`Juniper Ex. 1047-p. 1
`Juniper v Implicit
`
`

`

`1. INTRODUCTION ..................................................... 1
`
` 1.1 Motivation .................................................... 1
` 1.2 Scope ......................................................... 1
` 1.3 Interfaces .................................................... 1
` 1.4 Operation ..................................................... 2
`
`2. OVERVIEW ......................................................... 5
`
` 2.1 Relation to Other Protocols ................................... 9
` 2.2 Model of Operation ............................................ 5
` 2.3 Function Description .......................................... 7
` 2.4 Gateways ...................................................... 9
`
`3. SPECIFICATION ................................................... 11
`
` 3.1 Internet Header Format ....................................... 11
` 3.2 Discussion ................................................... 23
` 3.3 Interfaces ................................................... 31
`
`APPENDIX A: Examples & Scenarios ................................... 34
`APPENDIX B: Data Transmission Order ................................ 39
`
`GLOSSARY ............................................................ 41
`
`REFERENCES .......................................................... 45
`
`[Page i]
`
`Juniper Ex. 1047-p. 2
`Juniper v Implicit
`
`

`

`Internet Protocol
`
`September 1981
`
`[Page ii]
`
`Juniper Ex. 1047-p. 3
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1047-p. 4
`Juniper v Implicit
`
`

`

`
` September 1981
`
`RFC: 791
`Replaces: RFC 760
`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]
`
`Juniper Ex. 1047-p. 5
`Juniper v Implicit
`
`

`

`
` September 1981
`Internet Protocol
`Introduction
`
` 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.
`
`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) 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]
`
`Juniper Ex. 1047-p. 6
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1047-p. 7
`Juniper v Implicit
`
`

`

`
` September 1981
`Internet Protocol
`
`[Page 4]
`
`Juniper Ex. 1047-p. 8
`Juniper v Implicit
`
`

`

`
`September 1981
` 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 | | TFTP| ... | ... |
` +------+ +-----+ +-----+ +-----+
` | | | |
` +-----+ +-----+ +-----+
` | TCP | | UDP | ... | ... |
` +-----+ +-----+ +-----+
` | | |
` +--------------------------+----+
` | Internet Protocol & ICMP |
` +--------------------------+----+
` |
` +---------------------------+
` | 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]
`
`Juniper Ex. 1047-p. 9
`Juniper v Implicit
`
`

`

`
` September 1981
`Internet Protocol
`Overview
`
` 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 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]
`
`Juniper Ex. 1047-p. 10
`Juniper v Implicit
`
`

`

`
`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
` 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 [4]. 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 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]
`
`Juniper Ex. 1047-p. 11
`Juniper v Implicit
`
`

`

`
` September 1981
`Internet Protocol
`Overview
`
` 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.
`
` Fragmentation, transmission and reassembly across a local network
` 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]
`
`Juniper Ex. 1047-p. 12
`Juniper v Implicit
`
`

`

`
`September 1981
` Internet Protocol
` Overview
`
` 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
` 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|
` +-------------------------------+
` | |
` +---------------+ +---------------+
` | Local Net | | Local Net |
` +---------------+ +---------------+
`
` Gateway Protocols
`
` Figure 3.
`
` [Page 9]
`
`Juniper Ex. 1047-p. 13
`Juniper v Implicit
`
`

`

`
` September 1981
`Internet Protocol
`
`[Page 10]
`
`Juniper Ex. 1047-p. 14
`Juniper v Implicit
`
`

`

`
`September 1981
` 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 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]
`
`Juniper Ex. 1047-p. 15
`Juniper v Implicit
`
`

`

`
` September 1981
`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 (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 3: 0 = Normal Delay, 1 = Low Delay.
` Bits 4: 0 = Normal Throughput, 1 = High Throughput.
` Bits 5: 0 = Normal Relibility, 1 = High Relibility.
` Bit 6-7: Reserved for Future Use.
`
` 0 1 2 3 4 5 6 7
` +-----+-----+-----+-----+-----+-----+-----+-----+
` | | | | | | |
` | PRECEDENCE | D | T | R | 0 | 0 |
` | | | | | | |
` +-----+-----+-----+-----+-----+-----+-----+-----+
`
` Precedence
`
` 111 - Network Control
` 110 - Internetwork Control
` 101 - CRITIC/ECP
` 100 - Flash Override
` 011 - Flash
` 010 - Immediate
` 001 - Priority
` 000 - 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]
`
`Juniper Ex. 1047-p. 16
`Juniper v Implicit
`
`

`

`
`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
` 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: (DF) 0 = May Fragment, 1 = Don’t Fragment.
` Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
`
` 0 1 2
` +---+---+---+
` | | D | M |
` | 0 | F | F |
` +---+---+---+
`
` Fragment Offset: 13 bits
`
` This field indicates where in the datagram this fragment belongs.
`
` [Page 13]
`
`Juniper Ex. 1047-p. 17
`Juniper v Implicit
`
`

`

`
` September 1981
`Internet Protocol
`Specification
`
` 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 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
`
` A checksum on the header only. Since some header fields 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. See section 3.2.
`
` Destination Address: 32 bits
`
` The destination address. See section 3.2.
`
`[Page 14]
`
`Juniper Ex. 1047-p. 18
`Juniper v Implicit
`
`

`

`
`September 1981
` Internet Protocol
` Specification
`
` Options: variable
`
` The options may appear or not in datagrams. They must be
` 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:
`
` 1 bit copied flag,
` 2 bits option class,
` 5 bits option number.
`
` The copied flag indicates that this option is copied into all
` fragments on fragmentation.
`
` 0 = not copied
` 1 = copied
`
` The option classes are:
`
` 0 = control
` 1 = reserved for future use
` 2 = debugging and measurement
` 3 = reserved for future use
`
` [Page 15]
`
`Juniper Ex. 1047-p. 19
`Juniper v Implicit
`
`

`

`
` September 1981
`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 11 Security. Used to carry Security,
` Compartmentation, User Group (TCC), and
` Handling Restriction Codes compatible with DOD
` requirements.
` 0 3 var. Loose Source Routing. Used to route the
` internet datagram based on information
` supplied by the source.
` 0 9 var. Strict Source Routing. Used to route the
` internet datagram based on information
` supplied by the source.
` 0 7 var. Record Route. Used to trace the route an
` internet datagram takes.
` 0 8 4 Stream ID. Used to carry the stream
` identifier.
` 2 4 var. Internet Timestamp.
`
` Specific Option Definitions
`
` End of Option List
`
` +--------+
` |00000000|
` +--------+
` Type=0
`
` This option indicates the end of the option list.