Network Working Group J. Reynolds
Request for Comments: 990 J. Postel
ISI
Obsoletes RFCs: 960, 943, 923, 900, November 1986
870, 820, 790, 776, 770, 762, 758,
755, 750, 739, 604, 503, 433, 349
Obsoletes IENs: 127, 117, 93
ASSIGNED NUMBERS
Status of this Memo
This memo is an official status report on the numbers used in
protocols in the ARPA-Internet community. Distribution of this memo
is unlimited.
Introduction
This Network Working Group Request for Comments documents the
currently assigned values from several series of numbers used in
network protocol implementations. This RFC will be updated
periodically, and in any case current information can be obtained
from Joyce Reynolds. The assignment of numbers is also handled by
Joyce. If you are developing a protocol or application that will
require the use of a link, socket, port, protocol, network number,
etc., please contact Joyce to receive a number assignment.
Joyce K. Reynolds
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90292-6695
Phone: (213) 822-1511
ARPA mail: JKREYNOLDS@ISI.EDU
Most of the protocols mentioned here are documented in the RFC series
of notes. Some of the items listed are undocumented. Further
information on protocols can be found in the memo "Official
ARPA-Internet Protocols" [114]. The more prominent and more
generally used are documented in the "DDN Protocol Handbook" [46]
prepared by the NIC. Other collections of older or obsolete
protocols are contained in the "Internet Protocol Transition Workbook
[47], or in the "ARPANET Protocol Handbook" [48]. For further
information on ordering the complete 1985 DDN Protocol Handbook,
write: SRI International, DDN Network Information Center, Room EJ291,
333 Ravenswood Avenue, Meno Park, California, 94025. Or
call: 1-800-235-3155.
Reynolds & Postel [Page 1]

RFC 990 November 1986
Assigned Numbers
In the entries below the name and mailbox of the responsible
individual is indicated. The bracketed entry, e.g., [nn,iii], at the
right hand margin of the page indicates a reference for the listed
protocol, where the number ("nn") cites the document and the letters
("iii") cites the person. Whenever possible, the letters are a NIC
Ident as used in the WhoIs (NICNAME) service.
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian" order
[131]. That is, fields are described left to right, with the most
significant octet on the left and the least significant octet on the
right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are
numbered.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in
the diagram is the high order or most significant bit. That is, the
bit labeled 0 is the most significant bit. For example, the
following diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Significance of Bits
Similarly, whenever a multi-octet field represents a numeric quantity
Reynolds & Postel [Page 2]

RFC 990 November 1986
Assigned Numbers
the left most bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
Reynolds & Postel [Page 3]

RFC 990 November 1986
Network Numbers
The fourth type of address, class D, is used as a multicast
address [44]. The four highest-order bits are set to 1-1-1-0.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0| multicast address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class D Address
Note: No addresses are allowed with the four highest-order bits
set to 1-1-1-1. These addresses, called "class E", are reserved.
One commonly used notation for internet host addresses divides the
32-bit address into four 8-bit fields and specifies the value of each
field as a decimal number with the fields separated by periods. This
is called the "dotted decimal" notation. For example, the internet
address of B.ISI.EDU in dotted decimal is 010.003.000.052, or
10.3.0.52.
The dotted decimal notation will be used in the listing of assigned
network numbers. The class A networks will have nnn.rrr.rrr.rrr, the
class B networks will have nnn.nnn.rrr.rrr, and the class C networks
will have nnn.nnn.nnn.rrr, where nnn represents part or all of a
network number and rrr represents part or all of a local address.
There are four catagories of users of Internet Addresses: Research,
Defense, Government (Non-Defense), and Commercial. To reflect the
allocation of network identifiers among the categories, a
one-character code is placed to the left of the network number: R for
Research, D for Defense, G for Government, and C for Commercial (see
Appendix A for further details on this division of the network
identification).
Network numbers are assigned for networks that are connected to the
ARPA-Internet and DDN-Internet, and for independent networks that use
the IP family protocols (these are usually commercial). These
independent networks are marked with an asterisk preceding the
number.
The administrators of independent networks must apply separately for
permission to interconnect their network with either the
ARPA-Internet of the DDN-Internet. Independent networks should not
be listed in the working tables of either the ARPA-Internet or
DDN-Internet hosts or gateways.
Reynolds & Postel [Page 5]

RFC 990 November 1986
Network Numbers
For various reasons, the assigned numbers of networks are sometimes
changed. To ease the transition the old number will be listed for a
transition period as well. These "old number" entries will be marked
with a "T" following the number and preceding the name, and the
network name will be suffixed "-TEMP".
Special Addresses:
In certain contexts, it is useful to have fixed addresses with
functional significance rather than as identifiers of specific
hosts.
The address zero is to be interpreted as meaning "this", as in
"this network".
For example, the address 0.0.0.37 could be interpreted as
meaning host 37 on this network.
The address of all ones are to be interpreted as meaning "all",
as in "all hosts".
For example, the address 128.9.255.255 could be interpreted
as meaning all hosts on the network 128.9.
The class A network number 127 is assigned the "loopback"
function, that is, a datagram sent by a higher level protocol
to a network 127 address should loop back inside the host. No
datagram "sent" to a network 127 address should ever appear on
any network anywhere.
Reynolds & Postel [Page 6]

