RFC 1060 Assigned Numbers March 1990
MACHINE NAMES...................................................53
SYSTEM NAMES....................................................57
PROTOCOL AND SERVICE NAMES......................................58
TERMINAL TYPE NAMES.............................................62
DOCUMENTS.......................................................65
PEOPLE..........................................................76
Security Considerations.........................................86
Authors' Addresses..............................................86
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
the Internet Assigned Numbers Authority (IANA). If you are developing
a protocol or application that will require the use of a link, socket,
port, protocol, etc., please contact the IANA to receive a number
assignment.
Joyce K. Reynolds
Internet Assigned Numbers Authority
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90292-6695
Phone: (213) 822-1511
Electronic mail: JKREY@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 Internet
Protocols" [118]. The more prominent and more generally used are
documented in the "DDN Protocol Handbook, Volume Two, DARPA Internet
Protocols" [45] prepared by the NIC. Other collections of older or
obsolete protocols are contained in the "Internet Protocol Transition
Workbook" [76], or in the "ARPANET Protocol Transition Handbook"
[47]. For further information on ordering the complete 1985 DDN
Protocol Handbook, write: SRI International (SRI-NIC), DDN Network
Information Center, Room EJ291, 333 Ravenswood Avenue, Menlo Park,
CA., 94025; or call: 1-800-235-3155. Also, the Internet Activities
Board (IAB) publishes the "IAB Official Protocol Standards" [62],
which describes the state of standardization of protocols used in the
Internet. This document is issued quarterly. Current copies may be
obtained from the DDN Network Information Center or from the IANA.
In the entries below, the name and mailbox of the responsible
Reynolds & Postel [Page 2]

RFC 1060 Assigned Numbers March 1990
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.
Data Notations
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian" order
[21]. 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 3]

RFC 1060 Assigned Numbers March 1990
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.
Special Addresses:
There are five classes of IP addresses: Class A through Class E
[119]. Of these, Class D and Class E addresses are reserved for
experimental use. A gateway which is not participating in these
experiments must ignore all datagrams with a Class D or Class E
destination IP address. ICMP Destination Unreachable or ICMP
Redirect messages must not result from receiving such datagrams.
There are certain special cases for IP addresses [11]. These special
cases can be concisely summarized using the earlier notation for an
IP address:
IP-address ::= { <Network-number>, <Host-number> }
or
IP-address ::= { <Network-number>, <Subnet-number>,
<Host-number> }
if we also use the notation "-1" to mean the field contains all 1
bits. Some common special cases are as follows:
(a) {0, 0}
This host on this network. Can only be used as a source
address (see note later).
(b) {0, <Host-number>}
Specified host on this network. Can only be used as a
source address.
(c) { -1, -1}
Limited broadcast. Can only be used as a destination
address, and a datagram with this address must never be
forwarded outside the (sub-)net of the source.
(d) {<Network-number>, -1}
Directed broadcast to specified network. Can only be used
as a destination address.
Reynolds & Postel [Page 4]

RFC 1060 Assigned Numbers March 1990
(e) {<Network-number>, <Subnet-number>, -1}
Directed broadcast to specified subnet. Can only be used as
a destination address.
(f) {<Network-number>, -1, -1}
Directed broadcast to all subnets of specified subnetted
network. Can only be used as a destination address.
(g) {127, <any>}
Internal host loopback address. Should never appear outside
a host.
Reynolds & Postel [Page 5]

RFC 1060 Assigned Numbers March 1990
IP TOS PARAMETERS
This documents the default Type-of-Service values that are currently
recommended for the most important Internet protocols.
There are three binary TOS attributes: low delay, high throughput,
and high reliability; in each case, an attribute bit is turned on to
indicate "better". The three attributes cannot all be optimized
simultanously, and in fact the TOS algorithms that have been
discussed tend to make "better" values of the attributes mutually
exclusive. Therefore, the recommended values have at most one bit
on.
Generally, protocols which are involved in direct interaction with a
human should select low delay, while data transfers which may involve
large blocks of data are need high throughput. Finally, high
reliability is most important for datagram-based Internet management
functions.
Application protocols not included in these tables should be able to
make appropriate choice of low delay (1 0 0) or high throughput (0 1
0).
The following are recommended values for TOS:
----- Type-of-Service Value -----
Low High High
Protocol Delay Throughput Reliability
TELNET (1) 1 0 0
FTP
Control 1 0 0
Data (2) 0 1 0
TFTP 1 0 0
SMTP (3)
Cmd phase 1 0 0
DATA phase 0 1 0
Domain Name Service
UDP Query 1 0 0
TCP Query 0 0 0
Zone Tnsfr 0 1 0
NNTP 0 0 0
Reynolds & Postel [Page 21]

