rfc963.txt

RFC 相关的技术文档

                                     (number of bytes of option data)/4;

      In order to allow for padding, this statement should read

         to_SNP.dtgm.header_length :=
                             5 + ((number of bytes of option data)+3)/4;

      The identical statement appears in the action procedure
      fragment_and_send [MILS83a, sec 9.4.6.3.7], which prepares
      datagram fragments for transmission, and requires the same
      correction.




Sidhu                                                          [Page 13]



RFC 963                                                    November 1985
Some Problems with MIL-STD IP


      The procedure fragment_and_send also has this problem in two other
      places.  In the first, the number of octets in each fragment is
      computed by

         data_per_fragment := maximum subnet transmission unit
                                - (20 + number of bytes of option data);

      In order to allow for padding, this statement should read

         data_per_fragment := maximum subnet transmission unit
                      - (((20 + number of bytes of option data)+3)/4*4);

      (Actually, this statement must be changed to

         data_per_fragment := (maximum subnet transmission unit
                  - (((20 + number of bytes of option data)+3)/4*4)/8*8;

      in order to accomplish its intended purpose, for reasons which
      have been discussed above.)

      A similar problem occurs in the statement which computes the
      header length for individual fragments:

         to_SNP.dtgm.header_length := 5 +
                                      (number of copy options octets/4);

      To allow for padding, this should be changed to

         to_SNP.dtgm.header_length := 5 +
                                    (number of copy options octets+3/4);

      Notice that all of these errors can also be corrected if the
      English phrase "number of bytes of option data", and similar
      phrases, are always understood to include any necessary padding.

   5.2  Subnetworks with Small Transmission Sizes

      When an outgoing datagram is too large to be transmitted as a
      single packet, it must be fragmented.  On certain subnetworks, the
      possibility exists that the maximum number of bytes that may be
      transmitted at a time is less than the size of an IP packet header
      for a given datagram.  In this case, the datagram cannot be sent,
      even in fragmented form.  Note that this does not necessarily mean
      that the subnetwork cannot send any datagrams at all, since the
      size of the header may be highly variable.  When this problem
      arises, it should be detected by IP.  The proper place to detect
      this situation is in the function can_frag.


Sidhu                                                          [Page 14]



RFC 963                                                    November 1985
Some Problems with MIL-STD IP


      The can_frag decision function [MILS83a, sec 9.4.6.2.2] is used to
      determine whether a particular outgoing datagram, which is too
      long to be transmitted as a single fragment, is allowed to be
      fragmented. In the current specification, this function consists
      of the single statement

         if (from_ULP.dont_fragment = TRUE)
         then return NO
         else return YES
         end if;

      (A minor syntax error is that the return statements should be
      terminated by semicolons; see [ADA83, sec 5.1, sec 5.3, sec 5.9].)

      If the above problem occurs, the procedure fragment_and_send will
      obtain negative numbers for fragment sizes, with unpredictable
      results.  This should be prevented by assuring that the subnetwork
      can send the datagram header and at least one block (eight octets)
      of data.  The can_frag function should be recoded as

         if ((8 + ((number of bytes of option data)+3)/4*4 + 20)
                    > maximum transmission unit of the local subnetwork)
         then return NO;
         elsif (from_ULP.dont_fragment = TRUE)
         then return NO
         else return YES
         end if;

      This is similar to the logic of the function need_to_frag,
      discussed above.

   5.3  Subnetwork Interface

      Provision is made for the subnetwork to report errors to IP
      [MILS83a, sec 6.3.6.2], but no provision is made for the IP entity
      to take any action when such errors occur.

      In addition, the specification [MILS83a, sec 8.2.1.1] calls for
      the subnetwork to accept type-of-service indicators (precedence,
      reliability, delay, and throughput), which may be difficult to
      implement on many local networks.








Sidhu                                                          [Page 15]



RFC 963                                                    November 1985
Some Problems with MIL-STD IP


   5.4  ULP Errors

      The IP specification [MILS83a, sec 9.4.6.3.6] states

         The format of error reports to a ULP is implementation
         dependent. However, included in the report should be a value
         indicating the type of error, and some information to identify
         the associated data or datagram.

      The most natural way to provide the latter information would be to
      return the datagram identifier to the upper-level protocol, since
      this identifier is normally supplied by the sending ULP [MILS83a,
      sec 9.3.5].  However, the to_ULP data structure makes no provision
      for this information [MILS83a, sec 9.4.4.3], probably because this
      information is irrelevant for datagrams received from the
      subnetwork. Implementors may feel a need to add this field to the
      to_ULP data structure.

   5.5  Initialization of Data Structures

      The decision function reass_done [MILS83a, sec 9.4.6.2.6] makes
      the implicit assumption that data structures within each finite
      state machine are initialized to zero when the machine is created.
      In particular, this routine will not function properly unless
      state_vector.reassembly_map and state_vector.total_data_length are
      so initialized.  Since this assumption is not stated explicitly,
      implementors should be aware of it.  There may be other
      initialization assumptions that we have not discovered.

   5.6  Locally Defined Types

      The procedures error_to_source [MILS83a, sec 9.4.6.3.5] and
      error_to_ULP [MILS83a, sec 9.4.6.3.6] define enumeration types in
      comments.  The former contains the comment

         error_param : (PARAM_PROBLEM, EXPIRED_TTL, PROTOCOL_UNREACH);

      and the latter

         error_param : (PARAM_PROBLEM, CAN'T_FRAGMENT, NET_UNREACH,
                                        PROTOCOL_UNREACH, PORT_UNREACH);

      These enumerated values are used before they are encountered
      [MILS83a, sec 9.4.6.1.1, sec 9.4.6.1.2, sec 9.4.6.1.3, et al.];
      implementors will probably wish to define some error type
      globally.



Sidhu                                                          [Page 16]



RFC 963                                                    November 1985
Some Problems with MIL-STD IP


   5.7  Miscellaneous Difficulties

      The specification contains many Ada syntax errors, some of which
      have been shown above.  We have only mentioned syntax errors
      above, however, when they occurred in conjunction with other
      problems.  One of the main syntactic difficulties that we have not
      mentioned is that the specification frequently creates unnamed
      types, by declaring records within records; such declarations are
      legal in Pascal, but not in Ada [ADA83, sec 3.7].

      Another problem is that slice assignments frequently do not
      contain the same number of elements on the left and right sides,
      which will raise a run-time exception [ADA83, sec 5.2.1].  While
      we have mentioned some of these, there are others which are not
      enumerated above.

      In particular, the procedure error_to_source [MILS83a, sec
      9.4.6.3.5] contains the statement

         to_SNP.dtgm.data [8..N+3] := from_SNP.dtgm.data [0..N-1];

      We believe that N+3 is a misprint for N+8, but even so the left
      side contains one more byte than the right.  Implementors should
      carefully check every slice assignment.

6.  An Implementation of MIL Standard IP

   In our discussion above, we have pointed out several serious problems
   with the Military Standard IP [MILS83a] specification which must be
   corrected to produce a running implementation conforming to this
   standard.  We have produced a running C implementation for the MIL
   Standard IP, after problems discussed above were fixed in the IP
   specification.  An important feature of this implementation is that
   it was generated semi-automatically from the IP specification with
   the help of a protocol development system [BLUT82] [BLUT83] [SIDD83].
   Since this implementation was derived directly from the IP
   specification with the help of tools, it conforms to the IP standard
   better that any handed-coded IP implementation can do.

   The problems pointed out in this paper with the current specification
   of the MIL Standard IP [MILS83a] are based on an initial
   investigation of the protocol.







Sidhu                                                          [Page 17]



RFC 963                                                    November 1985
Some Problems with MIL-STD IP


NOTES

   [1] Ada is a registered trademark of the U.S. Government - Ada Joint
   Program Office.

   [2] d indicates a "don't care" condition.

ACKNOWLEDGEMENTS

   The author extends his gratitude to Tom Blumer Michael Breslin, Bob
   Pollack and Mark J. Vincenzes, for many helpful discussions.  Thanks
   are also due to B. Simon and M. Bernstein for bringing to author's
   attention a specification of the DoD Internet Protocol during 1981-82
   when a detailed study of this protocol began.  The author is also
   grateful to Jon Postel and Carl Sunshine for several informative
   discussions about DoD IP/TCP during the last few years.

REFERENCES

   [ADA83]   Military Standard Ada(R) Programming Language, United
             States Department of Defense, ANSI/MIL-STD-1815A-1983, 22
             January 1983

   [BLUT83]  Blumer, T. P., and Sidhu, D. P., "Mechanical Verification
             and Automatic Implementation of Communication Protocols,"
             to appear in IEEE Trans. Softw. Eng.

   [BLUT82]  Blumer, T. P., and Tenney, R. L., "A Formal Specification
             Technique and Implementation Method for Protocols,"
             Computer Networks, Vol. 6, No. 3, July 1982, pp. 201-217.

   [MILS83a] "Military Standard Internet Protocol," United States
             Department of Defense, MIL-STD-1777, 12 August 1983.

   [MILS83b] "Military Standard Transmission Control Protocol," United
             States Department of Defense, MIL-STD-1778, 12 August 1983.

   [POSJ81]  Postel, J. (ed.), "DoD Standard Internet Protocol," Defense
             Advanced Research Projects Agency, Information Processing
             Techniques Office, RFC-791, September 1981.

   [SDC82]   DCEC Protocol Standardization Program: Protocol
             Specification Report, System Development Corporation,
             TM-7172/301/00, 29 March 1982

   [SIDD83]  Sidhu, D. P., and Blumer, T. P., "Verification of NBS Class
             4 Transport Protocol," to appear in IEEE Trans. Comm.


Sidhu                                                          [Page 18]



RFC 963                                                    November 1985
Some Problems with MIL-STD IP


   [SIDD84]  Sidhu, D. P., and Blumer, T. P., "Some Problems with the
             Specification of the Military Standard Transmission Control
             Protocol," in Protocol Specification, Testing and
             Verification IV, (ed.) Y. Yemini et al (1984).













































Sidhu                                                          [Page 19]