home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc760 < prev    next >
Text File  |  1991-04-21  |  82KB  |  2,708 lines

  1.  
  2.  
  3. RFC: 760
  4. IEN: 128
  5.                                     
  6.                                     
  7.                                     
  8.                                     
  9.                                     
  10.                                     
  11.                                     
  12.                               DOD STANDARD
  13.                                     
  14.                            INTERNET PROTOCOL
  15.                                     
  16.                                     
  17.                                     
  18.                               January 1980
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.                               prepared for
  35.                                     
  36.                Defense Advanced Research Projects Agency
  37.                 Information Processing Techniques Office
  38.                          1400 Wilson Boulevard
  39.                        Arlington, Virginia  22209
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.                                    by
  48.  
  49.                      Information Sciences Institute
  50.                    University of Southern California
  51.                            4676 Admiralty Way
  52.                    Marina del Rey, California  90291
  53.  
  54. January 1980                                                            
  55.                                                        Internet Protocol
  56.  
  57.  
  58.  
  59.                            TABLE OF CONTENTS
  60.  
  61.     PREFACE ........................................................ iii
  62.  
  63. 1.  INTRODUCTION ..................................................... 1
  64.  
  65.   1.1  Motivation .................................................... 1
  66.   1.2  Scope ......................................................... 1
  67.   1.3  Interfaces .................................................... 1
  68.   1.4  Operation ..................................................... 2
  69.  
  70. 2.  OVERVIEW ......................................................... 5
  71.  
  72.   2.1  Relation to Other Protocols ................................... 5
  73.   2.2  Model of Operation ............................................ 5
  74.   2.3  Function Description .......................................... 7
  75.  
  76. 3.  SPECIFICATION ................................................... 11
  77.  
  78.   3.1  Internet Header Format ....................................... 11
  79.   3.2  Discussion ................................................... 21
  80.   3.3  Examples & Scenarios ......................................... 30
  81.   3.4  Interfaces ................................................... 34
  82.  
  83. GLOSSARY ............................................................ 37
  84.  
  85. REFERENCES .......................................................... 41
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.                                                                 [Page i]
  111.  
  112.  
  113.                                                             January 1980
  114. Internet Protocol
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169. [Page ii]                                                               
  170.  
  171.  
  172. January 1980                                                            
  173.                                                        Internet Protocol
  174.  
  175.  
  176.  
  177.                                 PREFACE
  178.  
  179.  
  180.  
  181. This document specifies the DoD Standard Internet Protocol.  This
  182. document is based on five earlier editions of the ARPA Internet Protocol
  183. Specification, and the present text draws heavily from them.  There have
  184. been many contributors to this work both in terms of concepts and in
  185. terms of text.  This edition revises the details security,
  186. compartmentation, and precedence features of the internet protocol.
  187.  
  188.                                                            Jon Postel
  189.  
  190.                                                            Editor
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.                                                               [Page iii]
  229.  
  230.  
  231. January 1980 
  232. RFC: 760
  233. IEN: 128
  234. Replaces:  IENs 123, 111,
  235. 80, 54, 44, 41, 28, 26
  236.  
  237.                               DOD STANDARD
  238.  
  239.                            INTERNET PROTOCOL
  240.  
  241.  
  242.  
  243.                             1.  INTRODUCTION
  244.  
  245. 1.1.  Motivation
  246.  
  247.   The Internet Protocol is designed for use in interconnected systems of
  248.   packet-switched computer communication networks.  Such a system has
  249.   been called a "catenet" [1].  The internet protocol provides for
  250.   transmitting blocks of data called datagrams from sources to
  251.   destinations, where sources and destinations are hosts identified by
  252.   fixed length addresses.  The internet protocol also provides for
  253.   fragmentation and reassembly of long datagrams, if necessary, for
  254.   transmission through "small packet" networks.
  255.  
  256. 1.2.  Scope
  257.  
  258.   The internet protocol is specifically limited in scope to provide the
  259.   functions necessary to deliver a package of bits (an internet
  260.   datagram) from a source to a destination over an interconnected system
  261.   of networks.  There are no mechanisms to promote data reliability,
  262.   flow control, sequencing, or other services commonly found in
  263.   host-to-host protocols.
  264.  
  265. 1.3.  Interfaces
  266.  
  267.   This protocol is called on by host-to-host protocols in an internet
  268.   environment.  This protocol calls on local network protocols to carry
  269.   the internet datagram to the next gateway or destination host.
  270.  
  271.   For example, a TCP module would call on the internet module to take a
  272.   TCP segment (including the TCP header and user data) as the data
  273.   portion of an internet datagram.  The TCP module would provide the
  274.   addresses and other parameters in the internet header to the internet
  275.   module as arguments of the call.  The internet module would then
  276.   create an internet datagram and call on the local network interface to
  277.   transmit the internet datagram.
  278.  
  279.   In the ARPANET case, for example, the internet module would call on a
  280.   local net module which would add the 1822 leader [2] to the internet
  281.   datagram creating an ARPANET message to transmit to the IMP.  The
  282.   ARPANET address would be derived from the internet address by the
  283.   local network interface and would be the address of some host in the
  284.   ARPANET, that host might be a gateway to other networks.
  285.  
  286.  
  287.                                                                 [Page 1]
  288.  
  289.  
  290.                                                             January 1980
  291. Internet Protocol
  292. Introduction
  293.  
  294.  
  295.  
  296. 1.4.  Operation
  297.  
  298.   The internet protocol implements two basic functions:  addressing and
  299.   fragmentation.
  300.  
  301.   The internet modules use the addresses carried in the internet header
  302.   to transmit internet datagrams toward their destinations.  The
  303.   selection of a path for transmission is called routing.
  304.  
  305.   The internet modules use fields in the internet header to fragment and
  306.   reassemble internet datagrams when necessary for transmission through
  307.   "small packet" networks.
  308.  
  309.   The model of operation is that an internet module resides in each host
  310.   engaged in internet communication and in each gateway that
  311.   interconnects networks.  These modules share common rules for
  312.   interpreting address fields and for fragmenting and assembling
  313.   internet datagrams.  In addition, these modules (especially in
  314.   gateways) may have procedures for making routing decisions and other
  315.   functions.
  316.  
  317.   The internet protocol treats each internet datagram as an independent
  318.   entity unrelated to any other internet datagram.  There are no
  319.   connections or logical circuits (virtual or otherwise).
  320.  
  321.   The internet protocol uses four key mechanisms in providing its
  322.   service:  Type of Service, Time to Live, Options, and Header Checksum.
  323.  
  324.   The Type of Service is used to indicate the quality of the service
  325.   desired; this may be thought of as selecting among Interactive, Bulk,
  326.   or Real Time, for example.  The type of service is an abstract or
  327.   generalized set of parameters which characterize the service choices
  328.   provided in the networks that make up the internet.  This type of
  329.   service indication is to be used by gateways to select the actual
  330.   transmission parameters for a particular network, the network to be
  331.   used for the next hop, or the next gateway when routing an internet
  332.   datagram.
  333.  
  334.   The Time to Live is an indication of the lifetime of an internet
  335.   datagram.  It is set by the sender of the datagram and reduced at the
  336.   points along the route where it is processed.  If the time to live
  337.   reaches zero before the internet datagram reaches its destination, the
  338.   internet datagram is destroyed.  The time to live can be thought of as
  339.   a self destruct time limit.
  340.  
  341.   The Options provide for control functions needed or useful in some
  342.   situations but unnecessary for the most common communications.  The
  343.  
  344.  
  345.  
  346. [Page 2]                                                                
  347.  
  348.  
  349. January 1980                                                            
  350.                                                        Internet Protocol
  351.                                                             Introduction
  352.  
  353.  
  354.  
  355.   options include provisions for timestamps, error reports, and special
  356.   routing.
  357.  
  358.   The Header Checksum provides a verification that the information used
  359.   in processing internet datagram has been transmitted correctly.  The
  360.   data may contain errors.  If the header checksum fails, the internet
  361.   datagram is discarded at once by the entity which detects the error.
  362.  
  363.   The internet protocol does not provide a reliable communication
  364.   facility.  There are no acknowledgments either end-to-end or
  365.   hop-by-hop.  There is no error control for data, only a header
  366.   checksum.  There are no retransmissions.  There is no flow control.
  367.  
  368.   
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.                                                                 [Page 3]
  406.  
  407.  
  408.                                                             January 1980
  409. Internet Protocol
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464. [Page 4]                                                                
  465.  
  466.  
  467. January 1980                                                            
  468.                                                        Internet Protocol
  469.  
  470.  
  471.  
  472.                               2.  OVERVIEW
  473.  
  474. 2.1.  Relation to Other Protocols
  475.  
  476.   The following diagram illustrates the place of the internet protocol
  477.   in the protocol hierarchy:
  478.  
  479.                                     
  480.                  +------+ +-----+ +-----+       +-----+
  481.                  |Telnet| | FTP | |Voice|  ...  |     |
  482.                  +------+ +-----+ +-----+       +-----+
  483.                        |   |         |             |   
  484.                       +-----+     +-----+       +-----+
  485.                       | TCP |     | RTP |  ...  |     |
  486.                       +-----+     +-----+       +-----+
  487.                          |           |             |   
  488.                       +-------------------------------+
  489.                       |       Internet Protocol       |
  490.                       +-------------------------------+
  491.                                      |                 
  492.                         +---------------------------+  
  493.                         |   Local Network Protocol  |  
  494.                         +---------------------------+  
  495.                                      |                 
  496.  
  497.  
  498.  
  499.                          Protocol Relationships
  500.  
  501.                                Figure 1.
  502.  
  503.   Internet protocol interfaces on one side to the higher level
  504.   host-to-host protocols and on the other side to the local network
  505.   protocol.
  506.  
  507. 2.2.  Model of Operation
  508.  
  509.   The  model of operation for transmitting a datagram from one
  510.   application program to another is illustrated by the following
  511.   scenario:
  512.  
  513.     We suppose that this transmission will involve one intermediate
  514.     gateway.
  515.  
  516.     The sending application program prepares its data and calls on its
  517.     local internet module to send that data as a datagram and passes the
  518.     destination address and other parameters as arguments of the call.
  519.  
  520.     The internet module prepares a datagram header and attaches the data
  521.  
  522.  
  523.                                                                 [Page 5]
  524.  
  525.  
  526.                                                             January 1980
  527. Internet Protocol
  528. Overview
  529.  
  530.  
  531.  
  532.     to it.  The internet module determines a local network address for
  533.     this internet address, in this case it is the address of a gateway.
  534.     It sends this datagram and the local network address to the local
  535.     network interface.
  536.  
  537.     The local network interface creates a local network header, and
  538.     attaches the datagram to it, then sends the result via the local
  539.     network.
  540.  
  541.     The datagram arrives at a gateway host wrapped in the local network
  542.     header, the local network interface strips off this header, and
  543.     turns the datagram over to the internet module.  The internet module
  544.     determines from the internet address that the datagram should be
  545.     forwarded to another host in a second network.  The internet module
  546.     determines a local net address for the destination host.  It calls
  547.     on the local network interface for that network to send the
  548.     datagram.
  549.  
  550.     This local network interface creates a local network header and
  551.     attaches the datagram sending the result to the destination host.
  552.  
  553.     At this destination host the datagram is stripped of the local net
  554.     header by the local network interface and handed to the internet
  555.     module.
  556.  
  557.     The internet module determines that the datagram is for an
  558.     application program in this host.  It passes the data to the
  559.     application program in response to a system call, passing the source
  560.     address and other parameters as results of the call.
  561.  
  562.                                     
  563.    Application                                           Application
  564.    Program                                                   Program
  565.          \                                                   /      
  566.        Internet Module      Internet Module      Internet Module    
  567.              \                 /       \                /           
  568.              LNI-1          LNI-1      LNI-2         LNI-2          
  569.                 \           /             \          /              
  570.                Local Network 1           Local Network 2            
  571.  
  572.  
  573.  
  574.                             Transmission Path
  575.  
  576.                                 Figure 2
  577.  
  578.  
  579.  
  580.  
  581.  
  582. [Page 6]                                                                
  583.  
  584.  
  585. January 1980                                                            
  586.                                                        Internet Protocol
  587.                                                                 Overview
  588.  
  589.  
  590.  
  591. 2.3.  Function Description
  592.  
  593.   The function or purpose of Internet Protocol is to move datagrams
  594.   through an interconnected set of networks.  This is done by passing
  595.   the datagrams from one internet module to another until the
  596.   destination is reached.  The internet modules reside in hosts and
  597.   gateways in the internet system.  The datagrams are routed from one
  598.   internet module to another through individual networks based on the
  599.   interpretation of an internet address.  Thus, one important mechanism
  600.   of the internet protocol is the internet address.
  601.  
  602.   In the routing of messages from one internet module to another,
  603.   datagrams may need to traverse a network whose maximum packet size is
  604.   smaller than the size of the datagram.  To overcome this difficulty, a
  605.   fragmentation mechanism is provided in the internet protocol.
  606.  
  607.   Addressing
  608.  
  609.     A distinction is made between names, addresses, and routes [3].   A
  610.     name indicates what we seek.  An address indicates where it is.  A
  611.     route indicates how to get there.  The internet protocol deals
  612.     primarily with addresses.  It is the task of higher level (i.e.,
  613.     host-to-host or application) protocols to make the mapping from
  614.     names to addresses.   The internet module maps internet addresses to
  615.     local net addresses.  It is the task of lower level (i.e., local net
  616.     or gateways) procedures to make the mapping from local net 
  617.     addresses to routes.
  618.  
  619.     Addresses are fixed length of four octets (32 bits).  An address
  620.     begins with a one octet network number, followed by a three octet
  621.     local address.  This three octet field is called the "rest" field.
  622.  
  623.     Care must be taken in mapping internet addresses to local net
  624.     addresses; a single physical host must be able to act as if it were
  625.     several distinct hosts to the extent of using several distinct
  626.     internet addresses.  A host should also be able to have several
  627.     physical interfaces (multi-homing).
  628.  
  629.     That is, a host should be allowed several physical interfaces to the
  630.     network with each having several logical internet addresses.
  631.  
  632.     Examples of address mappings may be found in reference [4].
  633.  
  634.   Fragmentation
  635.  
  636.     Fragmentation of an internet datagram may be necessary when it
  637.     originates in a local net that allows a large packet size and must
  638.  
  639.  
  640.  
  641.                                                                 [Page 7]
  642.  
  643.  
  644.                                                             January 1980
  645. Internet Protocol
  646. Overview
  647.  
  648.  
  649.  
  650.     traverse a local net that limits packets to a smaller size to reach
  651.     its destination.
  652.  
  653.     An internet datagram can be marked "don't fragment."  Any internet
  654.     datagram so marked is not to be internet fragmented under any
  655.     circumstances.  If internet datagram marked don't fragment cannot be
  656.     delivered to its destination without fragmenting it, it is to be
  657.     discarded instead.
  658.  
  659.     Fragmentation, transmission and reassembly across a local network
  660.     which is invisible to the internet protocol module is called
  661.     intranet fragmentation and may be used [5].
  662.  
  663.     The internet fragmentation and reassembly procedure needs to be able
  664.     to break a datagram into an almost arbitrary number of pieces that
  665.     can be later reassembled.  The receiver of the fragments uses the
  666.     identification field to ensure that fragments of different datagrams
  667.     are not mixed.  The fragment offset field tells the receiver the
  668.     position of a fragment in the original datagram.  The fragment
  669.     offset and length determine the portion of the original datagram
  670.     covered by this fragment.  The more-fragments flag indicates (by
  671.     being reset) the last fragment.  These fields provide sufficient
  672.     information to reassemble datagrams.
  673.  
  674.     The identification field is used to distinguish the fragments of one
  675.     datagram from those of another.  The originating protocol module of
  676.     an internet datagram sets the identification field to a value that
  677.     must be unique for that source-destination pair and protocol for the
  678.     time the datagram will be active in the internet system.  The
  679.     originating protocol module of a complete datagram sets the
  680.     more-fragments flag to zero and the fragment offset to zero.
  681.  
  682.     To fragment a long internet datagram, an internet protocol module
  683.     (for example, in a gateway), creates two new internet datagrams and
  684.     copies the contents of the internet header fields from the long
  685.     datagram into both new internet headers.  The data of the long
  686.     datagram is divided into two portions on a 8 octet (64 bit) boundary
  687.     (the second portion might not be an integral multiple of 8 octets,
  688.     but the first must be).  Call the number of 8 octet blocks in the
  689.     first portion NFB (for Number of Fragment Blocks).  The first
  690.     portion of the data is placed in the first new internet datagram,
  691.     and the total length field is set to the length of the first
  692.     datagram.  The more-fragments flag is set to one.  The second
  693.     portion of the data is placed in the second new internet datagram,
  694.     and the total length field is set to the length of the second
  695.     datagram.  The more-fragments flag carries the same value as the
  696.     long datagram.  The fragment offset field of the second new internet
  697.  
  698.  
  699.  
  700. [Page 8] 
  701.  
  702.  
  703. January 1980 
  704.                                                        Internet Protocol
  705.                                                                 Overview
  706.  
  707.  
  708.  
  709.     datagram is set to the value of that field in the long datagram plus
  710.     NFB.
  711.  
  712.     This procedure can be generalized for an n-way split, rather than
  713.     the two-way split described.
  714.  
  715.     To assemble the fragments of an internet datagram, an internet
  716.     protocol module (for example at a destination host) combines
  717.     internet datagram that all have the same value for the four fields:
  718.     identification, source, destination, and protocol.  The combination
  719.     is done by placing the data portion of each fragment in the relative
  720.     position indicated by the fragment offset in that fragment's
  721.     internet header.  The first fragment will have the fragment offset
  722.     zero, and the last fragment will have the more-fragments flag reset
  723.     to zero.
  724.  
  725.     
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.                                                                 [Page 9]
  760.  
  761.  
  762.                                                             January 1980
  763. Internet Protocol
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818. [Page 10]                                                               
  819.  
  820.  
  821. January 1980                                                            
  822.                                                        Internet Protocol
  823.  
  824.  
  825.  
  826.                            3.  SPECIFICATION
  827.  
  828. 3.1.  Internet Header Format
  829.  
  830.   A summary of the contents of the internet header follows:
  831.  
  832.                                     
  833.     0                   1                   2                   3   
  834.     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 
  835.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  836.    |Version|  IHL  |Type of Service|          Total Length         |
  837.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  838.    |         Identification        |Flags|      Fragment Offset    |
  839.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  840.    |  Time to Live |    Protocol   |         Header Checksum       |
  841.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  842.    |                       Source Address                          |
  843.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  844.    |                    Destination Address                        |
  845.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  846.    |                    Options                    |    Padding    |
  847.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  848.  
  849.                     Example Internet Datagram Header
  850.  
  851.                                Figure 3.
  852.  
  853.   Note that each tick mark represents one bit position.
  854.  
  855.   Version:  4 bits
  856.  
  857.     The Version field indicates the format of the internet header.  This
  858.     document describes version 4.
  859.  
  860.   IHL:  4 bits
  861.  
  862.     Internet Header Length is the length of the internet header in 32
  863.     bit words, and thus points to the beginning of the data.  Note that
  864.     the minimum value for a correct header is 5.
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.                                                                [Page 11]
  878.  
  879.  
  880.                                                             January 1980
  881. Internet Protocol
  882. Specification
  883.  
  884.  
  885.  
  886.   Type of Service:  8 bits
  887.  
  888.     The Type of Service provides an indication of the abstract
  889.     parameters of the quality of service desired.  These parameters are
  890.     to be used to guide the selection of the actual service parameters
  891.     when transmitting a datagram through a particular network.  Several
  892.     networks offer service precedence, which somehow treats high
  893.     precedence traffic as more important than other traffic.  A few
  894.     networks offer a Stream service, whereby one can achieve a smoother
  895.     service at some cost.  Typically this involves the reservation of
  896.     resources within the network.  Another choice involves a low-delay
  897.     vs. high-reliability trade off.  Typically networks invoke more
  898.     complex (and delay producing) mechanisms as the need for reliability
  899.     increases.
  900.  
  901.       Bits 0-2:  Precedence.
  902.       Bit    3:  Stream or Datagram.
  903.       Bits 4-5:  Reliability.
  904.       Bit    6:  Speed over Reliability.
  905.       Bits   7:  Speed.
  906.  
  907.          0     1     2     3     4     5     6     7
  908.       +-----+-----+-----+-----+-----+-----+-----+-----+
  909.       |                 |     |           |     |     |
  910.       |   PRECEDENCE    | STRM|RELIABILITY| S/R |SPEED|
  911.       |                 |     |           |     |     |
  912.       +-----+-----+-----+-----+-----+-----+-----+-----+
  913.  
  914.       PRECEDENCE          STRM      RELIABILITY  S/R      SPEED
  915.       111-Flash Override  1-STREAM  11-highest   1-speed  1-high
  916.       110-Flash           0-DTGRM   10-higher    0-rlblt  0-low
  917.       11X-Immediate                 01-lower
  918.       01X-Priority                  00-lowest
  919.       00X-Routine
  920.  
  921.     The type of service is used to specify the treatment of the datagram
  922.     during its transmission through the internet system.  In the
  923.     discussion (section 3.2) below, a chart shows the relationship of
  924.     the internet type of service to the actual service provided on the
  925.     ARPANET, the SATNET, and the PRNET.
  926.  
  927.   Total Length:  16 bits
  928.  
  929.     Total Length is the length of the datagram, measured in octets,
  930.     including internet header and data.  This field allows the length of
  931.     a datagram to be up to 65,535 octets.  Such long datagrams are
  932.     impractical for most hosts and networks.  All hosts must be prepared
  933.     to accept datagrams of up to 576 octets (whether they arrive whole
  934.  
  935.  
  936. [Page 12]                                                               
  937.  
  938.  
  939. January 1980                                                            
  940.                                                        Internet Protocol
  941.                                                            Specification
  942.  
  943.  
  944.  
  945.     or in fragments).  It is recommended that hosts only send datagrams
  946.     larger than 576 octets if they have assurance that the destination
  947.     is prepared to accept the larger datagrams.
  948.  
  949.     The number 576 is selected to allow a reasonable sized data block to
  950.     be transmitted in addition to the required header information.  For
  951.     example, this size allows a data block of 512 octets plus 64 header
  952.     octets to fit in a datagram.  The maximal internet header is 60
  953.     octets, and a typical internet header is 20 octets, allowing a
  954.     margin for headers of higher level protocols.
  955.  
  956.   Identification:  16 bits
  957.  
  958.     An identifying value assigned by the sender to aid in assembling the
  959.     fragments of a datagram.
  960.  
  961.   Flags:  3 bits
  962.  
  963.     Various Control Flags.
  964.  
  965.       Bit 0: reserved, must be zero
  966.       Bit 1: Don't Fragment This Datagram (DF).
  967.       Bit 2: More Fragments Flag (MF).
  968.  
  969.           0   1   2
  970.         +---+---+---+
  971.         |   | D | M |
  972.         | 0 | F | F |
  973.         +---+---+---+
  974.  
  975.   Fragment Offset:  13 bits
  976.  
  977.     This field indicates where in the datagram this fragment belongs.
  978.     The fragment offset is measured in units of 8 octets (64 bits).  The
  979.     first fragment has offset zero.
  980.  
  981.   Time to Live:  8 bits
  982.  
  983.     This field indicates the maximum time the datagram is allowed to
  984.     remain the internet system.  If this field contains the value zero,
  985.     then the datagram should be destroyed.  This field is modified in
  986.     internet header processing.  The time is measured in units of
  987.     seconds.  The intention is to cause undeliverable datagrams to be
  988.     discarded.
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.                                                                [Page 13]
  996.  
  997.  
  998.                                                             January 1980
  999. Internet Protocol
  1000. Specification
  1001.  
  1002.  
  1003.  
  1004.   Protocol:  8 bits
  1005.  
  1006.     This field indicates the next level protocol used in the data
  1007.     portion of the internet datagram.  The values for various protocols
  1008.     are specified in reference [6].
  1009.  
  1010.   Header Checksum:  16 bits
  1011.  
  1012.     A checksum on the header only.  Since some header fields may change
  1013.     (e.g., time to live), this is recomputed and verified at each point
  1014.     that the internet header is processed.
  1015.  
  1016.     The checksum algorithm is:
  1017.  
  1018.       The checksum field is the 16 bit one's complement of the one's
  1019.       complement sum of all 16 bit words in the header.  For purposes of
  1020.       computing the checksum, the value of the checksum field is zero.
  1021.  
  1022.     This is a simple to compute checksum and experimental evidence
  1023.     indicates it is adequate, but it is provisional and may be replaced
  1024.     by a CRC procedure, depending on further experience.
  1025.  
  1026.   Source Address:  32 bits
  1027.  
  1028.     The source address.  The first octet is the Source Network, and the
  1029.     following three octets are the Source Local Address.
  1030.  
  1031.   Destination Address:  32 bits
  1032.  
  1033.     The destination address.  The first octet is the Destination
  1034.     Network, and the following three octets are the Destination Local
  1035.     Address.
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054. [Page 14]                                                               
  1055.  
  1056.  
  1057. January 1980                                                            
  1058.                                                        Internet Protocol
  1059.                                                            Specification
  1060.  
  1061.  
  1062.  
  1063.   Options:  variable
  1064.  
  1065.     The option field is variable in length.  There may be zero or more
  1066.     options.  There are two cases for the format of an option:
  1067.  
  1068.       Case 1:  A single octet of option-type.
  1069.  
  1070.       Case 2:  An option-type octet, an option-length octet, and the
  1071.                actual option-data octets.
  1072.  
  1073.     The option-length octet counts the option-type octet and the
  1074.     option-length octet as well as the option-data octets.
  1075.  
  1076.     The option-type octet is viewed as having 3 fields:
  1077.  
  1078.       1 bit   reserved, must be zero
  1079.       2 bits  option class,
  1080.       5 bits  option number.
  1081.  
  1082.     The option classes are:
  1083.  
  1084.       0 = control
  1085.       1 = internet error
  1086.       2 = experimental debugging and measurement
  1087.       3 = reserved for future use
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.                                                                [Page 15]
  1114.  
  1115.  
  1116.                                                             January 1980
  1117. Internet Protocol
  1118. Specification
  1119.  
  1120.  
  1121.  
  1122.     The following internet options are defined:
  1123.  
  1124.       CLASS NUMBER LENGTH DESCRIPTION
  1125.       ----- ------ ------ -----------
  1126.         0     0      -    End of Option list.  This option occupies only
  1127.                           1 octet; it has no length octet.
  1128.         0     1      -    No Operation.  This option occupies only 1
  1129.                           octet; it has no length octet.
  1130.         0     2      4    Security.  Used to carry Security, and user
  1131.                           group (TCC) information compatible with DOD
  1132.                           requirements.
  1133.         0     3     var.  Source Routing.  Used to route the internet
  1134.                           datagram based on information supplied by the
  1135.                           source.
  1136.         0     7     var.  Return Route.  Used to record the route an
  1137.                           internet datagram takes.
  1138.         0     8      4    Stream ID.  Used to carry the stream
  1139.                           identifier.
  1140.         1     1     var.  General Error Report.  Used to report errors
  1141.                           in internet datagram processing.
  1142.         2     4      6    Internet Timestamp.
  1143.         2     5      6    Satellite Timestamp.
  1144.  
  1145.       
  1146.  
  1147.     Specific Option Definitions
  1148.  
  1149.       End of Option List
  1150.  
  1151.         +--------+
  1152.         |00000000|
  1153.         +--------+
  1154.           Type=0
  1155.  
  1156.         This option indicates the end of the option list.  This might
  1157.         not coincide with the end of the internet header according to
  1158.         the internet header length.  This is used at the end of all
  1159.         options, not the end of each option, and need only be used if
  1160.         the end of the options would not otherwise coincide with the end
  1161.         of the internet header.
  1162.  
  1163.         May be copied, introduced, or deleted on fragmentation.
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172. [Page 16]                                                               
  1173.  
  1174.  
  1175. January 1980                                                            
  1176.                                                        Internet Protocol
  1177.                                                            Specification
  1178.  
  1179.  
  1180.  
  1181.       No Operation
  1182.  
  1183.         +--------+
  1184.         |00000001|
  1185.         +--------+
  1186.           Type=1
  1187.  
  1188.         This option may be used between options, for example, to align
  1189.         the beginning of a subsequent option on a 32 bit boundary.
  1190.  
  1191.         May be copied, introduced, or deleted on fragmentation.
  1192.  
  1193.       Security
  1194.  
  1195.         This option provides a way for DOD hosts to send security and
  1196.         TCC (closed user groups) parameters through networks whose
  1197.         transport leader does not contain fields for this information.
  1198.         The format for this option is as follows:
  1199.  
  1200.           +--------+--------+---------+--------+
  1201.           |00000010|00000100|000000SS |  TCC   |
  1202.           +--------+--------+---------+--------+
  1203.             Type=2  Length=4
  1204.  
  1205.         Security:  2 bits
  1206.  
  1207.           Specifies one of 4 levels of security
  1208.  
  1209.             11-top secret
  1210.             10-secret
  1211.             01-confidential
  1212.             00-unclassified
  1213.  
  1214.         Transmission Control Code:  8 bits
  1215.  
  1216.           Provides a means to compartmentalize traffic and define
  1217.           controlled communities of interest among subscribers.
  1218.  
  1219.         Note that this option does not require processing by the
  1220.         internet module but does require that this information be passed
  1221.         to higher level protocol modules.  The security and TCC
  1222.         information might be used to supply class level and compartment
  1223.         information for transmitting datagrams into or through
  1224.         AUTODIN II.
  1225.  
  1226.         Must be copied on fragmentation.
  1227.  
  1228.  
  1229.  
  1230.  
  1231.                                                                [Page 17]
  1232.  
  1233.  
  1234.                                                             January 1980
  1235. Internet Protocol
  1236. Specification
  1237.  
  1238.  
  1239.  
  1240.       Source Route
  1241.  
  1242.         +--------+--------+--------+---------//--------+
  1243.         |00000011| length |        source route        |
  1244.         +--------+--------+--------+---------//--------+
  1245.           Type=3
  1246.  
  1247.         The source route option provides a means for the source of an
  1248.         internet datagram to supply routing information to be used by
  1249.         the gateways in forwarding the datagram to the destination.
  1250.  
  1251.         The option begins with the option type code.  The second octet
  1252.         is the option length which includes the option type code and the
  1253.         length octet, as well as length-2 octets of source route data.
  1254.  
  1255.         A source route is composed of a series of internet addresses.
  1256.         Each internet address is 32 bits or 4 octets.  The length
  1257.         defaults to two, which indicates the source route is empty and
  1258.         the remaining routing is to be based on the destination address
  1259.         field.
  1260.  
  1261.         If the address in destination address field has been reached and
  1262.         this option's length is not two, the next address in the source
  1263.         route replaces the address in the destination address field, and
  1264.         is deleted from the source route and this option's length is
  1265.         reduced by four.  (The Internet Header Length Field must be
  1266.         changed also.)
  1267.  
  1268.         Must be copied on fragmentation.
  1269.  
  1270.       Return Route
  1271.  
  1272.         +--------+--------+--------+---------//--------+
  1273.         |00000111| length |        return route        |
  1274.         +--------+--------+--------+---------//--------+
  1275.           Type=7
  1276.  
  1277.         The return route option provides a means to record the route of
  1278.         an internet datagram.
  1279.  
  1280.         The option begins with the option type code.  The second octet
  1281.         is the option length which includes the option type code and the
  1282.         length octet, as well as length-2 octets of return route data.
  1283.  
  1284.         A return route is composed of a series of internet addresses.
  1285.         The length defaults to two, which indicates the return route is
  1286.         empty.
  1287.  
  1288.  
  1289.  
  1290. [Page 18]                                                               
  1291.  
  1292.  
  1293. January 1980                                                            
  1294.                                                        Internet Protocol
  1295.                                                            Specification
  1296.  
  1297.  
  1298.  
  1299.         When an internet module routes a datagram it checks to see if
  1300.         the return route option is present.  If it is, it inserts its
  1301.         own internet address as known in the environment into which this
  1302.         datagram is being forwarded into the return route at the front
  1303.         of the address string and increments the length by four.
  1304.  
  1305.         Not copied on fragmentation, goes in first fragment only.
  1306.  
  1307.       Stream Identifier
  1308.  
  1309.         +--------+--------+---------+--------+
  1310.         |00001000|00000010|     Stream ID    |
  1311.         +--------+--------+---------+--------+
  1312.           Type=8  Length=4
  1313.  
  1314.         This option provides a way for the 16-bit SATNET stream
  1315.         identifier to be carried through networks that do not support
  1316.         the stream concept.
  1317.  
  1318.         Must be copied on fragmentation.
  1319.  
  1320.       General Error Report
  1321.  
  1322.         +--------+--------+--------+--------+--------+----//----+
  1323.         |00100001| length |err code|        id       |          |
  1324.         +--------+--------+--------+--------+--------+----//----+
  1325.          Type=33
  1326.  
  1327.         The general error report is used to report an error detected in
  1328.         processing an internet datagram to the source internet module of
  1329.         that datagram.  The "err code" indicates the type of error
  1330.         detected, and the "id" is copied from the identification field
  1331.         of the datagram in error, additional octets of error information
  1332.         may be present depending on the err code.
  1333.  
  1334.         If an internet datagram containing the general error report
  1335.         option is found to be in error or must be discarded, no error
  1336.         report is sent.
  1337.  
  1338.         ERR CODE:
  1339.  
  1340.           0 - Undetermined Error, used when no information is available
  1341.           about the type of error or the error does not fit any defined
  1342.           class.  Following the id should be as much of the datagram
  1343.           (starting with the internet header) as fits in the option
  1344.           space.
  1345.  
  1346.           1 - Datagram Discarded, used when specific information is
  1347.  
  1348.  
  1349.                                                                [Page 19]
  1350.  
  1351.  
  1352.                                                             January 1980
  1353. Internet Protocol
  1354. Specification
  1355.  
  1356.  
  1357.  
  1358.           available about the reason for discarding the datagram can be
  1359.           reported.  Following the id should be the original (4-octets)
  1360.           destination address, and the (1-octet) reason.
  1361.  
  1362.             Reason   Description
  1363.             ------   -----------
  1364.                0     No Reason
  1365.                1     No One Wants It - No higher level protocol or
  1366.                      application program at destination wants this
  1367.                      datagram.
  1368.                2     Fragmentation Needed & DF - Cannot deliver with out
  1369.                      fragmenting and has don't fragment bit set.
  1370.                3     Reassembly Problem - Destination could not
  1371.                      reassemble due to missing fragments when time to
  1372.                      live expired.
  1373.                4     Gateway Congestion - Gateway discarded datagram due
  1374.                      to congestion.
  1375.  
  1376.         The error report is placed in a datagram with the following
  1377.         values in the internet header fields:
  1378.  
  1379.           Version:  Same as the datagram in error.
  1380.           IHL:  As computed.
  1381.           Type of Service:  Zero.
  1382.           Total Length:  As computed.
  1383.           Identification:  A new identification is selected.
  1384.           Flags:  Zero.
  1385.           Fragment Offset:  Zero.
  1386.           Time to Live:  Sixty.
  1387.           Protocol:  Same as the datagram in error.
  1388.           Header Checksum:  As computed.
  1389.           Source Address:  Address of the error reporting module.
  1390.           Destination Address:  Source address of the datagram in error.
  1391.           Options:  The General Error Report Option.
  1392.           Padding:  As needed.
  1393.  
  1394.         Not copied on fragmentation, goes with first fragment.
  1395.  
  1396.       Internet Timestamp
  1397.  
  1398.         +--------+--------+--------+--------+--------+--------+
  1399.         |01000100|00000100|        time in milliseconds       |
  1400.         +--------+--------+--------+--------+--------+--------+
  1401.          Type=68  Length=6
  1402.  
  1403.         The data of the timestamp is a 32 bit time measured in
  1404.         milliseconds.
  1405.  
  1406.  
  1407.  
  1408. [Page 20]                                                               
  1409.  
  1410.  
  1411. January 1980                                                            
  1412.                                                        Internet Protocol
  1413.                                                            Specification
  1414.  
  1415.  
  1416.  
  1417.         Not copied on fragmentation, goes with first fragment
  1418.  
  1419.       Satellite Timestamp
  1420.  
  1421.         +--------+--------+--------+--------+--------+--------+
  1422.         |01000101|00000100|        time in milliseconds       |
  1423.         +--------+--------+--------+--------+--------+--------+
  1424.          Type=69  Length=6
  1425.  
  1426.         The data of the timestamp is a 32 bit time measured in
  1427.         milliseconds.
  1428.  
  1429.         Not copied on fragmentation, goes with first fragment
  1430.  
  1431.   Padding:  variable
  1432.  
  1433.     The internet header padding is used to ensure that the internet
  1434.     header ends on a 32 bit boundary.  The padding is zero.
  1435.  
  1436. 3.2.  Discussion
  1437.  
  1438.   The implementation of a protocol must be robust.  Each implementation
  1439.   must expect to interoperate with others created by different
  1440.   individuals.  While the goal of this specification is to be explicit
  1441.   about the protocol there is the possibility of differing
  1442.   interpretations.  In general, an implementation should be conservative
  1443.   in its sending behavior, and liberal in its receiving behavior.  That
  1444.   is, it should be careful to send well-formed datagrams, but should
  1445.   accept any datagram that it can interpret (e.g., not object to
  1446.   technical errors where the meaning is still clear).
  1447.  
  1448.   The basic internet service is datagram oriented and provides for the
  1449.   fragmentation of datagrams at gateways, with reassembly taking place
  1450.   at the destination internet protocol module in the destination host.
  1451.   Of course, fragmentation and reassembly of datagrams within a network
  1452.   or by private agreement between the gateways of a network is also
  1453.   allowed since this is transparent to the internet protocols and the
  1454.   higher-level protocols.  This transparent type of fragmentation and
  1455.   reassembly is termed "network-dependent" (or intranet) fragmentation
  1456.   and is not discussed further here.
  1457.  
  1458.   Internet addresses distinguish sources and destinations to the host
  1459.   level and provide a protocol field as well.  It is assumed that each
  1460.   protocol will provide for whatever multiplexing is necessary within a
  1461.   host.
  1462.  
  1463.  
  1464.  
  1465.  
  1466.  
  1467.                                                                [Page 21]
  1468.  
  1469.  
  1470.                                                             January 1980
  1471. Internet Protocol
  1472. Specification
  1473.  
  1474.  
  1475.  
  1476.   Addressing
  1477.  
  1478.     The 8 bit network number, which is the first octet of the address,
  1479.     has a value as specified in reference [6].
  1480.  
  1481.     The 24 bit local address, assigned by the local network, should
  1482.     allow for a single physical host to act as several distinct internet
  1483.     hosts.  That is, there should be mapping between internet host
  1484.     addresses and network/host interfaces that allows several internet
  1485.     addresses to correspond to one interface.  It should also be allowed
  1486.     for a host to have several physical interfaces and to treat the
  1487.     datagrams from several of them as if they were all addressed to a
  1488.     single host.  Address mappings between internet addresses and
  1489.     addresses for ARPANET, SATNET, PRNET, and other networks are
  1490.     described in reference [4].
  1491.  
  1492.   Fragmentation and Reassembly.
  1493.  
  1494.     The internet identification field (ID) is used together with the
  1495.     source and destination address, and the protocol fields, to identify
  1496.     datagram fragments for reassembly.
  1497.  
  1498.     The More Fragments flag bit (MF) is set if the datagram is not the
  1499.     last fragment.  The Fragment Offset field identifies the fragment
  1500.     location, relative to the beginning of the original unfragmented
  1501.     datagram.  Fragments are counted in units of 8 octets.  The
  1502.     fragmentation strategy is designed so than an unfragmented datagram
  1503.     has all zero fragmentation information (MF = 0, fragment offset =
  1504.     0).  If an internet datagram is fragmented, its data portion must be
  1505.     broken on 8 octet boundaries.
  1506.  
  1507.     This format allows 2**13 = 8192 fragments of 8 octets each for a
  1508.     total of 65,536 octets.  Note that this is consistent with the the
  1509.     datagram total length field.
  1510.  
  1511.     When fragmentation occurs, some options are copied, but others
  1512.     remain with the first fragment only.
  1513.  
  1514.     Every internet module must be able to forward a datagram of 68
  1515.     octets without further fragmentation.  This is because an internet
  1516.     header may be up to 60 octets, and the minimum fragment is 8 octets.
  1517.  
  1518.     Every internet destination must be able to receive a datagram of 576
  1519.     octets either in one piece or in fragments to be reassembled.
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526. [Page 22]                                                               
  1527.  
  1528.  
  1529. January 1980                                                            
  1530.                                                        Internet Protocol
  1531.                                                            Specification
  1532.  
  1533.  
  1534.  
  1535.     The fields which may be affected by fragmentation include:
  1536.  
  1537.       (1) options field
  1538.       (2) more fragments flag
  1539.       (3) fragment offset
  1540.       (4) internet header length field
  1541.       (5) total length field
  1542.       (6) header checksum
  1543.  
  1544.     If the Don't Fragment flag (DF) bit is set, then internet
  1545.     fragmentation of this datagram is NOT permitted, although it may be
  1546.     discarded.  This can be used to prohibit fragmentation in cases
  1547.     where the receiving host does not have sufficient resources to
  1548.     reassemble internet fragments.
  1549.  
  1550.     General notation in the following pseudo programs: "=<" means "less
  1551.     than or equal", "#" means "not equal", "=" means "equal", "<-" means
  1552.     "is set to".  Also, "x to y" includes x and excludes y; for example,
  1553.     "4 to 7" would include 4, 5, and 6 (but not 7).
  1554.  
  1555.     Fragmentation Procedure
  1556.  
  1557.       The maximum sized datagram that can be transmitted through the
  1558.       next network is called the maximum transmission unit (MTU).
  1559.  
  1560.       If the total length is less than or equal the maximum transmission
  1561.       unit then submit this datagram to the next step in datagram
  1562.       processing; otherwise cut the datagram into two fragments, the
  1563.       first fragment being the maximum size, and the second fragment
  1564.       being the rest of the datagram.  The first fragment is submitted
  1565.       to the next step in datagram processing, while the second fragment
  1566.       is submitted to this procedure in case it still too large.
  1567.  
  1568.       Notation:
  1569.  
  1570.         FO    -  Fragment Offset
  1571.         IHL   -  Internet Header Length
  1572.         MF    -  More Fragments flag
  1573.         TL    -  Total Length
  1574.         OFO   -  Old Fragment Offset
  1575.         OIHL  -  Old Internet Header Length
  1576.         OMF   -  Old More Fragments flag
  1577.         OTL   -  Old Total Length
  1578.         NFB   -  Number of Fragment Blocks
  1579.         MTU   -  Maximum Transmission Unit
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.                                                                [Page 23]
  1586.  
  1587.  
  1588.                                                             January 1980
  1589. Internet Protocol
  1590. Specification
  1591.  
  1592.  
  1593.  
  1594.       Procedure:
  1595.  
  1596.         IF TL =< MTU THEN Submit this datagram to the next step
  1597.              in datagram processing ELSE
  1598.         To produce the first fragment:
  1599.         (1)  Copy the original internet header;
  1600.         (2)  OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
  1601.         (3)  NFB <- (MTU-IHL*4)/8;
  1602.         (4)  Attach the first NFB*8 data octets;
  1603.         (5)  Correct the header:
  1604.              MF <- 1;  TL <- (IHL*4)+(NFB*8);
  1605.              Recompute Checksum;
  1606.         (6)  Submit this fragment to the next step in
  1607.              datagram processing;
  1608.         To produce the second fragment:
  1609.         (7)  Selectively copy the internet header (some options
  1610.              are not copied, see option definitions);
  1611.         (8)  Append the remaining data;
  1612.         (9)  Correct the header:
  1613.              IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
  1614.              TL <- OTL - NFB*8 - (OIHL-IHL)*4);
  1615.              FO <- OFO + NFB;  MF <- OMF;  Recompute Checksum;
  1616.         (10) Submit this fragment to the fragmentation test; DONE.
  1617.  
  1618.     Reassembly Procedure
  1619.  
  1620.       For each datagram the buffer identifier is computed as the
  1621.       concatenation of the source, destination, protocol, and
  1622.       identification fields.  If this is a whole datagram (that is both
  1623.       the fragment offset and the more fragments  fields are zero), then
  1624.       any reassembly resources associated with this buffer identifier
  1625.       are released and the datagram is forwarded to the next step in
  1626.       datagram processing.
  1627.  
  1628.       If no other fragment with this buffer identifier is on hand then
  1629.       reassembly resources are allocated.  The reassembly resources
  1630.       consist of a data buffer, a header buffer, a fragment block bit
  1631.       table, a total data length field, and a timer.  The data from the
  1632.       fragment is placed in the data buffer according to its fragment
  1633.       offset and length, and bits are set in the fragment block bit
  1634.       table corresponding to the fragment blocks received.
  1635.  
  1636.       If this is the first fragment (that is the fragment offset is
  1637.       zero)  this header is placed in the header buffer.  If this is the
  1638.       last fragment ( that is the more fragments field is zero) the
  1639.       total data length is computed.  If this fragment completes the
  1640.       datagram (tested by checking the bits set in the fragment block
  1641.       table), then the datagram is sent to the next step in datagram
  1642.  
  1643.  
  1644. [Page 24]                                                               
  1645.  
  1646.  
  1647. January 1980                                                            
  1648.                                                        Internet Protocol
  1649.                                                            Specification
  1650.  
  1651.  
  1652.  
  1653.       processing; otherwise the timer is set to the maximum of the
  1654.       current timer value and the value of the time to live field from
  1655.       this fragment; and the reassembly routine gives up control.
  1656.  
  1657.       If the timer runs out, the all reassembly resources for this
  1658.       buffer identifier are released.  The initial setting of the timer
  1659.       is a lower bound on the reassembly waiting time.  This is because
  1660.       the waiting time will be increased if the Time to Live in the
  1661.       arriving fragment is greater than the current timer value but will
  1662.       not be decreased if it is less.  The maximum this timer value
  1663.       could reach is the maximum time to live (approximately 4.25
  1664.       minutes).  The current recommendation for the initial timer
  1665.       setting is 15 seconds.  This may be changed as experience with
  1666.       this protocol accumulates.  Note that the choice of this parameter
  1667.       value is related to the buffer capacity available and the data
  1668.       rate of the transmission medium; that is, data rate times timer
  1669.       value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).
  1670.  
  1671.       Notation:
  1672.  
  1673.         FO    -  Fragment Offset
  1674.         IHL   -  Internet Header Length
  1675.         MF    -  More Fragments flag
  1676.         TTL   -  Time To Live
  1677.         NFB   -  Number of Fragment Blocks
  1678.         TL    -  Total Length
  1679.         TDL   -  Total Data Length
  1680.         BUFID -  Buffer Identifier
  1681.         RCVBT -  Fragment Received Bit Table
  1682.         TLB   -  Timer Lower Bound
  1683.  
  1684.  
  1685.  
  1686.  
  1687.  
  1688.  
  1689.  
  1690.  
  1691.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.                                                                [Page 25]
  1704.  
  1705.  
  1706.                                                             January 1980
  1707. Internet Protocol
  1708. Specification
  1709.  
  1710.  
  1711.  
  1712.       Procedure:
  1713.  
  1714.         (1)  BUFID <- source|destination|protocol|identification;
  1715.         (2)  IF FO = 0 AND MF = 0
  1716.         (3)     THEN IF buffer with BUFID is allocated
  1717.         (4)             THEN flush all reassembly for this BUFID;
  1718.         (5)          Submit datagram to next step; DONE.
  1719.         (6)     ELSE IF no buffer with BUFID is allocated
  1720.         (7)             THEN allocate reassembly resources
  1721.                              with BUFID;
  1722.                              TIMER <- TLB; TDL <- 0;
  1723.         (8)          put data from fragment into data buffer with
  1724.                      BUFID from octet FO*8 to
  1725.                                          octet (TL-(IHL*4))+FO*8;
  1726.         (9)          set RCVBT bits from FO
  1727.                                         to FO+((TL-(IHL*4)+7)/8);
  1728.         (10)         IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
  1729.         (11)         IF FO = 0 THEN put header in header buffer
  1730.         (12)         IF TDL # 0
  1731.         (13)          AND all RCVBT bits from 0
  1732.                                              to (TDL+7)/8 are set
  1733.         (14)            THEN TL <- TDL+(IHL*4)
  1734.         (15)                 Submit datagram to next step;
  1735.         (16)                 free all reassembly resources
  1736.                              for this BUFID; DONE.
  1737.         (17)         TIMER <- MAX(TIMER,TTL);
  1738.         (18)         give up until next fragment or timer expires;
  1739.         (19) timer expires: flush all reassembly with this BUFID; DONE.
  1740.  
  1741.       In the case that two or more fragments contain the same data
  1742.       either identically or through a partial overlap, this procedure
  1743.       will use the more recently arrived copy in the data buffer and
  1744.       datagram delivered.
  1745.  
  1746.   Identification
  1747.  
  1748.     The choice of the Identifier for a datagram is based on the need to
  1749.     provide a way to uniquely identify the fragments of a particular
  1750.     datagram.  The protocol module assembling fragments judges fragments
  1751.     to belong to the same datagram if they have the same source,
  1752.     destination, protocol, and Identifier.  Thus, the sender must choose
  1753.     the Identifier to be unique for this source, destination pair and
  1754.     protocol for the time the datagram (or any fragment of it) could be
  1755.     alive in the internet.
  1756.  
  1757.     It seems then that a sending protocol module needs to keep a table
  1758.     of Identifiers, one entry for each destination it has communicated
  1759.     with in the last maximum packet lifetime for the internet.
  1760.  
  1761.  
  1762. [Page 26]                                                               
  1763.  
  1764.  
  1765. January 1980                                                            
  1766.                                                        Internet Protocol
  1767.                                                            Specification
  1768.  
  1769.  
  1770.  
  1771.     However, since the Identifier field allows 65,536 different values,
  1772.     some host may be able to simply use unique identifiers independent
  1773.     of destination.
  1774.  
  1775.     It is appropriate for some higher level protocols to choose the
  1776.     identifier. For example, TCP protocol modules may retransmit an
  1777.     identical TCP segment, and the probability for correct reception
  1778.     would be enhanced if the retransmission carried the same identifier
  1779.     as the original transmission since fragments of either datagram
  1780.     could be used to construct a correct TCP segment.
  1781.  
  1782.   Type of Service
  1783.  
  1784.     The type of service (TOS) is for internet service quality selection.
  1785.     The type of service is specified along the abstract parameters
  1786.     precedence, reliability, and speed.  A further concern is the
  1787.     possibility of efficient handling of streams of datagrams.  These
  1788.     abstract parameters are to be mapped into the actual service
  1789.     parameters of the particular networks the datagram traverses.
  1790.  
  1791.     Precedence.  An independent measure of the importance of this
  1792.     datagram.
  1793.  
  1794.     Stream or Datagram.  Indicates if there will be other datagrams from
  1795.     this source to this destination at regular frequent intervals
  1796.     justifying the maintenance of stream processing information.
  1797.  
  1798.     Reliability.  A measure of the level of effort desired to ensure
  1799.     delivery of this datagram.
  1800.  
  1801.     Speed over Reliability.  Indicates the relative importance of speed
  1802.     and reliability when a conflict arises in meeting the pair of
  1803.     requests.
  1804.  
  1805.     Speed.  A measure of the importance of prompt delivery of this
  1806.     datagram.
  1807.  
  1808.     For example, the ARPANET has a priority bit, and a choice between
  1809.     "standard" messages (type 0) and "uncontrolled" messages (type 3),
  1810.     (the choice between single packet and multipacket messages can also
  1811.     be considered a service parameter). The uncontrolled messages tend
  1812.     to be less reliably delivered and suffer less delay.  Suppose an
  1813.     internet datagram is to be sent through the ARPANET.  Let the
  1814.     internet type of service be given as:
  1815.  
  1816.  
  1817.  
  1818.  
  1819.  
  1820.  
  1821.                                                                [Page 27]
  1822.  
  1823.  
  1824.                                                             January 1980
  1825. Internet Protocol
  1826. Specification
  1827.  
  1828.  
  1829.  
  1830.       Precedence:    5
  1831.       Stream:        0
  1832.       Reliability:   1
  1833.       S/R:           1
  1834.       Speed:         1
  1835.  
  1836.     The mapping of these parameters to those available for the ARPANET
  1837.     would be  to set the ARPANET priority bit on since the Internet
  1838.     priority is in the upper half of its range, to select uncontrolled
  1839.     messages since the speed and reliability requirements are equal and
  1840.     speed is preferred.
  1841.  
  1842.     The following chart presents the recommended mappings from the
  1843.     internet protocol type of service into the service parameters
  1844.     actually available on the ARPANET, the PRNET, and the SATNET:
  1845.  
  1846.       +------------+----------+----------+----------+----------+
  1847.       |Application | INTERNET | ARPANET  | PRNET    | SATNET   |
  1848.       +------------+----------+----------+----------+----------+
  1849.       |TELNET      |S/D:stream| T: 3     | R: ptp   | T: block |
  1850.       |  on        |  R:normal| S: S     | A: no    | D: min   |
  1851.       |   TCP      |S/R:speed |          |          | H: inf   |
  1852.       |            |  S:fast  |          |          | R: no    |
  1853.       +------------+----------+----------+----------+----------+
  1854.       |FTP         |S/D:stream| T: 0     | R: ptp   | T: block |
  1855.       |  on        |  R:normal| S: M     | A: no    | D: normal|
  1856.       |   TCP      |S/R:rlblt |          |          | H: inf   |
  1857.       |            |  S:normal|          |          | R: no    |
  1858.       +------------+----------+----------+----------+----------+
  1859.       |interactive |S/D:strm* | T: 3     | R: ptp   | T: stream|
  1860.       |narrow band |  R:least | S: S     | A: no    | D: min   |
  1861.       |  speech    |  P:speed |          |          | H: short |
  1862.       |            |  S:asap  |          |          | R: no    |
  1863.       +------------+----------+----------+----------+----------+
  1864.       |datagram    |S/D:dtgrm | T: 3 or 0| R:station| T: block |
  1865.       |            |  R:normal| S: S or M| A: no    | D: min   |
  1866.       |            |S/R:speed |          |          | H: short |
  1867.       |            |  S:fast  |          |          | R: no    |
  1868.       +------------+----------+----------+----------+----------+
  1869.        key:    S/D=strm/dtgrm   T=type     R=route  T=type
  1870.                R=reliability    S=size     A=ack    D=delay
  1871.                S/R=speed/rlblt                      H=holding time
  1872.                S=speed                              R=reliability
  1873.                *=requires stream set up
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880. [Page 28]                                                               
  1881.  
  1882.  
  1883. January 1980                                                            
  1884.                                                        Internet Protocol
  1885.                                                            Specification
  1886.  
  1887.  
  1888.  
  1889.   Time to Live
  1890.  
  1891.     The time to live is set by the sender to the maximum time the
  1892.     datagram is allowed to be in the internet system.  If the datagram
  1893.     is in the internet system longer than the time to live, then the
  1894.     datagram should be destroyed.  This field should be decreased at
  1895.     each point that the internet header is processed to reflect the time
  1896.     spent processing the datagram.  Even if no local information is
  1897.     available on the time actually spent, the field should be
  1898.     decremented by 1.  The time is measured in units of seconds (i.e.
  1899.     the value 1 means one second).  Thus, the maximum time to live is
  1900.     255 seconds or 4.25 minutes.
  1901.  
  1902.   Options
  1903.  
  1904.     The options are just that, optional.  That is, the presence or
  1905.     absence of an option is the choice of the sender, but each internet
  1906.     module must be able to parse every option.  There can be several
  1907.     options present in the option field.
  1908.  
  1909.     The options might not end on a 32-bit boundary.  The internet header
  1910.     should be filled out with octets of zeros.  The first of these would
  1911.     be interpreted as the end-of-options option, and the remainder as
  1912.     internet header padding.
  1913.  
  1914.     Every internet module must be able to act on the following options:
  1915.     End of Option List (0), No Operation (1), Source Route (3), Return
  1916.     Route (7), General Error Report (33), and Internet Timestamp (68).
  1917.     The Security Option (2) is required only if classified or
  1918.     compartmented traffic is to be passed.
  1919.  
  1920.   Checksum
  1921.  
  1922.     The internet header checksum is recomputed if the internet header is
  1923.     changed.  For example, a reduction of the time to live, additions or
  1924.     changes to internet options, or due to fragmentation.  This checksum
  1925.     at the internet level is intended to protect the internet header
  1926.     fields from transmission errors.
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.                                                                [Page 29]
  1940.  
  1941.  
  1942.                                                             January 1980
  1943. Internet Protocol
  1944. Specification
  1945.  
  1946.  
  1947.  
  1948. 3.3.  Examples & Scenarios
  1949.  
  1950.   Example 1:
  1951.  
  1952.     This is an example of the minimal data carrying internet datagram:
  1953.  
  1954.                                     
  1955.     0                   1                   2                   3   
  1956.     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 
  1957.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1958.    |Ver= 4 |IHL= 5 |Type of Service|        Total Length = 21      |
  1959.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1960.    |      Identification = 111     |Flg=0|   Fragment Offset = 0   |
  1961.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1962.    |   Time = 123  |  Protocol = 1 |        header checksum        |
  1963.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1964.    |                         source address                        |
  1965.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1966.    |                      destination address                      |
  1967.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1968.    |     data      |                                                
  1969.    +-+-+-+-+-+-+-+-+                                                
  1970.  
  1971.                        Example Internet Datagram
  1972.  
  1973.                                Figure 4.
  1974.  
  1975.     Note that each tick mark represents one bit position.
  1976.  
  1977.     This is a internet datagram in version 4 of internet protocol; the
  1978.     internet header consists of five 32 bit words, and the total length
  1979.     of the datagram is 21 octets.  This datagram is a complete datagram
  1980.     (not a fragment).
  1981.  
  1982.  
  1983.  
  1984.  
  1985.  
  1986.  
  1987.  
  1988.  
  1989.  
  1990.  
  1991.  
  1992.  
  1993.  
  1994.  
  1995.  
  1996.  
  1997.  
  1998. [Page 30]                                                               
  1999.  
  2000.  
  2001. January 1980                                                            
  2002.                                                        Internet Protocol
  2003.                                                            Specification
  2004.  
  2005.  
  2006.  
  2007.   Example 2:
  2008.  
  2009.     In this example, we show first a moderate size internet datagram
  2010.     (552 data octets), then two internet fragments that might result
  2011.     from the fragmentation of this datagram if the maximum sized
  2012.     transmission allowed were 280 octets.
  2013.  
  2014.                                     
  2015.     0                   1                   2                   3   
  2016.     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 
  2017.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2018.    |Ver= 4 |IHL= 5 |Type of Service|       Total Length = 472      |
  2019.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2020.    |     Identification = 111      |Flg=0|     Fragment Offset = 0 |
  2021.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2022.    |   Time = 123  | Protocol = 6  |        header checksum        |
  2023.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2024.    |                         source address                        |
  2025.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2026.    |                      destination address                      |
  2027.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2028.    |                             data                              |
  2029.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2030.    |                             data                              |
  2031.    \                                                               \
  2032.    \                                                               \
  2033.    |                             data                              |
  2034.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2035.    |             data              |                                
  2036.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                
  2037.  
  2038.                        Example Internet Datagram
  2039.  
  2040.                                Figure 5.
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.                                                                [Page 31]
  2058.  
  2059.  
  2060.                                                             January 1980
  2061. Internet Protocol
  2062. Specification
  2063.  
  2064.  
  2065.  
  2066.     Now the first fragment that results from splitting the datagram
  2067.     after 256 data octets.
  2068.  
  2069.                                     
  2070.     0                   1                   2                   3   
  2071.     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 
  2072.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2073.    |Ver= 4 |IHL= 5 |Type of Service|       Total Length = 276      |
  2074.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2075.    |     Identification = 111      |Flg=1|     Fragment Offset = 0 |
  2076.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2077.    |   Time = 119  | Protocol = 6  |        Header Checksum        |
  2078.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2079.    |                         source address                        |
  2080.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2081.    |                      destination address                      |
  2082.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2083.    |                             data                              |
  2084.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2085.    |                             data                              |
  2086.    \                                                               \
  2087.    \                                                               \
  2088.    |                             data                              |
  2089.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2090.    |                             data                              |
  2091.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2092.  
  2093.                        Example Internet Fragment
  2094.  
  2095.                                Figure 6.
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116. [Page 32]                                                               
  2117.  
  2118.  
  2119. January 1980                                                            
  2120.                                                        Internet Protocol
  2121.                                                            Specification
  2122.  
  2123.  
  2124.  
  2125.     And the second fragment.
  2126.  
  2127.                                     
  2128.     0                   1                   2                   3   
  2129.     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 
  2130.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2131.    |Ver= 4 |IHL= 5 |Type of Service|       Total Length = 216      |
  2132.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2133.    |     Identification = 111      |Flg=0|  Fragment Offset  =  32 |
  2134.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2135.    |   Time = 119  | Protocol = 6  |        Header Checksum        |
  2136.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2137.    |                         source address                        |
  2138.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2139.    |                      destination address                      |
  2140.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2141.    |                             data                              |
  2142.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2143.    |                             data                              |
  2144.    \                                                               \
  2145.    \                                                               \
  2146.    |                             data                              |
  2147.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2148.    |            data               |                                
  2149.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                
  2150.  
  2151.                        Example Internet Fragment
  2152.  
  2153.                                Figure 7.
  2154.  
  2155.  
  2156.  
  2157.  
  2158.  
  2159.  
  2160.  
  2161.  
  2162.  
  2163.  
  2164.  
  2165.  
  2166.  
  2167.  
  2168.  
  2169.  
  2170.  
  2171.  
  2172.  
  2173.  
  2174.  
  2175.                                                                [Page 33]
  2176.  
  2177.  
  2178.                                                             January 1980
  2179. Internet Protocol
  2180. Specification
  2181.  
  2182.  
  2183.  
  2184.   Example 3:
  2185.  
  2186.     Here, we show an example of a datagram containing options:
  2187.  
  2188.                                     
  2189.     0                   1                   2                   3   
  2190.     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 
  2191.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2192.    |Ver= 4 |IHL= 8 |Type of Service|       Total Length = 576      |
  2193.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2194.    |       Identification = 111    |Flg=0|     Fragment Offset = 0 |
  2195.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2196.    |   Time = 123  |  Protocol = 6 |       Header Checksum         |
  2197.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2198.    |                        source address                         |
  2199.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2200.    |                      destination address                      |
  2201.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2202.    | Opt. Code = x | Opt.  Len.= 3 | option value  | Opt. Code = x |
  2203.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2204.    | Opt. Len. = 4 |           option value        | Opt. Code = 1 |
  2205.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2206.    | Opt. Code = y | Opt. Len. = 3 |  option value | Opt. Code = 0 |
  2207.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2208.    |                             data                              |
  2209.    \                                                               \
  2210.    \                                                               \
  2211.    |                             data                              |
  2212.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2213.    |                             data                              |
  2214.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2215.  
  2216.                        Example Internet Datagram
  2217.  
  2218.                                Figure 8.
  2219.  
  2220. 3.4.  Interfaces
  2221.  
  2222.   Internet protocol interfaces on one side to the local network and on
  2223.   the other side to either a higher level protocol or an application
  2224.   program.  In the following, the higher level protocol or application
  2225.   program (or even a gateway program) will be called the "user" since it
  2226.   is using the internet module.  Since internet protocol is a datagram
  2227.   protocol, there is minimal memory or state maintained between datagram
  2228.   transmissions, and each call on the internet protocol module by the
  2229.   user supplies all the necessary information.
  2230.  
  2231.  
  2232.  
  2233.  
  2234. [Page 34]                                                               
  2235.  
  2236.  
  2237. January 1980                                                            
  2238.                                                        Internet Protocol
  2239.                                                            Specification
  2240.  
  2241.  
  2242.  
  2243.   For example, the following two calls satisfy the requirements for the
  2244.   user to internet protocol module communication ("=>" means returns):
  2245.  
  2246.     SEND (dest, TOS, TTL, BufPTR, len, Id, DF, options => result)
  2247.  
  2248.       where:
  2249.  
  2250.         dest = destination address
  2251.         TOS = type of service
  2252.         TTL = time to live
  2253.         BufPTR = buffer pointer
  2254.         len = length of buffer
  2255.         Id  = Identifier
  2256.         DF = Don't Fragment
  2257.         options = option data
  2258.         result = response
  2259.           OK = datagram sent ok
  2260.           Error = error in arguments or local network error
  2261.  
  2262.     RECV (BufPTR => result, source, dest, prot, TOS, len)
  2263.  
  2264.       where:
  2265.  
  2266.         BufPTR = buffer pointer
  2267.         result = response
  2268.           OK = datagram received ok
  2269.           Error = error in arguments
  2270.         source = source address
  2271.         dest = destination address
  2272.         prot = protocol
  2273.         TOS = type of service
  2274.         len = length of buffer
  2275.  
  2276.   When the user sends a datagram, it executes the SEND call supplying
  2277.   all the arguments.  The internet protocol module, on receiving this
  2278.   call, checks the arguments and prepares and sends the message.  If the
  2279.   arguments are good and the datagram is accepted by the local network,
  2280.   the call returns successfully.  If either the arguments are bad, or
  2281.   the datagram is not accepted by the local network, the call returns
  2282.   unsuccessfully.  On unsuccessful returns, a reasonable report should
  2283.   be made as to the cause of the problem, but the details of such
  2284.   reports are up to individual implementations.
  2285.  
  2286.   When a datagram arrives at the internet protocol module from the local
  2287.   network, either there is a pending RECV call from the user addressed
  2288.   or there is not.  In the first case, the pending call is satisfied by
  2289.   passing the information from the datagram to the user.  In the second
  2290.   case, the user addressed is notified of a pending datagram.  If the
  2291.  
  2292.  
  2293.                                                                [Page 35]
  2294.  
  2295.  
  2296.                                                             January 1980
  2297. Internet Protocol
  2298. Specification
  2299.  
  2300.  
  2301.  
  2302.   user addressed does not exist, an error datagram is returned to the
  2303.   sender, and the data is discarded.
  2304.  
  2305.   The notification of a user may be via a pseudo interrupt or similar
  2306.   mechanism, as appropriate in the particular operating system
  2307.   environment of the implementation.
  2308.  
  2309.   A user's RECV call may then either be immediately satisfied by a
  2310.   pending datagram, or the call may be pending until a datagram arrives.
  2311.  
  2312.   An implementation may also allow or require a call to the internet
  2313.   module to indicate interest in or reserve exclusive use of a class of
  2314.   datagrams (e.g., all those with a certain value in the protocol
  2315.   field).
  2316.  
  2317.   
  2318.  
  2319.  
  2320.  
  2321.  
  2322.  
  2323.  
  2324.  
  2325.  
  2326.  
  2327.  
  2328.  
  2329.  
  2330.  
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343.  
  2344.  
  2345.  
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.  
  2352. [Page 36]                                                               
  2353.  
  2354.  
  2355. January 1980                                                            
  2356.                                                        Internet Protocol
  2357.  
  2358.  
  2359.  
  2360.                                 GLOSSARY
  2361.  
  2362.  
  2363.  
  2364. 1822
  2365.           BBN Report 1822, "The Specification of the Interconnection of
  2366.           a Host and an IMP".  The specification of interface between a
  2367.           host and the ARPANET.
  2368.  
  2369. ARPANET message
  2370.           The unit of transmission between a host and an IMP in the
  2371.           ARPANET.  The maximum size is about 1012 octets (8096 bits).
  2372.  
  2373. ARPANET packet
  2374.           A unit of transmission used internally in the ARPANET between
  2375.           IMPs. The maximum size is about 126 octets (1008 bits).
  2376.  
  2377. Destination
  2378.           The destination address, an internet header field.
  2379.  
  2380. DF
  2381.           The Don't Fragment bit carried in the flags field.
  2382.  
  2383. Flags
  2384.           An internet header field carrying various control flags.
  2385.  
  2386. Fragment Offset
  2387.           This internet header field indicates where in the internet
  2388.           datagram a fragment belongs.
  2389.  
  2390. header
  2391.           Control information at the beginning of a message, segment,
  2392.           datagram, packet or block of data.
  2393.  
  2394. Identification
  2395.           An internet header field carrying the identifying value
  2396.           assigned by the sender to aid in assembling the fragments of a
  2397.           datagram.
  2398.  
  2399. IHL
  2400.           The internet header field Internet Header Length is the length
  2401.           of the internet header measured in 32 bit words.
  2402.  
  2403. IMP
  2404.           The Interface Message Processor, the packet switch of the
  2405.           ARPANET.
  2406.  
  2407.  
  2408.  
  2409.  
  2410.  
  2411.                                                                [Page 37]
  2412.  
  2413.  
  2414.                                                             January 1980
  2415. Internet Protocol
  2416. Glossary
  2417.  
  2418.  
  2419.  
  2420. Internet Address
  2421.           A four octet (32 bit) source or destination address consisting
  2422.           of a Network field and a Local Address field.
  2423.  
  2424. internet fragment
  2425.           A portion of the data of an internet datagram with an internet
  2426.           header.
  2427.  
  2428. internet datagram
  2429.           The unit of data exchanged between a pair of internet modules
  2430.           (includes the internet header).
  2431.  
  2432. ARPANET leader
  2433.           The control information on an ARPANET message at the host-IMP
  2434.           interface.
  2435.  
  2436. Local Address
  2437.           The address of a host within a network.  The actual mapping of
  2438.           an internet local address on to the host addresses in a
  2439.           network is quite general, allowing for many to one mappings.
  2440.  
  2441. MF
  2442.           The More-Fragments Flag carried in the internet header flags
  2443.           field.
  2444.  
  2445. module
  2446.           An implementation, usually in software, of a protocol or other
  2447.           procedure.
  2448.  
  2449. more-fragments flag
  2450.           A flag indicating whether or not this internet datagram
  2451.           contains the end of an internet datagram, carried in the
  2452.           internet header Flags field.
  2453.  
  2454. NFB
  2455.           The Number of Fragment Blocks in a the data portion of an
  2456.           internet fragment.  That is, the length of a portion of data
  2457.           measured in 8 octet units.
  2458.  
  2459. octet
  2460.           An eight bit byte.
  2461.  
  2462. Options
  2463.           The internet header Options field may contain several options,
  2464.           and each option may be several octets in length.  The options
  2465.           are used primarily in testing situations, for example to carry
  2466.           timestamps.
  2467.  
  2468.  
  2469.  
  2470. [Page 38]                                                               
  2471.  
  2472.  
  2473. January 1980                                                            
  2474.                                                        Internet Protocol
  2475.                                                                 Glossary
  2476.  
  2477.  
  2478.  
  2479. Padding
  2480.           The internet header Padding field is used to ensure that the
  2481.           data begins on 32 bit word boundary.  The padding is zero.
  2482.  
  2483. Protocol
  2484.           In this document, the next higher level protocol identifier,
  2485.           an internet header field.
  2486.  
  2487. Rest
  2488.           The 3 octet (24 bit) local address portion of an Internet
  2489.           Address.
  2490.  
  2491. RTP
  2492.           Real Time Protocol:  A host-to-host protocol for communication
  2493.           of time critical information.
  2494.  
  2495. Source
  2496.           The source address, an internet header field.
  2497.  
  2498. TCP
  2499.           Transmission Control Protocol:  A host-to-host protocol for
  2500.           reliable communication in internet environments.
  2501.  
  2502. TCP Segment
  2503.           The unit of data exchanged between TCP modules (including the
  2504.           TCP header).
  2505.  
  2506. Total Length
  2507.           The internet header field Total Length is the length of the
  2508.           datagram in octets including internet header and data.
  2509.  
  2510. Type of Service
  2511.           An internet header field which indicates the type (or quality)
  2512.           of service for this internet datagram.
  2513.  
  2514. User
  2515.           The user of the internet protocol.  This may be a higher level
  2516.           protocol module, an application program, or a gateway program.
  2517.  
  2518. Version
  2519.           The Version field indicates the format of the internet header.
  2520.  
  2521.  
  2522.  
  2523.  
  2524.  
  2525.  
  2526.  
  2527.  
  2528.  
  2529.                                                                [Page 39]
  2530.  
  2531.  
  2532.                                                             January 1980
  2533. Internet Protocol
  2534.  
  2535.  
  2536.  
  2537.  
  2538.  
  2539.  
  2540.  
  2541.  
  2542.  
  2543.  
  2544.  
  2545.  
  2546.  
  2547.  
  2548.  
  2549.  
  2550.  
  2551.  
  2552.  
  2553.  
  2554.  
  2555.  
  2556.  
  2557.  
  2558.  
  2559.  
  2560.  
  2561.  
  2562.  
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578.  
  2579.  
  2580.  
  2581.  
  2582.  
  2583.  
  2584.  
  2585.  
  2586.  
  2587.  
  2588. [Page 40]                                                               
  2589.  
  2590.  
  2591. January 1980                                                            
  2592.                                                        Internet Protocol
  2593.  
  2594.  
  2595.  
  2596.                                REFERENCES
  2597.  
  2598.  
  2599.  
  2600. [1]  Cerf, V., "The Catenet Model for Internetworking," Information
  2601.      Processing Techniques Office, Defense Advanced Research Projects
  2602.      Agency, IEN 48, July 1978.
  2603.  
  2604. [2]  Bolt Beranek and Newman, "Specification for the Interconnection of
  2605.      a Host and an IMP," BBN Technical Report 1822, May 1978 (Revised).
  2606.  
  2607. [3]  Shoch, J., "Inter-Network Naming, Addressing, and Routing,"
  2608.      COMPCON, IEEE Computer Society, Fall 1978.
  2609.  
  2610. [4]  Postel, J., "Address Mappings," IEN 115, USC/Information Sciences
  2611.      Institute, August 1979.
  2612.  
  2613. [5]  Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
  2614.      Computer Networks, v. 3, n. 1, February 1979.
  2615.  
  2616. [6]  Postel, J., "Assigned Numbers," RFC 762, IEN 127, USC/Information
  2617.      Sciences Institute, January 1980.
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.  
  2645.  
  2646.  
  2647.                                                                [Page 41]
  2648.  
  2649.  
  2650.                                                             January 1980
  2651. Internet Protocol
  2652.  
  2653.  
  2654.  
  2655.  
  2656.  
  2657.  
  2658.  
  2659.  
  2660.  
  2661.  
  2662.  
  2663.  
  2664.  
  2665.  
  2666.  
  2667.  
  2668.  
  2669.  
  2670.  
  2671.  
  2672.  
  2673.  
  2674.  
  2675.  
  2676.  
  2677.  
  2678.  
  2679.  
  2680.  
  2681.  
  2682.  
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688.  
  2689.  
  2690.  
  2691.  
  2692.  
  2693.  
  2694.  
  2695.  
  2696.  
  2697.  
  2698.  
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706. [Page 42]                                                               
  2707.  
  2708.