RFC 1060 Assigned Numbers March 1990
ARPANET AND MILNET LOGICAL ADDRESSES
The ARPANET facility for "logical addressing" is described in RFC-878
[57] and RFC-1005 [109]. A portion of the possible logical addresses
are reserved for standard uses.
There are 49,152 possible logical host addresses. Of these, 256 are
reserved for assignment to well-known functions. Assignments for
well-known functions are made by the IANA. Assignments for other
logical host addresses are made by the NIC.
Logical Address Assignments:
Decimal Description References
------- ----------- ----------
0 Reserved [JBP]
1 The BBN Core Gateways [MB]
2-254 Unassigned [JBP]
255 Reserved [JBP]
Reynolds & Postel [Page 30]

RFC 1060 Assigned Numbers March 1990
ARPANET AND MILNET 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 [2].
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-63 BBNCC Monitoring [MB]
64-149 Unassigned [JBP]
150 Xerox NS IDP [133,XEROX]
151 Unassigned [JBP]
152 PARC Universal Protocol [8,XEROX]
153 TIP Status Reporting [JGH]
154 TIP Accounting [JGH]
155 Internet Protocol [regular] [105,JBP]
156-158 Internet Protocol [experimental] [105,JBP]
159 Figleaf Link [JBW1]
160 Blacker Local Network Protocol [DM28]
161-194 Unassigned [JBP]
195 ISO-IP [64,RXM]
196-247 Experimental Protocols [JBP]
248-255 Network Maintenance [JGH]
Reynolds & Postel [Page 31]

RFC 1060 Assigned Numbers March 1990
ARPANET AND MILNET X.25 ADDRESS MAPPINGS
All MILNET hosts are assigned addresses by the Defense Data Network
(DDN). The address of a MILNET host may be obtained from the Network
Information Center (NIC), represented as an ASCII text string in what
is called "host table format". This section describes the process by
which MILNET X.25 addresses may be derived from addresses in the NIC
host table format.
A NIC host table address consists of the ASCII text string
representations of four decimal numbers separated by periods,
corresponding to the four octeted of a thirty-two bit Internet
address. The four decimal numbers are referred to in this section as
"n", "h' "l", and "i". Thus, a host table address may be represented
as: "n.h.l.i". Each of these four numbers will have either one, two,
or three decimal digits and will never have a value greater than 255.
For example, in the host table, address: "10.2.0.124", n=10, h=2,
l=0, and i=124. To convert a host table address to a MILNET X.25
address:
1. If h < 64, the host table address corresponds to the X.25
physical address:
ZZZZ F IIIHHZZ (SS)
where:
ZZZZ = 0000 as required
F = 0 because the address is a physical address;
III is a three decimal digit respresentation of
"i", right-adjusted and padded with leading
zeros if required;
HH is a two decimal digit representation of "h",
right-adjusted and padded with leading zeros
if required;
ZZ = 00 and
(SS) is optional
In the example given above, the host table address 10.2.0.124
corresponds to the X.25 physical address 000001240200.
Reynolds & Postel [Page 32]

RFC 1060 Assigned Numbers March 1990
2. If h > 64 or h = 64, the host table address corresponds to the
X.25 logical address
ZZZZ F RRRRRZZ (SS)
where:
ZZZZ = 0000 as required
F = 1 because the address is a logical address;
RRRRR is a five decimal digit representation of
the result "r" of the calculation
r = h * 256 + i
(Note that the decimal representation of
"r" will always require five digits);
ZZ = 00 and
(SS) is optional
Thus, the host table address 10.83.0.207 corresponds to the X.25
logical address 000012145500.
In both cases, the "n" and "l" fields of the host table address are
not used.
Reynolds & Postel [Page 33]

RFC 1060 Assigned Numbers March 1990
ETHERNET VENDOR ADDRESS COMPONENTS
Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal
digits (0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the
Ethernet interface within the station) and the last/right 6 digits
which specify the interface serial number for that interface vendor.
Ethernet addresses might be written unhyphenated (e.g.,
123456789ABC), or with one hyphen (e.g., 123456-789ABC), but should
be written hyphenated by octets (e.g., 12-34-56-78-9A-BC).
These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left) will be
even, not odd.
At present, it is not clear how the IEEE assigns Ethernet block
addresses. Whether in blocks of 2**24 or 2**25, and whether
multicasts are assigned with that block or separately. A portion of
the vendor block address is reportedly assigned serially, with the
other portion intentionally assigned randomly. If there is a global
algorithm for which addresses are designated to be physical (in a
chipset) versus logical (assigned in software), or globally-assigned
versus locally-assigned addresses, some of the known addresses do not
follow the scheme (e.g., AA0003; 02xxxx).
00000C Cisco
00000F NeXT
000010 Sytek
00001D Cabletron
000020 DIAB (Data Intdustrier AB)
000022 Visual Technology
00002A TRW
00005A S & Koch
00005E IANA
000065 Network General
00006B MIPS
000077 MIPS
00007A Ardent
000089 Cayman Systems Gatorbox
000093 Proteon
00009F Ameristar Technology
0000A2 Wellfleet
0000A3 Network Application Technology
0000A6 Network General (internal assignment, not for products)
0000A7 NCD X-terminals
0000A9 Network Systems
0000AA Xerox Xerox machines
Reynolds & Postel [Page 38]