RFC 990 November 1986
ARPANET Link Numbers
ASSIGNED ARPANET LINK NUMBERS
The word "link" here refers to a field in the original ARPANET
Host/IMP interface leader. The link was originally defined as an
8-bit field. Later specifications defined this field as the
"message-id" with a length of 12 bits. The name link now refers to
the high order 8 bits of this 12-bit message-id field. The Host/IMP
interface is defined in BBN Report 1822 [10].
The low-order 4 bits of the message-id field are called the sub-link.
Unless explicitly specified otherwise for a particular protocol,
there is no sender to receiver significance to the sub-link. The
sender may use the sub-link in any way he chooses (it is returned in
the RFNM by the destination IMP), the receiver should ignore the
sub-link.
Link Assignments:
Decimal Description References
------- ----------- ----------
0 Reserved [JBP]
1-149 Unassigned [JBP]
150 Xerox NS IDP [139,HGM]
151 Unassigned [JBP]
152 PARC Universal Protocol [15,HGM]
153 TIP Status Reporting [JGH]
154 TIP Accounting [JGH]
155 Internet Protocol [regular] [101,JBP]
156-158 Internet Protocol [experimental] [101,JBP]
159 Figleaf Link [JBW1]
160-194 Unassigned [JBP]
195 ISO-IP [65,RXM]
196-247 Experimental Protocols [JBP]
248-255 Network Maintenance [JGH]
Reynolds & Postel [Page 35]

