Network Working Group J. Reynolds
Request for Comments: 1700 J. Postel
STD: 2 ISI
Obsoletes RFCs: 1340, 1060, 1010, 990, 960, October 1994
943, 923, 900, 870, 820, 790, 776, 770,
762, 758,755, 750, 739, 604, 503, 433, 349
Obsoletes IENs: 127, 117, 93
Category: Standards Track
ASSIGNED NUMBERS
Status of this Memo
This memo is a status report on the parameters (i.e., numbers and
keywords) used in protocols in the Internet community. Distribution
of this memo is unlimited.
OVERVIEW
This RFC is a snapshot of the ongoing process of the assignment of
protocol parameters for the Internet protocol suite. To make the
current information readily available the assignments are kept up-to-
date in a set of online text files. This RFC has been assembled by
catinating these files together with a minimum of formatting "glue".
The authors appologize for the somewhat rougher formatting and style
than is typical of most RFCs.
We expect that various readers will notice specific items that should be
corrected. Please send any specific corrections via email to
<iana@isi.edu>.
Reynolds & Postel [Page 1]

RFC 1700 Assigned Numbers October 1994
INTRODUCTION
The files in this directory document the currently assigned values for
several series of numbers used in network protocol implementations.
ftp://ftp.isi.edu/in-notes/iana/assignments
The Internet Assigned Numbers Authority (IANA) is the central
coordinator for the assignment of unique parameter values for Internet
protocols. The IANA is chartered by the Internet Society (ISOC) and
the Federal Network Council (FNC) to act as the clearinghouse to
assign and coordinate the use of numerous Internet protocol
parameters.
The Internet protocol suite, as defined by the Internet Engineering
Task Force (IETF) and its steering group (the IESG), contains numerous
parameters, such as internet addresses, domain names, autonomous
system numbers (used in some routing protocols), protocol numbers,
port numbers, management information base object identifiers,
including private enterprise numbers, and many others.
The common use of the Internet protocols by the Internet community
requires that the particular values used in these parameter fields be
assigned uniquely. It is the task of the IANA to make those unique
assignments as requested and to maintain a registry of the currently
assigned values.
Requests for parameter assignments (protocols, ports, etc.) should be
sent to <iana@isi.edu>.
Requests for SNMP network management private enterprise number
assignments should be sent to <iana-mib@isi.edu>.
The IANA is located at and operated by the Information Sciences
Institute (ISI) of the University of Southern California (USC).
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
Electronic mail: IANA@ISI.EDU
Phone: +1 310-822-1511
Reynolds & Postel [Page 2]

RFC 1700 Assigned Numbers October 1994
Most of the protocols 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, "Internet Official Protocol
Standards" (STD 1).
Data Notations
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian" order
[COHEN]. 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
the left most bit of the whole field is the most significant bit. When
Reynolds & Postel [Page 3]

RFC 1700 Assigned Numbers October 1994
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. Of
these, Classes A, B, and C are used for unicast addresses, Class D is
used for multicast addresses, and Class E addresses are reserved for
future use.
With the advent of classless addressing [CIDR1, CIDR2], the
network-number part of an address may be of any length, and the whole
notion of address classes becomes less important.
There are certain special cases for IP addresses. 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 1700 Assigned Numbers October 1994
WELL KNOWN PORT NUMBERS
The Well Known Ports are controlled and assigned by the IANA and on
most systems can only be used by system (or root) processes or by
programs executed by privileged users.
Ports are used in the TCP [RFC793] to name the ends of logical
connections which carry long term conversations. For the purpose of
providing services to unknown callers, a service contact port is
defined. This list specifies the port used by the server process as
its contact port. The contact port is sometimes called the
"well-known port".
To the extent possible, these same port assignments are used with the
UDP [RFC768].
The assigned ports use a small portion of the possible port numbers.
For many years the assigned ports were in the range 0-255. Recently,
the range for assigned ports managed by the IANA has been expanded to
the range 0-1023.
Port Assignments:
Keyword Decimal Description References
------- ------- ----------- ----------
0/tcp Reserved
0/udp Reserved
# Jon Postel <postel@isi.edu>
tcpmux 1/tcp TCP Port Service Multiplexer
tcpmux 1/udp TCP Port Service Multiplexer
# Mark Lottor <MKL@nisc.sri.com>
compressnet 2/tcp Management Utility
compressnet 2/udp Management Utility
compressnet 3/tcp Compression Process
compressnet 3/udp Compression Process
# Bernie Volz <VOLZ@PROCESS.COM>
# 4/tcp Unassigned
# 4/udp Unassigned
rje 5/tcp Remote Job Entry
rje 5/udp Remote Job Entry
# Jon Postel <postel@isi.edu>
# 6/tcp Unassigned
# 6/udp Unassigned
echo 7/tcp Echo
echo 7/udp Echo
# Jon Postel <postel@isi.edu>
# 8/tcp Unassigned
Reynolds & Postel [Page 16]

