  * [DECnet] LAN Address and Protocol RegistryM Last Technical Review: 15-OCT-1991                            Size: 587 lines     @ COPYRIGHT (c) 1988, 1989, 1990 by Digital Equipment Corporation.G ALL RIGHTS RESERVED. No distribution except as provided under contract.   1 PRODUCT:  DECnet[TM] Digital Network Architecture   # LAST TECHNICAL REVIEW:  15-OCT-1991   % SOURCE: Customer Support Center / USA      SUBJECT:  ! LAN Address and protocol registry   M This registry information is from the Distributed Systems Architecture group.     J PREFACE:                                                               iii  L This is the Digital registry of LAN addresses, multicast addresses, EthernetI protocol types, IEEE 802.2 SAPs, and IEEE Protocol IDs, and FDDI Extended  Service Frame IDs.  K Address and protocol assignments used in Digital products under development F are shown here. Such assignments will be included in revisions of thisK document as products are released. All address, protocol type, and protocol I ID values in ranges assigned to Digital that are not shown as assigned in N this document are reserved for future use and may be assigned at a later time.     Chapter 1   Introduction  L This is the Digital registry of LAN addresses, multicast addresses, EthernetI protocol types, IEEE 802.2 SAPs, and IEEE Protocol IDs, and FDDI Extended L Service Frame IDs. The values shown here apply to all LAN types that conformO to the IEEE general structure, i.e., IEEE 802.3 (CSMA/CD), including Ethernet), I 802.4 (Token Bus), 802.5 (Token Ring) and ANSI FDDI. For more information 9 about these, refer to the applicable standards documents:   0     o IEEE 802   - LAN Overview and Architecture  :     o IEEE 802.2 - Logical Link Control (ISBN 471-82748-7)  G     o IEEE 802.3 - CSMA/CD: Carrier Sense Multiple Access with Collison /                    Detection (ISBN 471-82749-5)   M     o The Ethernet - A Local Area Network - Version 2.0 (DIGITAL order number                     AA-K759B-TK)   7     o IEEE 802.4 - Token-passing Bus (ISBN 471-82750-9)        o IEEE 802.5 - Token Ring   M     o ANSI X3.139-1987 - Fiber Distributed Data Interface (FDDI) - Token ring -                    media access control (MAC)   L     o ANSI X3T9.5/84-49 Rev. 6.2 - Fiber Distributed Data Interface (FDDI) -+                    Station Management (SMT)       1.1   Notation  canonical form  N   The order of transmission of bits within each byte differs for various LANs:K   for IEEE 802.3 and 802.4, the least significant bit is transmitted first; O   for IEEE 802.5 and FDDI, the most significant bit is transmitted first.* This N   transmission order applies to all date "after" the MAC header; in particular/   it applies to the SAP and Protocol ID fields.   J   The destination Address and Source Address fields in the MAC are treatedM   differently: these are viewed as bitstrings where the first bit transmitted    is always the Multicast bit.  L * More precisely, in FDDI the most significant 4 bits of the byte are trans-L   mitted first; FDDI uses an encoding scheme in which transmission occurs in   4-bit units.  N   Clearly this combination of two different rules and the variety of transmis-N   sion order can lead to confusion in the use of address value assignments. ToM   reduce this problem, IEEE has defined (in IEEE 802.1A - Overview and Archi- M   tecture) the "canonical" representation for addresses and other values. All =   values given in the registry are written in canonical form.   M   The canonical form is written as a sequence of hexidecimal byte values sep- K   arated by hyphens. The byte transmission order is from left to right. The 3   bits within each byte are interpreted as follows:   L     o For MAC addresses, the first bit transmitted (i.e., in the first byte,L       the Multicast bit) is written as the Least Significant Bit of the can-       onical form.  M     o For all other values (i.e., SAP and Protocol ID), the Least Significant O       Bit of the value is written as the Least Significant Bit of the canonical        form.   N   An example of a canonical form MAC address, and its interpretation for vari-J   ous LANs, is shown below. In this example, the IEEE 802.x line shows theK   bits as transmitted (left to right) in the MAC header address fields. For I   the FDDI, it shows the FDDI PHY symbols as transmitted (left to right).   #     Canonical:    AC-DE-48-00-00-80 G     IEEE 802.x:   00110101 01111011 00010010 00000000 00000000 00000001 .     FDDI:         3 5  7 B  1 2  0 0  0 0  0 1  I   The second example shows a Protocol ID from a SNAP frame. As before the L   IEEE 802.x lines show the bits as transmitted (left to right) and the FDDI1   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   L   Implementors developing IEEE 802.5 or FDDI products should carefully studyN   these rules, and the details given in IEEE 802.2A, to ensure that addresses,2   SAP values, and Protocol IDs are used correctly.     Chapter 2   Addresses   K 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:  6   01-80-C2-00-00-00   IEEE 802.1d Bridge group addressG   01-80-C2-00-00-0x   IEEE 802.1d Reserved (always filtered by bridges) J   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 N   01-80-C2-00-00-14   ISO IS-IS (ISO DP 10589) All Level 1 Intermediate System&                       Network EntitiesN   01-80-C2-00-00-15   ISO IS-IS (ISO DP 10589) All Level 2 Intermediate System&                       Network Entities6   01-80-C2-00-00-16   ISO 10030 - All CONS End Systems1   01-80-C2-00-00-17   ISO 10030 - All CONS SNAREs G   01-80-C2-00-01-00   ANSI FDDI SMT - RMT directed beacon group address G   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 EntitiesG   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   K   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   K   The following address blocks previously assigned to DIGITAL by Xerox fall M   into the Locally Administered Address space according to IEEE 802 standard. 0   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  8   The current DIGITAL multicast address assignments are:  9  AB-00-00-01-00-00         DNA Dump/Load Assistance (MOP) 3  AB-00-00-02-00-00         DNA Remote Console (MOP) <  AB-00-00-03-00-00         DNA Level 1 Routing Layer routers6  AB-00-00-04-00-00         DNA Routing Layer end nodes'  AB-00-04-00-xx-xx         Customer use B  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 2  09-00-2B-00-00-07         NetBios emulator (PCSG)5  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 SolicitationB  09-00-2B-02-01-04         LAT directory service solict (to slave)9  09-00-2B-02-01-05         FDDI Ring Purger advertisement I  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   J The following addresses have been assigned to DIGITAL prototypes, parts or units.  8  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 0  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 5  08-00-2B-4x-xx-xx *   Shadow(1) for PROM 23-365A1-00 2  08-00-2B-5x-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-63-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-64-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-65-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-66-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-67-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-68-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-69-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-6A-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-6B-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-6C-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-6D-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-6E-xx-xx *   Shadow for PROM 23-365A1-002  08-00-2B-6F-xx-xx *   Shadow for PROM 23-365A1-002  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  N (1) The "shadow" addresses are allocated in one-to-one correspondence with theL     addresses stored in PROM 23-365A1-00. A system containing a PROM with anN     address in the range 08-00-2B-0x-xx-xx, 08-00-2B-1x-xx-xx, or 08-00-2B-23-I     xx-xx through 08-00-2B-3F-xx-xx may also use the corresponding shadow P     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  L   The following are address blocks assigned to other organizations, but used   in Digital products.  9   00-00-69-02-xx-xx    DTQNA, Concord Communications Inc.          Chapter 3   Protocol Types    E 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 use3  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  H The protocol types 00-00 through 05-DC are reserved so that 802.3 formatF frames can be distinguished from Ethernet format frames.  Use of theseE 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.     9 4.1  Cross-company Assignments (Universally Administered)   $      Last revision date: 16 May 1990  D   The cross-company (Universally Administered) SAP assignments are :  ?   03    LLC sublayer management function group SAP(IEEE 802.1b)    FF    Global DSAP      00    Null SAPD   02    LLC sublayer management function individual SAP(IEEE 802.1b)3   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 0   4E    EIA RS-511 Manufacturing Message Service2   7E    ISO 8208 (X.25 over IEEE 802.2 type 2 LLC)8   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  L Currently DIGITAL adheres to the following IEEE SNAP Protocol Identification Assignments.  9 5.1  Cross-company Assignments (Universally Administered)   )      Last revision date: 21 November 1990   O   The cross-company assigned (Universally Administered) Protocol Identification 
   codes are :   H   00-00-00-xx-xx    Ethernet protocol type mapping according to Internet%                     standard RFC 1042 K   00-00-F8-xx-xx    Alternate Ethernet protocol type mapping protocol. This K                     Protocol ID is used by bridges in place of the 00-00-00 M                     Protocol ID when the corresponding Ethernet protocol type I                     is listed for alternate translation an a table in the J                     bridge. This is done for protocols (such as AppleTalk)M                     where both Ethernet format and RFC 1042 format frames are M                     used, but not in conformance with RFC 1122 (Host Require-                      ments).   K                     NOTE: This range of Protocol IDs "SHALL NOT" be used on 4                           IEEE 802.3 (CSMA/CD) LANs.   5.2  Received From IEEE 802   *      Last revision date: 26 September 1989    I   The following Protocol Identification code blocks have been assigned to    DIGITAL from IEEE.     08-00-2B-xx-xx   00-00-F8-xx-xx  M   NOTE: Out of the OUI 00-00-F8, the entire range of possible Protocol Ident- L         ifiers have been assigned by Digital tp IEEE 802. Consequently. "no"D         Protocol Identifier assignments may be made from that block.   5.2.1 Assigned By DIGITAL   )       Last revision date: 15 October 1991   9   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 0  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 8  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 IDse  J   Extended Service Frames are defined in the ANSI FDDI (SMT) standard. SMTC   frames are used for FDDI layer management functions and allow for L   communication between cooperating FDDI SMT entities on a single FDDI ring.M   The Extended Service Frame class is used in SMT for proprietary extensions,iM   experimental functions, etc., within the framework of the services providedn   by the SMT frames.  J   In order to allow Extended Service Frames (ESF) to be defined by variousL   parties without the risk of conflicks, the data portion of each ESF beginsI   with an "ESF ID". This field serves essentially the same purpose as the O   Protocol ID in SNAP frames. The first 3 bytes are the OUI of the organization N   that defined the particular frame, and the remaining 3 bytes are assigned asN   desired by the organization. ESF IDs assigned by DIGITAL will have DIGITAL'sM   OUI as the first 3 bytes, and the remaining 3 bytes will be used as a frame E   type. This eliminates the need for a separate frame type field, and /   simplifies processing of received ESF frames.   3 6.1  CAUTION  - ESF ID unconventional encoding rule   N     As defined by the SMT standard, ESF IDs are *not* represented in canonicalI     form in the SMT frame. Instead, they are encoded in the bytewise bit- G     reversed form, in the same way as addresses in the FDDI MAC header. F     Implementers must pay particular attention to this issue, to avoidH     incorrectly encoding ESF IDs or misinterpreting received ESF frames.  L     For more details on the rules for encoding SMT frames, refer to the FDDI4     SMT standard (Chapter 4 in the Rev 5.1 version).    9 6.2  Cross-company assignments (universally administered)   '      Last revision date: 9 January 1990   7    There are no cross-company globally assigned ESF IDs      6.3  Assigned by DIGITAL  (      Last revision date:  4 October 1991  J    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     1 Chapter 7   802.5 Token Ring functional addresses   N   The so-called "functional addresses" are a special case form of the standardL   IEEE 802 multicast (group) addresses. Th theory IEEE 802.5 supports normalN   multicast addressing, but actual implementations to not, and instead support>   only the very limited capabilities of functional addressing.  K   Functional addresses have the form of locally administered addresses, but M   they are administered by IBM. Most are used for functions that are specific N   to the 802.5 token ring. A few relate to general functions that on other LAN2   types are supported by real multicast addresses.  7 7.1 CAUTION - Reversed notation of functional addresses   I     IBM writes functional addresses in byte wise reversed notation, i.e., H     interpreting the first address bit sent as the high order bit of theH     octet in the written form. This is the reverse of the canonical formI     as described in Chapter 1, and is a source of potential confusion and      "serious" bugs.   E     In the functional address lists in the remainder of this chapter, E     addresses are given first in the canonical form, and then also in G     the IBM notation. The canonical form is with hyphens, as usual; the I     IBM notation is shown with colons as separator, which is the IEEE 802 M     recommended way for showing addresses in this form. (IBM generally writes       them without any separator.)  + 7.2  General format of functional addresses   M   All functional addresses are of the form 03-00-xx-xx-xx-xx (C000xxxxxxxx in I   reversed notation). In other words, they are locally administered group J   addresses. The remaining bits of the first two octets are zero. The nextI   bit (17th bit)  is also zero to indicate a functional address. (If this I   bit is one, it indicates an 802.5 token ring specific multicast address L   of a different form, which fortunately does not seem to be actually used.)0   In the remaining 31 bits, a single bit is set.  L   As a result, a total of 31 distinct functional addresses exists. Implemen-L   tations can filter functional addresses by checking the first 17 bits, andF   matching the remaining 31 bits against a mask (i.e., AND operation),L   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  N  03-00-00-00-02-00 C0:00:00:00:40:00  ISO 9542 All End-system Network EntitiesN  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   4  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 heartbeat8  03-00-00-00-00-10 C0:00:00:00:00:08  Ring error monitorA  03-00-00-00-00-08 C0:00:00:00:00:10  Configuration report server C  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  Bridge1  03-00-00-00-40-00 C0:00:00:00:02:00  IMPL server 8  03-00-00-00-20-00 C0:00:00:00:04:00  Ring authorization1  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 concentrator5  03-00-00-00-04-00 C0:00:00:00:20:00  IBM LAN Manager 4  03-00-00-01-00-00 C0:00:00:80:00:00  Novell NetWare  I   Note that Novell has taken over one of the addresses specified as "user    defined".    7.5   Remaining assignments   0  03-00-00-80-00-00 C0:00:00:01:00:00  unassigned0  03-00-00-40-00-00 C0:00:00:02:00:00  unassigned0  03-00-00-20-00-00 C0:00:00:04:00:00  unassigned  2  03-00-00-10-00-00 C0:00:00:08:00:00  User defined2  03-00-00-08-00-00 C0:00:00:10:00:00  User defined-  03-00-00-04-00-00 C00000200000  User defined 2  03-00-00-02-00-00 C0:00:00:40:00:00  User definedC  03-00-00-01-00-00 C0:00:00:80:00:00  User defined (used by Novell) 2  03-00-80-00-00-00 C0:00:01:00:00:00  User defined2  03-00-40-00-00-00 C0:00:02:00:00:00  User defined2  03-00-20-00-00-00 C0:00:04:00:00:00  User defined2  03-00-10-00-00-00 C0:00:08:00:00:00  User defined2  03-00-08-00-00-00 C0:00:10:00:00:00  User defined2  03-00-04-00-00-00 C0:00:20:00:00:00  User defined2  03-00-02-00-00-00 C0:00:40:00:00:00  User defined      G IBM and NETBIOS are trademarks of International Business Machines Corp. 0 Novell and NetWare are trademarks of Novell Inc.0 AppleTalk is a trademark of Apple Computer Corp.    