As per Relevance of the word statement, we have this rfc below:
Network Working Group Deepinder P.
Request for Comments: 963 Iowa State
November 1985
SOME PROBLEMS WITH THE SPECIFICATION OF
MILITARY STANDARD INTERNET
STATUS OF THIS
The purpose of this RFC is to provide helpful information on
Military Standard Internet Protocol (MIL-STD-1777) so that one
obtain a reliable implementation of this protocol standard
Distribution of this note is unlimited
This paper points out several significant problems in
specification of the Military Standard Internet
(MIL-STD-1777, dated August 1983 [MILS83a]). These results are
on an initial investigation of this protocol standard. The
are: (1) a failure to reassemble fragmented messages completely; (2)
a missing state transition; (3) errors in testing for
completion; (4) errors in computing fragment sizes; (5) minor
in message reassembly; (6) incorrectly computed length for
datagrams. This note also proposes solutions to these problems
1.
In recent years, much progress has been made in creating
integrated set of tools for developing reliable
protocols. These tools provide assistance in the specification
verification, implementation and testing of protocols.
protocols have been analyzed and developed using such tools
Examples of automated verification and implementation of several
world protocols are discussed in [BLUT82] [BLUT83] [SIDD83] [SIDD84].
We are currently working on the automatic implementation of
Military Standard Internet Protocol (IP). This analysis will
based on the published specification [MILS83a] of IP dated 12
1983.
While studying the MIL Standard IP specification, we have
numerous errors in the specification of this protocol.
consequence of these errors is that the protocol will never
fragmented incoming datagrams; if this error is corrected,
datagrams will be missing some data and their lengths will
incorrectly reported. In addition, outgoing datagrams that
divided into fragments will be missing some data. The proof of
statements follows from the specification of IP [MILS83a]
discussed below
Sidhu [Page 1]
RFC 963 November 1985
Some Problems with MIL-STD
2. Internet
The Internet Protocol (IP) is a network layer protocol in the
protocol hierarchy which provides communication across
packet-switched networks in an internetwork environment. IP
a pure datagram service with no mechanism for reliability,
control, sequencing, etc. Instead, these features are provided by
connection-oriented protocol, DoD Transmission Control Protocol (TCP
[MILS83b], which is implemented in the layer above IP. TCP
designed to operate successfully over channels that are
unreliable, i.e., which can lose, damage, duplicate, and
packets
Over the years, DARPA has supported specifications of
versions of IP; the last one appeared in [POSJ81]. A few years ago
the Defense Communications Agency decided to standardize IP for
in DoD networks. For this purpose, the DCA supported
specification of this protocol, following the design discussed
[POSJ81] and the technique and organization defined in [SDC82].
detailed specification of this protocol, given in [MILS83a], has
adopted as the DoD standard for the Internet Protocol
The specification of IP state transitions is organized into
tables; the decision functions and action procedures are specified
a subset of Ada[1], and may employ a set of machine-specific
structures. Decision tables are supplied for the pairs
interface event> as follows: <inactive, send from upper layer>,
<inactive, receive from lower layer>, and
lower layer>. To provide an error indication in the case that
fragments of a datagram are received but some are missing, a
table is also supplied for the pair reassembly
limit elapsed>. (The event names are English descriptions and
the names employed by [MILS83a].)
3. Problems with MIL Standard
One of the major functions of IP is the fragmentation of
that cannot be transmitted over a subnetwork in one piece, and
subsequent reassembly. The specification has several problems
this area. One of the most significant is the failure to insert
last fragment of an incoming datagram; this would cause datagrams
be delivered to the upper-level protocol (ULP) with some
missing. Another error in this area is that an incorrect value of
data length for reassembled datagrams is passed to the ULP,
unpredictable consequences
As the specification [MILS83a] is now written, these errors are
Sidhu [Page 2]
RFC 963 November 1985
Some Problems with MIL-STD
little consequence, since the test for reassembly completion
always fail, with the result that reassembled datagrams would
be delivered at all
In addition, a missing row in one of the decision tables creates
problem that network control (ICMP) messages that arrive in
will never be processed. Among the other errors are the
that a few bytes will be discarded from each fragment transmitted
certain statements that will create run-time exceptions instead
performing their intended functions
A general problem with this specification is that the
language and action table portions of the specification were
not checked by any automatic syntax checking process. Variable
procedure names are occasionally misspelled, and the syntax of
action statements is often incorrect. We have enumerated some
these problems below as a set of cautionary notes to implementors
but we do not claim to have listed them all. In particular,
errors are only discussed when they occur in conjunction with
problems
The following section discusses some of the serious errors that
have discovered with the MIL standard IP [MIL83a] during our
study of this protocol. We also propose corrections to each of
problems
4. Detailed Discussion of the
Problem 1: Failure to Insert Last
This problem occurs in the decision table corresponding to
state reassembling and the input "receive from lower layer
[MILS83a, sec 9.4.6.1.3]. The problem occurs in the following
of this table:[2]
________________________________________________________
check- SNP TTL where a reass
sum params valid to frag done check
valid? valid? ? ? ? ? sum
__________________________________________________________________
YES YES YES ULP YES YES d reass
delivery
state :=
__________________________________________________________________
The reass_done function, as will be seen below, returns YES if
Sidhu [Page 3]
RFC 963 November 1985
Some Problems with MIL-STD
fragment just received is the last fragment needed to assemble
complete datagram and NO otherwise. The action
reass_delivery simply delivers a completely reassembled
to the upper-level protocol. It is the action
reassemble that inserts an incoming fragment into the
being assembled. Since this row does not call reassemble,
result will be that every incoming fragmented datagram will
delivered to the upper layer with one fragment missing.
solution is to rewrite this row of the table as follows
________________________________________________________
check- SNP TTL where a reass
sum params valid to frag done check
valid? valid? ? ? ? ? sum
__________________________________________________________________
YES YES YES ULP YES YES d reassemble
reass
delivery
state :=
__________________________________________________________________
Incidentally, the mnemonic value of the name of the reass_
function is questionable, since at the moment this function
called datagram reassembly cannot possibly have been completed.
better name for this function might be last_fragment
Problem 2: Missing State
This problem is the omission of a row of the same decision
[MILS83a, sec 9.4.6.1.3]. Incoming packets may be directed to
upper-level protocol (ULP), or they may be network
messages, which are marked ICMP (Internet Control
Protocol). When control messages have been completely assembled
they are processed by an IP procedure called analyze.
decision table contains the
________________________________________________________
check- SNP TTL where a reass
sum params valid to frag done check
valid? valid? ? ? ? ? sum
__________________________________________________________________
YES YES YES ICMP YES NO d reassemble
__________________________________________________________________
Sidhu [Page 4]
RFC 963 November 1985
Some Problems with MIL-STD
but makes no provision for the case in which where_to
ICMP, a_frag returns YES, and reass_done returns YES.
additional row should be inserted, which reads as follows
________________________________________________________
check- SNP TTL where a reass
sum params valid to frag done check
valid? valid? ? ? ? ? sum
__________________________________________________________________
YES YES YES ICMP YES YES d reassemble
analyze
state :=
__________________________________________________________________
Omitting this row means that incoming fragmented ICMP
will never be analyzed, since the state machine does not have
action specified when the last fragment is received
Problem 3: Errors in reass_
The function reass_done, as can be seen from the above,
whether the incoming subnetwork packet contains the last
needed to complete the reassembly of an IP datagram. In order
understand the errors in this function, we must first
how it employs its data structures
The reassembly of incoming fragments is accomplished by means of
bit map maintained separately for each state machine. Since
fragments are not necessarily the same length, each bit in the
represents not a fragment, but a block, that is, a unit of
octets. Each fragment, with the possible exception of the "tail
fragment (we shall define this term below), is an integral
of consecutive blocks. Each fragment's offset from the
of the datagram is given, in units of blocks, by a field in
packet header of each incoming packet. The total length of
fragment, including the fragment's header, is specified in
header field total_length; this length is given in octets.
length of the header is specified in the field header_length;
length is given in words, that is, units of four octets
In analyzing this subroutine, we must distinguish between
"tail" fragment and the "last" fragment. We define the
fragment as the one which is received last in time, that is,
fragment that permits reassembly to be completed. The
fragment is the fragment that is spatially last, that is,
fragment that is spatially located after any other fragment.
Sidhu [Page 5]
RFC 963 November 1985
Some Problems with MIL-STD
length and offset of the tail fragment make it possible to
the length of the entire datagram. This computation is
done in the action procedure reassembly, and the result is
in the state vector field total_data_length; if the tail
has not been received, this value is assumed to be zero
It is the task of the reass_done function [MILS83a, sec 9.4.6.2.6]
to determine whether the incoming fragment is the last fragment
This determination is made as follows
1) If the tail fragment has not been received previously
the incoming fragment is not the tail fragment, then return NO
2) Otherwise, if the tail fragment has not been received,
the incoming fragment is the tail fragment, determine
all fragments spatially preceding the tail fragment have
been received
3) Otherwise, if the tail fragment has been received earlier
determine whether the incoming fragment is the last one
to complete reassembly
The evaluation of case (2) is accomplished by the
statment
if (state_vector.reassembly_map from 0
(((from_SNP.dtgm.total_length -
(from_SNP.dtgm.header_length * 4) + 7) / 8)
+ 7) / 8 is set
then return YES
The double occurrence of the subexpression " + 7 ) / 8"
apparently a misprint. The function f(x) = (x + 7) / 8
convert x from octets to blocks, rounding any remainder upward
There is no need for this function to be performed twice.
second problem is that the fragment_offset field of the
packet is ignored. The tail fragment specifies only its
length, not the length of the entire datagram; to determine
latter, the tail fragment's offset must be added to the
fragment's own length. The third problem hinges on the meaning
the English "... from ... to ..." phrase. If this phrase has
same meaning as the ".." range indication in Ada [ADA83, sec 3.6],
that is, includes both the upper and lower bounds, then it
necessary to subtract 1 from the final expression
The expression following the word to, above, should thus
changed to
Sidhu [Page 6]
RFC 963 November 1985
Some Problems with MIL-STD
from_SNP.dtgm.fragment_offset +
((from_SNP.dtgm.total_length -
(from_SNP.dtgm.header_length * 4) + 7) / 8) - 1
Another serious problem with this routine occurs when
case (3). In this case, the relevant statement
if (all reassembly map from 0
(state_vector.total_data_length + 7)/8 is
then return
If the tail fragment was received earlier, the code asks,
effect, whether all the bits in the reassembly map have been set
This, however, will not be the case even if the incoming
is the last fragment, since the routine reassembly, which
sets these bits, has not yet been called for this fragment.
statement must therefore skip the bits corresponding to
incoming fragment. In specifying the range to be tested
allowance must be made for whether these bits fall at
beginning of the bit map or in the middle (the case where
fall at the end has already been tested). The statement
therefore be changed to
if from_SNP.dtgm.fragment_offset = 0
if (all reassembly map
from_SNP.dtgm.fragment_offset +
((from_SNP.dtgm.total_length -
from_SNP.dtgm.header_length * 4) + 7) / 8
to ((state_vector.total_data_length + 7) / 8 - 1) is set
then return YES
else return NO
end if
if (all reassembly map from 0
(from_SNP.dtgm.fragment_offset - 1) is set
and (all reassembly map
from_SNP.dtgm.fragment_offset +
((from_SNP.dtgm.total_length -
from_SNP.dtgm.header_length * 4) + 7) / 8
to ((state_vector.total_data_length + 7) / 8 - 1) is set
then return YES
else return NO
end if
end if
Sidhu [Page 7]
RFC 963 November 1985
Some Problems with MIL-STD
Note that here again it is necessary to subtract 1 from the
bound
Problem 4: Errors in fragment_and_
The action procedure fragment_and_send [MILS83a, sec 9.4.6.3.7]
used to break up datagrams that are too large to be sent
the subnetwork as a single packet. The specification
[MILS83a sec 9.2.2, sec 9.4.6.3.7] each fragment, except
the "tail" fragment, to contain a whole number of 8-octet
(called "blocks"); moreover, each fragment must begin at a
boundary
In the algorithm set forth in fragment_and_send, all
except the tail fragment are set to the same size; the
begins by calculating this size. This is done by the
statement
data_per_fragment := maximum subnet transmission
- (20 + number of bytes of option data);
Besides the failure to allow for header padding, which
discussed in the next section, this statement makes the
error of not assuring that the result is an integral multiple
the block size, i.e., a multiple of eight octets. The
of this would be that as many as seven octets per fragment
never be sent at all. To correct this problem, and to allow
header padding, this statement must be changed
data_per_fragment := (maximum subnet transmission
- (((20 + number of bytes of option data)+3)/4*4)/8*8;
Another problem in this procedure is the failure to provide
the case in which the length of the data is an exact multiple
eight. The procedure contains the
number_of fragments := (from_ULP.length +
(data_per_fragment - 1)) / data_per_fragment
data_in_last_frag := from_ULP.length modulo data_per_fragment
(Note that in our terminology we would rename data_in_last_frag
data_in_tail_frag; notice, also, that the proper spelling of
Ada operator is mod [ADA83, sec 4.5.5].)
If data_in_last_frag is zero, some serious difficulties arise
One result might be that the datagram will be broken into one
Sidhu [Page 8]
RFC 963 November 1985
Some Problems with MIL-STD
fragment than necessary, with the tail fragment containing no
bytes. The assignment of data into the tail fragment will
even though it will now take the
output_data [i..i-1] := input_data [j..j-1];
because Ada makes provision for so-called "null slices" [ADA83,
sec 4.1.2] and will treat this assignment as a no-op [ADA83,
5.2.1].
This does, however, cause the transmission of an
packet, and also creates difficulties for the
procedure, which must now be prepared to handle empty packets,
which not even one bit of the reassembly map should be set
Moreover, as the procedure is now written, even this will
occur. This is because the calculation of the number of
is incorrect
A numerical example will clarify this point. Suppose that
total datagram length is 16 bytes and that the number of bytes
fragment is to be 8. Then the above statements will
number_of_fragments = (16 + 7)/8 = 2 and data_in_last_frag = 16
mod 8 = 0. The result of the inconsistency
number_of_fragments and data_in_last_frag will be that instead
sending three fragments, of lengths 8, 8, and 0, the
will send only two fragments, of lengths 8 and 0; the last
octets will never be sent
To avoid these difficulties, the specification should add
following statement, immediately after
data_in_last_frag
if data_in_last_frag = 0
data_in_last_frag := data_per_fragment
end if
This procedure also contains several minor errors. In addition
failures to account for packet header padding, which
enumerated in the next section, there is a failure to convert
header length from words (four octets) to octets in one statement
This statement, which calculates the total length of the non-
fragments,
to_SNP.dtgm.total_length := to_SNP.dtgm.header_
+ data_per_fragment
Sidhu [Page 9]
RFC 963 November 1985
Some Problems with MIL-STD
Since header length is expressed in units of words,
statement should
to_SNP.dtgm.total_length := to_SNP.dtgm.header_length * 4
+ data_per_fragment
This is apparently no more than a misprint, since
corresponding calculation for the tail fragment is done correctly
Problem 5: Errors in
The action procedure reassembly [MILS83a, sec 9.4.6.3.9], which
referred to as reassemble elsewhere in the specification [MILS83a
sec 9.4.6.1.2, sec 9.4.6.1.3], inserts an incoming fragment into
datagram being reassembled. This procedure contains
relatively minor errors
In two places in this procedure, a range is written to contain
more member than it ought to have. In the first, data from
fragment is to be inserted into the datagram being reassembled
state_vector.data [from_SNP.dtgm.fragment_offset*8 ..
from_SNP.dtgm.fragment_offset*8 + data_in_frag] :=
from_SNP.dtgm.data [0..data_in_frag-1];
In this statement, the slice on the left contains one more
than the slice on the right. This will cause a run-time
to be raised [ADA83, sec 5.2.1]. The statement should
state_vector.data [from_SNP.dtgm.fragment_offset*8 ..
from_SNP.dtgm.fragment_offset*8 + data_in_frag - 1] :=
from_SNP.dtgm.data [0..data_in_frag-1];
A similar problem occurs in the computation of the range of
in the reassembly map that corresponds to the incoming fragment
This statement
for j in (from_SNP.dtgm.fragment_offset) ..
((from_SNP.dtgm.fragment_offset +
data_in_frag + 7)/8)
Not only are the parentheses in this statement located
(because the function f(x) = (x + 7) / 8 should be executed
on the argument data_in_frag), but also this range contains
extra member. The statement should
Sidhu [Page 10]
RFC 963 November 1985
Some Problems with MIL-STD
for j in (from_SNP.dtgm.fragment_offset) ..
(from_SNP.dtgm.fragment_offset +
(data_in_frag + 7)/8) - 1
Note that if the statement is corrected in this manner it
also handle the case of a zero-length fragment, mentioned above
since the loop will not be executed even once [ADA83, sS 5.5].
Another minor problem occurs when this procedure attempts to
the header of the leading fragment. The relevant statement
state_vector.header := from_SNP.dtgm
This statement attempts to transfer the entire incoming
into a record that is big enough to contain only the header.
result, in Ada, is not truncation, but a run-time
[ADA83, sec 5.2]. The correction should be something
state_vector.header := from_SNP.dtgm.header
This correction cannot be made without also defining the
portion of the datagram as a subrecord in [MILS83a, sec 9.4.4.6];
such a definition would also necessitate changing many
statements. For example, from_SNP.dtgm.fragment_offset would
have to be written as from_SNP.dtgm.header.fragment_offset
Another possible solution is to write the above statement as
series of assignments for each field in the header, in
following fashion
state_vector.header.version :=
from_SNP.dtgm.version
state_vector.header.header_length :=
from_SNP.dtgm.header_length
state_vector.header.type_of_service :=
from_SNP.dtgm.type_of_service
-- etc
Note also that this procedure will fail if an incoming fragment
other than the tail fragment, does not contain a multiple of
characters. Implementors must be careful to check for this in
decision function SNP_params_valid [MILS83a, sec 9.4.6.2.7].
Sidhu [Page 11]
RFC 963 November 1985
Some Problems with MIL-STD
Problem 6: Incorrect Data Length for Fragmented
The procedure reassembled_delivery [MILS83a, sec 9.4.6.3.10]
not deliver the proper data length to the upper-level protocol
This is because the assignment
to_ULP.length := state_vector.header.total_
- state_vector.header.header_length * 4;
The fields in state_vector.header have been filled in by
reassembly procedure, discussed above, by copying the header
the leading fragment. The field total_length in this fragment
however, refers only to this particular fragment, and not to
entire datagram (this is not entirely clear from it definition
[MILS83a, sec 9.3.4], but the fragment_and_send
[MILS83a, sec 9.4.6.3.7] insures that this is the case).
The length of the entire datagram can only be computed from
length and offset of the tail fragment. This computation
actually done in the reassembly procedure [MILS83a,
9.4.6.3.9], and the result saved in state_vector.total_data_
(see above). It is impossible, however, for reassembly to fill
state_vector.header.total_length at this time,
state_vector.header.header_length is filled in from the
fragment, which may not yet have been received
Therefore, reassembled_delivery must replace the above
to_ULP.length := state_vector.total_data_length
The consequence of leaving this error uncorrected is that
upper-level protocol will be informed only of the delivery of
many octets as there are in the lead fragment
5. Implementation Difficulties of MIL Standard
In addition to the problems discussed above, there are
features of the MIL standard IP specification [MILS83a] which lead
difficulties for the implementor. These difficulties, while
actually errors in the specification, take the form of
which are not explicitly stated, but of which implementors must
aware
Sidhu [Page 12]
RFC 963 November 1985
Some Problems with MIL-STD
5.1 Header
In several places, the specification makes a computation of
length of a packet header without explicitly allowing for padding
The padding is needed because the specification requires [MILS83a
sec 9.3.14] that each header end on a 32-bit boundary
One place this problem arises is in the need_to_frag
function [MILS83a, sec 9.4.6.2.5]. This function is used
determine whether fragmentation is required for an
datagram. It consists of the single
if ((from_ULP.length + (number of bytes of option data
+ 20) > maximum transmission unit of the local
then return
else return NO
end if
(A minor syntax error results from not terminating the
return statement with a semicolon [ADA83, sec 5.1, sec 5.3,
5.9].) In order to allow for padding, the expression for
length of the outgoing datagram should
(((from_ULP.length + (number of bytes of option data) + 20)
+ 3)/4 * 4)
Another place that this problem arises is in the action
build_and_send [MILS83a, sec 9.4.6.3.2], which
unfragmented datagrams for transmission. To compute the
field header_length, which is expressed in words, i.e., units
four octets [MILS83a, sec 9.3.2], this procedure contains
to_SNP.dtgm.header_length := 5 +
(number of bytes of option data)/4;
In order to allow for padding, this statement should
to_SNP.dtgm.header_length :=
5 + ((number of bytes of option data)+3)/4;
The identical statement appears in the action
fragment_and_send [MILS83a, sec 9.4.6.3.7], which
datagram fragments for transmission, and requires the
correction
Sidhu [Page 13]
RFC 963 November 1985
Some Problems with MIL-STD
The procedure fragment_and_send also has this problem in two
places. In the first, the number of octets in each fragment
computed
data_per_fragment := maximum subnet transmission
- (20 + number of bytes of option data);
In order to allow for padding, this statement should
data_per_fragment := maximum subnet transmission
- (((20 + number of bytes of option data)+3)/4*4);
(Actually, this statement must be changed
data_per_fragment := (maximum subnet transmission
- (((20 + number of bytes of option data)+3)/4*4)/8*8;
in order to accomplish its intended purpose, for reasons
have been discussed above.)
A similar problem occurs in the statement which computes
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_SNP.dtgm.header_length := 5 +
(number of copy options octets+3/4);
Notice that all of these errors can also be corrected if
English phrase "number of bytes of option data", and
phrases, are always understood to include any necessary padding
5.2 Subnetworks with Small Transmission
When an outgoing datagram is too large to be transmitted as
single packet, it must be fragmented. On certain subnetworks,
possibility exists that the maximum number of bytes that may
transmitted at a time is less than the size of an IP packet
for a given datagram. In this case, the datagram cannot be sent
even in fragmented form. Note that this does not necessarily
that the subnetwork cannot send any datagrams at all, since
size of the header may be highly variable. When this
arises, it should be detected by IP. The proper place to
this situation is in the function can_frag
Sidhu [Page 14]
RFC 963 November 1985
Some Problems with MIL-STD
The can_frag decision function [MILS83a, sec 9.4.6.2.2] is used
determine whether a particular outgoing datagram, which is
long to be transmitted as a single fragment, is allowed to
fragmented. In the current specification, this function
of the single
if (from_ULP.dont_fragment = TRUE
then return
else return
end if
(A minor syntax error is that the return statements should
terminated by semicolons; see [ADA83, sec 5.1, sec 5.3, sec 5.9].)
If the above problem occurs, the procedure fragment_and_send
obtain negative numbers for fragment sizes, with
results. This should be prevented by assuring that the
can send the datagram header and at least one block (eight octets
of data. The can_frag function should be recoded
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
else return
end if
This is similar to the logic of the function need_to_frag
discussed above
5.3 Subnetwork
Provision is made for the subnetwork to report errors to
[MILS83a, sec 6.3.6.2], but no provision is made for the IP
to take any action when such errors occur
In addition, the specification [MILS83a, sec 8.2.1.1] calls
the subnetwork to accept type-of-service indicators (precedence
reliability, delay, and throughput), which may be difficult
implement on many local networks
Sidhu [Page 15]
RFC 963 November 1985
Some Problems with MIL-STD
5.4 ULP
The IP specification [MILS83a, sec 9.4.6.3.6]
The format of error reports to a ULP is
dependent. However, included in the report should be a
indicating the type of error, and some information to
the associated data or datagram
The most natural way to provide the latter information would be
return the datagram identifier to the upper-level protocol,
this identifier is normally supplied by the sending ULP [MILS83a
sec 9.3.5]. However, the to_ULP data structure makes no
for this information [MILS83a, sec 9.4.4.3], probably because
information is irrelevant for datagrams received from
subnetwork. Implementors may feel a need to add this field to
to_ULP data structure
5.5 Initialization of Data
The decision function reass_done [MILS83a, sec 9.4.6.2.6]
the implicit assumption that data structures within each
state machine are initialized to zero when the machine is created
In particular, this routine will not function properly
state_vector.reassembly_map and state_vector.total_data_length
so initialized. Since this assumption is not stated explicitly
implementors should be aware of it. There may be
initialization assumptions that we have not discovered
5.6 Locally Defined
The procedures error_to_source [MILS83a, sec 9.4.6.3.5]
error_to_ULP [MILS83a, sec 9.4.6.3.6] define enumeration types
comments. The former contains the
error_param : (PARAM_PROBLEM, EXPIRED_TTL, PROTOCOL_UNREACH);
and the
error_param : (PARAM_PROBLEM, CAN'T_FRAGMENT, NET_UNREACH
PROTOCOL_UNREACH, PORT_UNREACH);
These enumerated values are used before they are
[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
globally
Sidhu [Page 16]
RFC 963 November 1985
Some Problems with MIL-STD
5.7 Miscellaneous
The specification contains many Ada syntax errors, some of
have been shown above. We have only mentioned syntax
above, however, when they occurred in conjunction with
problems. One of the main syntactic difficulties that we have
mentioned is that the specification frequently creates
types, by declaring records within records; such declarations
legal in Pascal, but not in Ada [ADA83, sec 3.7].
Another problem is that slice assignments frequently do
contain the same number of elements on the left and right sides
which will raise a run-time exception [ADA83, sec 5.2.1].
we have mentioned some of these, there are others which are
enumerated above
In particular, the procedure error_to_source [MILS83a,
9.4.6.3.5] contains the
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
side contains one more byte than the right. Implementors
carefully check every slice assignment
6. An Implementation of MIL Standard
In our discussion above, we have pointed out several serious
with the Military Standard IP [MILS83a] specification which must
corrected to produce a running implementation conforming to
standard. We have produced a running C implementation for the
Standard IP, after problems discussed above were fixed in the
specification. An important feature of this implementation is
it was generated semi-automatically from the IP specification
the help of a protocol development system [BLUT82] [BLUT83] [SIDD83].
Since this implementation was derived directly from the
specification with the help of tools, it conforms to the IP
better that any handed-coded IP implementation can do
The problems pointed out in this paper with the current
of the MIL Standard IP [MILS83a] are based on an
investigation of the protocol
Sidhu [Page 17]
RFC 963 November 1985
Some Problems with MIL-STD
[1] Ada is a registered trademark of the U.S. Government - Ada
Program Office
[2] d indicates a "don't care" condition
The author extends his gratitude to Tom Blumer Michael Breslin,
Pollack and Mark J. Vincenzes, for many helpful discussions.
are also due to B. Simon and M. Bernstein for bringing to author'
attention a specification of the DoD Internet Protocol during 1981-82
when a detailed study of this protocol began. The author is
grateful to Jon Postel and Carl Sunshine for several
discussions about DoD IP/TCP during the last few years
[ADA83] Military Standard Ada(R) Programming Language,
States Department of Defense, ANSI/MIL-STD-1815A-1983, 22
January 1983
[BLUT83] Blumer, T. P., and Sidhu, D. P., "Mechanical
and Automatic Implementation of Communication Protocols,"
to appear in IEEE Trans. Softw. Eng
[BLUT82] Blumer, T. P., and Tenney, R. L., "A Formal
Technique and Implementation Method for Protocols,"
Computer Networks, Vol. 6, No. 3, July 1982, pp. 201-217.
[MILS83a] "Military Standard Internet Protocol," United
Department of Defense, MIL-STD-1777, 12 August 1983.
[MILS83b] "Military Standard Transmission Control Protocol,"
States Department of Defense, MIL-STD-1778, 12 August 1983.
[POSJ81] Postel, J. (ed.), "DoD Standard Internet Protocol,"
Advanced Research Projects Agency, Information
Techniques Office, RFC-791, September 1981.
[SDC82] DCEC Protocol Standardization Program:
Specification Report, System Development Corporation
TM-7172/301/00, 29 March 1982
[SIDD83] Sidhu, D. P., and Blumer, T. P., "Verification of NBS
4 Transport Protocol," to appear in IEEE Trans. Comm
Sidhu [Page 18]
RFC 963 November 1985
Some Problems with MIL-STD
[SIDD84] Sidhu, D. P., and Blumer, T. P., "Some Problems with
Specification of the Military Standard Transmission
Protocol," in Protocol Specification, Testing
Verification IV, (ed.) Y. Yemini et al (1984).
Sidhu [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