RFC 1700 Assigned Numbers October 1994
SUN RPC NUMBERS
To obtain SUN Remote Procedure Call (RPC) numbers send an e-mail
request to "rpc@sun.com".
The RPC port management service ('portmap' in SunOS versions less than
5.0 and 'rpcbind' in SunOS versions greater than 5.0) "registers" the
IP port number that is allocated to a particular service when that
service is created. It does not allocate ports on behalf of those
services.
For an exact specification of the semantics refer to the source code
of svcudp_create() and svctcp_create() in the archives. In short
however is that these interfaces, and svc_tli_create their Transport
Independent RPC equivalent, take either a user specified port number
or RPC_ANY (-1) which effectively means "I don't care." In the "I
don't care" case the create code simply calls socket(2) or t_open(3n)
which allocates an IP port based on the rules:
if euid of the requesting process is 0 (i.e., root)
allocate the next available port number in the
reserved port range.
else
allocate the next available port in the non-reserved
range.
Port numbers count up sequentially.
Can a port that is "assigned" can be used when the assignee's service
is not present? Say port 501 is assigned to the "jeans" service. On
a machine that does not have the "jeans" service, nor has any clients
that might be expecting to use it, is port 501 available for other
uses? Any dynamic allocation process, like the portmapper, that
chooses the next unused port might allocate port 501 dynamically to a
process that asked for a "I don't care" port. So any dynamic
allocation scheme may pick an unused port that happened to correspond
to a port number that had been "assigned" but was currently unused.
While it might be desirable, it is impossible to guarantee that any
unused port, even though officially assigned to a service, is not
picked by a dynamic allocator since such an assignment might occur
long after the delivery of the system into a site that doesn't watch
for the latest list.
There is the restriction that only "superuser" on BSD derived systems
such as SunOS can bind to a port number that is less than 1024. So
programs have used this information in the past to identify whether or
Reynolds & Postel [Page 61]

RFC 1700 Assigned Numbers October 1994
not the service they were talking to was started by the superuser on
the remote system. Making this assumption is dangerous because not
all system enforce this restriction.
Sun RPC services use ports that are currently unused. If someone
noted that an RPC service was using port 781, it would be just as
happy using port 891, or 951. The service doesn't care what port it
gets, remote clients will query the portmapper to ask it what port
number was assigned to the service when it was started. The key is
that the port was not currently in use. The only port that ONC/RPC
must have is 111 its assigned port for the portmap service.
The most common complaint comes when people put a new service on their
system. When they configure their systems they put the new service
configuration commands at the end of their system startup scripts.
During startup, several network services may be started. Those
services that are ONC/RPC based just pick the next available port,
those that have pre-assigned ports bind to their pre-assigned port.
Clearly the correct sequence is to have all services that need a
particular port to be started first (or if they are "latent" services
that are started by inetd, to have inetd started). Finally, the RPC
services should be started as they will be assigned unused ports. (In
the BSD networking code (which we use) the algorithm for picking
ports is in the file in_pcb.c, function in_pcbbind().)
Services should be started in this order:
a) Services that will "run" continuously and have an assigned
port. Note that this includes rpcbind (nee portmap) that has
port 111 assigned to it.
b) inetd - which will automatically create sockets for those
services that have reserved ports but only run on demand
(like finger)
c) RPC services - which will automatically pick unused ports and
maximize efficiency of the "IP Port" namespace.
The include file /usr/include/netinet/in.h defines a constant
IPPORT_RESERVED to be 1024. The relevant text is:
/*
* Ports < IPPORT_RESERVED are reserved for
* privileged processes (e.g. root).
* Ports > IPPORT_USERRESERVED are reserved
* for servers, not necessarily privileged.
*/
#define IPPORT_RESERVED 1024
Reynolds & Postel [Page 62]