RFC 990 November 1986
IEEE 802 Numbers
IEEE 802 NUMBERS OF INTEREST
Some of the networks of all classes are IEEE 802 Networks. These
systems may use a Link Service Access Point (LSAP) field in much the
same way the ARPANET uses the "link" field, further, there is a
extension of the LSAP header called the Sub-Network Access Protocol
(SNAP).
The IEEE likes to describe numbers in binary in bit transmission
order, which is the opposite of the big-endian order used throughout
the Internet protocol documentation.
Assignments:
Link Service Access Point Description References
-------------------------- ----------- ----------
IEEE Internet
binary binary decimal
00000000 00000000 0 Null LSAP [IEEE]
11000000 00000011 3 Group LLC Sublayer Mgt [IEEE]
01000000 00000010 4 Indiv LLC Sublayer Mgt [IEEE]
01100000 00000110 6 DOD IP [101,JBP]
01110000 00001110 14 PROWAY-LAN [IEEE]
01110010 01001110 78 EIA-RS 511 [IEEE]
01110001 10001110 142 PROWAY-LAN [IEEE]
01010101 10101010 170 SNAP [IEEE]
01111111 11111110 254 ISO DIS 8473 [65,JXJ]
11111111 11111111 255 Global DSAP [IEEE]
These numbers (and others) are assigned by the IEEE Standards Office.
The address is: IEEE Standards Office, 345 East 47th Street, New
York, N.Y. 10017, Attn: Vince Condello. Phone: (212) 705-7092.
At an ad hoc special session on "IEEE 802 Networks and ARP" held
during the TCP Vendors Workshop (August 1986), an approach to a
consistent way to sent DOD-IP datagrams and other IP related
protocols on 802 networks was developed.
Due to some evolution of the IEEE 802.2 standards and the need to
provide for a standard way to do additional DOD-IP related protocols
(such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the
following new policy is established, which will replace the old
policy (see RFC-960 and RFC-948 [138]).
The new policy is for DDN and ARPA-Internet community to use IEEE
802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the
Reynolds & Postel [Page 36]

RFC 990 November 1986
IEEE 802 Numbers
SNAP with an organization code indicating that the following 16 bits
specify the Ethertype code (where IP = 2048 (0800 hex), see Ethernet
Numbers of Interest).
Header
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP
+--------+--------+---------+--------+--------+
The values of K1 and K2 must be assigned by the IEEE. There is
already assigned a value of K1 that indicates that the 5-octet SNAP
header follows. There may be a value of K2 that is already assigned
that indicates that the last two octets of the SNAP header holds the
EtherType.
The total length of the SAP Header and the SNAP header is 8-octets,
making the 802.2 protocol overhead come out on a nice octet boundary.
K1 is 170. The IEEE like to talk about things in bit transmission
order and specifies this value as 01010101. In big-endian order, as
used in Internet specifications, this becomes 10101010 binary, or
AA hex, or 170 decimal.
We believe that K2 is 0 (zero). This must be further investigated.
As an interim measure use K2 = 0.
The use of the IP LSAP (K1 = 6) is to be phased out as quickly as
possible.
Reynolds & Postel [Page 37]

RFC 990 November 1986
Machine Names
OFFICIAL MACHINE NAMES
These are the Official Machine Names as they appear in the NIC Host
Table. Their use is described in RFC 952 [49].
An Official Machine Name or CPU Type may be up to 40 characters taken
from the set of uppercase letters, digits, and the two punctuation
characters hyphen and slash. It must start with a letter, and end
with a letter or digit.
ALTO
AMDAHL-V7
APOLLO
ATT-3B20
BBN-C/60
BURROUGHS-B/29
BURROUGHS-B/4800
BUTTERFLY
C/30
C/70
CADLINC
CADR
CDC-170
CDC-170/750
CDC-173
CELERITY-1200
COMTEN-3690
CP8040
CTIWS-117
DANDELION
DEC-10
DEC-1050
DEC-1077
DEC-1080
DEC-1090
DEC-1090B
DEC-1090T
DEC-2020T
DEC-2040
DEC-2040T
DEC-2050T
DEC-2060
DEC-2060T
DEC-2065
DEC-FALCON
DEC-KS10
DORADO
Reynolds & Postel [Page 42]

RFC 990 November 1986
System Names
OFFICIAL SYSTEM NAMES
These are the Official System Names as they appear in the NIC Host
Table. Their use is described in RFC 952 [49].
An Official System Names or Operating System Type may be up to 40
characters taken from the set of uppercase letters, digits, and the
two punctuation characters hyphen and slash. It must start with a
letter, and end with a letter or digit.
AEGIS
APOLLO
BS-2000
CEDAR
CGW
CHRYSALIS
CMOS
CMS
COS
CPIX
CTOS
DCN
DDNOS
DOMAIN
EDX
ELF
EMBOS
EMMOS
EPOS
FOONEX
FUZZ
GCOS
GPOS
HDOS
IMAGEN
INTERCOM
IMPRESS
INTERLISP
IOS
ITS
LISP
LISPM
LOCUS
MINOS
MOS
MPE5
MSDOS
Reynolds & Postel [Page 46]

RFC 990 November 1986
Terminal Type Names
OFFICIAL TERMINAL TYPE NAMES
These are the Official Terminal Type Names. Their use is described
in RFC 930 [124].
An Official Terminal Type Names may be up to 40 characters taken from
the set of uppercase letters, digits, and the two punctuation
characters hyphen and slash. It must start with a letter, and end
with a letter or digit.
ADDS-CONSUL-980
ADDS-REGENT-100
ADDS-REGENT-20
ADDS-REGENT-200
ADDS-REGENT-25
ADDS-REGENT-40
ADDS-REGENT-60
AMPEX-DIALOGUE-80
ANDERSON-JACOBSON-630
ANDERSON-JACOBSON-832
ANDERSON-JACOBSON-841
ANN-ARBOR-AMBASSADOR
ARDS
BITGRAPH
BUSSIPLEXER
CALCOMP-565
CDC-456
CDI-1030
CDI-1203
CLNZ
COMPUCOLOR-II
CONCEPT-100
CONCEPT-104
CONCEPT-108
DATA-100
DATA-GENERAL-6053
DATAGRAPHIX-132A
DATAMEDIA-1520
DATAMEDIA-1521
DATAMEDIA-2500
DATAMEDIA-3025
DATAMEDIA-3025A
DATAMEDIA-3045
DATAMEDIA-3045A
DATAMEDIA-DT80/1
DATAPOINT-2200
DATAPOINT-3000
Reynolds & Postel [Page 51]

RFC 990 November 1986
Appendix A
Within the Research community, network identifiers will only be
granted to applicants who show evidence that they are acquiring
standard Bolt Beranek and Newman gateway software or have
implemented or are acquiring a gateway meeting the Exterior
Gateway Protocol requirements. Acquisition of the Berkeley BSD
4.3 UNIX software might be considered evidence of the latter.
Experimental networks which later become operational need not be
renumbered. Rather, the identifiers could be moved from Research
to Defense, Government or Commercial status. Thus, network
identifiers may change state among Research, Defense, Government
and Commercial, but the number of identifiers allocated to each
use must remain within the limits indicated above. To make
possible this fluid assignment, the network identifier spaces are
not allocated by simple partition, but rather by specific
assignment.
Protocol Identifiers
These assignments are shared by the four communities.
Port Numbers
These assignments are shared by the four communities.
ARPANET Link Numbers
These assignments are shared by the four communities.
IP Version Numbers
These assignments are shared by the four communities.
TCP, IP and Telnet Option Identifiers
These assignments are shared by the four communities.
Implementation:
Joyce Reynolds is the coordinator for all number assignments.
Reynolds & Postel [Page 75]