The Vines Reliable Data Transport protocol is referred to as
'vipc vipc-rdp' OR 'vipc 0x01'."
DECODING
"Children of vipc are deemed to start at the first byte after the
packet type field (i.e. at offset 5 in the vipc header)."
REFERENCE
"BANYAN"
::= { vip 0x01 }
-- Banyan treats vipc, vipc-dgp and vipc-rdp as one protocol, IPC.
-- Vines IPC really comes in two flavours. The first is used to
-- send unreliable datagrams (vipc packet type 0x00). The second
-- used to send reliable datagrams (vipc packet type 0x01),
-- consisting of up to four actual packets.
-- In order to distinguish between these we need two 'virtual'
-- protocols to identify which is which.
vipc-dgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Vines Unreliable Datagram Protocol."
CHILDREN
"Children of vipc-dgp are identified by the 16 bit port numbers
contained in the vipc (this protocol's parent protocol) header.
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
Children of vipc-dgp are defined as 'vipc-dgp a' where 'a' is the
port number in hexadecimal notation.
The StreetTalk protocol running over vipc-dgp would be referred
to as 'vipc-dgp streettalk' OR 'vipc-dgp 0x000F'.
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"Children of vipc-dgp are deemed to start after the single
padding byte found in the vipc header. In the case of vipc-dgp
the vipc header is a so called 'short' header, total length 6
bytes (including the final padding byte)."
REFERENCE
"BANYAN"
::= { vipc 0x00 }
vipc-rdp PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Vines Reliable Datagram Protocol."
CHILDREN
"Children of vipc-rdp are identified by the 16 bit port numbers
contained in the vipc (this protocol's parent protocol) header.
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
Children of vipc-dgp are defined as 'vipc-rdp a' where 'a' is the
port number in hexadecimal notation.
The StreetTalk protocol running over vipc-rdp would be referred
to as 'vipc-rdp streettalk' OR 'vipc-rdp 0x000F'.
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"Children of vipc-rdp are deemed to start after the error/length
field at the end of the vipc header. For vipc-rdp the vipc
header is a so called 'long' header, total 16 bytes (including
the final error/length field).
vipc-rdp includes a high level fragmentation scheme which allows
up to four vipc packets to be sent as a single atomic PDU. The
countsFragments(0) PARAMETERS bit indicates whether the probe can
(and should) identify the child protocol in all fragments or only
the leading one."
REFERENCE
"BANYAN"
::= { vipc 0x01 }
vspp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Banyan Vines Sequenced Packet Protocol."
CHILDREN
"Children of vspp are identified by the 16 bit port numbers
contained in the vspp header.
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
Children of vspp are defined as 'vspp a' where 'a' is the port
number in hexadecimal notation.
The StreetTalk protocol running over vspp would be referred to as
'vspp streettalk' OR 'vspp 0x000F'.
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"The implementation must ensure only those vspp packets which
contain application data are decoded and passed on to children.
Although it is suggested that the packet type and control fields
should be used to determine this fact it is beyond the scope of
this document to fully define the algorithm used."
REFERENCE
"BANYAN"
::= { vip 0x02 }
vrtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Routing Update Protocol."
REFERENCE
"BANYAN"
::= { vip 0x05 }
vicp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Internet Control Protocol."
REFERENCE
"BANYAN"
::= { vip 0x06 }
3.1.6. The DECNet Protocol Stack
dec PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC"
REFERENCE
"Digital Corporation"
::= {
ether2 0x6000,
802-1Q 0x6000 -- [0.0.96.0]
}
lat PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Local Area Transport Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6004,
802-1Q 0x6004 -- [0.0.96.4]
}
mop PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Maintenance Operations Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6001, -- mop dump/load
ether2 0x6002, -- mop remote console
802-1Q 0x6001, -- [0.0.96.1] VLAN + mop dump/load
802-1Q 0x6002 -- [0.0.96.2] VLAN + mop remote console
}
dec-diag PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Diagnostic Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6005,
802-1Q 0x6005 -- [0.0.96.5]
}
lavc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Local Area VAX Cluster Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6007,
802-1Q 0x6007 -- [0.0.96.7]
}
drp PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(1)
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DEC Routing Protocol."
CHILDREN
"There is only one child of DRP, NSP. This is encoded as [
0.0.0.1 ]."
ADDRESS-FORMAT
"There are three address formats used in DRP packets, 2-byte
(short data packet and all control except ethernet endnode &
router hello messages), 6-byte (ethernet router & endnode hello
messages) and 8-byte (long data packet). All of these contain
the 2-byte format address in the last 2 bytes with the remaining
bytes being unimportant for the purposes of system
identification. It is beyond the scope of this document to
define the algorithms used to identify packet types and hence
address formats.
The 2-byte address format is the concatenation of a 6-bit area
and a 10-bit node number. In all cases this is placed in little
endian format (i.e. LSB, MSB). The probe, however, will return
them in network order (MSB, LSB). Regardless of the address
format in the packet, the probe will always use the 2-byte
format.
For example area=13 (001101) and node=311 (0100110111) gives:
0011 0101 0011 0111 = 0x3537 in network order (the order the
probe should return the address in).
In packets this same value would appear as (hex):
2-byte 37 35
6-byte AA 00 04 00 37 35
8-byte 00 00 AA 00 04 00 37 35
Notice that the AA 00 04 00 prefix is defined in the
specification but is unimportant and should not be parsed.
Notice that control messages only have a source address in the
header and so they can never be added into the conversation based
tables."
DECODING
"NSP runs over DRP data packets; all other packet types are DRP
control packets of one sort or another and do not carry any
higher layer protocol.
NSP packets are deemed to start at the beginning of the DRP data
area.
Data packets may be fragmented over multiple DRP data packets.
The countsFragments(1) parameter indicates whether a probe can
(and should) attribute non-leading fragments to the child
protocol (above NSP in this case) or not.
Recognition of DRP data packets and fragments is beyond the scope
of this document."
REFERENCE
"DECnet Digital Network Architecture
Phase IV
Routing Layer Functional Specification
Order# AA-X435A-TK
Digital Equipment Corporation, Maynard, Massachusetts, USA"
::= {
ether2 0x6003,
snap 0x6003,
802-1Q 0x6003 -- [0.0.96.3]
}
nsp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"DEC Network Services Protocol."
CHILDREN
"Children of NSP are identified by the SCP 8-bit object type.
Notice that the object type is included only in the session
establishment messages (connect initiate, retransmitted connect
initiate).
Children of NSP are encoded [ 0.0.0.a ] where 'a' is the SCP
object type. Children of NSP are named as 'nsp' followed by the
SCP object type in decimal. CTERM is referred to as 'nsp cterm'
OR 'nsp 42'."
DECODING
"An implementation is encouraged to examine SCP headers included
in NSP control messages in order to determine which child
protocol is present over a given session. It is beyond the scope
of this document to define the algorithm used to do this.
The tracksSessions(1) flag indicates whether the probe can (and
should) perform this analysis."
REFERENCE
"DECnet Digital Network Architecture
Phase IV
NSP Functional Specification
Order# AA-X439A-TK
Digital Equipment Corporation, Maynard, Massachusetts, USA"
::= { drp 1 }
dap-v1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Data Access Protocol version 1."
REFERENCE
"Digital Corporation"
::= { nsp 1 }
dap-v4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Data Access Protocol versions 4 and above."
REFERENCE
"Digital Corporation"
::= { nsp 17 }
nice PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Network Information and Control Exchange protocol."
REFERENCE
"Digital Corporation"
::= { nsp 19 }
dec-loop PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Loopback Protocol."
REFERENCE
"Digital Corporation"
::= { nsp 25 }
dec-event PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Event Protocol."
REFERENCE
"Digital Corporation"
::= { nsp 26 }
cterm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC CTERM Protocol."
REFERENCE
"Digital Corporation"
::= { nsp 42 }
3.1.7. The IBM SNA Protocol Stack.
sna-th PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IBM's SNA TH protocol."
REFERENCE
"IBM Systems Network Architecture
Format and Protocol
Reference Manual: Architectural Logic
SC30-3112-2
IBM System Communications Division,
Publications Development,
Department E02,
PO Box 12195,
Research Triangle Park,
North Carolina 27709."
::= {
llc 0x04, -- [0.0.0.4]
llc 0x08, -- [0.0.0.8]
llc 0x0c, -- [0.0.0.12]
ether2 0x80d5, -- [0.0.128.213]
802-1Q 0x02000004, -- 1Q-LLC [2.0.0.4]
802-1Q 0x02000008, -- 1Q-LLC [2.0.0.8]
802-1Q 0x0200000c, -- 1Q-LLC [2.0.0.12]
802-1Q 0x80d5 -- [0.0.128.213]
}
3.1.8. The NetBEUI/NetBIOS Family
-- CHILDREN OF NETBIOS
-- The NetBIOS/NetBEUI functions are implemented over a wide variety of
-- transports. Despite varying implementations they all share two
-- features. First, all sessions are established by connecting to
-- locally named services. Second, all sessions transport application
-- data between the client and the named service. In all cases the
-- identification of the application protocol carried within the data
-- packets is beyond the scope of this document.]
--
-- Children of NetBIOS/NetBEUI are identified by the following (32 bit)
-- enumeration
--
-- 1 smb (Microsoft's Server Message Block Protocol)
-- 2 notes (Lotus' Notes Protocol)
-- 3 cc-mail (Lotus' CC Mail Protocol)
--
-- Children of NetBIOS/NetBEUI are encoded as [ a.b.c.d ] where 'a', 'b',
-- 'c' and 'd' are the four octets of the enumerated value in network
-- order (i.e. 'a' is the MSB and 'd' is the LSB).
--
-- For example notes over NetBEUI is declared as
-- 'notes ::= { netbeui 2 }'
-- but is referred to as
-- 'netbeui notes' OR 'netbeui 2'.
netbeui PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Lan Manager NetBEUI protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
DECODING
"NETBEUI provides a named service lookup function. This function
allows clients to locate a service by (locally assigned) name.
An implementation is encouraged to follow lookups and session
establishments and having determined the child protocol, track
them.
How the child protocol is determined and how the sessions are
tracked is an implementation specific matter and is beyond the
scope of this document."
REFERENCE
"IBM"
::= {
llc 0xF0, -- [0.0.0.240]
802-1Q 0x020000F0 -- 1Q-LLC [2.0.0.240]
}
nbt-name PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NetBIOS-over-TCP name protocol."
REFERENCE
"RFC1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.' RFC1002
[RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
::= {
udp 137,
tcp 137
}
nbt-session PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NetBIOS-over-TCP session protocol."
REFERENCE
"RFC1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.' RFC1002
[RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
::= {
udp 139,
tcp 139
}
nbt-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"NetBIOS-over-TCP datagram protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"RFC1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.' RFC1002
[RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
::= {
udp 138,
tcp 138
}
netbios-3com PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"3COM NetBIOS protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"3Com Corporation"
::= {
ether2 0x3C00,
ether2 0x3C01,
ether2 0x3C02,
ether2 0x3C03,
ether2 0x3C04,
ether2 0x3C05,
ether2 0x3C06,
ether2 0x3C07,
ether2 0x3C08,
ether2 0x3C09,
ether2 0x3C0A,
ether2 0x3C0B,
ether2 0x3C0C,
ether2 0x3C0D,
802-1Q 0x3C00,
802-1Q 0x3C01,
802-1Q 0x3C02,
802-1Q 0x3C03,
802-1Q 0x3C04,
802-1Q 0x3C05,
802-1Q 0x3C06,
802-1Q 0x3C07,
802-1Q 0x3C08,
802-1Q 0x3C09,
802-1Q 0x3C0A,
802-1Q 0x3C0B,
802-1Q 0x3C0C,
802-1Q 0x3C0D
}
nov-netbios PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell's version of the NetBIOS protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"Novell Corporation"
::= {
nov-sap 0x0020, -- preferred encapsulation to use, even though
-- the following are typically used also
-- ipx 0x14, -- when reached by IPX packet type
-- nov-pep 0x0455 -- when reached by socket number
}
burst PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell burst-mode transfer"
REFERENCE
"Novell Corporation"
::= { nov-pep 0x0d05 }
3.2. Multi-stack protocols
smb PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Microsoft Server Message Block Protocol."
REFERENCE
"Microsoft Corporation"
::= {
netbeui 1,
netbios-3com 1,
nov-netbios 1,
nbt-data 1,
nbt-session 1,
nov-pep 0x550,
nov-pep 0x552
}
notes PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Lotus Notes Protocol."
REFERENCE
"Lotus Development"
::= {
netbeui 2,
netbios-3com 2,
nov-netbios 2,
nbt-data 2,
tcp 1352,
udp 1352,
nov-sap 0x039b
}
ccmail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Lotus CC-mail Protocol."
REFERENCE
"Lotus Development"
::= {
netbeui 3,
netbios-3com 3,
nov-netbios 3,
nbt-data 3,
tcp 3264,
udp 3264
}
snmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
REFERENCE
"The SNMP SMI is defined in RFC1902 [RFC1902]. Version 1 of the
SNMP protocol is defined in RFC1905 [RFC1905]. Transport
mappings are defined in RFC1906 [RFC1906]; RFC1420 (SNMP over
IPX) [RFC1420]; RFC1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
nov-pep 0x900f, -- [ 0.0.144.15 ]
atalk 8,
tcp 161
}
snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC1902 [RFC1902]. The SNMP
protocol is defined in RFC1905 [RFC1905]. Transport mappings
are defined in RFC1906 [RFC1906]; RFC1420 (SNMP over IPX)
[RFC1420]; RFC1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
nov-pep 0x9010,
atalk 9,
tcp 162
}
-- END
4. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
5. Acknowledgements
This document was produced by the IETF RMONMIB Working Group.
The authors wish to thank the following people for their
contributions to this document:
Anil Singhal
Frontier Software Development, Inc.
Jeanne Haney
Bay Networks
Dan Hansen
Network General Corp.
Special thanks are in order to the following people for writing RMON
PI macro compilers, and improving the specification of the PI macro
language:
David Perkins
DeskTalk Systems, Inc.
Skip Koppenhaver
Technically Elite, Inc.
6. References
[IEN158] J. Haverty, "XNET Formats for Internet Protocol Version
4", IEN 158, October 1980.
[RFC407] Bressler, R., Guida. R. and A. McKenzie, "Remote Job Entry
Protocol", RFC407, October 1972.
[RFC493] Michener, J., Cotton, I., Kelley, K., Liddle, D. and E.
Meyer, "E.W., Jr Graphics Protocol", RFC493, April 1973.
[RFC734] Crispin, M., "SUPDUP Protocol", RFC734, October 1977.
[RFC740] Braden, R., "NETRJS Protocol", RFC740, November 1977.
[RFC741] Cohen, D., "Specifications for the Network Voice
Protocol", RFC741, ISI/RR 7539, March 1976.
[RFC759] Postel, J., "Internet Message Protocol", RFC759, August
1980.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC768,
August 1980.
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC791, September 1981.
[RFC792] Postel, J., "Internet Control Message Protocol - DARPA
Internet Program Protocol Specification", STD 5, RFC792,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 5, RFC793,
September 1981.
[RFC818] Postel, J., "Remote User Telnet service", RFC818,
November 1982.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC823] Hinden, R. and A. Sheltzer, "The DARPA Internet Gateway",
RFC823, September 1982.
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol or
Converting Network Protocol Addresses to 48-bit Ethernet
Addresses for Transmission on Ethernet Hardware", STD 37,
RFC826, November 1982.
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC854, May 1983.
[RFC862] Postel, J., "Echo Protocol", STD 20, RFC862, May 1983.
[RFC863] Postel, J., "Discard Protocol", STD 21, RFC863, May 1983.
[RFC864] Postel, J., "Character Generator Protocol", STD 22, RFC
864, May 1983.
[RFC865] Postel, J., "Quote of the Day Protocol", STD 23, RFC865,
May 1983.
[RFC866] Postel, J., "Active Users", STD 26, RFC866, May 1983.
[RFC867] Postel, J., "Daytime Protocol", STD 25, RFC867, May 1983.
[RFC868] Postel, J., "Time Protocol", STD 26, RFC868, May 1983.
[RFC869] Hinden, R., "A Host Monitoring Protocol", RFC869,
December 1983.
[RFC887] Accetta, M., "Resource Location Protocol", RFC887,
December 1983.
[RFC904] International Telegraph and Telephone Co., D. Mills,
"Exterior Gateway Protocol Formal Specification", STD 18,
RFC904, April 1984.
[RFC905] McKenzie, A., "ISO Transport Protocol Specification - ISO
DP 8073", RFC905, April 1984.
[RFC908] Velten, D., Hinden, R., and J. Sax, "Reliable Data
Protocol", RFC908, July 1984.
[RFC913] Lottor, M., "Simple File Transfer Protocol", RFC913,
September 1984.
[RFC915] Elvy, M. and R. Nedved, "Network mail path service", RFC
915, December 1984.
[RFC937] Butler, M., Chase, D., Goldberger, J., Postel, J., and J.
Reynolds, "Post Office Protocol - version 2", RFC937,
February 1985.
[RFC938] Miller, T., "Internet Reliable Transaction Protocol", RFC
938, February 1985.
[RFC951] Croft, W. and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)",
RFC951, September 1985.
[RFC953] Feinler, E., Harrenstien, K. and M. Stahl, "Hostname
Server", RFC953, October 1985.
[RFC954] Feinler, E., Harrenstien, K. and M. Stahl,
"NICNAME/WHOIS", RFC954, October 1985.
[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD
9, RFC959, October 1985.
[RFC972] Wancho, F., "Password Generator Protocol", RFC972,
January 1986.
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol: A Proposed Standard for the Stream-Based
Transmission of News", RFC977, February 1986.
[RFC996] Mills, D., "Statistics server", RFC996, February 1987.
[RFC998] Clark, D., Lambert, M. and L. Zhang, "NETBLT: A Bulk Data
Transfer Protocol", RFC998, March 1987.
[RFC1001] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, End-to-End
Services Task Force. "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Concepts and methods",
STD 19, RFC1001, March 1987.
[RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, End-to-End
Services Task Force. "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed
specifications.", STD 19, RFC1002, March 1987.
[RFC1021] Partridge, C. and G. Trewitt, "High-level Entity
Management System HEMS", RFC1021, October 1987.
[RFC1028] Case, J., Davin, J., Fedor, M. and M. Schoffstall, "Simple
Gateway Monitoring Protocol", RFC1028, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC1035, November 1987.
[RFC1056] Lambert, M., "PCMAIL: A distributed mail system for
personal computers", RFC1056, June 1988.
[RFC1057] Sun Microsystems, Inc, "RPC: Remote Procedure Call
Protocol Specification version 2", RFC1057, June 1988.
[RFC1064] Crispin, M., "Interactive Mail Access Protocol: Version
2", RFC1064, July 1988.
[RFC1068] DeSchon, A. and R. Braden, "Background File Transfer
Program BFTP", RFC1068, August 1988.
[RFC1070] Hagens, R., Hall, N. and M. Rose, "Use of the Internet as
a subnetwork for experimentation with the OSI network
layer", RFC1070, February 1989.
[RFC1078] Lottor, M., "TCP port service Multiplexer TCPMUX", RFC
1078, November, 1988.
[RFC1086] Onions, J. and M. Rose, "ISO-TP0 bridge between TCP and
X.25", RFC1086, December 1988.
[RFC1095] Warrier, U. and L. Besaw, "Common Management Information
Services and Protocol over TCP/IP (CMOT)", RFC1095, April
1989.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC1112, August 1989.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, May 1990.
[RFC1203] Rice, J., "Interactive Mail Access Protocol - Version 3",
RFC1203, February 1991.
[RFC1204] Lee, D. and S. Yeh, "Message Posting Protocol (MPP)", RFC
1204, February 1991.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC1212, March 1991.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC1213, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC1215, March 1991.
[RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25
Frames", RFC1226, May 1991.
[RFC1227] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, May 1991.
[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
RFC1234, June 1991.
[RFC1235] Ioannidis, J. and G. Maguire, Jr., "The Coherent File
Distribution Protocol", RFC1235, June 1991.
[RFC1241] Mills, D. and R. Woodburn, "A Scheme for an Internet
Encapsulation Protocol: Version 1", RFC1241, July 1991.
[RFC1249] Howes, T., Smith, M. and B. Beecher, "DIXIE Protocol
Specification", RFC1249, August 1991.
[RFC1267] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)", RFC1267, October 1991.
[RFC1282] Kantor, B., "BSD Rlogin", RFC1282, December 1991.
[RFC1288] Zimmerman, D., "The Finger User Information Protocol", RFC
1288, December 1991.
[RFC1301] Amstrong, S., Freier, A. and K. Marzullo, "Multicast
Transport Protocol", RFC1301, February 1992.
[RFC1305] Mills, D., "Network Time Protocol (v3)", RFC1305, April
1992.
[RFC1312] Nelson, R. and G. Arnold, "Message Send Protocol", RFC
1312, April 1992.
[RFC1339] Dorner, S. and P. Resnick, "Remote Mail Checking
Protocol", RFC1339, June 1992.
[RFC1350] Sollins, K., "TFTP Protocol (revision 2)", RFC1350, July
1992.
[RFC1413] St. Johns, M., "Identification Protocol", RFC1413,
February 1993.
[RFC1419] Minshall, G. and M. Ritter, "SNMP over AppleTalk", RFC
1419, March 1993.
[RFC1420] Bostock, S., "SNMP over IPX", RFC1420, March 1993.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
John, D., Torrey, D. and B. Alberti, "The Internet Gopher
Protocol (a distributed document search and retrieval
protocol)", RFC1436, March 1993.
[RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
RFC1459, May 1993.
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol", RFC
1476, June 1993.
[RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol
Specification: Version 1", RFC1479, July 1993.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC1483, July 1993.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC1492, July 1993.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC1510, September 1993.
[RFC1583] Moy, J., "OSPF Version 2", RFC1583, March 1994.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC1702,
October 1994.
[RFC1725] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
RFC1725, November 1994.
[RFC1729] Lynch, C., "Using the Z39.50 Information Retrieval
Protocol in the Internet Environment", RFC1729, December
1994.
[RFC1730] Crispin, M., "Internet Message Access Protocol - Version
4", RFC1730, December 1994.
[RFC1739] Kessler, G. and S. Shepard, "A Primer On Internet and
TCP/IP Tools", RFC1739, December 1994.
[RFC1745] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for
IP---OSPF Interaction", RFC1745, December 1994.
[RFC1757] Waldbusser, S., "Remote Network Monitoring MIB", RFC1757,
February 1995.
[RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol", RFC1777, March 1995.
[RFC1782] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC
1782, March 1995.
[RFC1783] Malkin, G. and A. Harkin, "TFTP BlockOption Option", RFC
1783, March 1995.
[RFC1784] Malkin, G. and A. Harkin, "TFTP Timeout Interval and
Transfer Size Options", RFC1784, March 1995.
[RFC1798] Young, A., "Connection-less Lightweight Directory Access
Protocol", RFC1798, June 1995.
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version
3 Protocol Specification", RFC1813, June 1995.
[RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol
Version 2 (ST2)", RFC1819, August 1995.
[RFC1831] Srinivasan, R., "Remote Procedure Call Protocol Version
2", RFC1831, August 1995.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC1853, October 1995.
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC1901,
January 1996.
[RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1902,
January 1996.
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,