RFC 1700 Assigned Numbers October 1994
#define IPPORT_USERRESERVED 5000
Portmap does not allocate ports, the kernel allocates ports. The code
that does this is part of nearly every UNIX system in the world (and
since the BSD code is 'free' it is often the same code). RPC services
ask the kernel to allocate them a port by calling the "bind()" system
call. The parameter they pass is "INADDR_ANY" which means "allocate
me any IP port you want". The kernel does that by looking at all of
the ports that are currently in use and picking one that is not
currently used. The number picked is either less that 1024 if the
process is privledged, or greater than 1024 if the process is not
privledged. After the kernel has allocated a port, the service
registers this allocation with portmap. The portmapper is merely a
registry of previously allocated ports. Note "allocated" here is
being used in the sense that they are used by an open socket, not
assigned a well known name.
The role of /etc/services is to provide an idea to people who are
looking at network traffic as to where a packet may have originated
from or is headed to. For services like finger that have assigned
ports, they can just hard code the port they want into their
executable. (it isn't like it will change, and if they read it from
/etc/services and someone had mistyped the port number it won't
interoperate with clients anyway!)
It is not practical to read the /etc/services file into the kernel to
prevent it from giving out port numbers that are "pre-assigned", nor
is it generally desirable since with the correct ordering of startup
it is completely unneccesary.
Editors Note: This information was supplied by Chuck McManis of Sun.
[]
URL = ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbersReynolds & Postel [Page 63]

RFC 1700 Assigned Numbers October 1994
------------ -------------------------------- ---------
SEND Send as mail [RFC821]
SOML Send as mail or terminal [RFC821]
SAML Send as mail and terminal [RFC821]
EXPN Expand the mailing list [RFC821]
HELP Supply helpful information [RFC821]
TURN Turn the operation around [RFC821]
8BITMIME Use 8-bit data [RFC1652]
SIZE Message size declaration [RFC1653]
VERB Verbose [Eric Allman]
ONEX One message transaction only [Eric Allman]
MAIL EXTENSION TYPES
The Simple Mail Transfer Protocol [RFC821] specifies a set of
commands or services for mail transfer. A general procedure for
extending the set of services is defined in [RFC1651]. The set of
service extensions is listed here.
Service Ext EHLO Keyword Parameters Verb Reference
----------- ------------ ---------- ---------- ---------
Send SEND none SEND [RFC821]
Send or Mail SOML none SOML [RFC821]
Send and Mail SAML none SAML [RFC821]
Expand EXPN none EXPN [RFC821]
Help HELP none HELP [RFC821]
Turn TURN none TURN [RFC821]
8 Bit MIME 8BITMIME none none [RFC1652]
Size SIZE number none [RFC1653]
MAIL SYSTEM NAMES
In some places, an identification of other mail systems is used.
One of these is in "The COSINE and Internet X.500 Schema" (section
9.3.18) [RFC1274]. The mail system names listed here are used as the
legal values in that schema under the "otherMailbox" attribute
"mailboxType" type (which must be a PrintableString).
Another place is in "Mapping between X.400(1988) / ISO 10021 and RFC
822" (section 4.2.2) [RFC1327]. The names listed here are used as
Reynolds & Postel [Page 84]

