[DECnet] LAN Address and Protocol Registry Last Technical Review: 15-OCT-1991 Size: 587 lines COPYRIGHT (c) 1988, 1989, 1990 by Digital Equipment Corporation. ALL RIGHTS RESERVED. No distribution except as provided under contract. PRODUCT: DECnet[TM] Digital Network Architecture LAST TECHNICAL REVIEW: 15-OCT-1991 SOURCE: Customer Support Center / USA SUBJECT: LAN Address and protocol registry This registry information is from the Distributed Systems Architecture group. PREFACE: iii This is the Digital registry of LAN addresses, multicast addresses, Ethernet protocol types, IEEE 802.2 SAPs, and IEEE Protocol IDs, and FDDI Extended Service Frame IDs. Address and protocol assignments used in Digital products under development are shown here. Such assignments will be included in revisions of this document as products are released. All address, protocol type, and protocol ID values in ranges assigned to Digital that are not shown as assigned in this document are reserved for future use and may be assigned at a later time. Chapter 1 Introduction This is the Digital registry of LAN addresses, multicast addresses, Ethernet protocol types, IEEE 802.2 SAPs, and IEEE Protocol IDs, and FDDI Extended Service Frame IDs. The values shown here apply to all LAN types that conform to the IEEE general structure, i.e., IEEE 802.3 (CSMA/CD), including Ethernet), 802.4 (Token Bus), 802.5 (Token Ring) and ANSI FDDI. For more information about these, refer to the applicable standards documents: o IEEE 802 - LAN Overview and Architecture o IEEE 802.2 - Logical Link Control (ISBN 471-82748-7) o IEEE 802.3 - CSMA/CD: Carrier Sense Multiple Access with Collison Detection (ISBN 471-82749-5) o The Ethernet - A Local Area Network - Version 2.0 (DIGITAL order number AA-K759B-TK) o IEEE 802.4 - Token-passing Bus (ISBN 471-82750-9) o IEEE 802.5 - Token Ring o ANSI X3.139-1987 - Fiber Distributed Data Interface (FDDI) - Token ring media access control (MAC) o ANSI X3T9.5/84-49 Rev. 6.2 - Fiber Distributed Data Interface (FDDI) - Station Management (SMT) 1.1 Notation canonical form The order of transmission of bits within each byte differs for various LANs: for IEEE 802.3 and 802.4, the least significant bit is transmitted first; for IEEE 802.5 and FDDI, the most significant bit is transmitted first.* This transmission order applies to all date "after" the MAC header; in particular it applies to the SAP and Protocol ID fields. The destination Address and Source Address fields in the MAC are treated differently: these are viewed as bitstrings where the first bit transmitted is always the Multicast bit. * More precisely, in FDDI the most significant 4 bits of the byte are trans- mitted first; FDDI uses an encoding scheme in which transmission occurs in 4-bit units. Clearly this combination of two different rules and the variety of transmis- sion order can lead to confusion in the use of address value assignments. To reduce this problem, IEEE has defined (in IEEE 802.1A - Overview and Archi- tecture) the "canonical" representation for addresses and other values. All values given in the registry are written in canonical form. The canonical form is written as a sequence of hexidecimal byte values sep- arated by hyphens. The byte transmission order is from left to right. The bits within each byte are interpreted as follows: o For MAC addresses, the first bit transmitted (i.e., in the first byte, the Multicast bit) is written as the Least Significant Bit of the can- onical form. o For all other values (i.e., SAP and Protocol ID), the Least Significant Bit of the value is written as the Least Significant Bit of the canonical form. An example of a canonical form MAC address, and its interpretation for vari- ous LANs, is shown below. In this example, the IEEE 802.x line shows the bits as transmitted (left to right) in the MAC header address fields. For the FDDI, it shows the FDDI PHY symbols as transmitted (left to right). Canonical: AC-DE-48-00-00-80 IEEE 802.x: 00110101 01111011 00010010 00000000 00000000 00000001 FDDI: 3 5 7 B 1 2 0 0 0 0 0 1 The second example shows a Protocol ID from a SNAP frame. As before the IEEE 802.x lines show the bits as transmitted (left to right) and the FDDI line he symbols as transmitted (left to right). Canonical: AC-DE-48-00-80 IEEE 802.3: 00110101 01111011 00010010 00000000 00000001 IEEE 802.4: 00110101 01111011 00010010 00000000 00000001 IEEE 802.5: 10101100 11011110 01001000 00000000 10000000 FDDI: A C D E 4 8 0 0 8 0 Implementors developing IEEE 802.5 or FDDI products should carefully study these rules, and the details given in IEEE 802.2A, to ensure that addresses, SAP values, and Protocol IDs are used correctly. Chapter 2 Addresses DIGITAL currently adheres to the following individual and multicast address assignments. 2.1 Cross-company, globally defined Assignments Last revision date: 18 January 1991 The cross-company multicast addresses are: 01-80-C2-00-00-00 IEEE 802.1d Bridge group address 01-80-C2-00-00-0x IEEE 802.1d Reserved (always filtered by bridges) 01-80-C2-00-00-10 IEEE 802.1d All LANs Bridge Management group address 01-80-C2-00-00-11 IEEE 802.1e Load Server group address 01-80-C2-00-00-12 IEEE 802.1e Loadable Device group address 01-80-C2-00-00-14 ISO IS-IS (ISO DP 10589) All Level 1 Intermediate System Network Entities 01-80-C2-00-00-15 ISO IS-IS (ISO DP 10589) All Level 2 Intermediate System Network Entities 01-80-C2-00-00-16 ISO 10030 - All CONS End Systems 01-80-C2-00-00-17 ISO 10030 - All CONS SNAREs 01-80-C2-00-01-00 ANSI FDDI SMT - RMT directed beacon group address 01-80-C2-00-01-10 ANSI FDDI SMT - Status Report Frame group address 01-80-C2-00-01-20 ANSI FDDI SMT - All Root Concentrator MACs 09-00-2B-00-00-04 ISO 9542 All End-system Network Entities 09-00-2B-00-00-05 ISO 9542 All Intermediate System Network Entities CF-00-00-00-00-00 Loopback Assistance FF-FF-FF-FF-FF-FF Broadcast 2.2 Received from Xerox/IEEE Last revision date: 1 May 1989 The following address blocks have been assigned to DIGITAL from Xerox and IEEE address administration. AA-00-00-xx-xx-xx AA-00-01-xx-xx-xx AA-00-02-xx-xx-xx AA-00-03-xx-xx-xx AA-00-04-xx-xx-xx 08-00-2B-xx-xx-xx 00-00-F8-xx-xx-xx 2.2.1 Obsolete Assignments by Xerox Last revision date: November 25, 1985 The following address blocks previously assigned to DIGITAL by Xerox fall into the Locally Administered Address space according to IEEE 802 standard. No new assignments will be made in this space. AA-00-00-xx-xx-xx AA-00-01-xx-xx-xx AA-00-02-xx-xx-xx AA-00-03-xx-xx-xx AA-00-04-xx-xx-xx 2.2.2 Multicast addresses assigned by DIGITAL Last revision date: 15 October 1991 The current DIGITAL multicast address assignments are: AB-00-00-01-00-00 DNA Dump/Load Assistance (MOP) AB-00-00-02-00-00 DNA Remote Console (MOP) AB-00-00-03-00-00 DNA Level 1 Routing Layer routers AB-00-00-04-00-00 DNA Routing Layer end nodes AB-00-04-00-xx-xx Customer use AB-00-04-01-xx-xx System Communication Architecture (SCA) 09-00-2B-00-00-02 VAXELN 09-00-2B-00-00-03 LAN Traffic Monitor 09-00-2B-00-00-06 CSMA/CD Encryption 09-00-2B-00-00-07 NetBios emulator (PCSG) 09-00-2B-00-00-0F Local Area Transport (LAT) 09-00-2B-01-00-00 All Bridges 09-00-2B-01-00-01 All Local Bridges 09-00-2B-02-00-00 DNA Level 2 Routing Layer routers 09-00-2B-02-01-00 DNA Naming Service Advertisement 09-00-2B-02-01-01 DNA Naming Service Solicitation 09-00-2B-02-01-04 LAT directory service solict (to slave) 09-00-2B-02-01-05 FDDI Ring Purger advertisement 09-00-2B-02-01-07 LAT directory service solict - X service class 09-00-2B-04-xx-xx Local Area System Transport (LAST) 2.2.3 Physical addresses assigned by DIGITAL Last revision date: 4 October 1991 The following addresses have been assigned to DIGITAL prototypes, parts or units. AA-00-04-xx-xx-xx DECnet Phase IV station addresses AA-00-03-00-xx-xx UNA Prototype AA-00-03-01-xx-xx PROM 23-365A1-00 AA-00-03-02-xx-xx Miscellaneous Assignments AA-00-03-02-00-00 H4000-TA Ethernet Transceiver Tester AA-00-03-03-xx-xx NI20 Products 08-00-2B-0x-xx-xx PROM 23-365A1-00 08-00-2B-1x-xx-xx PROM 23-365A1-00 08-00-2B-22-00-00 Bridge Management 08-00-2B-23-xx-xx * PROM 23-365A1-00 08-00-2B-24-xx-xx * PROM 23-365A1-00 08-00-2B-25-xx-xx * PROM 23-365A1-00 08-00-2B-26-xx-xx * PROM 23-365A1-00 08-00-2B-27-xx-xx * PROM 23-365A1-00 08-00-2B-28-xx-xx * PROM 23-365A1-00 08-00-2B-29-xx-xx * PROM 23-365A1-00 08-00-2B-2A-xx-xx * PROM 23-365A1-00 08-00-2B-2B-xx-xx * PROM 23-365A1-00 08-00-2B-2C-xx-xx * PROM 23-365A1-00 08-00-2B-2D-xx-xx * PROM 23-365A1-00 08-00-2B-2E-xx-xx * PROM 23-365A1-00 08-00-2B-2F-xx-xx * PROM 23-365A1-00 08-00-2B-3x-xx-xx * PROM 23-365A1-00 08-00-2B-4x-xx-xx * Shadow(1) for PROM 23-365A1-00 08-00-2B-5x-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-63-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-64-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-65-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-66-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-67-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-68-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-69-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-6A-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-6B-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-6C-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-6D-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-6E-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-6F-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-7x-xx-xx * Shadow for PROM 23-365A1-00 08-00-2B-E0-xx-xx * VAXft 3000 fault tolerant LAN addresses 08-00-2B-F0-xx-xx * VAXft 3000 fault tolerant LAN addresses (1) The "shadow" addresses are allocated in one-to-one correspondence with the addresses stored in PROM 23-365A1-00. A system containing a PROM with an address in the range 08-00-2B-0x-xx-xx, 08-00-2B-1x-xx-xx, or 08-00-2B-23- xx-xx through 08-00-2B-3F-xx-xx may also use the corresponding shadow address, which is formed by adding the value 00-00-00-40-00-00 to the PROM's address. 2.3 Other physical addresses Last revision date: 2 May 1988 The following are address blocks assigned to other organizations, but used in Digital products. 00-00-69-02-xx-xx DTQNA, Concord Communications Inc. Chapter 3 Protocol Types DIGITAL currently adheres to the following protocol type assignments. 3.1 Cross-company Assignments Last revision date: 1 March 1988 The cross-company protocol type is: 90-00 Ethernet Loopback protocol 3.2 Received from Xerox Last revision date: November 25, 1985 60-00 to 60-09 80-38 to 80-42 3.2.1 Assigned by DIGITAL Last revision date: 4 October 1991 The DIGITAL protocol types are: 60-01 DNA Dump/Load (MOP) 60-02 DNA Remote Console (MOP) 60-03 DNA Routing 60-04 Local Area Transport (LAT) 60-05 Diagnostics 60-06 Customer use 60-07 System Communication Architecture (SCA) 80-38 Bridge 80-3A reserved 80-3B VAXELN 80-3C DNA Naming Service 80-3D CSMA/CD Encryption 80-3F LAN Traffic Monitor 80-40 NetBios emulator (PCSG) 80-41 Local Area System Transport (LAST) 80-42 reserved The protocol types 00-00 through 05-DC are reserved so that 802.3 format frames can be distinguished from Ethernet format frames. Use of these protocol types in Ethernet format frames is incompatible with correct operation of the CSMA/CD Data Link. Chapter 4 SAPS DIGITAL currently adheres to the following SAP assignments. 4.1 Cross-company Assignments (Universally Administered) Last revision date: 16 May 1990 The cross-company (Universally Administered) SAP assignments are : 03 LLC sublayer management function group SAP(IEEE 802.1b) FF Global DSAP 00 Null SAP 02 LLC sublayer management function individual SAP(IEEE 802.1b) 06 ARPAnet IP (obsolete, replaced by RFC 1042) 0E PROWAY (IEC 955) network management and initialization 42 IEEE 802.1d (ISO 10038) transparent bridge protocol 4E EIA RS-511 Manufacturing Message Service 7E ISO 8208 (X.25 over IEEE 802.2 type 2 LLC) 8E PROWAY (IEC 955) active station list maintenance AA SNAP SAP FE ISO Network Layer entity 4.2 Received From IEEE 802 Last revision date: August 26, 1986 There is no SAP received from IEEE 802. 4.2.1 Assigned By DIGITAL Last revision date: August 26, 1986 There is no SAP assigned. Chapter 5 Protocol IDs Currently DIGITAL adheres to the following IEEE SNAP Protocol Identification Assignments. 5.1 Cross-company Assignments (Universally Administered) Last revision date: 21 November 1990 The cross-company assigned (Universally Administered) Protocol Identification codes are : 00-00-00-xx-xx Ethernet protocol type mapping according to Internet standard RFC 1042 00-00-F8-xx-xx Alternate Ethernet protocol type mapping protocol. This Protocol ID is used by bridges in place of the 00-00-00 Protocol ID when the corresponding Ethernet protocol type is listed for alternate translation an a table in the bridge. This is done for protocols (such as AppleTalk) where both Ethernet format and RFC 1042 format frames are used, but not in conformance with RFC 1122 (Host Require- ments). NOTE: This range of Protocol IDs "SHALL NOT" be used on IEEE 802.3 (CSMA/CD) LANs. 5.2 Received From IEEE 802 Last revision date: 26 September 1989 The following Protocol Identification code blocks have been assigned to DIGITAL from IEEE. 08-00-2B-xx-xx 00-00-F8-xx-xx NOTE: Out of the OUI 00-00-F8, the entire range of possible Protocol Ident- ifiers have been assigned by Digital tp IEEE 802. Consequently. "no" Protocol Identifier assignments may be made from that block. 5.2.1 Assigned By DIGITAL Last revision date: 15 October 1991 The DIGITAL assigned Protocol Identification codes are: 08-00-2B-60-01 DNA Dump/Load (MOP) 08-00-2B-60-02 DNA Remote Console (MOP) 08-00-2B-60-03 DNA Routing 08-00-2B-60-04 Local Area Transport (LAT) 08-00-2B-60-05 Diagnostics 08-00-2B-60-06 Customer use 08-00-2B-60-07 System Communication Architecture (SCA) 08-00-2B-80-3B VAXELN 08-00-2B-80-3C DNA Naming Service 08-00-2B-80-3D CSMA/CD Encryption 08-00-2B-80-3F LAN Traffic Monitor 08-00-2B-80-40 NetBios emulator (PCSG) 08-00-2B-90-00 MOP LAN Loopback protocol 08-00-2B-80-41 Local Area System Transport (LAST) PATHWORKS clients 08-00-2B-90-00 MOP LAN Loopback protocol Chapter 6 FDDI Extended Service Frame IDs Extended Service Frames are defined in the ANSI FDDI (SMT) standard. SMT frames are used for FDDI layer management functions and allow for communication between cooperating FDDI SMT entities on a single FDDI ring. The Extended Service Frame class is used in SMT for proprietary extensions, experimental functions, etc., within the framework of the services provided by the SMT frames. In order to allow Extended Service Frames (ESF) to be defined by various parties without the risk of conflicks, the data portion of each ESF begins with an "ESF ID". This field serves essentially the same purpose as the Protocol ID in SNAP frames. The first 3 bytes are the OUI of the organization that defined the particular frame, and the remaining 3 bytes are assigned as desired by the organization. ESF IDs assigned by DIGITAL will have DIGITAL's OUI as the first 3 bytes, and the remaining 3 bytes will be used as a frame type. This eliminates the need for a separate frame type field, and simplifies processing of received ESF frames. 6.1 CAUTION - ESF ID unconventional encoding rule As defined by the SMT standard, ESF IDs are *not* represented in canonical form in the SMT frame. Instead, they are encoded in the bytewise bit- reversed form, in the same way as addresses in the FDDI MAC header. Implementers must pay particular attention to this issue, to avoid incorrectly encoding ESF IDs or misinterpreting received ESF frames. For more details on the rules for encoding SMT frames, refer to the FDDI SMT standard (Chapter 4 in the Rev 5.1 version). 6.2 Cross-company assignments (universally administered) Last revision date: 9 January 1990 There are no cross-company globally assigned ESF IDs 6.3 Assigned by DIGITAL Last revision date: 4 October 1991 The following Extended Service Frame IDs have been assigned by DIGITAL. 10-00-D4-00-01-00 Ringer Purger Hello 10-00-D4-00-02-00 Candidate Purger Hello Chapter 7 802.5 Token Ring functional addresses The so-called "functional addresses" are a special case form of the standard IEEE 802 multicast (group) addresses. Th theory IEEE 802.5 supports normal multicast addressing, but actual implementations to not, and instead support only the very limited capabilities of functional addressing. Functional addresses have the form of locally administered addresses, but they are administered by IBM. Most are used for functions that are specific to the 802.5 token ring. A few relate to general functions that on other LAN types are supported by real multicast addresses. 7.1 CAUTION - Reversed notation of functional addresses IBM writes functional addresses in byte wise reversed notation, i.e., interpreting the first address bit sent as the high order bit of the octet in the written form. This is the reverse of the canonical form as described in Chapter 1, and is a source of potential confusion and "serious" bugs. In the functional address lists in the remainder of this chapter, addresses are given first in the canonical form, and then also in the IBM notation. The canonical form is with hyphens, as usual; the IBM notation is shown with colons as separator, which is the IEEE 802 recommended way for showing addresses in this form. (IBM generally writes them without any separator.) 7.2 General format of functional addresses All functional addresses are of the form 03-00-xx-xx-xx-xx (C000xxxxxxxx in reversed notation). In other words, they are locally administered group addresses. The remaining bits of the first two octets are zero. The next bit (17th bit) is also zero to indicate a functional address. (If this bit is one, it indicates an 802.5 token ring specific multicast address of a different form, which fortunately does not seem to be actually used.) In the remaining 31 bits, a single bit is set. As a result, a total of 31 distinct functional addresses exists. Implemen- tations can filter functional addresses by checking the first 17 bits, and matching the remaining 31 bits against a mask (i.e., AND operation), accepting the frame if the function bit in the address is set in the mask. 7.3 LAN independent functions Last revision date: 13 April 1990 03-00-00-00-02-00 C0:00:00:00:40:00 ISO 9542 All End-system Network Entities 03-00-00-00-01-00 C0:00:00:00:80:00 ISO 9542 All Intermediate System Network Entities 7.4 802.5 specific functions Last revision date: 13 April 1990 03-00-00-00-00-80 C0:00:00:00:00:01 Active Monitor 03-00-00-00-00-40 C0:00:00:00:00:02 Ring parameter server 03-00-00-00-00-20 C0:00:00:00:00:04 Network server heartbeat 03-00-00-00-00-10 C0:00:00:00:00:08 Ring error monitor 03-00-00-00-00-08 C0:00:00:00:00:10 Configuration report server 03-00-00-00-00-04 C0:00:00:00:00:20 Synchronous bandwidth manager 03-00-00-00-00-02 C0:00:00:00:00:40 Locate - directory server 03-00-00-00-00-01 C0:00:00:00:00:80 NETBIOS 03-00-00-00-80-00 C0:00:00:00:01:00 Bridge 03-00-00-00-40-00 C0:00:00:00:02:00 IMPL server 03-00-00-00-20-00 C0:00:00:00:04:00 Ring authorization 03-00-00-00-10-00 C0:00:00:00:08:00 LAN gateway 03-00-00-00-08-00 C0:00:00:00:10:00 Ring wiring concentrator 03-00-00-00-04-00 C0:00:00:00:20:00 IBM LAN Manager 03-00-00-01-00-00 C0:00:00:80:00:00 Novell NetWare Note that Novell has taken over one of the addresses specified as "user defined". 7.5 Remaining assignments 03-00-00-80-00-00 C0:00:00:01:00:00 unassigned 03-00-00-40-00-00 C0:00:00:02:00:00 unassigned 03-00-00-20-00-00 C0:00:00:04:00:00 unassigned 03-00-00-10-00-00 C0:00:00:08:00:00 User defined 03-00-00-08-00-00 C0:00:00:10:00:00 User defined 03-00-00-04-00-00 C00000200000 User defined 03-00-00-02-00-00 C0:00:00:40:00:00 User defined 03-00-00-01-00-00 C0:00:00:80:00:00 User defined (used by Novell) 03-00-80-00-00-00 C0:00:01:00:00:00 User defined 03-00-40-00-00-00 C0:00:02:00:00:00 User defined 03-00-20-00-00-00 C0:00:04:00:00:00 User defined 03-00-10-00-00-00 C0:00:08:00:00:00 User defined 03-00-08-00-00-00 C0:00:10:00:00:00 User defined 03-00-04-00-00-00 C0:00:20:00:00:00 User defined 03-00-02-00-00-00 C0:00:40:00:00:00 User defined IBM and NETBIOS are trademarks of International Business Machines Corp. Novell and NetWare are trademarks of Novell Inc. AppleTalk is a trademark of Apple Computer Corp.