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.

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 "IAB Official Protocol Standards" [62].

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.

Reynolds & Postel [Page 2]

RFC 1340 Assigned Numbers July 1992

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.

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).

Similarly, whenever a multi-octet field represents a numeric quantity 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 1340 Assigned Numbers July 1992

Special Addresses:

There are five classes of IP addresses: Class A through Class E [119]. Of these, Class E addresses are reserved for experimental use. A gateway which is not participating in these experiments must ignore all datagrams with a 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.

(e) {<Network-number>, <Subnet-number>, -1}

Directed broadcast to specified subnet. Can only be used as a destination address.

Reynolds & Postel [Page 4]

RFC 1340 Assigned Numbers July 1992

(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 1340 Assigned Numbers July 1992

VERSION NUMBERS

In the Internet Protocol (IP) [45,105] there is a field to identify the version of the internetwork general protocol. This field is 4 bits in size.

The Well Known Ports are controlled and assigned by the IANA and on mostsystems can only be used by system (or root) processes or by programsexecuted by privileged users.

Ports are used in the TCP [45,106] to name the ends of logicalconnections which carry long term conversations. For the purpose ofproviding services to unknown callers, a service contact port isdefined. This list specifies the port used by the server process as itscontact port. The contact port is sometimes called the "well-knownport".

To the extent possible, these same port assignments are used with theUDP [46,104].

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 tothe range 0-1023.

The Registered Ports are not controlled by the IANA and on most systemscan be used by ordinary user processes or programs executed by ordinaryusers.

Ports are used in the TCP [45,106] to name the ends of logicalconnections which carry long term conversations. For the purpose ofproviding services to unknown callers, a service contact port isdefined. This list specifies the port used by the server process as itscontact port. While the IANA can not control uses of these ports itdoes register or list uses of these ports as a convienence to thecommunity.

To the extent possible, these same port assignments are used with theUDP [46,104].

Host Extensions for IP Multicasting (RFC-1112) [43] specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Current addresses are listed below.

In the normal Internet dotted decimal notation this is 0.0.94 since the bytes are transmitted higher order first and bits within bytes are transmitted lower order first (see "Data Notation" in the Introduction).

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

Reynolds & Postel [Page 29]

RFC 1340 Assigned Numbers July 1992

IP TOS PARAMETERS

This documents the default Type-of-Service values that are currently recommended for the most important Internet protocols.

There are four assigned TOS values: low delay, high throughput, high reliability, and low cost; in each case, the TOS value is used to indicate "better". Only one TOS value or property can be requested in any one IP datagram.

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 (8 decimal, 1000 binary) or high throughput (4 decimail, 0100 binary).

(3) If the implementation does not support changing the TOS during the lifetime of the connection, then the recommended TOS on opening the connection is the default TOS (0000).

(4) Although ICMP request messages are normally sent with the default TOS, there are sometimes good reasons why they would be sent with some other TOS value. An ICMP response always uses the same TOS value as was used in the corresponding ICMP request message.

An application may (at the request of the user) substitute 0001 (minimize monetary cost) for any of the above values.

Reynolds & Postel [Page 31]

RFC 1340 Assigned Numbers July 1992

IP TIME TO LIVE PARAMETER

The current recommended default time to live (TTL) for the Internet Protocol (IP) [45,105] is 64.

Reynolds & Postel [Page 32]

RFC 1340 Assigned Numbers July 1992

DOMAIN SYSTEM PARAMETERS

The Internet Domain Naming System (DOMAIN) includes several parameters. These are documented in RFC-1034, [81] and RFC-1035 [82]. The CLASS parameter is listed here. The per CLASS parameters are defined in separate RFCs as indicated.

The Bootstrap Protocol (BOOTP) RFC-951 [36] describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The BOOTP Vendor Information Extensions RFC-1084 [117] describes an addition to the Bootstrap Protocol (BOOTP).

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) RFC-1157 [15], or the "Common Management Information Protocol over TCP" (CMOT) [142].

The data structure is the "Structure and Indentification of Management Information for TCP/IP-based Internets" (SMI) RFC-1155 [120], and the "Management Information Base for Network Management of TCP/IP-based Internets" (MIB-II) [121].

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) RFC-1028 [37] also defined a data structure. The parameter assignments used with SGMP are included here for hist orical 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 MILNET 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.

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 [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.

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:

In both cases, the "n" and "l" fields of the host table address are not used.

Reynolds & Postel [Page 52]

RFC 1340 Assigned Numbers July 1992

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 MILNET uses the "link" field. Further, there is an 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.

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 send DoD-IP datagrams and other IP related protocols (such as the Address Resolution Protocol (ARP)) on 802 networks was developed, using the SNAP extension (see RFC-1042 [90]).

Reynolds & Postel [Page 53]

RFC 1340 Assigned Numbers July 1992

ETHERNET NUMBERS OF INTEREST

Many of the networks of all classes are Ethernets (10Mb) or Experimental Ethernets (3Mb). These systems use a message "type" field in much the same way the ARPANET uses the "link" field.

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).

Below are two tables describing the arrangement of protocol fields or type field assignments so that one could send NS Datagrams on the MILNET or Internet Datagrams on 10Mb Ethernet, and also protocol and type fields so one could encapsulate each kind of Datagram in the other.

The Point-to-Point Protocol (PPP) Data Link Layer [146,147,175] contains a 16 bit Protocol field to identify the the encapsulated protocol. The Protocol field is consistent with the ISO 3309 (HDLC) extension mechanism for Address fields. All Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0", and the least significant bit of the least significant octet equals "1".

Protocol field values in the "0---" to "3---" range identify the network-layer protocol of specific datagrams, and values in the "8-- -" to "b---" range identify datagrams belonging to the associated Network Control Protocol (NCP), if any.

It is recommended that values in the "02--" to "1e--" and "--01" to "--1f" ranges not be assigned, as they are compression inefficient.

Protocol field values in the "4---" to "7---" range are used for protocols with low volume traffic which have no associated NCP.

Protocol field values in the "c---" to "e---" range identify datagrams as Control Protocols (such as LCP).

PPP LCP AND IPCP CODES

The Point-to-Point Protocol (PPP) Link Control Protocol (LCP) [146] and Internet Protocol Control Protocol (IPCP) [147] contain an 8 bit Code field which identifies the type of packet. These Codes are assigned as follows:

The Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) specifies a number of Configuration Options [147] which are distinguished by an 8 bit Type field. These Types are assigned as follows:

CCITT defines the high order two bits of the first octet of call user data as follows:

00 - Used for other CCITT recomendations (such as X.29) 01 - Reserved for use by "national" administrative authorities 10 - Reserved for use by international administrative authoorities 11 - Reserved for arbitrary use between consenting DTEs

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 inRFC-952 [53].

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.

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 RFC-952 [53].

A system name may be up to 40 characters taken from the set of upper- case letters, digits, and the three punctuation characters hyphen, period, and slash. It must start with a letter, and end with a letter or digit.

These are the Official Terminal Type Names. Their use is described inRFC-930 [128]. The maximum length of a name is 40 characters.

A terminal names may be up to 40 characters taken from the set of upper-case letters, digits, and the two punctuation characters hyphen andslash. It must start with a letter, and end with a letter or digit.