RFC 1700 Assigned Numbers October 1994
the legal values in that schema under the "std-or-address" attribute
"registered-dd-type" type (which must be a "key-string").
Note that key-string = <a-z, A-Z, 0-9, and "-" >.
Mail System Name Description Reference
---------------- ------------------------------- ---------
mcimail MCI Mail
MAIL TRANSMISSION TYPES
The Simple Mail Transfer Protocol [RFC821] and the Standard for the
Format of ARPA Internet Text Messages [RFC822] specify that a set of
"Received" lines will be prepended to the headers of electronic mail
messages as they are transported through the Internet. These received
line may optionally include either or both a "via" phrase and/or a
"with" phrase. The legal values for the phrases are listed here. The
via phrase is intended to indicate the link or physical medium over
which the message was transferred. The with phrase is intended to
indicate the protocol or logical process that was used to transfer the
message.
VIA link types Description Reference
-------------- ---------------------------- ---------
UUCP Unix-to-Unix Copy Program [???]
WITH protocol types Description Reference
------------------- ---------------------------- ---------
SMTP Simple Mail Transfer Protocol [RFC821]
ESMTP SMTP with Service Extensions [RFC1651]
REFERENCES
[ANSI-X12]
[POSTSCRIPT] Adobe Systems Inc., "PostScript Langpuage Reference
Manual", 2nd Edition, 2nd Printing, January 1991.
[IS-10646]
Reynolds & Postel [Page 85]

RFC 1700 Assigned Numbers October 1994
CHARACTER SETS
These are the official names for character sets that may be used in
the Internet and may be referred to in Internet documentation. These
names are expressed in ANSI_X3.4-1968 which is commonly called
US-ASCII or simply ASCII. The character set most commonly use in the
Internet and used especially in protocol standards is US-ASCII, this
is strongly encouraged. The use of the name US-ASCII is also
encouraged.
The character set names may be up to 40 characters taken from the
printable characters of US-ASCII. However, no distinction is made
between use of upper and lower case letters.
Character Set Reference
------------- ---------
Name: ANSI_X3.4-1968 [RFC1345,KXS2]
Source: ECMA registry
Alias: iso-ir-6
Alias: ANSI_X3.4-1986
Alias: ISO_646.irv:1991
Alias: ASCII
Alias: ISO646-US
Alias: US-ASCII
Alias: us
Alias: IBM367
Alias: cp367
Name: ISO-10646-UCS-2
Source: the 2-octet Basic Multilingual Plane, aka Unicode
this needs to specify network byte order: the standard
does not specify (it is a 16-bit integer space)
Name: ISO-10646-UCS-4
Source: the full code space. (same comment about byte order,
these are 31-bit numbers.
Name: ISO-10646-UTF-1
Source: Universal Transfer Format (1), this is the multibyte
encoding, that subsets ASCII-7. It does not have byte
ordering issues.
Name: ISO_646.basic:1983 [RFC1345,KXS2]
Source: ECMA registry
Alias: ref
Reynolds & Postel [Page 101]

RFC 1700 Assigned Numbers October 1994
NETWORK MANAGEMENT PARAMETERS
For the management of hosts and gateways on the Internet a data
structure for the information has been defined. This data structure
should be used with any of several possible management protocols, such
as the "Simple Network Management Protocol" (SNMP) [RFC1157], or the
"Common Management Information Protocol over TCP" (CMOT) [RFC1095].
The data structure is the "Structure and Indentification of Management
Information for TCP/IP-based Internets" (SMI) [RFC1155], and the
"Management Information Base for Network Management of TCP/IP-based
Internets" (MIB-II) [RFC1213].
The SMI includes the provision for panrameters or codes to indicate
experimental or private data structures. These parameter assignments
are listed here.
The older "Simple Gateway Monitoring Protocol" (SGMP) [RFC1028] also
defined a data structure. The parameter assignments used with SGMP
are included here for historical completeness.
The network management object identifiers are under the iso (1), org
(3), dod (6), internet (1), or 1.3.6.1, branch of the name space.
The major branches are:
1 iso1.3 org1.3.6 dod1.3.6.1 internet1.3.6.1.1 directory1.3.6.1.2 mgmt1.3.6.1.2.1 mib-21.3.6.1.2.1.2.2.1.3 ifType1.3.6.1.2.1.10 transmission1.3.6.1.2.1.10.23 transmission.ppp1.3.6.1.2.1.27 application1.3.6.1.2.1.28 mta1.3.6.1.3 experimental1.3.6.1.4 private1.3.6.1.4.1 enterprise1.3.6.1.5 security1.3.6.1.6 SNMPv21.3.6.1.7 mail
SMI Network Management Directory Codes:
Prefix: iso.org.dod.internet.directory (1.3.6.1.1.)
Reynolds & Postel [Page 119]

RFC 1700 Assigned Numbers October 1994
-- OIDs of the form {applTCPProtoID port} are intended to be used
-- for TCP-based protocols that don't have OIDs assigned by other
-- means. {applUDPProtoID port} serves the same purpose for
-- UDP-based protocols. In either case 'port' corresponds to
-- the primary port number being used by the protocol. For example,
-- assuming no other OID is assigned for SMTP, an OID of
-- {applTCPProtoID 25} could be used, since SMTP is a TCP-based
-- protocol that uses port 25 as its primary port.
Prefix: iso.org.dod.internet.mgmt.mib-2.mta (1.3.6.1.2.1.28)
(1.3.6.1.2.1.28.2.1.24)
mtaGroupMailProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An identification of the protocol being used by this group.
For an group employing OSI protocols, this will be the
Application Context. For Internet applications, the IANA
maintains a registry of the OIDs which correspond to
well-known message transfer protocols. If the application
protocol is not listed in the registry, an OID value of the
form {applTCPProtoID port} or {applUDProtoID port} are used
for TCP-based and UDP-based protocols, respectively. In
either case 'port' corresponds to the primary port number
being used by the group. applTCPProtoID and applUDPProtoID
are defined in [5]."
::= {mtaGroupEntry 24}
Decimal Name Description
------- ---- -----------
0 Reserved
SMI Network Management Experimental Codes:
Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.)
Decimal Name Description References
------- ---- ----------- ----------
0 Reserved [JKR1]
1 CLNS ISO CLNS Objects [GS2]
* 2 T1-Carrier T1 Carrier Objects [FB77]
* 3 IEEE802.3 Ethernet-like Objects [JXC]
* 4 IEEE802.5 Token Ring-like Objects [EXD]
* 5 DECNet-PHIV DECNet Phase IV [JXS2]
* 6 Interface Generic Interface Objects [KZM]
Reynolds & Postel [Page 124]

RFC 1700 Assigned Numbers October 1994
1 = Assigned by IANA for other uses
The latter representation corresponds to the Internet standard
bit-order, and is the format that most programmers have to deal with.
Using this representation, the range of Internet Multicast addresses
is:
01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF in hex, or
1.0.94.0.0.0 to 1.0.94.127.255.255 in dotted decimal
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
00000E Fujitsu
00000F NeXT
000010 Sytek
00001D Cabletron
000020 DIAB (Data Intdustrier AB)000022 Visual Technology
00002A TRW
Reynolds & Postel [Page 173]

RFC 1700 Assigned Numbers October 1994
MILNET LINK NUMBERS
The word "link" here refers to a field in the original MILNET 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 [BBN1822].
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 [ETHERNET,XEROX]
151 Unassigned [JBP]
152 PARC Universal Protocol [PUP,XEROX]
153 TIP Status Reporting [JGH]
154 TIP Accounting [JGH]
155 Internet Protocol [regular] [RFC791,JBP]
156-158 Internet Protocol [experimental] [RFC791,JBP]
159 Figleaf Link [JBW1]
160 Blacker Local Network Protocol [DM28]
161-194 Unassigned [JBP]
195 ISO-IP [RFC926,RXM]
196-247 Experimental Protocols [JBP]
248-255 Network Maintenance [JGH]
MILNET LOGICAL ADDRESSES
The MILNET facility for "logical addressing" is described in [RFC878]
and [RFC1005]. 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
Reynolds & Postel [Page 186]

RFC 1700 Assigned Numbers October 1994
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]
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
Reynolds & Postel [Page 187]

RFC 1700 Assigned Numbers October 1994
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.
2. If h > 64 or h = 64, the host table address corresponds to theX.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.
REFERENCES
[BBN1822] BBN, "Specifications for the Interconnection of a Host and
Reynolds & Postel [Page 188]

RFC 1700 Assigned Numbers October 1994
MACHINE NAMES
These are the Official Machine Names as they appear in the Domain Name
System HINFO records and the NIC Host Table. Their use is described
in [RFC952].
A 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.
AMIGA-500
AMIGA-500/010
AMIGA-500/020
AMIGA-500/EC030
AMIGA-500/030
AMIGA-600
AMIGA-1000
AMIGA-1000/010
AMIGA-1000/020
AMIGA-1000/EC030
AMIGA-1000/030
AMIGA-1200
AMIGA-1200/EC030
AMIGA-1200/030
AMIGA-1200/EC040
AMIGA-1200/LC040
AMIGA-1200/040
AMIGA-2000
AMIGA-2000/010
AMIGA-2000/020
AMIGA-2000/EC030
AMIGA-2000/030
AMIGA-2000/LC040
AMIGA-2000/EC040
AMIGA-2000/040
AMIGA-3000
AMIGA-3000/EC040
AMIGA-3000/LC040
AMIGA-3000/040
AMIGA-3000/060
AMIGA-4000/EC030
AMIGA-4000/030
AMIGA-4000/LC040
AMIGA-4000/040
AMIGA-4000/060
ALTO
Reynolds & Postel [Page 207]

RFC 1700 Assigned Numbers October 1994
OPERATING SYSTEM NAMES
These are the Official System Names as they appear in the Domain Name
System HINFO records and the NIC Host Table. Their use is described in
[RFC952].
A system name may be up to 40 characters taken from the set of
uppercase letters, digits, and the three punctuation characters
hyphen, period, and slash. It must start with a letter, and end with
a letter or digit.
AEGIS
AMIGA-OS-1.2
AMIGA-OS-1.3
AMIGA-OS-2.0
AMIGA-OS-2.1
AMIGA-OS-3.0
AMIGA-OS-3.1
APOLLO
AIX/370
AIX-PS/2
BS-2000
CEDAR
CGW
CHORUS
CHRYSALIS
CMOS
CMS
COS
CPIX
CTOS
CTSS
DCN
DDNOS
DOMAIN
DOS
EDX
ELF
EMBOS
EMMOS
EPOS
FOONEX
FORTH
FUZZ
GCOS
GPOS
Reynolds & Postel [Page 215]

RFC 1700 Assigned Numbers October 1994
TERMINAL TYPE NAMES
These are the Official Terminal Type Names. Their use is described in
[RFC930]. The maximum length of a name is 40 characters.
A terminal 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
ADDS-VIEWPOINT
ADDS-VIEWPOINT-60
AED-512
AMPEX-DIALOGUE-210
AMPEX-DIALOGUE-80
AMPEX-210
AMPEX-230
ANDERSON-JACOBSON-510
ANDERSON-JACOBSON-630
ANDERSON-JACOBSON-832
ANDERSON-JACOBSON-841
ANN-ARBOR-AMBASSADOR
ANSI
ARDS
BITGRAPH
BUSSIPLEXER
CALCOMP-565
CDC-456
CDI-1030
CDI-1203
C-ITOH-101
C-ITOH-50
C-ITOH-80
CLNZ
COMPUCOLOR-II
CONCEPT-100
CONCEPT-104
CONCEPT-108
DATA-100
Reynolds & Postel [Page 219]