home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1001.txt < prev    next >
Text File  |  1996-05-07  |  158KB  |  2,114 lines

  1.  Network Working Group Request for Comments: 1001                                March, 1987 
  2.  
  3.  
  4.  
  5.               PROTOCOL STANDARD FOR A NetBIOS SERVICE                      ON A TCP/UDP TRANSPORT:                       CONCEPTS AND METHODS 
  6.  
  7.  
  8.  
  9.                              ABSTRACT 
  10.  
  11. This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment.  Both local network and internet operation are supported.  Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. 
  12.  
  13. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques.  Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications". 
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43. NetBIOS Working Group                                           [Page 1] 
  44.  RFC 1001                                                      March 1987 
  45.  
  46.                         SUMMARY OF CONTENTS 
  47.  
  48.  1.  STATUS OF THIS MEMO                                             6 2.  ACKNOWLEDGEMENTS                                                6 3.  INTRODUCTION                                                    7 4.  DESIGN PRINCIPLES                                               7 5.  OVERVIEW OF NetBIOS                                            10 6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD                  15 7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS         15 8.  RELATED PROTOCOLS AND SERVICES                                 16 9.  NetBIOS SCOPE                                                  16 10.  NetBIOS END-NODES                                             16 11.  NetBIOS SUPPORT SERVERS                                       18 12.  TOPOLOGIES                                                    20 13.  GENERAL METHODS                                               23 14.  REPRESENTATION OF NETBIOS NAMES                               25 15.  NetBIOS NAME SERVICE                                          27 16.  NetBIOS SESSION SERVICE                                       48 17.  NETBIOS DATAGRAM SERVICE                                      55 18.  NODE CONFIGURATION PARAMETERS                                 58 19.  MINIMAL CONFORMANCE                                           59 REFERENCES                                                         60 APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING          61 APPENDIX B - IMPLEMENTATION CONSIDERATIONS                         62 
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78. NetBIOS Working Group                                           [Page 2] 
  79.  RFC 1001                                                      March 1987 
  80.  
  81.                          TABLE OF CONTENTS 
  82.  
  83.  1.  STATUS OF THIS MEMO                                             6 
  84.  
  85. 2.  ACKNOWLEDGEMENTS                                                6 
  86.  
  87. 3.  INTRODUCTION                                                    7 
  88.  
  89. 4.  DESIGN PRINCIPLES                                               8   4.1  PRESERVE NetBIOS SERVICES                                    8   4.2  USE EXISTING STANDARDS                                       8   4.3  MINIMIZE OPTIONS                                             8   4.4  TOLERATE ERRORS AND DISRUPTIONS                              8   4.5  DO NOT REQUIRE CENTRAL MANAGEMENT                            9   4.6  ALLOW INTERNET OPERATION                                     9   4.7  MINIMIZE BROADCAST ACTIVITY                                  9   4.8  PERMIT IMPLEMENTATION ON EXISTING SYSTEMS                    9   4.9  REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE                9   4.10  MAXIMIZE EFFICIENCY                                        10   4.11  MINIMIZE NEW INVENTIONS                                    10 
  90.  
  91. 5.  OVERVIEW OF NetBIOS                                            10   5.1  INTERFACE TO APPLICATION PROGRAMS                           10   5.2  NAME SERVICE                                                11   5.3  SESSION SERVICE                                             12   5.4  DATAGRAM SERVICE                                            13   5.5  MISCELLANEOUS FUNCTIONS                                     14   5.6  NON-STANDARD EXTENSIONS                                     15 
  92.  
  93. 6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD                  15 
  94.  
  95. 7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS         15 
  96.  
  97. 8.  RELATED PROTOCOLS AND SERVICES                                 16 
  98.  
  99. 9.  NetBIOS SCOPE                                                  16 
  100.  
  101. 10.  NetBIOS END-NODES                                             16   10.1  BROADCAST (B) NODES                                        16   10.2  POINT-TO-POINT (P) NODES                                   16   10.3  MIXED MODE (M) NODES                                       16 
  102.  
  103. 11.  NetBIOS SUPPORT SERVERS                                       18   11.1  NetBIOS NAME SERVER (NBNS) NODES                           18      11.1.1  RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM    19   11.2  NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES          19   11.3  RELATIONSHIP OF NBNS AND NBDD NODES                        20   11.4  RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES        20 12.  TOPOLOGIES                                                    20   12.1  LOCAL                                                      20 
  104.  
  105.  
  106.  
  107. NetBIOS Working Group                                           [Page 3] 
  108.  RFC 1001                                                      March 1987 
  109.  
  110.       12.1.1  B NODES ONLY                                          21      12.1.2  P NODES ONLY                                          21      12.1.3  MIXED B AND P NODES                                   21   12.2  INTERNET                                                   22      12.2.1  P NODES ONLY                                          22      12.2.2  MIXED M AND P NODES                                   23 
  111.  
  112. 13.  GENERAL METHODS                                               23   13.1  REQUEST/RESPONSE INTERACTION STYLE                         23      13.1.1  RETRANSMISSION OF REQUESTS                            24      13.1.2  REQUESTS WITHOUT RESPONSES: DEMANDS                   24   13.2  TRANSACTIONS                                               25      13.2.1  TRANSACTION ID                                        25   13.3  TCP AND UDP FOUNDATIONS                                    25 
  113.  
  114. 14.  REPRESENTATION OF NETBIOS NAMES                               25   14.1  FIRST LEVEL ENCODING                                       26   14.2  SECOND LEVEL ENCODING                                      27 
  115.  
  116. 15.  NetBIOS NAME SERVICE                                          27   15.1  OVERVIEW OF NetBIOS NAME SERVICE                           27      15.1.1  NAME REGISTRATION (CLAIM)                             27      15.1.2  NAME QUERY (DISCOVERY)                                28      15.1.3  NAME RELEASE                                          28        15.1.3.1  EXPLICIT RELEASE                                  28        15.1.3.2  NAME LIFETIME AND REFRESH                         29        15.1.3.3  NAME CHALLENGE                                    29        15.1.3.4  GROUP NAME FADE-OUT                               29      15.1.3.5  NAME CONFLICT                                       30      15.1.4  ADAPTER STATUS                                        31      15.1.5  END-NODE NBNS INTERACTION                             31        15.1.5.1  UDP, TCP, AND TRUNCATION                          31        15.1.5.2  NBNS WACK                                         32        15.1.5.3  NBNS REDIRECTION                                  32      15.1.6  SECURED VERSUS NON-SECURED NBNS                       32      15.1.7  CONSISTENCY OF THE NBNS DATA BASE                     32      15.1.8  NAME CACHING                                          34   15.2  NAME REGISTRATION TRANSACTIONS                             34      15.2.1  NAME REGISTRATION BY B NODES                          34      15.2.2  NAME REGISTRATION BY P NODES                          35        15.2.2.1  NEW NAME, OR NEW GROUP MEMBER                     35        15.2.2.2  EXISTING NAME AND OWNER IS STILL ACTIVE           36        15.2.2.3  EXISTING NAME AND OWNER IS INACTIVE               37      15.2.3  NAME REGISTRATION BY M NODES                          38   15.3  NAME QUERY TRANSACTIONS                                    39      15.3.1  QUERY BY B NODES                                      39      15.3.2  QUERY BY P NODES                                      40      15.3.3  QUERY BY M NODES                                      43      15.3.4  ACQUIRE GROUP MEMBERSHIP LIST                         43   15.4  NAME RELEASE TRANSACTIONS                                  44      15.4.1  RELEASE BY B NODES                                    44 
  117.  
  118.  
  119.  
  120. NetBIOS Working Group                                           [Page 4] 
  121.  RFC 1001                                                      March 1987 
  122.  
  123.       15.4.2  RELEASE BY P NODES                                    44      15.4.3  RELEASE BY M NODES                                    44   15.5  NAME MAINTENANCE TRANSACTIONS                              45      15.5.1  NAME REFRESH                                          45      15.5.2  NAME CHALLENGE                                        46      15.5.3  CLEAR NAME CONFLICT                                   47   15.6  ADAPTER STATUS TRANSACTIONS                                47 
  124.  
  125. 16.  NetBIOS SESSION SERVICE                                       48   16.1  OVERVIEW OF NetBIOS SESSION SERVICE                        49      16.1.1  SESSION ESTABLISHMENT PHASE OVERVIEW                  49        16.1.1.1  RETRYING AFTER BEING RETARGETTED                  50        16.1.1.2  SESSION ESTABLISHMENT TO A GROUP NAME             51      16.1.2  STEADY STATE PHASE OVERVIEW                           51      16.1.3  SESSION TERMINATION PHASE OVERVIEW                    51   16.2  SESSION ESTABLISHMENT PHASE                                52   16.3  SESSION DATA TRANSFER PHASE                                54      16.3.1  DATA ENCAPSULATION                                    54      16.3.2  SESSION KEEP-ALIVES                                   54 
  126.  
  127. 17.  NETBIOS DATAGRAM SERVICE                                      55   17.1  OVERVIEW OF NetBIOS DATAGRAM SERVICE                       55      17.1.1  UNICAST, MULTICAST, AND BROADCAST                     55      17.1.2  FRAGMENTATION OF NetBIOS DATAGRAMS                    55   17.2  NetBIOS DATAGRAMS BY B NODES                               57   17.3  NetBIOS DATAGRAMS BY P AND M NODES                         58 
  128.  
  129. 18.  NODE CONFIGURATION PARAMETERS                                 58 
  130.  
  131. 19.  MINIMAL CONFORMANCE                                           59 
  132.  
  133. REFERENCES                                                         60 
  134.  
  135. APPENDIX A                                                         61 
  136.  
  137. INTEGRATION WITH INTERNET GROUP MULTICASTING                       61   A-1.  ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES              61   A-2.  CONSTRAINTS                                                61 
  138.  
  139. APPENDIX B                                                         62 
  140.  
  141. IMPLEMENTATION CONSIDERATIONS                                      62   B-1.  IMPLEMENTATION MODELS                                      62      B-1.1  MODEL INDEPENDENT CONSIDERATIONS                       63      B-1.2  SERVICE OPERATION FOR EACH MODEL                       63   B-2.  CASUAL AND RESTRICTED NetBIOS APPLICATIONS                 64   B-3.  TCP VERSUS SESSION KEEP-ALIVES                             66   B-4.  RETARGET ALGORITHMS                                        67   B-5.  NBDD SERVICE                                               68   B-6.  APPLICATION CONSIDERATIONS                                 68      B-6.1  USE OF NetBIOS DATAGRAMS                               68 
  142.  
  143.  
  144.  
  145. NetBIOS Working Group                                           [Page 5] 
  146.  RFC 1001                                                      March 1987 
  147.  
  148.               PROTOCOL STANDARD FOR A NetBIOS SERVICE                      ON A TCP/UDP TRANSPORT:                       CONCEPTS AND METHODS 
  149.  
  150.  1.  STATUS OF THIS MEMO 
  151.  
  152.    This RFC specifies a proposed standard for the Internet    community.  Since this topic is new to the Internet community,    discussions and suggestions are specifically requested. 
  153.  
  154.    Please send written comments to: 
  155.  
  156.            Karl Auerbach            Epilogue Technology Corporation            P.O. Box 5432            Redwood City, CA   94063 
  157.  
  158.    Please send online comments to: 
  159.  
  160.            Avnish Aggarwal                    Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu                    Usenet:   ucbvax!mtxinu!excelan!avnish 
  161.  
  162.    Distribution of this document is unlimited. 
  163.  
  164. 2.  ACKNOWLEDGEMENTS 
  165.  
  166.    This RFC has been developed under the auspices of the Internet    Activities Board, especially the End-to-End Services Task Force. 
  167.  
  168.    The following individuals have contributed to the development of    this RFC: 
  169.  
  170.    Avnish Aggarwal       Arvind Agrawal        Lorenzo Aguilar    Geoffrey Arnold       Karl Auerbach         K. Ramesh Babu    Keith Ball            Amatzia Ben-Artzi     Vint Cerf    Richard Cherry        David Crocker         Steve Deering    Greg Ennis            Steve Holmgren        Jay Israel    David Kaufman         Lee LaBarre           James Lau    Dan Lynch             Gaylord Miyata        David Stevens    Steve Thomas          Ishan Wu 
  171.  
  172.    The system proposed by this RFC does not reflect any existing    Netbios-over-TCP implementation.  However, the design    incorporates considerable knowledge obtained from prior    implementations.  Special thanks goes to the following    organizations which have provided this invaluable information: 
  173.  
  174.    CMC/Syros      Excelan        Sytek          Ungermann-Bass 
  175.  
  176.  
  177.  
  178.  NetBIOS Working Group                                           [Page 6] 
  179.  RFC 1001                                                      March 1987 
  180.  
  181.  3.  INTRODUCTION 
  182.  
  183.    This RFC describes the ideas and general methods used to provide    NetBIOS on a TCP and UDP foundation.  A companion RFC, "Protocol    Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed    Specifications"[1] contains detailed descriptions of packet    formats, protocols, and defined constants and variables. 
  184.  
  185.    The NetBIOS service has become the dominant mechanism for    personal computer networking.  NetBIOS provides a vendor    independent interface for the IBM Personal Computer (PC) and    compatible systems. 
  186.  
  187.    NetBIOS defines a software interface not a protocol.  There is no    "official" NetBIOS service standard.  In practice, however, the    IBM PC-Network version is used as a reference.  That version is    described in the IBM document 6322916, "Technical Reference PC    Network"[2]. 
  188.  
  189.    Protocols supporting NetBIOS services have been constructed on    diverse protocol and hardware foundations.  Even when the same    foundation is used, different implementations may not be able to    interoperate unless they use a common protocol.  To allow NetBIOS    interoperation in the Internet, this RFC defines a standard    protocol to support NetBIOS services using TCP and UDP. 
  190.  
  191.    NetBIOS has generally been confined to personal computers to    date.  However, since larger computers are often well suited to    run certain NetBIOS applications, such as file servers, this    specification has been designed to allow an implementation to be    built on virtually any type of system where the TCP/IP protocol    suite is available. 
  192.  
  193.    This standard defines a set of protocols to support NetBIOS    services. 
  194.  
  195.    These protocols are more than a simple communications service    involving two entities.  Rather, this note describes a    distributed system in which many entities play a part even if    they are not involved as an end-point of a particular NetBIOS    connection. 
  196.  
  197.    This standard neither constrains nor determines how those    services are presented to application programs. 
  198.  
  199.    Nevertheless, it is expected that on computers operating under    the PC-DOS and MS-DOS operating systems that the existing NetBIOS    interface will be preserved by implementors. 
  200.  
  201.    NOTE: Various symbolic values are used in this document.  For          their definitions, refer to the Detailed Specifications[1]. 
  202.  
  203.  
  204.  
  205. NetBIOS Working Group                                           [Page 7] 
  206.  RFC 1001                                                      March 1987 
  207.  
  208.  4.  DESIGN PRINCIPLES 
  209.  
  210.    In order to develop the specification the following design principles    were adopted to guide the effort.  Most are typical to any protocol    standardization effort; however, some have been assigned priorities    that may be considered unusual. 
  211.  
  212. 4.1.  PRESERVE NetBIOS SERVICES 
  213.  
  214.    In the absence of an "official" standard for NetBIOS services, the    version found in the IBM PC Network Technical Reference[2] is used. 
  215.  
  216.    NetBIOS is the foundation of a large body of existing applications.    It is desirable to operate these applications on TCP networks and to    extend them beyond personal computers into larger hosts.  To support    these applications, NetBIOS on TCP must closely conform to the    services offered by existing NetBIOS systems. 
  217.  
  218.    IBM PC-Network NetBIOS contains some implementation specific    characteristics.  This standard does not attempt to completely    preserve these.  It is certain that some existing software requires    these characteristics and will fail to operate correctly on a NetBIOS    service based on this RFC. 
  219.  
  220. 4.2.  USE EXISTING STANDARDS 
  221.  
  222.    Protocol development, especially with standardization, is a demanding    process.  The development of new protocols must be minimized. 
  223.  
  224.    It is considered essential that an existing standard which provides    the necessary functionality with reasonable performance always be    chosen in preference to developing a new protocol. 
  225.  
  226.    When a standard protocol is used, it must be unmodified. 
  227.  
  228. 4.3.  MINIMIZE OPTIONS 
  229.  
  230.    The standard for NetBIOS on TCP should contain few, if any, options. 
  231.  
  232.    Where options are included, the options should be designed so that    devices with different option selections should interoperate. 
  233.  
  234. 4.4.  TOLERATE ERRORS AND DISRUPTIONS 
  235.  
  236.    NetBIOS networks typically operate in an uncontrolled environment.    Computers come on-line at arbitrary times.  Computers usually go    off-line without any notice to their peers.  The software is often    operated by users who are unfamiliar with networks and who may    randomly perturb configuration settings. 
  237.  
  238.    Despite this chaos, NetBIOS networks work.  NetBIOS on TCP must also 
  239.  
  240.  
  241.  
  242. NetBIOS Working Group                                           [Page 8] 
  243.  RFC 1001                                                      March 1987 
  244.  
  245.     be able to operate well in this environment. 
  246.  
  247.    Robust operation does not necessarily mean that the network is proof    against all disruptions.  A typical NetBIOS network may be disrupted    by certain types of behavior, whether inadvertent or malicious. 
  248.  
  249. 4.5.  DO NOT REQUIRE CENTRAL MANAGEMENT 
  250.  
  251.    NetBIOS on TCP should be able to operate, if desired, without    centralized management beyond that typically required by a TCP based    network. 
  252.  
  253. 4.6.  ALLOW INTERNET OPERATION 
  254.  
  255.    The proposed standard recognizes the need for NetBIOS operation    across a set of networks interconnected by network (IP) level relays    (gateways.) 
  256.  
  257.    However, the standard assumes that this form of operation will be    less frequent than on the local MAC bridged-LAN. 
  258.  
  259. 4.7.  MINIMIZE BROADCAST ACTIVITY 
  260.  
  261.    The standard pre-supposes that the only broadcast services are those    supported by UDP.  Multicast capabilities are not assumed to be    available in any form. 
  262.  
  263.    Despite the availability of broadcast capabilities, the standard    recognizes that some administrations may wish to avoid heavy    broadcast activity.  For example, an administration may wish to avoid    isolated non-participating hosts from the burden of receiving and    discarding NetBIOS broadcasts. 
  264.  
  265. 4.8.  PERMIT IMPLEMENTATION ON EXISTING SYSTEMS 
  266.  
  267.    The NetBIOS on TCP protocol should be implementable on common    operating systems, such as Unix(tm) and VAX/VMS(tm), without massive    effort. 
  268.  
  269.    The NetBIOS protocols should not require services typically    unavailable on presently existing TCP/UDP/IP implementations. 
  270.  
  271. 4.9.  REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE 
  272.  
  273.    The protocol definition should specify only the minimal set of    protocols required for interoperation.  However, additional protocol    elements may be defined to enhance efficiency.  These latter elements    may be generated at the option of the sender, although they must be    accepted by all receivers. 
  274.  
  275.  
  276.  
  277.  
  278.  
  279. NetBIOS Working Group                                           [Page 9] 
  280.  RFC 1001                                                      March 1987 
  281.  
  282.  4.10.  MAXIMIZE EFFICIENCY 
  283.  
  284.    To be useful, a protocol must conduct its business quickly. 
  285.  
  286. 4.11.  MINIMIZE NEW INVENTIONS 
  287.  
  288.    When an existing protocol is not quite able to support a necessary    function, but with a small amount of change, it could, that protocol    should be used.  This is felt to be easier to achieve than    development of new protocols; further, it is likely to have more    general utility for the Internet. 
  289.  
  290. 5.  OVERVIEW OF NetBIOS 
  291.  
  292.    This section describes the NetBIOS services.  It is for background    information only.  The reader may chose to skip to the next section. 
  293.  
  294.    NetBIOS was designed for use by groups of PCs, sharing a broadcast    medium.  Both connection (Session) and connectionless (Datagram)    services are provided, and broadcast and multicast are supported.    Participants are identified by name.  Assignment of names is    distributed and highly dynamic. 
  295.  
  296.    NetBIOS applications employ NetBIOS mechanisms to locate resources,    establish connections, send and receive data with an application    peer, and terminate connections.  For purposes of discussion, these    mechanisms will collectively be called the NetBIOS Service. 
  297.  
  298.    This service can be implemented in many different ways.  One of the    first implementations was for personal computers running the PC-DOS    and MS-DOS operating systems.  It is possible to implement NetBIOS    within other operating systems, or as processes which are,    themselves, simply application programs as far as the host operating    system is concerned. 
  299.  
  300.    The NetBIOS specification, published by IBM as "Technical Reference    PC Network"[2] defines the interface and services available to the    NetBIOS user.  The protocols outlined by that document pertain only    to the IBM PC Network and are not generally applicable to other    networks. 
  301.  
  302. 5.1.  INTERFACE TO APPLICATION PROGRAMS 
  303.  
  304.    NetBIOS on personal computers includes both a set of services and an    exact program interface to those services.  NetBIOS on other computer    systems may present the NetBIOS services to programs using other    interfaces.  Except on personal computers, no clear standard for a    NetBIOS software interface has emerged. 
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  NetBIOS Working Group                                          [Page 10] 
  311.  RFC 1001                                                      March 1987 
  312.  
  313.  5.2.  NAME SERVICE 
  314.  
  315.    NetBIOS resources are referenced by name.  Lower-level address    information is not available to NetBIOS applications.  An    application, representing a resource, registers one or more names    that it wishes to use. 
  316.  
  317.    The name space is flat and uses sixteen alphanumeric characters.    Names may not start with an asterisk (*). 
  318.  
  319.    Registration is a bid for use of a name.  The bid may be for    exclusive (unique) or shared (group) ownership.  Each application    contends with the other applications in real time.  Implicit    permission is granted to a station when it receives no objections.    That is, a bid is made and the application waits for a period of    time.  If no objections are received, the station assumes that it has    permission. 
  320.  
  321.    A unique name should be held by only one station at a time.  However,    duplicates ("name conflicts") may arise due to errors. 
  322.  
  323.    All instances of a group name are equivalent. 
  324.  
  325.    An application referencing a name generally does not know (or care)    whether the name is registered as a unique or a group name. 
  326.  
  327.    An explicit name deletion function is specified, so that applications    may remove a name.  Implicit name deletion occurs when a station    ceases operation.  In the case of personal computers, implicit name    deletion is a frequent occurrence. 
  328.  
  329.    The Name Service primitives are: 
  330.  
  331.       1)   Add Name 
  332.  
  333.            The requesting application wants exclusive use of the name. 
  334.  
  335.       2)   Add Group Name 
  336.  
  337.            The requesting application is willing to share use of the            name with other applications. 
  338.  
  339.       3)   Delete Name 
  340.  
  341.            The application no longer requires use of the name.  It is            important to note that typical use of NetBIOS is among            independently-operated personal computers.  A common way to            stop using a PC is to turn it off; in this case, the            graceful give-back mechanism, provided by the Delete Name            function, is not used.  Because this occurs frequently, the            network service must support this behavior. 
  342.  
  343.  
  344.  
  345. NetBIOS Working Group                                          [Page 11] 
  346.  RFC 1001                                                      March 1987 
  347.  
  348.  5.3.  SESSION SERVICE 
  349.  
  350.    A session is a reliable message exchange, conducted between a pair of    NetBIOS applications.  Sessions are full-duplex, sequenced, and    reliable.  Data is organized into messages.  Each message may range    in size from 0 to 131,071 bytes.  No expedited or urgent data    capabilities are present. 
  351.  
  352.    Multiple sessions may exist between any pair of calling and called    names. 
  353.  
  354.    The parties to a connection have access to the calling and called    names. 
  355.  
  356.    The NetBIOS specification does not define how a connection request to    a shared (group) name resolves into a session.  The usual assumption    is that a session may be established with any one owner of the called    group name. 
  357.  
  358.    An important service provided to NetBIOS applications is the    detection of sessions failure.  The loss of a session is reported to    an application via all of the outstanding service requests for that    session.  For example, if the application has only a NetBIOS receive    primitive pending and the session terminates, the pending receive    will abort with a termination indication. 
  359.  
  360.    Session Service primitives are: 
  361.  
  362.       1)   Call 
  363.  
  364.            Initiate a session with a process that is listening under            the specified name.  The calling entity must indicate both a            calling name (properly registered to the caller) and a            called name. 
  365.  
  366.       2)   Listen 
  367.  
  368.            Accept a session from a caller.  The listen primitive may be            constrained to accept an incoming call from a named caller.            Alternatively, a call may be accepted from any caller. 
  369.  
  370.       3)   Hang Up 
  371.  
  372.            Gracefully terminate a session.  All pending data is            transferred before the session is terminated. 
  373.  
  374.       4)   Send 
  375.  
  376.            Transmit one message.  A time-out can occur.  A time-out of            any session send forces the non-graceful termination of the            session. 
  377.  
  378.  
  379.  
  380. NetBIOS Working Group                                          [Page 12] 
  381.  RFC 1001                                                      March 1987 
  382.  
  383.             A "chain send" primitive is required by the PC NetBIOS            software interface to allow a single message to be gathered            from pieces in various buffers.  Chain Send is an interface            detail and does not effect the protocol. 
  384.  
  385.       5)   Receive 
  386.  
  387.            Receive data.  A time-out can occur.  A time-out on a            session receive only terminates the receive, not the            session, although the data is lost. 
  388.  
  389.            The receive primitive may be implemented with variants, such            as "Receive Any", which is required by the PC NetBIOS            software interface.  Receive Any is an interface detail and            does not effect the protocol. 
  390.  
  391.       6)   Session Status 
  392.  
  393.            Obtain information about all of the requestor's sessions,            under the specified name.  No network activity is involved. 
  394.  
  395. 5.4.  DATAGRAM SERVICE 
  396.  
  397.    The Datagram service is an unreliable, non-sequenced, connectionless    service.  Datagrams are sent under cover of a name properly    registered to the sender. 
  398.  
  399.    Datagrams may be sent to a specific name or may be explicitly    broadcast. 
  400.  
  401.    Datagrams sent to an exclusive name are received, if at all, by the    holder of that name.  Datagrams sent to a group name are multicast to    all holders of that name.  The sending application program cannot    distinguish between group and unique names and thus must act as if    all non-broadcast datagrams are multicast. 
  402.  
  403.    As with the Session Service, the receiver of the datagram is told the    sending and receiving names. 
  404.  
  405.    Datagram Service primitives are: 
  406.  
  407.       1)   Send Datagram 
  408.  
  409.            Send an unreliable datagram to an application that is            associated with the specified name.  The name may be unique            or group; the sender is not aware of the difference.  If the            name belongs to a group, then each member is to receive the            datagram. 
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  NetBIOS Working Group                                          [Page 13] 
  416.  RFC 1001                                                      March 1987 
  417.  
  418.        2)   Send Broadcast Datagram 
  419.  
  420.            Send an unreliable datagram to any application with a            Receive Broadcast Datagram posted. 
  421.  
  422.       3)   Receive Datagram 
  423.  
  424.            Receive a datagram sent by a specified originating name to            the specified name.  If the originating name is an asterisk,            then the datagram may have been originated under any name. 
  425.  
  426.            Note: An arriving datagram will be delivered to all pending            Receiving Datagrams that have source and destination            specifications matching those of the datagram.  In other            words, if a program (or group of programs) issue a series of            identical Receive Datagrams, one datagram will cause the            entire series to complete. 
  427.  
  428.       4)   Receive Broadcast Datagram 
  429.  
  430.            Receive a datagram sent as a broadcast. 
  431.  
  432.            If there are multiple pending Receive Broadcast Datagram            operations pending, all will be satisfied by the same            received datagram. 
  433.  
  434. 5.5.  MISCELLANEOUS FUNCTIONS 
  435.  
  436.    The following functions are present to control the operation of the    hardware interface to the network.  These functions are generally    implementation dependent. 
  437.  
  438.       1)   Reset 
  439.  
  440.            Initialize the local network adapter. 
  441.  
  442.       2)   Cancel 
  443.  
  444.            Abort a pending NetBIOS request.  The successful cancel of a            Send (or Chain Send) operation will terminate the associated            session. 
  445.  
  446.       3)   Adapter Status 
  447.  
  448.            Obtain information about the local network adapter or of a            remote adapter. 
  449.  
  450.       4)   Unlink 
  451.  
  452.            For use with Remote Program Load (RPL).  Unlink redirects            the PC boot disk device back to the local disk.  See the 
  453.  
  454.  
  455.  
  456. NetBIOS Working Group                                          [Page 14] 
  457.  RFC 1001                                                      March 1987 
  458.  
  459.             NetBIOS specification for further details concerning RPL and            the Unlink operation (see page 2-35 in [2]). 
  460.  
  461.       5)   Remote Program Load 
  462.  
  463.            Remote Program Load (RPL) is not a NetBIOS function.  It is            a NetBIOS application defined by IBM in their NetBIOS            specification (see pages 2-80 through 2-82 in [2]). 
  464.  
  465. 5.6.  NON-STANDARD EXTENSIONS 
  466.  
  467.    The IBM Token Ring implementation of NetBIOS has added at least one    new user capability: 
  468.  
  469.       1)    Find Name 
  470.  
  471.            This function determines whether a given name has been            registered on the network. 
  472.  
  473. 6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 
  474.  
  475.    The protocol specified by this standard permits an implementer to    provide all of the NetBIOS services as described in the IBM    "Technical Reference PC Network"[2]. 
  476.  
  477.    The following NetBIOS facilities are outside the scope of this    specification.  These are local implementation matters and do not    impact interoperability: 
  478.  
  479.      -  RESET      -  SESSION STATUS      -  UNLINK      -  RPL (Remote Program Load) 
  480.  
  481. 7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 
  482.  
  483.    The protocols described in this RFC require service interfaces to the    following: 
  484.  
  485.      -  TCP[3,4]      -  UDP[5] 
  486.  
  487.    Byte ordering, addressing conventions (including addresses to be    used for broadcasts and multicasts) are defined by the most    recent version of: 
  488.  
  489.      -  Assigned Numbers[6] 
  490.  
  491.     Additional definitions and constraints are in: 
  492.  
  493.  
  494.  
  495.  NetBIOS Working Group                                          [Page 15] 
  496.  RFC 1001                                                      March 1987 
  497.  
  498.       -  IP[7]      -  Internet Subnets[8,9,10] 
  499.  
  500.  8.  RELATED PROTOCOLS AND SERVICES 
  501.  
  502.    The design of the protocols described in this RFC allow for the    future incorporation of the following protocols and services.    However, before this may occur, certain extensions may be required to    the protocols defined in this RFC or to those listed below. 
  503.  
  504.      -  Domain Name Service[11,12,13,14]      -  Internet Group Multicast[15,16] 
  505.  
  506. 9.  NetBIOS SCOPE 
  507.  
  508.    A "NetBIOS Scope" is the population of computers across which a    registered NetBIOS name is known.  NetBIOS broadcast and multicast    datagram operations must reach the entire extent of the NetBIOS    scope. 
  509.  
  510.    An internet may support multiple, non-intersecting NetBIOS Scopes. 
  511.  
  512.    Each NetBIOS scope has a "scope identifier".  This identifier is a    character string meeting the requirements of the domain name system    for domain names. 
  513.  
  514.    NOTE: Each implementation of NetBIOS-over-TCP must provide          mechanisms to manage the scope identifier(s) to be used. 
  515.  
  516.    Control of scope identifiers implies a requirement for additional    NetBIOS interface capabilities.  These may be provided through    extensions of the user service interface or other means (such as node    configuration parameters.)  The nature of these extensions is not    part of this specification. 
  517.  
  518. 10.  NetBIOS END-NODES 
  519.  
  520.    End-nodes support NetBIOS service interfaces and contain    applications. 
  521.  
  522.    Three types of end-nodes are part of this standard: 
  523.  
  524.      -  Broadcast ("B") nodes      -  Point-to-point ("P") nodes      -  Mixed mode ("M") nodes 
  525.  
  526.    An IP address may be associated with only one instance of one of the    above types. 
  527.  
  528.    Without having preloaded name-to-address tables, NetBIOS participants 
  529.  
  530.  
  531.  
  532. NetBIOS Working Group                                          [Page 16] 
  533.  RFC 1001                                                      March 1987 
  534.  
  535.     are faced with the task of dynamically resolving references to one    another.  This can be accomplished with broadcast or mediated point-    to-point communications. 
  536.  
  537.    B nodes use local network broadcasting to effect a rendezvous with    one or more recipients.  P and M nodes use the NetBIOS Name Server    (NBNS) and the NetBIOS Datagram Distribution Server (NBDD) for this    same purpose. 
  538.  
  539.    End-nodes may be combined in various topologies.  No matter how    combined, the operation of the B, P, and M nodes is not altered. 
  540.  
  541.    NOTE: It is recommended that the administration of a NetBIOS          scope avoid using both M and B nodes within the same scope.          A NetBIOS scope should contain only B nodes or only P and M          nodes. 
  542.  
  543. 10.1.  BROADCAST (B) NODES 
  544.  
  545.    Broadcast (or "B") nodes communicate using a mix of UDP datagrams    (both broadcast and directed) and TCP connections.  B nodes may    freely interoperate with one another within a broadcast area.  A    broadcast area is a single MAC-bridged "B-LAN".  (See Appendix A for    a discussion of using Internet Group Multicasting as a means to    extend a broadcast area beyond a single B-LAN.) 
  546.  
  547. 10.2.  POINT-TO-POINT (P) NODES 
  548.  
  549.    Point-to-point (or "P") nodes communicate using only directed UDP    datagrams and TCP sessions.  P nodes neither generate nor listen for    broadcast UDP packets.  P nodes do, however, offer NetBIOS level    broadcast and multicast services using capabilities provided by the    NBNS and NBDD. 
  550.  
  551.    P nodes rely on NetBIOS name and datagram distribution servers.    These servers may be local or remote; P nodes operate the same in    either case. 
  552.  
  553. 10.3.  MIXED MODE (M) NODES 
  554.  
  555.    Mixed mode nodes (or "M") nodes are P nodes which have been given    certain B node characteristics.  M nodes use both broadcast and    unicast.  Broadcast is used to improve response time using the    assumption that most resources reside on the local broadcast medium    rather than somewhere in an internet. 
  556.  
  557.    M nodes rely upon NBNS and NBDD servers.  However, M nodes may    continue limited operation should these servers be temporarily    unavailable. 
  558.  
  559.  
  560.  
  561.  
  562.  
  563. NetBIOS Working Group                                          [Page 17] 
  564.  RFC 1001                                                      March 1987 
  565.  
  566.  11.  NetBIOS SUPPORT SERVERS 
  567.  
  568.    Two types of support servers are part of this standard: 
  569.  
  570.      -  NetBIOS name server ("NBNS") nodes      -  Netbios datagram distribution ("NBDD") nodes 
  571.  
  572.    NBNS and NBDD nodes are invisible to NetBIOS applications and are    part of the underlying NetBIOS mechanism. 
  573.  
  574.    NetBIOS name and datagram distribution servers are the focus of name    and datagram activity for P and M nodes. 
  575.  
  576.    Both the name (NBNS) and datagram distribution (NBDD) servers are    permitted to shift part of their operation to the P or M end-node    which is requesting a service. 
  577.  
  578.    Since the assignment of responsibility is dynamic, and since P and M    nodes must be prepared to operate should the NetBIOS server delegate    control to the maximum extent, the system naturally accommodates    improvements in NetBIOS server function.  For example, as Internet    Group Multicasting becomes more widespread, new NBDD implementations    may elect to assume full responsibility for NetBIOS datagram    distribution. 
  579.  
  580.    Interoperability between different implementations is assured by    imposing requirements on end-node implementations that they be able    to accept the full range of legal responses from the NBNS or NBDD. 
  581.  
  582. 11.1.  NetBIOS NAME SERVER (NBNS) NODES 
  583.  
  584.    The NBNS is designed to allow considerable flexibility with its    degree of responsibility for the accuracy and management of NetBIOS    names.  On one hand, the NBNS may elect not to accept full    responsibility, leaving the NBNS essentially a "bulletin board" on    which name/address information is freely posted (and removed) by P    and M nodes without validation by the NBNS.  Alternatively, the NBNS    may elect to completely manage and validate names.  The degree of    responsibility that the NBNS assumes is asserted by the NBNS each    time a name is claimed through a simple mechanism.  Should the NBNS    not assert full control, the NBNS returns enough information to the    requesting node so that the node may challenge any putative holder of    the name. 
  585.  
  586.    This ability to shift responsibility for NetBIOS name management    between the NBNS and the P and M nodes allows a network administrator    (or vendor) to make a tradeoff between NBNS simplicity, security, and    delay characteristics. 
  587.  
  588.    A single NBNS may be implemented as a distributed entity, such as the    Domain Name Service.  However, this RFC does not attempt to define 
  589.  
  590.  
  591.  
  592. NetBIOS Working Group                                          [Page 18] 
  593.  RFC 1001                                                      March 1987 
  594.  
  595.     the internal communications which would be used. 
  596.  
  597. 11.1.1.  RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM 
  598.  
  599.    The NBNS design attempts to align itself with the Domain Name System    in a number of ways. 
  600.  
  601.    First, the NetBIOS names are encoded in a form acceptable to the    domain name system. 
  602.  
  603.    Second, a scope identifier is appended to each NetBIOS name.  This    identifier meets the restricted character set of the domain system    and has a leading period.  This makes the NetBIOS name, in    conjunction with its scope identifier, a valid domain system name. 
  604.  
  605.    Third, the negotiated responsibility mechanisms permit the NBNS to be    used as a simple bulletin board on which are posted (name,address)    pairs.  This parallels the existing domain sytem query service. 
  606.  
  607.    This RFC, however, requires the NBNS to provide services beyond those    provided by the current domain name system.  An attempt has been made    to coalesce all the additional services which are required into a set    of transactions which follow domain name system styles of interaction    and packet formats. 
  608.  
  609.    Among the areas in which the domain name service must be extended    before it may be used as an NBNS are: 
  610.  
  611.      -  Dynamic addition of entries      -  Dynamic update of entry data      -  Support for multiple instance (group) entries      -  Support for entry time-to-live values and ability to accept         refresh messages to restart the time-to-live period      -  New entry attributes 
  612.  
  613. 11.2.  NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES 
  614.  
  615.    The internet does not yet support broadcasting or multicasting.  The    NBDD extends NetBIOS datagram distribution service to this    environment. 
  616.  
  617.    The NBDD may elect to complete, partially complete, or totally refuse    to service a node's request to distribute a NetBIOS datagram.  An    end-node may query an NBDD to determine whether the NBDD will deliver    a datagram to a specific NetBIOS name. 
  618.  
  619.    The design of NetBIOS-over-TCP lends itself to the use of Internet    Group Multicast.  For details see Appendix A. 
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  NetBIOS Working Group                                          [Page 19] 
  626.  RFC 1001                                                      March 1987 
  627.  
  628.  11.3.  RELATIONSHIP OF NBNS AND NBDD NODES 
  629.  
  630.    This RFC defines the NBNS and NBDD as distinct, separate entities. 
  631.  
  632.    In the absence of NetBIOS name information, a NetBIOS datagram    distribution server must send a copy to each end-node within a    NetBIOS scope. 
  633.  
  634.    An implementer may elect to construct NBNS and NBDD nodes which have    a private protocol for the exchange of NetBIOS name information.    Alternatively, an NBNS and NBDD may be implemented within the same    device. 
  635.  
  636.    NOTE: Implementations containing private NBNS-NBDD protocols or          combined NBNS-NBDD functions must be clearly identified. 
  637.  
  638. 11.4.  RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES 
  639.  
  640.    As defined in this RFC, neither NBNS nor NBDD nodes interact with B    nodes.  NetBIOS servers do not listen to broadcast traffic on any    broadcast area to which they may be attached.  Nor are the NetBIOS    support servers even aware of B node activities or names claimed or    used by B nodes. 
  641.  
  642.    It may be possible to extend both the NBNS and NBDD so that they    participate in B node activities and act as a bridge to P and M    nodes.  However, such extensions are beyond the scope of this    specification. 
  643.  
  644. 12.  TOPOLOGIES 
  645.  
  646.    B, P, M, NBNS, and NBDD nodes may be combined in various ways to form    useful NetBIOS environments.  This section describes some of these    combinations. 
  647.  
  648.    There are three classes of operation: 
  649.  
  650.      -  Class 0:  B nodes only.      -  Class 1:  P nodes only.      -  Class 2:  P and M nodes together. 
  651.  
  652.    In the drawings which follow, any P node may be replaced by an M    node.  The effects of such replacement will be mentioned in    conjunction with each example below. 
  653.  
  654. 12.1.  LOCAL 
  655.  
  656.    A NetBIOS scope is operating locally when all entities are within the    same broadcast area. 
  657.  
  658.  
  659.  
  660.  
  661.  
  662. NetBIOS Working Group                                          [Page 20] 
  663.  RFC 1001                                                      March 1987 
  664.  
  665.  12.1.1.  B NODES ONLY 
  666.  
  667.    Local operation with only B nodes is the most basic mode of    operation.  Name registration and discovery procedures use broadcast    mechanisms.  The NetBIOS scope is limited by the extent of the    broadcast area.  This configuration does not require NetBIOS support    servers. 
  668.  
  669.    ====+=========+=====BROADCAST AREA=====+==========+=========+====        |         |                        |          |         |        |         |                        |          |         |     +--+--+   +--+--+                  +--+--+    +--+--+   +--+--+     |  B  |   |  B  |                  |  B  |    |  B  |   |  B  |     +-----+   +-----+                  +-----+    +-----+   +-----+ 
  670.  
  671. 12.1.2.  P NODES ONLY 
  672.  
  673.    This configuration would typically be used when the network    administrator desires to eliminate NetBIOS as a source of broadcast    activity. 
  674.  
  675.     ====+=========+==========+=B'CAST AREA=+==========+=========+====        |         |          |             |          |         |        |         |          |             |          |         |     +--+--+   +--+--+    +--+--+       +--+--+    +--+--+   +--+--+     |  P  |   |  P  |    |NBNS |       |  P  |    |NBDD |   |  P  |     +-----+   +-----+    +-----+       +-----+    +-----+   +-----+ 
  676.  
  677.     This configuration operates the same as if it were in an internet and    is cited here only due to its convenience as a means to reduce the    use of broadcast. 
  678.  
  679.    Replacement of one or more of the P nodes with M nodes will not    affect the operation of the other P and M nodes.  P and M nodes will    be able to interact with one another.  Because M nodes use broadcast,    overall broadcast activity will increase. 
  680.  
  681. 12.1.3.  MIXED B AND P NODES 
  682.  
  683.    B and P nodes do not interact with one another.  Replacement of P    nodes with M nodes will allow B's and M's to interact. 
  684.  
  685.    NOTE: B nodes and M nodes may be intermixed only on a local          broadcast area.  B and M nodes should not be intermixed in          an internet environment. 
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693. NetBIOS Working Group                                          [Page 21] 
  694.  RFC 1001                                                      March 1987 
  695.  
  696.  12.2.  INTERNET 
  697.  
  698. 12.2.1.  P NODES ONLY 
  699.  
  700.    P nodes may be scattered at various locations in an internetwork.    They require both an NBNS and an NBDD for NetBIOS name and datagram    support, respectively. 
  701.  
  702.    The NetBIOS scope is determined by the NetBIOS scope identifier    (domain name) used by the various P (and M) nodes.  An internet may    contain numerous NetBIOS scopes. 
  703.  
  704.                    +-----+                    |  P  |                    +--+--+              |    +-----+                       |                 |----+  P  |                       |                 |    +-----+                 /-----+-----\           |    +-----+      |           |  +------+ |    +-----+    |  P  +------+  INTERNET +--+G'WAY |-+----+  P  |    +-----+      |           |  +------+ |    +-----+                 /-----+-----/           |               /       |                 |    +-----+             /         |                 |----+  P  |      +-----+       +--+--+              |    +-----+      |NBNS +       |NBDD |      +-----+       +--+--+ 
  705.  
  706.    Any P node may be replaced by an M node with no loss of function to    any node.  However, broadcast activity will be increased in the    broadcast area to which the M node is attached. 
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. NetBIOS Working Group                                          [Page 22] 
  731.  RFC 1001                                                      March 1987 
  732.  
  733.  12.2.2.  MIXED M AND P NODES 
  734.  
  735.    M and P nodes may be mixed.  When locating NetBIOS names, M nodes    will tend to find names held by other M nodes on the same common    broadcast area in preference to names held by P nodes or M nodes    elsewhere in the network. 
  736.  
  737.                          +-----+                          |  P  |                          +--+--+                             |                             |                       /-----+-----\          +-----+      |           |      +-----+          |  P  +------+  INTERNET +------+NBDD |          +-----+      |           |      +-----+                       /-----+-----/                     /       |                   /         |            +-----+       +--+--+            |NBNS +       |G'WAY|            +-----+       +--+--+                             |                             |    ====+=========+==========+=B'CAST AREA=+==========+=========+====        |         |          |             |          |         |        |         |          |             |          |         |     +--+--+   +--+--+    +--+--+       +--+--+    +--+--+   +--+--+     |  M  |   |  P  |    |  M  |       |  P  |    |  M  |   |  P  |     +-----+   +-----+    +--+--+       +-----+    +-----+   +-----+ 
  738.  
  739.     NOTE: B and M nodes should not be intermixed in an internet          environment.  Doing so would allow undetected NetBIOS name          conflicts to arise and cause unpredictable behavior. 
  740.  
  741. 13.  GENERAL METHODS 
  742.  
  743.    Overlying the specific protocols, described later, are a few general    methods of interaction between entities. 
  744.  
  745. 13.1.  REQUEST/RESPONSE INTERACTION STYLE 
  746.  
  747.    Most interactions between entities consist of a request flowing in    one direction and a subsequent response flowing in the opposite    direction. 
  748.  
  749.    In those situations where interactions occur on unreliable transports    (i.e. UDP) or when a request is broadcast, there may not be a strict    interlocking or one-to-one relationship between requests and    responses. 
  750.  
  751.  
  752.  
  753. NetBIOS Working Group                                          [Page 23] 
  754.  RFC 1001                                                      March 1987 
  755.  
  756.     In no case, however, is more than one response generated for a    received request.  While a response is pending the responding entity    may send one or more wait acknowledgements. 
  757.  
  758. 13.1.1.  RETRANSMISSION OF REQUESTS 
  759.  
  760.    UDP is an unreliable delivery mechanism where packets can be lost,    received out of transmit sequence, duplicated and delivery can be    significantly delayed.  Since the NetBIOS protocols make heavy use of    UDP, they have compensated for its unreliability with extra    mechanisms. 
  761.  
  762.    Each NetBIOS packet contains all the necessary information to process    it.  None of the protocols use multiple UDP packets to convey a    single request or response.  If more information is required than    will fit in a single UDP packet, for example, when a P-type node    wants all the owners of a group name from a NetBIOS server, a TCP    connection is used.  Consequently, the NetBIOS protocols will not    fail because of out of sequence delivery of UDP packets. 
  763.  
  764.    To overcome the loss of a request or response packet, each request    operation will retransmit the request if a response is not received    within a specified time limit. 
  765.  
  766.    Protocol operations sensitive to successive response packets, such as    name conflict detection, are protected from duplicated packets    because they ignore successive packets with the same NetBIOS    information.  Since no state on the responder's node is associated    with a request, the responder just sends the appropriate response    whenever a request packet arrives.  Consequently, duplicate or    delayed request packets have no impact. 
  767.  
  768.    For all requests, if a response packet is delayed too long another    request packet will be transmitted.  A second response packet being    sent in response to the second request packet is equivalent to a    duplicate packet.  Therefore, the protocols will ignore the second    packet received.  If the delivery of a response is delayed until    after the request operation has been completed, successfully or not,    the response packet is ignored. 
  769.  
  770. 13.1.2.  REQUESTS WITHOUT RESPONSES: DEMANDS 
  771.  
  772.    Some request types do not have matching responses.  These requests    are known as "demands".  In general a "demand" is an imperative    request; the receiving node is expected to obey.  However, because    demands are unconfirmed, they are used only in situations where, at    most, limited damage would occur if the demand packet should be lost. 
  773.  
  774.    Demand packets are not retransmitted. 
  775.  
  776.  
  777.  
  778.  
  779.  
  780. NetBIOS Working Group                                          [Page 24] 
  781.  RFC 1001                                                      March 1987 
  782.  
  783.  13.2.  TRANSACTIONS 
  784.  
  785.    Interactions between a pair of entities are grouped into    "transactions".  These transactions comprise one or more    request/response pairs. 
  786.  
  787. 13.2.1.  TRANSACTION ID 
  788.  
  789.    Since multiple simultaneous transactions may be in progress between a    pair of entities a "transaction id" is used. 
  790.  
  791.    The originator of a transaction selects an ID unique to the    originator.  The transaction id is reflected back and forth in each    interaction within the transaction.  The transaction partners must    match responses and requests by comparison of the transaction ID and    the IP address of the transaction partner.  If no matching request    can be found the response must be discarded. 
  792.  
  793.    A new transaction ID should be used for each transaction.  A simple    16 bit transaction counter ought to be an adequate id generator.  It    is probably not necessary to search the space of outstanding    transaction ID to filter duplicates: it is extremely unlikely that    any transaction will have a lifetime that is more than a small    fraction of the typical counter cycle period.  Use of the IP    addresses in conjunction with the transaction ID further reduces the    possibility of damage should transaction IDs be prematurely re-used. 
  794.  
  795. 13.3.  TCP AND UDP FOUNDATIONS 
  796.  
  797.    This version of the NetBIOS-over-TCP protocols uses UDP for many    interactions.  In the future this RFC may be extended to permit such    interactions to occur over TCP connections (perhaps to increase    efficiency when multiple interactions occur within a short time or    when NetBIOS datagram traffic reveals that an application is using    NetBIOS datagrams to support connection- oriented service.) 
  798.  
  799. 14.  REPRESENTATION OF NETBIOS NAMES 
  800.  
  801.    NetBIOS names as seen across the client interface to NetBIOS are    exactly 16 bytes long.  Within the NetBIOS-over-TCP protocols, a    longer representation is used. 
  802.  
  803.    There are two levels of encoding.  The first level maps a NetBIOS    name into a domain system name.  The second level maps the domain    system name into the "compressed" representation required for    interaction with the domain name system. 
  804.  
  805.    Except in one packet, the second level representation is the only    NetBIOS name representation used in NetBIOS-over-TCP packet formats.    The exception is the RDATA field of a NODE STATUS RESPONSE packet. 
  806.  
  807.  
  808.  
  809.  NetBIOS Working Group                                          [Page 25] 
  810.  RFC 1001                                                      March 1987 
  811.  
  812.  14.1.  FIRST LEVEL ENCODING 
  813.  
  814.    The first level representation consists of two parts: 
  815.  
  816.      -  NetBIOS name      -  NetBIOS scope identifier 
  817.  
  818.    The 16 byte NetBIOS name is mapped into a 32 byte wide field using a    reversible, half-ASCII, biased encoding.  Each half-octet of the    NetBIOS name is encoded into one byte of the 32 byte field.  The    first half octet is encoded into the first byte, the second half-    octet into the second byte, etc. 
  819.  
  820.    Each 4-bit, half-octet of the NetBIOS name is treated as an 8-bit,    right-adjusted, zero-filled binary number.  This number is added to    value of the ASCII character 'A' (hexidecimal 41).  The resulting 8-    bit number is stored in the appropriate byte.  The following diagram    demonstrates this procedure: 
  821.  
  822.                           0 1 2 3 4 5 6 7                         +-+-+-+-+-+-+-+-+                         |a b c d|w x y z|          ORIGINAL BYTE                         +-+-+-+-+-+-+-+-+                             |       |                    +--------+       +--------+                    |                         |     SPLIT THE NIBBLES                    v                         v             0 1 2 3 4 5 6 7           0 1 2 3 4 5 6 7            +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+            |0 0 0 0 a b c d|         |0 0 0 0 w x y z|            +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+                    |                         |                    +                         +     ADD 'A'                    |                         |             0 1 2 3 4 5 6 7           0 1 2 3 4 5 6 7            +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+            |0 1 0 0 0 0 0 1|         |0 1 0 0 0 0 0 1|            +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+ 
  823.  
  824.    This encoding results in a NetBIOS name being represented as a    sequence of 32 ASCII, upper-case characters from the set    {A,B,C...N,O,P}. 
  825.  
  826.    The NetBIOS scope identifier is a valid domain name (without a    leading dot). 
  827.  
  828.    An ASCII dot (2E hexidecimal) and the scope identifier are appended    to the encoded form of the NetBIOS name, the result forming a valid    domain name. 
  829.  
  830.  
  831.  
  832.  NetBIOS Working Group                                          [Page 26] 
  833.  RFC 1001                                                      March 1987 
  834.  
  835.     For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope    "SCOPE.ID.COM" would be represented at level one by the ASCII    character string: 
  836.  
  837.         FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM 
  838.  
  839. 14.2.  SECOND LEVEL ENCODING 
  840.  
  841.    The first level encoding must be reduced to second level encoding.    This is performed according to the rules defined in on page 31 of RFC    883[12] in the section on "Domain name representation and    compression".  Also see the section titled "Name Formats" in the    Detailed Specifications[1]. 
  842.  
  843. 15.  NetBIOS NAME SERVICE 
  844.  
  845.    Before a name may be used, the name must be registered by a node.    Once acquired, the name must be defended against inconsistent    registration by other nodes.  Before building a NetBIOS session or    sending a NetBIOS datagram, the one or more holders of the name must    be located. 
  846.  
  847.    The NetBIOS name service is the collection of procedures through    which nodes acquire, defend, and locate the holders of NetBIOS names. 
  848.  
  849.    The name service procedures are different depending whether the end-    node is of type B, P, or M. 
  850.  
  851. 15.1.  OVERVIEW OF NetBIOS NAME SERVICE 
  852.  
  853. 15.1.1.  NAME REGISTRATION (CLAIM) 
  854.  
  855.    Each NetBIOS node can own more than one name.  Names are acquired    dynamically through the registration (name claim) procedures. 
  856.  
  857.    Every node has a permanent unique name.  This name, like any other    name, must be explicitly registered by all end-node types. 
  858.  
  859.    A name can be unique (exclusive) or group (non-exclusive).  A unique    name may be owned by a single node; a group name may be owned by any    number of nodes.  A name ceases to exist when it is not owned by at    least one node.  There is no intrinsic quality of a name which    determines its characteristics: these are established at the time of    registration. 
  860.  
  861.    Each node maintains state information for each name it has    registered.  This information includes: 
  862.  
  863.      -  Whether the name is a group or unique name      -  Whether the name is "in conflict"      -  Whether the name is in the process of being deleted 
  864.  
  865.  
  866.  
  867. NetBIOS Working Group                                          [Page 27] 
  868.  RFC 1001                                                      March 1987 
  869.  
  870.     B nodes perform name registration by broadcasting claim requests,    soliciting a defense from any node already holding the name. 
  871.  
  872.    P nodes perform name registration through the agency of the NBNS. 
  873.  
  874.    M nodes register names through an initial broadcast, like B nodes,    then, in the absence of an objection, by following the same    procedures as a P node.  In other words, the broadcast action may    terminate the attempt, but is not sufficient to confirm the    registration. 
  875.  
  876. 15.1.2.  NAME QUERY (DISCOVERY) 
  877.  
  878.    Name query (also known as "resolution" or "discovery") is the    procedure by which the IP address(es) associated with a NetBIOS name    are discovered.  Name query is required during the following    operations: 
  879.  
  880.    During session establishment, calling and called names must be    specified.  The calling name must exist on the node that posts the    CALL.  The called name must exist on a node that has previously    posted a LISTEN.  Either name may be a unique or group name. 
  881.  
  882.    When a directed datagram is sent, a source and destination name must    be specified.  If the destination name is a group name, a datagram is    sent to all the members of that group. 
  883.  
  884.    Different end-node types perform name resolution using different    techniques, but using the same packet formats: 
  885.  
  886.      -  B nodes solicit name information by broadcasting a request. 
  887.  
  888.      -  P nodes ask the NBNS. 
  889.  
  890.      -  M nodes broadcast a request.  If that does not provide the         desired information, an inquiry is sent to the NBNS. 
  891.  
  892. 15.1.3.  NAME RELEASE 
  893.  
  894.    NetBIOS names may be released explicitly or silently by an end- node.    Silent release typically occurs when an end-node fails or is turned-    off.  Most of the mechanisms described below are present to detect    silent name release. 
  895.  
  896. 15.1.3.1.  EXPLICIT RELEASE 
  897.  
  898.    B nodes explicitly release a name by broadcasting a notice. 
  899.  
  900.    P nodes send a notification to their NBNS. 
  901.  
  902.    M nodes both broadcast a notice and inform their supporting NBNS. 
  903.  
  904.  
  905.  
  906. NetBIOS Working Group                                          [Page 28] 
  907.  RFC 1001                                                      March 1987 
  908.  
  909.  15.1.3.2.  NAME LIFETIME AND REFRESH 
  910.  
  911.    Names held by an NBNS are given a lifetime during name registration.    The NBNS will consider a name to have been silently released if the    end-node fails to send a name refresh message to the NBNS before the    lifetime expires.  A refresh restarts the lifetime clock. 
  912.  
  913.    NOTE: The implementor should be aware of the tradeoff between          accuracy of the database and the internet overhead that the          refresh mechanism introduces.  The lifetime period should          be tuned accordingly. 
  914.  
  915.     For group names, each end-node must send refresh messages.  A node    that fails to do so will be considered to have silently released the    name and dropped from the group. 
  916.  
  917.    The lifetime period is established through a simple negotiation    mechanism during name registration:  In the name registration    request, the end-node proposes a lifetime value or requests an    infinite lifetime.  The NBNS places an actual lifetime value into the    name registration response.  The NBNS is always allowed to respond    with an infinite actual period.  If the end node proposed an infinite    lifetime, the NBNS may respond with any definite period.  If the end    node proposed a definite period, the NBNS may respond with any    definite period greater than or equal to that proposed. 
  918.  
  919.    This negotiation of refresh times gives the NBNS means to disable or    enable refresh activity.  The end-nodes may set a minimum refresh    cycle period. 
  920.  
  921.    NBNS implementations which are completely reliable may disable    refresh. 
  922.  
  923. 15.1.3.3.  NAME CHALLENGE 
  924.  
  925.    To detect whether a node has silently released its claim to a name,    it is necessary on occasion to challenge that node's current    ownership.  If the node defends the name then the node is allowed to    continue possession.  Otherwise it is assumed that the node has    released the name. 
  926.  
  927.    A name challenge may be issued by an NBNS or by a P or M node.  A    challenge may be directed towards any end-node type: B, P, or M. 
  928.  
  929. 15.1.3.4.  GROUP NAME FADE-OUT 
  930.  
  931.    NetBIOS groups may contain an arbitrarily large number of members.    The time to challenge all members could be quite large. 
  932.  
  933.    To avoid long delays when names are claimed through an NBNS, an 
  934.  
  935.  
  936.  
  937. NetBIOS Working Group                                          [Page 29] 
  938.  RFC 1001                                                      March 1987 
  939.  
  940.     optimistic heuristic has been adopted.  It is assumed that there will    always be some node which will defend a group name.  Consequently, it    is recommended that the NBNS will immediately reject a claim request    for a unique name when there already exists a group with the same    name.  The NBNS will never return an IP address (in response to a    NAME REGISTRATION REQUEST) when a group name exists. 
  941.  
  942.    An NBNS will consider a group to have faded out of existence when the    last remaining member fails to send a timely refresh message or    explicitly releases the name. 
  943.  
  944. 15.1.3.5.  NAME CONFLICT 
  945.  
  946.    Name conflict exists when a unique name has been claimed by more than    one node on a NetBIOS network.  B, M, and NBNS nodes may detect a    name conflict.  The detection mechanism used by B and M nodes is    active only during name discovery.  The NBNS may detect conflict at    any time it verifies the consistency of its name database. 
  947.  
  948.    B and M nodes detect conflict by examining the responses received in    answer to a broadcast name query request.  The first response is    taken as authoritative.  Any subsequent, inconsistent responses    represent conflicts. 
  949.  
  950.    Subsequent responses are inconsistent with the authoritative response    when: 
  951.  
  952.         The subsequent response has the same transaction ID as the         NAME QUERY REQUEST.      AND         The subsequent response is not a duplicate of the         authoritative response.      AND EITHER:              The group/unique characteristic of the authoritative              response is "unique".           OR              The group/unique characteristic of the subsequent              response is "unique". 
  953.  
  954.    The period in which B and M nodes examine responses is limited by a    conflict timer, CONFLICT_TIMER.  The accuracy or duration of this    timer is not crucial: the NetBIOS system will continue to operate    even with persistent name conflicts. 
  955.  
  956.    Conflict conditions are signaled by sending a NAME CONFLICT DEMAND to    the node owning the offending name.  Nothing is sent to the node    which originated the authoritative response. 
  957.  
  958.    Any end-node that receives NAME CONFLICT DEMAND is required to update    its "local name table" to reflect that the name is in conflict.  (The    "local name table" on each node contains names that have been 
  959.  
  960.  
  961.  
  962. NetBIOS Working Group                                          [Page 30] 
  963.  RFC 1001                                                      March 1987 
  964.  
  965.     successfully registered by that node.) 
  966.  
  967.    Notice that only those nodes that receive the name conflict message    place a conflict mark next to a name. 
  968.  
  969.    Logically, a marked name does not exist on that node.  This means    that the node should not defend the name (for name claim purposes),    should not respond to a name discovery requests for that name, nor    should the node send name refresh messages for that name.    Furthermore, it can no longer be used by that node for any session    establishment or sending or receiving datagrams.  Existing sessions    are not affected at the time a name is marked as being in conflict. 
  970.  
  971.    The only valid user function against a marked name is DELETE NAME.    Any other user NetBIOS function returns immediately with an error    code of "NAME CONFLICT". 
  972.  
  973. 15.1.4.  ADAPTER STATUS 
  974.  
  975.    An end-node or the NBNS may ask any other end-node for a collection    of information about the NetBIOS status of that node.  This status    consists of, among other things, a list of the names which the node    believes it owns.  The returned status is filtered to contain only    those names which have the same NetBIOS scope identifier as the    requestor's name. 
  976.  
  977.    When requesting node status, the requestor identifies the target node    by NetBIOS name  A name query transaction may be necessary to acquire    the IP address for the name.  Locally cached name information may be    used in lieu of a query transaction.  The requesting node sends a    NODE STATUS REQUEST.  In response, the receiving node sends a NODE    STATUS RESPONSE containing its local name table and various    statistics. 
  978.  
  979.    The amount of status which may be returned is limited by the size of    a UDP packet.  However, this is sufficient for the typical NODE    STATUS RESPONSE packet. 
  980.  
  981. 15.1.5.  END-NODE NBNS INTERACTION 
  982.  
  983.    There are certain characteristics of end-node to NBNS interactions    which are in common and are independent of any particular transaction    type. 
  984.  
  985. 15.1.5.1.  UDP, TCP, AND TRUNCATION 
  986.  
  987.    For all transactions between an end-node and an NBNS, either UDP or    TCP may be used as a transport.  If the NBNS receives a UDP based    request, it will respond using UDP.  If the amount of information    exceeds what fits into a UDP packet, the response will contain a    "truncation flag".  In this situation, the end- node may open a TCP 
  988.  
  989.  
  990.  
  991. NetBIOS Working Group                                          [Page 31] 
  992.  RFC 1001                                                      March 1987 
  993.  
  994.     connection to the NBNS, repeat the request, and receive a complete,    untruncated response. 
  995.  
  996. 15.1.5.2.  NBNS WACK 
  997.  
  998.    While a name service request is in progress, the NBNS may issue a    WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK) to assure the client end-    node that the NBNS is still operational and is working on the    request. 
  999.  
  1000. 15.1.5.3.  NBNS REDIRECTION 
  1001.  
  1002.    The NBNS, because it follows Domain Name system styles of    interaction, is permitted to redirect a client to another NBNS. 
  1003.  
  1004. 15.1.6.  SECURED VERSUS NON-SECURED NBNS 
  1005.  
  1006.    An NBNS may be implemented in either of two general ways:  The NBNS    may monitor, and participate in, name activity to ensure consistency.    This would be a "secured" style NBNS.  Alternatively, an NBNS may be    implemented to be essentially a "bulletin board" on which name    information is posted and responsibility for consistency is delegated    to the end-nodes.  This would be a "non-secured" style NBNS. 
  1007.  
  1008. 15.1.7.  CONSISTENCY OF THE NBNS DATA BASE 
  1009.  
  1010.    Even in a properly running NetBIOS scope the NBNS and its community    of end-nodes may occasionally lose synchronization with respect to    the true state of name registrations. 
  1011.  
  1012.    This may occur should the NBNS fail and lose all or part of its    database. 
  1013.  
  1014.    More commonly, a P or M node may be turned-off (thus forgetting the    names it has registered) and then be subsequently turned back on. 
  1015.  
  1016.    Finally, errors may occur or an implementation may be incorrect. 
  1017.  
  1018.    Various approaches have been incorporated into the NetBIOS-over- TCP    protocols to minimize the impact of these problems. 
  1019.  
  1020.       1.   The NBNS (or any other node) may "challenge" (using a NAME            QUERY REQUEST) an end-node to verify that it actually owns a            name. 
  1021.  
  1022.            Such a challenge may occur at any time.  Every end-node must            be prepared to make a timely response. 
  1023.  
  1024.            Failure to respond causes the NBNS to consider that the            end-node has released the name in question. 
  1025.  
  1026.  
  1027.  
  1028.  NetBIOS Working Group                                          [Page 32] 
  1029.  RFC 1001                                                      March 1987 
  1030.  
  1031.             (If UDP is being used as the underlying transport, the            challenge, like all other requests, must be retransmitted            some number of times in the absence of a response.) 
  1032.  
  1033.       2.   The NBNS (or any other node) may request (using the NODE            STATUS REQUEST) that an end-node deliver its entire name            table. 
  1034.  
  1035.            This may occur at any time.  Every end-node must be prepared            to make a timely response. 
  1036.  
  1037.            Failure to respond permits (but does not require) the NBNS            to consider that the end-node has failed and released all            names to which it had claims.  (Like the challenge, on a UDP            transport, the request must be retransmitted in the absence            of a response.) 
  1038.  
  1039.       3.   The NBNS may revoke a P or M node's use of a name by sending            either a NAME CONFLICT DEMAND or a NAME RELEASE REQUEST to            the node. 
  1040.  
  1041.            The receiving end-node may continue existing sessions which            use that name, but must otherwise cease using that name.  If            the NBNS placed the name in conflict, the name may be re-            acquired only by deletion and subsequent reclamation.  If            the NBNS requested that the name be released, the node may            attempt to re-acquire the name without first performing a            name release transaction. 
  1042.  
  1043.       4.   The NBNS may impose a "time-to-live" on each name it            registers.  The registering node is made aware of this time            value during the name registration procedure. 
  1044.  
  1045.            Simple or reliable NBNS's may impose an infinite time-to-            live. 
  1046.  
  1047.       5.   If an end-node holds any names that have finite time-to-            live values, then that node must periodically send a status            report to the NBNS.  Each name is reported using the NAME            REFRESH REQUEST packet. 
  1048.  
  1049.            These status reports restart the timers of both the NBNS and            the reporting node.  However, the only timers which are            restarted are those associated with the name found in the            status report.  Timers on other names are not affected. 
  1050.  
  1051.            The NBNS may consider that a node has released any name            which has not been refreshed within some multiple of name's            time-to-live. 
  1052.  
  1053.            A well-behaved NBNS, would, however, issue a challenge to-, 
  1054.  
  1055.  
  1056.  
  1057. NetBIOS Working Group                                          [Page 33] 
  1058.  RFC 1001                                                      March 1987 
  1059.  
  1060.             or request a list of names from-, the non-reporting end-            node before deleting its name(s).  The absence of a            response, or of the name in a response, will confirm the            NBNS decision to delete a name. 
  1061.  
  1062.       6.   The absence of reports may cause the NBNS to infer that the            end-node has failed.  Similarly, receipt of information            widely divergent from what the NBNS believes about the node,            may cause the NBNS to consider that the end-node has been            restarted. 
  1063.  
  1064.            The NBNS may analyze the situation through challenges or            requests for a list of names. 
  1065.  
  1066.       7.   A very cautious NBNS is free to poll nodes (by sending NAME            QUERY REQUEST or NODE STATUS REQUEST packets) to verify that            their name status is the same as that registered in the            NBNS. 
  1067.  
  1068.            NOTE:  Such polling activity, if used at all by an            implementation, should be kept at a very low level or            enabled only during periods when the NBNS has some reason to            suspect that its information base is inaccurate. 
  1069.  
  1070.       8.   P and M nodes can detect incorrect name information at            session establishment. 
  1071.  
  1072.            If incorrect information is found, NBNS is informed via a            NAME RELEASE REQUEST originated by the end-node which            detects the error. 
  1073.  
  1074. 15.1.8.  NAME CACHING 
  1075.  
  1076.    An end-node may keep a local cache of NetBIOS name-to-IP address    translation entries. 
  1077.  
  1078.    All cache entries should be flushed on a periodic basis. 
  1079.  
  1080.    In addition, a node ought to flush any cache information associated    with an IP address if the node receives any information indicating    that there may be any possibility of trouble with the node at that IP    address.  For example, if a NAME CONFLICT DEMAND is sent to a node,    all cached information about that node should be cleared within the    sending node. 
  1081.  
  1082. 15.2.  NAME REGISTRATION TRANSACTIONS 
  1083.  
  1084. 15.2.1.  NAME REGISTRATION BY B NODES 
  1085.  
  1086.    A name claim transaction initiated by a B node is broadcast    throughout the broadcast area.  The NAME REGISTRATION REQUEST will be 
  1087.  
  1088.  
  1089.  
  1090. NetBIOS Working Group                                          [Page 34] 
  1091.  RFC 1001                                                      March 1987 
  1092.  
  1093.     heard by all B and M nodes in the area.  Each node examines the claim    to see whether it it is consistent with the names it owns.  If an    inconsistency exists, a NEGATIVE NAME REGISTRATION RESPONSE is    unicast to the requestor.  The requesting node obtains ownership of    the name (or membership in the group) if, and only if, no NEGATIVE    NAME REGISTRATION RESPONSEs are received within the name claim    timeout, CONFLICT_TIMER.  (See "Defined Constants and Variables" in    the Detailed Specification for the value of this timer.) 
  1094.  
  1095.    A B node proclaims its new ownership by broadcasting a NAME OVERWRITE    DEMAND. 
  1096.  
  1097.                        B-NODE REGISTRATION PROCESS    <-----NAME NOT ON NETWORK------>   <----NAME ALREADY EXISTS----> 
  1098.  
  1099.    REQ. NODE                      NODE                     REQ.NODE                                  HOLDING                                   NAME 
  1100.  
  1101.    (BROADCAST) REGISTER                        (BROADCAST) REGISTER    ------------------->                        <------------------- 
  1102.  
  1103.         REGISTER                                     REGISTER    ------------------->                        <------------------- 
  1104.  
  1105.         REGISTER                         NEGATIVE RESPONSE    ------------------->             ------------------------------> 
  1106.  
  1107.           OVERWRITE    ------------------->               (NODE DOES NOT HAVE THE NAME) 
  1108.  
  1109.    (NODE HAS THE NAME) 
  1110.  
  1111.    The NAME REGISTRATION REQUEST, like any request, must be repeated if    no response is received within BCAST_REQ_RETRY_TIMEOUT.  Transmission    of the request is attempted BCAST_REQ_RETRY_COUNT times. 
  1112.  
  1113. 15.2.2.  NAME REGISTRATION BY P NODES 
  1114.  
  1115.    A name registration may proceed in various  ways depending whether    the name being registered is new to the NBNS.  If the name is known    to the NBNS, then challenges may be sent to the prior holder(s). 
  1116.  
  1117. 15.2.2.1.  NEW NAME, OR NEW GROUP MEMBER 
  1118.  
  1119.    The diagram, below, shows the sequence of events when an end-node    registers a name which is new to the NBNS.  (The diagram omits WACKs,    NBNS redirections, and retransmission of requests.) 
  1120.  
  1121.    This same interaction will occur if the name being registered is a    group name and the group already exists.  The NBNS will add the 
  1122.  
  1123.  
  1124.  
  1125. NetBIOS Working Group                                          [Page 35] 
  1126.  RFC 1001                                                      March 1987 
  1127.  
  1128.     registrant to the set of group members. 
  1129.  
  1130.                        P-NODE REGISTRATION PROCESS             (server has no previous information about the name) 
  1131.  
  1132.               P-NODE                            NBNS                           REGISTER                 ---------------------------------> 
  1133.  
  1134.                         POSITIVE RESPONSE                 <--------------------------------- 
  1135.  
  1136.    The interaction is rather simple: the end-node sends a NAME    REGISTRATION REQUEST, the NBNS responds with a POSITIVE NAME    REGISTRATION RESPONSE. 
  1137.  
  1138. 15.2.2.2.  EXISTING NAME AND OWNER IS STILL ACTIVE 
  1139.  
  1140.    The following diagram shows interactions when an attempt is made to    register a unique name, the NBNS is aware of an existing owner, and    that existing owner is still active. 
  1141.  
  1142.    There are two sides to the diagram.  The left side shows how a non-    secured NBNS would handle the matter.  Secured NBNS activity is shown    on the right. 
  1143.  
  1144.                        P-NODE REGISTRATION PROCESS                (server HAS a previous owner that IS active) 
  1145.  
  1146.     <------NON-SECURED STYLE------->  <---------SECURED STYLE-------> 
  1147.  
  1148.    REQ. NODE           NBNS       NODE         NBNS         REQ.NODE                                  HOLDING                                   NAME 
  1149.  
  1150.          REGISTER                                      REGISTER    ------------------->                         <-------------------                                        QUERY     END-NODE CHALLENGE              <------------    <-------------------                QUERY                                     <------------              QUERY    ----------------------------->                                      POSITIVE RESP              QUERY                   ------------>    ----------------------------->                 NEGATIVE RESPONSE                                                   -----------------> 
  1151.  
  1152.          POSITIVE RESPONSE    <---------------------------- 
  1153.  
  1154.  
  1155.  
  1156. NetBIOS Working Group                                          [Page 36] 
  1157.  RFC 1001                                                      March 1987 
  1158.  
  1159.     A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a    END-NODE CHALLENGE REGISTRATION RESPONSE.  This response asks the    end-node to issue a challenge transaction against the node indicated    in the response.  In this case, the prior node will defend against    the challenge and the registering end-node will simply drop the    registration attempt without further interaction with the NBNS. 
  1160.  
  1161.    A secured NBNS will refrain from answering the NAME REGISTRATION    REQUEST until the NBNS has itself challenged the prior holder(s) of    the name.  In this case, the NBNS finds that that the name is still    being defended and consequently returns a NEGATIVE NAME REGISTRATION    RESPONSE to the registrant. 
  1162.  
  1163.    Due to the potential time for the secured NBNS to make the    challenge(s), it is likely that a WACK will be sent by the NBNS to    the registrant. 
  1164.  
  1165.    Although not shown in the diagram, a non-secured NBNS will send a    NEGATIVE NAME REGISTRATION RESPONSE to a request to register a unique    name when there already exists a group of the same name.  A secured    NBNS may elect to poll (or challenge) the group members to determine    whether any active members remain.  This may impose a heavy load on    the network.  It is recommended that group names be allowed to fade-    out through the name refresh mechanism. 
  1166.  
  1167. 15.2.2.3.  EXISTING NAME AND OWNER IS INACTIVE 
  1168.  
  1169.    The following diagram shows interactions when an attempt is made to    register a unique name, the NBNS is aware of an existing owner, and    that existing owner is no longer active. 
  1170.  
  1171.    A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a    END-NODE CHALLENGE REGISTRATION RESPONSE.  This response asks the    end-node to issue a challenge transaction against the node indicated    in the response.  In this case, the prior node will not defend    against the challenge.  The registrant will inform the NBNS through a    NAME OVERWRITE REQUEST.  The NBNS will replace the prior name    information in its database with the information in the overwrite    request. 
  1172.  
  1173.    A secured NBNS will refrain from answering the NAME REGISTRATION    REQUEST until the NBNS has itself challenged the prior holder(s) of    the name.  In this case, the NBNS finds that that the name is not    being defended and consequently returns a POSITIVE NAME REGISTRATION    RESPONSE to the registrant. 
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183. NetBIOS Working Group                                          [Page 37] 
  1184.  RFC 1001                                                      March 1987 
  1185.  
  1186.                         P-NODE REGISTRATION PROCESS              (server HAS a previous owner that is NOT active) 
  1187.  
  1188.     <------NON-SECURED STYLE----->  <----------SECURED STYLE--------> 
  1189.  
  1190.    REQ. NODE           NBNS     NODE           NBNS         REQ.NODE                                HOLDING                                 NAME 
  1191.  
  1192.          REGISTER                                    REGISTER    ------------------->                         <-------------------                                        QUERY     END-NODE CHALLENGE             <------------    <-------------------                QUERY                                    <------------          NAME QUERY REQUEST                        POSITIVE RESPONSE    ---------------------------->                 ------------------>               QUERY    ----------------------------> 
  1193.  
  1194.        OVERWRITE    -------------------> 
  1195.  
  1196.     POSITIVE RESPONSE    <------------------ 
  1197.  
  1198.    Due to the potential time for the secured NBNS to make the    challenge(s), it is likely that a WACK will be sent by the NBNS to    the registrant. 
  1199.  
  1200.    A secured NBNS will immediately send a NEGATIVE NAME REGISTRATION    RESPONSE in answer to any NAME OVERWRITE REQUESTS it may receive. 
  1201.  
  1202. 15.2.3.  NAME REGISTRATION BY M NODES 
  1203.  
  1204.    An M node begin a name claim operation as if the node were a B node:    it broadcasts a NAME REGISTRATION REQUEST and listens for NEGATIVE    NAME REGISTRATION RESPONSEs.  Any NEGATIVE NAME REGISTRATION RESPONSE    prevents the M node from obtaining the name and terminates the claim    operation. 
  1205.  
  1206.    If, however, the M node does not receive any NEGATIVE NAME    REGISTRATION RESPONSE, the M node must continue the claim procedure    as if the M node were a P node. 
  1207.  
  1208.    Only if both name claims were successful does the M node acquire the    name. 
  1209.  
  1210.    The following diagram illustrates M node name registration: 
  1211.  
  1212.  
  1213.  
  1214.  NetBIOS Working Group                                          [Page 38] 
  1215.  RFC 1001                                                      March 1987 
  1216.  
  1217.                         M-NODE REGISTRATION PROCESS 
  1218.  
  1219.    <---NAME NOT IN BROADCAST AREA--> <--NAME IS IN BROADCAST AREA--> 
  1220.  
  1221.    REQ. NODE                       NODE                     REQ.NODE                                   HOLDING                                    NAME 
  1222.  
  1223.    (BROADCAST) REGISTER                         (BROADCAST) REGISTER    ------------------->                         <------------------- 
  1224.  
  1225.         REGISTER                                     REGISTER    ------------------->                         <------------------- 
  1226.  
  1227.         REGISTER                        NEGATIVE RESPONSE    ------------------->             -------------------------------> 
  1228.  
  1229.                   !                     (NODE DOES NOT HAVE THE NAME)     INITIATE     !     A P-NODE     !     REGISTRATION !                  V 
  1230.  
  1231. 15.3.  NAME QUERY TRANSACTIONS 
  1232.  
  1233.    Name query transactions are initiated by end-nodes to obtain the IP    address(es) and other attributes associated with a NetBIOS name. 
  1234.  
  1235. 15.3.1.  QUERY BY B NODES 
  1236.  
  1237.    The following diagram shows how B nodes go about discovering who owns    a name. 
  1238.  
  1239.    The left half of the diagram illustrates what happens if there are no    holders of the name.  In that case no responses are received in    answer to the broadcast NAME QUERY REQUEST(s). 
  1240.  
  1241.    The right half shows a POSITIVE NAME QUERY RESPONSE unicast by a name    holder in answer to the broadcast request.  A name holder will make    this response to every NAME QUERY REQUEST that it hears.  And each    holder acts this way.  Thus, the node sending the request may receive    many responses, some duplicates, and from many nodes. 
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253. NetBIOS Working Group                                          [Page 39] 
  1254.  RFC 1001                                                      March 1987 
  1255.  
  1256.                           B-NODE DISCOVERY PROCESS 
  1257.  
  1258.     <------NAME NOT ON NETWORK------>  <---NAME PRESENT ON NETWORK--> 
  1259.  
  1260.       REQ. NODE                    NODE                     REQ.NODE                                   HOLDING                                    NAME 
  1261.  
  1262.        (BROADCAST) QUERY                           (BROADCAST) QUERY    ---------------------->                    <--------------------- 
  1263.  
  1264.       NAME QUERY REQUEST                          NAME QUERY REQUEST    ---------------------->                    <--------------------- 
  1265.  
  1266.            QUERY                        POSITIVE RESPONSE    ---------------------->           ------------------------------> 
  1267.  
  1268.    Name query is generally, but not necessarily, a prelude to NetBIOS    session establishment or NetBIOS datagram transmission.  However,    name query may be used for other purposes. 
  1269.  
  1270.    A B node may elect to build a group membership list for subsequent    use (e.g. for session establishment) by collecting and saving the    responses. 
  1271.  
  1272. 15.3.2.  QUERY BY P NODES 
  1273.  
  1274.    An NBNS answers queries from a P node with a list of IP address and    other information for each owner of the name.  If there are multiple    owners (i.e. if the name is a group name), the NBNS loads as many    answers into the response as will fit into a UDP packet.  A    truncation flag indicates whether any additional owner information    remains.  All the information may be obtained by repeating the query    over a TCP connection. 
  1275.  
  1276.    The NBNS is not required to impose any order on its answer list. 
  1277.  
  1278.    The following diagram shows what happens if the NBNS has no    information about the name: 
  1279.  
  1280.                       P-NODE DISCOVERY PROCESS             (server has no information about the name) 
  1281.  
  1282.               P-NODE                            NBNS                         NAME QUERY REQUEST                 ---------------------------------> 
  1283.  
  1284.                         NEGATIVE RESPONSE                 <--------------------------------- 
  1285.  
  1286.  
  1287.  
  1288.  NetBIOS Working Group                                          [Page 40] 
  1289.  RFC 1001                                                      March 1987 
  1290.  
  1291.     The next diagram illustrates interaction between the end-node and the    NBNS when the NBNS does have information about the name.  This    diagram shows, in addition, the retransmission of the request by the    end-node in the absence of a timely response.  Also shown are WACKs    (or temporary, intermediate responses) sent by the NBNS to the end-    node: 
  1292.  
  1293.                      P-NODE QUERY PROCESS            (server HAS information about the name) 
  1294.  
  1295.         P-NODE                                 NBNS                        NAME QUERY REQUEST         /---------------------------------------->        /        !          (OPTIONAL)   WACK        !  <- - - - - - - - - - - - - - - - - - - -        !         !        !timer    !        !         ! (optional timer restart)        !         !         \        V           QUERY          \--------------------------------------->                               .                               .                               .                             QUERY         /---------------------------------------->        /        !          (OPTIONAL)   WACK        !  <- - - - - - - - - - - - - - - - - - - -        !         !        !timer    !        !         ! (optional timer restart)        !         !         \        V           QUERY          \--------------------------------------->                               .                               . 
  1296.  
  1297.                     POSITIVE RESPONSE          <----------------------------------------- 
  1298.  
  1299.     The following diagram illustrates NBNS redirection.  Upon receipt of    a NAME QUERY REQUEST, the NBNS redirects the client to another NBNS.    The client repeats the request to the new NBNS and obtains a    response.  The diagram shows that response as a POSITIVE NAME QUERY    RESPONSE.  However any legal NBNS response may occur in actual    operation. 
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305. NetBIOS Working Group                                          [Page 41] 
  1306.  RFC 1001                                                      March 1987 
  1307.  
  1308.                             NBNS REDIRECTION 
  1309.  
  1310.               P-NODE                            NBNS                          NAME QUERY REQUEST                 ---------------------------------> 
  1311.  
  1312.                     REDIRECT NAME QUERY RESPONSE                 <--------------------------------- 
  1313.  
  1314.        (START FROM THE         VERY BEGINNING         USING THE ADDRESS         OF THE NEWLY         SUPPLIED NBNS.)                                                 NEW               P-NODE                            NBNS                          NAME QUERY REQUEST                 ---------------------------------> 
  1315.  
  1316.                    POSITIVE NAME QUERY RESPONSE                 <--------------------------------- 
  1317.  
  1318.    The next diagram shows how a P or M node tells the NBNS that the NBNS    has provided incorrect information.  This procedure may begin after a    DATAGRAM ERROR packet has been received or a session set-up attempt    has discovered that the NetBIOS name does not exist at the    destination, the IP address of which was obtained from the NBNS    during a prior name query transaction.  The NBNS, in this case a    secure NBNS, issues queries to verify whether the information is, in    fact, incorrect.  The NBNS closes the transaction by sending either a    POSITIVE or NEGATIVE NAME RELEASE RESPONSE, depending on the results    of the verification. 
  1319.  
  1320.                  CORRECTING NBNS INFORMATION BASE 
  1321.  
  1322.               P-NODE                            NBNS                        NAME RELEASE REQUEST                 --------------------------------->                                                         QUERY                                                   ----------------> 
  1323.  
  1324.                                                         QUERY                                                   ----------------> 
  1325.  
  1326.                                       (NAME TAKEN OFF THE DATABASE                                        IF NBNS FINDS IT TO BE                                        INCORRECT) 
  1327.  
  1328.                     POSITIVE/NEGATIVE RESPONSE                 <--------------------------------- 
  1329.  
  1330.  
  1331.  
  1332.  NetBIOS Working Group                                          [Page 42] 
  1333.  RFC 1001                                                      March 1987 
  1334.  
  1335.  15.3.3.  QUERY BY M NODES 
  1336.  
  1337.    M node name query follows the B node pattern.  In the absence of    adequate results, the M node then continues by performing a P node    type query.  This is shown in the following diagram: 
  1338.  
  1339.                        M-NODE DISCOVERY PROCESS 
  1340.  
  1341.     <---NAME NOT ON BROADCAST AREA-->  <--NAME IS ON BROADCAST AREA-> 
  1342.  
  1343.    REQ. NODE                       NODE                     REQ.NODE                                   HOLDING                                    NAME 
  1344.  
  1345.        (BROADCAST) QUERY                           (BROADCAST) QUERY    --------------------->                    <---------------------- 
  1346.  
  1347.      NAME QUERY REQUEST                           NAME QUERY REQUEST    --------------------->                    <---------------------- 
  1348.  
  1349.            QUERY                           POSITIVE RESPONSE    --------------------->           -------------------------------> 
  1350.  
  1351.                    !        INITIATE    !        A P-NODE    !        DISCOVERY   !        PROCESS     !                    V 
  1352.  
  1353.  
  1354.  
  1355. 15.3.4.  ACQUIRE GROUP MEMBERSHIP LIST 
  1356.  
  1357.    The entire membership of a group may be acquired by sending a NAME    QUERY REQUEST to the NBNS.  The NBNS will respond with a POSITIVE    NAME QUERY RESPONSE or a NEGATIVE NAME QUERY RESPONSE.  A negative    response completes the procedure and indicates that there are no    members in the group. 
  1358.  
  1359.    If the positive response has the truncation bit clear, then the    response contains the entire list of group members.  If the    truncation bit is set, then this entire procedure must be repeated,    but using TCP as a foundation rather than UDP. 
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369. NetBIOS Working Group                                          [Page 43] 
  1370.  RFC 1001                                                      March 1987 
  1371.  
  1372.  15.4.  NAME RELEASE TRANSACTIONS 
  1373.  
  1374. 15.4.1.  RELEASE BY B NODES 
  1375.  
  1376.    A NAME RELEASE DEMAND contains the following information: 
  1377.  
  1378.      -  NetBIOS name      -  The scope of the NetBIOS name      -  Name type: unique or group      -  IP address of the releasing node      -  Transaction ID 
  1379.  
  1380.    REQUESTING                                     OTHER    B-NODE                                         B-NODES                      NAME RELEASE DEMAND               ----------------------------------> 
  1381.  
  1382. 15.4.2.  RELEASE BY P NODES 
  1383.  
  1384.    A NAME RELEASE REQUEST contains the following information: 
  1385.  
  1386.      -  NetBIOS name      -  The scope of the NetBIOS name      -  Name type: unique or group      -  IP address of the releasing node      -  Transaction ID 
  1387.  
  1388.     A NAME RELEASE RESPONSE contains the following information: 
  1389.  
  1390.      -  NetBIOS name      -  The scope of the NetBIOS name      -  Name type: unique or group      -  IP address of the releasing node      -  Transaction ID      -  Result:           -  Yes: name was released           -  No: name was not released, a reason code is provided 
  1391.  
  1392.    REQUESTING    P-NODE                                         NBNS                      NAME RELEASE REQUEST               ----------------------------------> 
  1393.  
  1394.                      NAME RELEASE RESPONSE               <--------------------------------- 
  1395.  
  1396. 15.4.3.  RELEASE BY M NODES 
  1397.  
  1398.    The name release procedure of the M node is a combination of the P    and B node name release procedures.  The M node first performs the P 
  1399.  
  1400.  
  1401.  
  1402. NetBIOS Working Group                                          [Page 44] 
  1403.  RFC 1001                                                      March 1987 
  1404.  
  1405.     release procedure.  If the P procedure fails then the release    procedure does not continue, it fails.  If and only if the P    procedure succeeds then the M node broadcasts the NAME RELEASE DEMAND    to the broadcast area, the B procedure. 
  1406.  
  1407.    NOTE: An M node typically performs a B-style operation and then a          P-style operation.  In this case, however, the P-style          operation comes first. 
  1408.  
  1409.    The following diagram illustrates the M node name release procedure: 
  1410.  
  1411.    <-----P procedure fails-------> <-------P procedure succeeds---> 
  1412.  
  1413.    REQUESTING               NBNS    REQUESTING             NBNS    M-NODE                           M-NODE 
  1414.  
  1415.        NAME RELEASE REQUEST               NAME RELEASE REQUEST      -------------------------->       ------------------------> 
  1416.  
  1417.        NEGATIVE RELEASE RESPONSE        POSITIVE RELEASE RESPONSE      <--------------------------       <------------------------- 
  1418.  
  1419.                                                            OTHER                                                            M-NODES 
  1420.  
  1421.                                            NAME RELEASE DEMAND                                         ------------------------> 
  1422.  
  1423. 15.5.  NAME MAINTENANCE TRANSACTIONS 
  1424.  
  1425. 15.5.1.  NAME REFRESH 
  1426.  
  1427.    Name refresh transactions are used to handle the following    situations: 
  1428.  
  1429.       a)   An NBNS node needs to detect if a P or M node has "silently"            gone down, so that names held by that node can be purged            from the data base. 
  1430.  
  1431.        b)   If the NBNS goes down, it needs to be able to reconstruct            the data base when it comes back up. 
  1432.  
  1433.        c)   If the network should be partitioned, the NBNS needs to be            able to able to update its data base when the network            reconnects. 
  1434.  
  1435.    Each P or M node is responsible for sending periodic NAME REFRESH    REQUESTs for each name that it has registered.  Each refresh packet    contains a single name that has been successfully registered by that 
  1436.  
  1437.  
  1438.  
  1439. NetBIOS Working Group                                          [Page 45] 
  1440.  RFC 1001                                                      March 1987 
  1441.  
  1442.     node.  The interval between such packets is negotiated between the    end node and the NBNS server at the time that the name is initially    claimed.  At name claim time, an end node will suggest a refresh    timeout value.  The NBNS node can modify this value in the reply    packet.  A NBNS node can also choose to tell the end node to not send    any refresh packet by using the "infinite" timeout value in the    response packet.  The timeout value returned by the NBNS is the    actual refresh timeout that the end node must use. 
  1443.  
  1444.    When a node sends a NAME REFRESH REQUEST, it must be prepared to    receive a negative response.  This would happen, for example, if the    the NBNS discovers that the the name had already been assigned to    some other node.  If such a response is received, the end node should    mark the name as being in conflict.  Such an entry should be treated    in the same way as if name conflict had been detected against the    name.  The following diagram illustrates name refresh: 
  1445.  
  1446.    <-----Successful Refresh-----> <-----Unsuccessful Refresh----> 
  1447.  
  1448.    REFRESHING               NBNS   REFRESHING               NBNS    NODE                            NODE 
  1449.  
  1450.        NAME REFRESH REQUEST             NAME REFRESH REQUEST      ------------------------>        -----------------------> 
  1451.  
  1452.          POSITIVE RESPONSE                NEGATIVE RESPONSE      <------------------------        <-----------------------                                     !                                     !                                     V                               MARK NAME IN                                 CONFLICT 
  1453.  
  1454. 15.5.2.  NAME CHALLENGE 
  1455.  
  1456.    Name challenge is done by sending a NAME QUERY REQUEST to an end node    of any type.  If a POSITIVE NAME QUERY RESPONSE is returned, then    that node still owns the name.  If a NEGATIVE NAME QUERY RESPONSE is    received or if no response is received, it can be assumed that the    end node no longer owns the name. 
  1457.  
  1458.    Name challenge can be performed either by the NBNS node, or by an end    node.  When an end-node sends a name claim packet, the NBNS node may    do the challenge operation.  The NBNS node can choose, however, to    require the end node do the challenge.  In that case, the NBNS will    send an END-NODE CHALLENGE RESPONSE packet to the end node, which    should then proceed to challenge the putative owner. 
  1459.  
  1460.    Note that the name challenge procedure sends a normal NAME QUERY    REQUEST packet to the end node.  It does not require a special    packet.  The only new packet introduced is the END-NODE CHALLENGE 
  1461.  
  1462.  
  1463.  
  1464. NetBIOS Working Group                                          [Page 46] 
  1465.  RFC 1001                                                      March 1987 
  1466.  
  1467.     RESPONSE which is sent by an NBNS node when the NBNS wants the end-    node to perform the challenge operation. 
  1468.  
  1469. 15.5.3.  CLEAR NAME CONFLICT 
  1470.  
  1471.    It is possible during a refresh request from a M or P node for a NBNS    to detects a name in conflict.  The response to the NAME REFRESH    REQUEST must be a NEGATIVE NAME REGISTRATION RESPONSE.  Optionally,    in addition, the NBNS may send a NAME CONFLICT DEMAND or a NAME    RELEASE REQUEST to the refreshing node.  The NAME CONFLICT DEMAND    forces the node to place the name in the conflict state.  The node    will eventually inform it's user of the conflict.  The NAME RELEASE    REQUEST will force the node to flush the name from its local name    table completely.  This forces the node to flush the name in    conflict.  This does not cause termination of existing sessions using    this name. 
  1472.  
  1473.    The following diagram shows an NBNS detecting and correcting a    conflict: 
  1474.  
  1475.    REFRESHING NODE                                 NBNS 
  1476.  
  1477.                      NAME REFRESH REQUEST            -----------------------------------------> 
  1478.  
  1479.                NEGATIVE NAME REGISTRATION RESPONSE            <----------------------------------------- 
  1480.  
  1481.                      NAME CONFLICT DEMAND            <----------------------------------------- 
  1482.  
  1483.                              OR 
  1484.  
  1485.                      NAME RELEASE REQUEST            <----------------------------------------- 
  1486.  
  1487.                POSITIVE/NEGATIVE RELEASE REQUEST            -----------------------------------------> 
  1488.  
  1489. 15.6.  ADAPTER STATUS TRANSACTIONS 
  1490.  
  1491.    Adapter status is obtained from a node as follows: 
  1492.  
  1493.       1.   Perform a name discovery operation to obtain the IP            addresses of a set of end-nodes. 
  1494.  
  1495.       2.   Repeat until all end-nodes from the set have been used: 
  1496.  
  1497.            a.   Select one end-node from the set. 
  1498.  
  1499.            b.   Send a NODE STATUS REQUEST to that end-node using UDP. 
  1500.  
  1501.  
  1502.  
  1503. NetBIOS Working Group                                          [Page 47] 
  1504.  RFC 1001                                                      March 1987 
  1505.  
  1506.             c.   Await a NODE STATUS RESPONSE.  (If a timely response is                 not forthcoming, repeat step "b" UCAST_REQ_RETRY_COUNT                 times.  After the last retry, go to step "a".) 
  1507.  
  1508.            d.   If the truncation bit is not set in the response, the                 response contains the entire node status.  Return the                 status to the user and terminate this procedure. 
  1509.  
  1510.            e.   If the truncation bit is set in the response, then not                 all status was returned because it would not fit into                 the response packet.  The responder will set the                 truncation bit if the IP datagram length would exceed                 MAX_DATAGRAM_LENGTH.  Return the status to the user and                 terminate this procedure. 
  1511.  
  1512.  3.   Return error to user, no status obtained. 
  1513.  
  1514.    The repetition of step 2, above, through all nodes of the set, is    optional. 
  1515.  
  1516.    Following is an example transaction of a successful Adapter Status    operation: 
  1517.  
  1518.    REQUESTING NODE                                 NAME OWNER 
  1519.  
  1520.                        NAME QUERY REQUEST            -----------------------------------------> 
  1521.  
  1522.                    POSITIVE NAME QUERY RESPONSE            <----------------------------------------- 
  1523.  
  1524.                        NODE STATUS REQUEST            -----------------------------------------> 
  1525.  
  1526.                       NODE STATUS RESPONSE            <----------------------------------------- 
  1527.  
  1528. 16.  NetBIOS SESSION SERVICE 
  1529.  
  1530.    The NetBIOS session service begins after one or more IP addresses    have been found for the target name.  These addresses may have been    acquired using the NetBIOS name query transactions or by other means,    such as a local name table or cache. 
  1531.  
  1532.    NetBIOS session service transactions, packets, and protocols are    identical for all end-node types.  They involve only directed    (point-to-point) communications. 
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  NetBIOS Working Group                                          [Page 48] 
  1539.  RFC 1001                                                      March 1987 
  1540.  
  1541.  16.1.  OVERVIEW OF NetBIOS SESSION SERVICE 
  1542.  
  1543.    Session service has three phases: 
  1544.  
  1545.      Session establishment - it is during this phase that the IP         address and TCP port of the called name is determined, and a         TCP connection is established with the remote party. 
  1546.  
  1547.      Steady state - it is during this phase that NetBIOS data         messages are exchanged over the session.  Keep-alive packets         may also be exchanged if the participating nodes are so         configured. 
  1548.  
  1549.      Session close - a session is closed whenever either a party (in         the session) closes the session or it is determined that one         of the parties has gone down. 
  1550.  
  1551. 16.1.1.  SESSION ESTABLISHMENT PHASE OVERVIEW 
  1552.  
  1553.    An end-node begins establishment of a session to another node by    somehow acquiring (perhaps using the name query transactions or a    local cache) the IP address of the node or nodes purported to own the    destination name. 
  1554.  
  1555.    Every end-node awaits incoming NetBIOS session requests by listening    for TCP calls to a well-known service port, SSN_SRVC_TCP_PORT.  Each    incoming TCP connection represents the start of a separate NetBIOS    session initiation attempt.  The NetBIOS session server, not the    ultimate application, accepts the incoming TCP connection(s). 
  1556.  
  1557.    Once the TCP connection is open, the calling node sends session    service request packet.  This packet contains the following    information: 
  1558.  
  1559.      -  Calling IP address (see note)      -  Calling NetBIOS name      -  Called IP address (see note)      -  Called NetBIOS name 
  1560.  
  1561.    NOTE: The IP addresses are obtained from the TCP service          interface. 
  1562.  
  1563.    When the session service request packet arrives at the NetBIOS    server, one of the the following situations will exist: 
  1564.  
  1565.    -    There exists a NetBIOS LISTEN compatible with the incoming         call and there are adequate resources to permit session         establishment to proceed. 
  1566.  
  1567.    -    There exists a NetBIOS LISTEN compatible with the incoming         call, but there are inadequate resources to permit 
  1568.  
  1569.  
  1570.  
  1571. NetBIOS Working Group                                          [Page 49] 
  1572.  RFC 1001                                                      March 1987 
  1573.  
  1574.          establishment of a session. 
  1575.  
  1576.    -    The called name does, in fact, exist on the called node, but         there is no pending NetBIOS LISTEN compatible with the         incoming call. 
  1577.  
  1578.    -    The called name does not exist on the called node. 
  1579.  
  1580.    In all but the first case, a rejection response is sent back over the    TCP connection to the caller.  The TCP connection is then closed and    the session phase terminates.  Any retry is the responsibility of the    caller.  For retries in the case of a group name, the caller may use    the next member of the group rather than immediately retrying the    instant address.  In the case of a unique name, the caller may    attempt an immediate retry using the same target IP address unless    the called name did not exist on the called node.  In that one case,    the NetBIOS name should be re-resolved. 
  1581.  
  1582.    If a compatible LISTEN exists, and there are adequate resources, then    the session server may transform the existing TCP connection into the    NetBIOS data session.  Alternatively, the session server may    redirect, or "retarget" the caller to another TCP port (and IP    address). 
  1583.  
  1584.    If the caller is redirected, the caller begins the session    establishment anew, but using the new IP address and TCP port given    in the retarget response.  Again a TCP connection is created, and    again the calling and called node exchange credentials.  The called    party may accept the call, reject the call, or make a further    redirection. 
  1585.  
  1586.    This mechanism is based on the presumption that, on hosts where it is    not possible to transfer open TCP connections between processes, the    host will have a central session server.  Applications willing to    receive NetBIOS calls will obtain an ephemeral TCP port number, post    a TCP unspecified passive open on that port, and then pass that port    number and NetBIOS name information to the NetBIOS session server    using a NetBIOS LISTEN operation.  When the call is placed, the    session server will "retarget" the caller to the application's TCP    socket.  The caller will then place a new call, directly to the    application.  The application has the responsibility to mimic the    session server at least to the extent of receiving the calling    credentials and then accepting or rejecting the call. 
  1587.  
  1588. 16.1.1.1.  RETRYING AFTER BEING RETARGETTED 
  1589.  
  1590.    A calling node may find that it can not establish a session with a    node to which it was directed by the retargetting procedure.  Since    retargetting may be nested, there is an issue whether the caller    should begin a retry at the initial starting point or back-up to an    intermediate retargetting point.  The caller may use any method.  A 
  1591.  
  1592.  
  1593.  
  1594. NetBIOS Working Group                                          [Page 50] 
  1595.  RFC 1001                                                      March 1987 
  1596.  
  1597.     discussion of two such methods is in Appendix B, "Retarget    Algorithms". 
  1598.  
  1599. 16.1.1.2.  SESSION ESTABLISHMENT TO A GROUP NAME 
  1600.  
  1601.    Session establishment with a group name requires special    consideration.  When a NetBIOS CALL attempt is made to a group name,    name discovery will result in a list (possibly incomplete) of the    members of that group.  The calling node selects one member from the    list and attempts to build a session.  If that fails, the calling    node may select another member and make another attempt. 
  1602.  
  1603.    When the session service attempts to make a connection with one of    the members of the group, there is no guarantee that that member has    a LISTEN pending against that group name, that the called node even    owns, or even that the called node is operating. 
  1604.  
  1605. 16.1.2.  STEADY STATE PHASE OVERVIEW 
  1606.  
  1607.    NetBIOS data messages are exchanged in the steady state.  NetBIOS    messages are sent by prepending the user data with a message header    and sending the header and the user data over the TCP connection.    The receiver removes the header and passes the data to the NetBIOS    user. 
  1608.  
  1609.    In order to detect failure of one of the nodes or of the intervening    network, "session keep alive" packets may be periodically sent in the    steady state. 
  1610.  
  1611.    Any failure of the underlying TCP connection, whether a reset, a    timeout, or other failure, implies failure of the NetBIOS session. 
  1612.  
  1613. 16.1.3.  SESSION TERMINATION PHASE OVERVIEW 
  1614.  
  1615.    A NetBIOS session is terminated normally when the user requests the    session to be closed or when the session service detects the remote    partner of the session has gracefully terminated the TCP connection.    A NetBIOS session is abnormally terminated when the session service    detects a loss of the connection.  Connection loss can be detected    with the keep-alive function of the session service or TCP, or on the    failure of a SESSION MESSAGE send operation. 
  1616.  
  1617.    When a user requests to close a session, the service first attempts a    graceful in-band close of the TCP connection.  If the connection does    not close within the SSN_CLOSE_TIMEOUT the TCP connection is aborted.    No matter how the TCP connection is terminated, the NetBIOS session    service always closes the NetBIOS session. 
  1618.  
  1619.    When the session service receives an indication from TCP that a    connection close request has been received, the TCP connection and    the NetBIOS session are immediately closed and the user is informed 
  1620.  
  1621.  
  1622.  
  1623. NetBIOS Working Group                                          [Page 51] 
  1624.  RFC 1001                                                      March 1987 
  1625.  
  1626.     of the loss of the session.  All data received up to the close    indication should be delivered, if possible, to the session's user. 
  1627.  
  1628. 16.2.  SESSION ESTABLISHMENT PHASE 
  1629.  
  1630.    All the following diagrams assume a name query operation was    successfully completed by the caller node for the listener's name. 
  1631.  
  1632.    This first diagram shows the sequence of network events used to    successfully establish a session without retargetting by the    listener.  The TCP connection is first established with the well-    known NetBIOS session service TCP port, SSN_SRVC_TCP_PORT.  The    caller then sends a SESSION REQUEST packet over the TCP connection    requesting a session with the listener.  The SESSION REQUEST contains    the caller's name and the listener's name.  The listener responds    with a POSITIVE SESSION RESPONSE informing the caller this TCP    connection is accepted as the connection for the data transfer phase    of the session. 
  1633.  
  1634.            CALLER                          LISTENER 
  1635.  
  1636.                        TCP CONNECT            ====================================>                         TCP ACCEPT            <===================================                      SESSION REQUEST            ------------------------------------>                     POSITIVE RESPONSE            <----------------------------------- 
  1637.  
  1638.    The second diagram shows the sequence of network events used to    successfully establish a session when the listener does retargetting.    The session establishment procedure is the same as with the first    diagram up to the listener's response to the SESSION REQUEST.  The    listener, divided into two sections, the listen processor and the    actual listener, sends a SESSION RETARGET RESPONSE to the caller.    This response states the call is acceptable, but the data transfer    TCP connection must be at the new IP address and TCP port.  The    caller then re-iterates the session establishment process anew with    the new IP address and TCP port after the initial TCP connection is    closed.  The new listener then accepts this connection for the data    transfer phase with a POSITIVE SESSION RESPONSE. 
  1639.  
  1640.            CALLER                  LISTEN PROCESSOR        LISTENER 
  1641.  
  1642.                    TCP CONNECT            =============================>                    TCP ACCEPT            <=============================                    SESSION REQUEST            -----------------------------> 
  1643.  
  1644.  
  1645.  
  1646. NetBIOS Working Group                                          [Page 52] 
  1647.  RFC 1001                                                      March 1987 
  1648.  
  1649.                SESSION RETARGET RESPONSE            <-----------------------------                    TCP CLOSE            <=============================                    TCP CLOSE            =============================> 
  1650.  
  1651.                        TCP CONNECT            ====================================================>                         TCP ACCEPT            <====================================================                      SESSION REQUEST            ---------------------------------------------------->                     POSITIVE RESPONSE            <---------------------------------------------------- 
  1652.  
  1653.    The third diagram is the sequence of network events for a rejected    session request with the listener.  This type of rejection could    occur with either a non-retargetting listener or a retargetting    listener.  After the TCP connection is established at    SSN_SRVC_TCP_PORT, the caller sends the SESSION REQUEST over the TCP    connection.  The listener does not have either a listen pending for    the listener's name or the pending NetBIOS listen is specific to    another caller's name.  Consequently, the listener sends a NEGATIVE    SESSION RESPONSE and closes the TCP connection. 
  1654.  
  1655.            CALLER                          LISTENER 
  1656.  
  1657.                         TCP CONNECT            ====================================>                         TCP ACCEPT            <===================================                      SESSION REQUEST            ------------------------------------>                     NEGATIVE RESPONSE            <-----------------------------------                         TCP CLOSE            <===================================                         TCP CLOSE            ====================================> 
  1658.  
  1659.    The fourth diagram is the sequence of network events when session    establishment fails with a retargetting listener.  After being    redirected, and after the initial TCP connection is closed the caller    tries to establish a TCP connection with the new IP address and TCP    port.  The connection fails because either the port is unavailable or    the target node is not active.  The port unavailable race condition    occurs if another caller has already acquired the TCP connection with    the listener.  For additional implementation suggestions, see    Appendix B, "Retarget Algorithms". 
  1660.  
  1661.  
  1662.  
  1663.  NetBIOS Working Group                                          [Page 53] 
  1664.  RFC 1001                                                      March 1987 
  1665.  
  1666.             CALLER                  LISTEN PROCESSOR        LISTENER 
  1667.  
  1668.                    TCP CONNECT            =============================>                    TCP ACCEPT            <=============================                    SESSION REQUEST            ----------------------------->                    REDIRECT RESPONSE            <-----------------------------                    TCP CLOSE            <=============================                    TCP CLOSE            =============================> 
  1669.  
  1670.                        TCP CONNECT            ====================================================> 
  1671.  
  1672.                      CONNECTION REFUSED OR TIMED OUT            <=================================================== 
  1673.  
  1674.  16.3.  SESSION DATA TRANSFER PHASE 
  1675.  
  1676. 16.3.1.  DATA ENCAPSULATION 
  1677.  
  1678.    NetBIOS messages are exchanged in the steady state.  Messages are    sent by prepending user data with message header and sending the    header and the user data over the TCP connection.  The receiver    removes the header and delivers the NetBIOS data to the user. 
  1679.  
  1680. 16.3.2.  SESSION KEEP-ALIVES 
  1681.  
  1682.    In order to detect node failure or network partitioning, "session    keep alive" packets are periodically sent in the steady state.  A    session keep alive packet is discarded by a peer node. 
  1683.  
  1684.    A session keep alive timer is maintained for each session.  This    timer is reset whenever any data is sent to, or received from, the    session peer.  When the timer expires, a NetBIOS session keep-alive    packet is sent on the TCP connection.  Sending the keep-alive packet    forces data to flow on the TCP connection, thus indirectly causing    TCP to detect whether the connection is still active. 
  1685.  
  1686.    Since many TCP implementations provide a parallel TCP "keep- alive"    mechanism, the NetBIOS session keep-alive is made a configurable    option.  It is recommended that the NetBIOS keep- alive mechanism be    used only in the absence of TCP keep-alive. 
  1687.  
  1688.    Note that unlike TCP keep alives, NetBIOS session keep alives do not    require a response from the NetBIOS peer -- the fact that it was 
  1689.  
  1690.  
  1691.  
  1692. NetBIOS Working Group                                          [Page 54] 
  1693.  RFC 1001                                                      March 1987 
  1694.  
  1695.     possible to send the NetBIOS session keep alive is sufficient    indication that the peer, and the connection to it, are still active. 
  1696.  
  1697.    The only requirement for interoperability is that when a session keep    alive packet is received, it should be discarded. 
  1698.  
  1699. 17.  NETBIOS DATAGRAM SERVICE 
  1700.  
  1701. 17.1.  OVERVIEW OF NetBIOS DATAGRAM SERVICE 
  1702.  
  1703.    Every NetBIOS datagram has a named destination and source.  To    transmit a NetBIOS datagram, the datagram service must perform a name    query operation to learn the IP address and the attributes of the    destination NetBIOS name.  (This information may be cached to avoid    the overhead of name query on subsequent NetBIOS datagrams.) 
  1704.  
  1705.    NetBIOS datagrams are carried within UDP packets.  If a NetBIOS    datagram is larger than a single UDP packet, it may be fragmented    into several UDP packets. 
  1706.  
  1707.    End-nodes may receive NetBIOS datagrams addressed to names not held    by the receiving node.  Such datagrams should be discarded.  If the    name is unique then a DATAGRAM ERROR packet is sent to the source of    that NetBIOS datagram. 
  1708.  
  1709. 17.1.1.  UNICAST, MULTICAST, AND BROADCAST 
  1710.  
  1711.    NetBIOS datagrams may be unicast, multicast, or broadcast.  A NetBIOS    datagram addressed to a unique NetBIOS name is unicast.  A NetBIOS    datatgram addressed to a group NetBIOS name, whether there are zero,    one, or more actual members, is multicast.  A NetBIOS datagram sent    using the NetBIOS "Send Broadcast Datagram" primitive is broadcast. 
  1712.  
  1713. 17.1.2.  FRAGMENTATION OF NetBIOS DATAGRAMS 
  1714.  
  1715.    When the header and data of a NetBIOS datagram exceeds the maximum    amount of data allowed in a UDP packet, the NetBIOS datagram must be    fragmented before transmission and reassembled upon receipt. 
  1716.  
  1717.    A NetBIOS Datagram is composed of the following protocol elements: 
  1718.  
  1719.      -  IP header of 20 bytes (minimum)      -  UDP header of 8 bytes      -  NetBIOS Datagram Header of 14 bytes      -  The NetBIOS Datagram data. 
  1720.  
  1721.    The NetBIOS Datagram data section is composed of 3 parts: 
  1722.  
  1723.      -  Source NetBIOS name (255 bytes maximum)      -  Destination NetBIOS name (255 bytes maximum)      -  The NetBIOS user's data (maximum of 512 bytes) 
  1724.  
  1725.  
  1726.  
  1727. NetBIOS Working Group                                          [Page 55] 
  1728.  RFC 1001                                                      March 1987 
  1729.  
  1730.     The two name fields are in second level encoded format (see section    14.) 
  1731.  
  1732.    A maximum size NetBIOS datagram is 1064 bytes.  The minimal maximum    IP datagram size is 576 bytes.  Consequently, a NetBIOS Datagram may    not fit into a single IP datagram.  This makes it necessary to permit    the fragmentation of NetBIOS Datagrams. 
  1733.  
  1734.    On networks meeting or exceeding the minimum IP datagram length    requirement of 576 octets, at most two NetBIOS datagram fragments    will be generated.  The protocols and packet formats accommodate    fragmentation into three or more parts. 
  1735.  
  1736.    When a NetBIOS datagram is fragmented, the IP, UDP and NetBIOS    Datagram headers are present in each fragment.  The NetBIOS Datagram    data section is split among resulting UDP datagrams.  The data    sections of NetBIOS datagram fragments do not overlap. The only    fields of the NetBIOS Datagram header that would vary are the FLAGS    and OFFSET fields. 
  1737.  
  1738.    The FIRST bit in the FLAGS field indicate whether the fragment is the    first in a sequence of fragments.  The MORE bit in the FLAGS field    indicates whether other fragments follow. 
  1739.  
  1740.    The OFFSET field is the byte offset from the beginning of the NetBIOS    datagram data section to the first byte of the data section in a    fragment.  It is 0 for the first fragment.  For each subsequent    fragment, OFFSET is the sum of the bytes in the NetBIOS data sections    of all preceding fragments. 
  1741.  
  1742.    If the NetBIOS datagram was not fragmented: 
  1743.  
  1744.      -  FIRST = TRUE      -  MORE = FALSE      -  OFFSET = 0 
  1745.  
  1746.    If the NetBIOS datagram was fragmented: 
  1747.  
  1748.      -  First fragment:           -  FIRST = TRUE           -  MORE = TRUE           -  OFFSET = 0 
  1749.  
  1750.      -  Intermediate fragments:           -  FIRST = FALSE           -  MORE = TRUE           -  OFFSET = sum(NetBIOS data in prior fragments) 
  1751.  
  1752.      -  Last fragment:           -  FIRST = FALSE           -  MORE = FALSE 
  1753.  
  1754.  
  1755.  
  1756. NetBIOS Working Group                                          [Page 56] 
  1757.  RFC 1001                                                      March 1987 
  1758.  
  1759.            -  OFFSET = sum(NetBIOS data in prior fragments) 
  1760.  
  1761.    The relative position of intermediate fragments may be ascertained    from OFFSET. 
  1762.  
  1763.    An NBDD must remember the destination name of the first fragment in    order to relay the subsequent fragments of a single NetBIOS datagram.    The name information can be associated with the subsequent fragments    through the transaction ID, DGM_ID, and the SOURCE_IP, fields of the    packet.  This information can be purged by the NBDD after the last    fragment has been processed or FRAGMENT_TO time has expired since the    first fragment was received. 
  1764.  
  1765. 17.2.  NetBIOS DATAGRAMS BY B NODES 
  1766.  
  1767.    For NetBIOS datagrams with a named destination (i.e. non- broadcast),    a B node performs a name discovery for the destination name before    sending the datagram.  (Name discovery may be bypassed if information    from a previous discovery is held in a cache.)  If the name type    returned by name discovery is UNIQUE, the datagram is unicast to the    sole owner of the name.  If the name type is GROUP, the datagram is    broadcast to the entire broadcast area using the destination IP    address BROADCAST_ADDRESS. 
  1768.  
  1769.    A receiving node always filters datagrams based on the destination    name.  If the destination name is not owned by the node or if no    RECEIVE DATAGRAM user operations are pending for the name, then the    datagram is discarded.  For datagrams with a UNIQUE name destination,    if the name is not owned by the node then the receiving node sends a    DATAGRAM ERROR packet.  The error packet originates from the    DGM_SRVC_UDP_PORT and is addressed to the SOURCE_IP and SOURCE_PORT    from the bad datagram.  The receiving node quietly discards datagrams    with a GROUP name destination if the name is not owned by the node. 
  1770.  
  1771.    Since broadcast NetBIOS datagrams do not have a named destination,    the B node sends the DATAGRAM SERVICE packet(s) to the entire    broadcast area using the destination IP address BROADCAST_ADDRESS.    In order for the receiving nodes to distinguish this datagram as a    broadcast NetBIOS datagram, the NetBIOS name used as the destination    name is '*' (hexadecimal 2A) followed by 15 bytes of hexidecimal 00.    The NetBIOS scope identifier is appended to the name before it is    converted into second-level encoding.  For example, if the scope    identifier is "NETBIOS.SCOPE" then the first-level encoded name would    be: 
  1772.  
  1773.         CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.NETBIOS.SCOPE 
  1774.  
  1775.    According to [2], a user may not provide a NetBIOS name beginning    with "*". 
  1776.  
  1777.    For each node in the broadcast area that receives the NetBIOS 
  1778.  
  1779.  
  1780.  
  1781. NetBIOS Working Group                                          [Page 57] 
  1782.  RFC 1001                                                      March 1987 
  1783.  
  1784.     broadcast datagram, if any RECEIVE BROADCAST DATAGRAM user operations    are pending then the data from the NetBIOS datagram is replicated and    delivered to each.  If no such operations are pending then the node    silently discards the datagram. 
  1785.  
  1786. 17.3.  NetBIOS DATAGRAMS BY P AND M NODES 
  1787.  
  1788.    P and M nodes do not use IP broadcast to distribute NetBIOS    datagrams. 
  1789.  
  1790.    Like B nodes, P and M nodes must perform a name discovery or use    cached information to learn whether a destination name is a group or    a unique name. 
  1791.  
  1792.    Datagrams to unique names are unicast directly to the destination by    P and M nodes, exactly as they are by B nodes. 
  1793.  
  1794.    Datagrams to group names and NetBIOS broadcast datagrams are unicast    to the NBDD.  The NBDD then relays the datagrams to each of the nodes    specified by the destination name. 
  1795.  
  1796.    An NBDD may not be capable of sending a NetBIOS datagram to a    particular NetBIOS name, including the broadcast NetBIOS name ("*")    defined above.  A query mechanism is available to the end- node to    determine if a NBDD will be able to relay a datagram to a given name.    Before a datagram, or its fragments, are sent to the NBDD the P or M    node may send a DATAGRAM QUERY REQUEST packet to the NBDD with the    DESTINATION_NAME from the DATAGRAM SERVICE packet(s).  The NBDD will    respond with a DATAGRAM POSITIVE QUERY RESPONSE if it will relay    datagrams to the specified destination name.  After a positive    response the end-node unicasts the datagram to the NBDD.  If the NBDD    will not be able to relay a datagram to the destination name    specified in the query, a DATAGRAM NEGATIVE QUERY RESPONSE packet is    returned.  If the NBDD can not distribute a datagram, the end-node    then has the option of getting the name's owner list from the NBNS    and sending the datagram directly to each of the owners. 
  1797.  
  1798.    An NBDD must be able to respond to DATAGRAM QUERY REQUEST packets.    The response may always be positive.  However, the usage or    implementation of the query mechanism by a P or M node is optional.    An implementation may always unicast the NetBIOS datagram to the NBDD    without asking if it will be relayed.  Except for the datagram query    facility described above, an NBDD provides no feedback to indicate    whether it forwarded a datagram. 
  1799.  
  1800. 18.  NODE CONFIGURATION PARAMETERS 
  1801.  
  1802.      -  B NODES:           -  Node's permanent unique name           -  Whether IGMP is in use           -  Broadcast IP address to use 
  1803.  
  1804.  
  1805.  
  1806. NetBIOS Working Group                                          [Page 58] 
  1807.  RFC 1001                                                      March 1987 
  1808.  
  1809.            -  Whether NetBIOS session keep-alives are needed           -  Usable UDP data field length (to control fragmentation)      -  P NODES:           -  Node's permanent unique name           -  IP address of NBNS           -  IP address of NBDD           -  Whether NetBIOS session keep-alives are needed           -  Usable UDP data field length (to control fragmentation)      -  M NODES:           -  Node's permanent unique name           -  Whether IGMP is in use           -  Broadcast IP address to use           -  IP address of NBNS           -  IP address of NBDD           -  Whether NetBIOS session keep-alives are needed           -  Usable UDP data field length (to control fragmentation) 
  1810.  
  1811.  19.  MINIMAL CONFORMANCE 
  1812.  
  1813.    To ensure multi-vendor interoperability, a minimally conforming    implementation based on this specification must observe the following    rules: 
  1814.  
  1815.    a)   A node designed to work only in a broadcast area must         conform to the B node specification. 
  1816.  
  1817.    b)   A node designed to work only in an internet must conform to         the P node specification. 
  1818.  
  1819.  
  1820.  
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843. NetBIOS Working Group                                          [Page 59] 
  1844.  RFC 1001                                                      March 1987 
  1845.  
  1846.  
  1847.  
  1848. REFERENCES 
  1849.  
  1850.        [1]  "Protocol Standard For a NetBIOS Service on a TCP/UDP            Transport: Detailed Specifications", RFC 1002, March 1987. 
  1851.  
  1852.       [2]  IBM Corp., "IBM PC Network Technical Reference Manual", No.            6322916, First Edition, September 1984. 
  1853.  
  1854.       [3]  J. Postel (Ed.), "Transmission Control Protocol", RFC 793,            September 1981. 
  1855.  
  1856.       [4]  MIL-STD-1778 
  1857.  
  1858.       [5]  J. Postel, "User Datagram Protocol", RFC 768, 28 August            1980. 
  1859.  
  1860.       [6]  J. Reynolds, J. Postel, "Assigned Numbers", RFC 990,            November 1986. 
  1861.  
  1862.       [7]  J.  Postel, "Internet Protocol", RFC 791, September 1981. 
  1863.  
  1864.       [8]  J. Mogul, "Internet Subnets", RFC 950, October 1984 
  1865.  
  1866.       [9]  J.  Mogul, "Broadcasting Internet Datagrams in the Presence            of Subnets", RFC 922, October 1984. 
  1867.  
  1868.       [10] J.  Mogul, "Broadcasting Internet Datagrams", RFC 919,            October 1984. 
  1869.  
  1870.       [11] P. Mockapetris, "Domain Names - Concepts and Facilities",            RFC 882, November 1983. 
  1871.  
  1872.       [12] P. Mockapetris, "Domain Names - Implementation and            Specification", RFC 883, November 1983. 
  1873.  
  1874.       [13] P. Mockapetris, "Domain System Changes and Observations",            RFC 973, January 1986. 
  1875.  
  1876.       [14] C. Partridge, "Mail Routing and the Domain System", RFC 974,            January 1986. 
  1877.  
  1878.       [15] S. Deering, D. Cheriton, "Host Groups: A Multicast Extension            to the Internet Protocol", RFC 966, December 1985. 
  1879.  
  1880.       [16] S. Deering, "Host Extensions for IP Multicasting", RFC 988,            July 1986. 
  1881.  
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  NetBIOS Working Group                                          [Page 60] 
  1887.  RFC 1001                                                      March 1987 
  1888.  
  1889.  APPENDIX A 
  1890.  
  1891.     This appendix contains supporting technical discussions.  It is not    an integral part of the NetBIOS-over-TCP specification. 
  1892.  
  1893.    INTEGRATION WITH INTERNET GROUP MULTICASTING 
  1894.  
  1895.    The Netbios-over-TCP system described in this RFC may be easily    integrated with the Internet Group Multicast system now being    developed for the internet. 
  1896.  
  1897.    In the main body of the RFC, the notion of a broadcast area was    considered to be a single MAC-bridged "B-LAN".  However, the    protocols defined will operate over an extended broadcast area    resulting from the creation of a permanent Internet Multicast Group. 
  1898.  
  1899.    Each separate broadcast area would be based on a separate permanent    Internet Multicast Group.  This multicast group address would be used    by B and M nodes as their BROADCAST_ADDRESS. 
  1900.  
  1901.    In order to base the broadcast area on a multicast group certain    additional procedures are required and certain constraints must be    met. 
  1902.  
  1903. A-1.  ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES 
  1904.  
  1905.    All B or M nodes operating on an IGMP based broadcast area must have    IGMP support in their IP layer software.  These nodes must perform an    IGMP join operation to enter the IGMP group before engaging in    NetBIOS activity. 
  1906.  
  1907. A-2.  CONSTRAINTS 
  1908.  
  1909.    Broadcast Areas may overlap.  For this reason, end-nodes must be    careful to examine the NetBIOS scope identifiers in all received    broadcast packets. 
  1910.  
  1911.    The NetBIOS broadcast protocols were designed for a network that    exhibits a low average transit time and low rate of packet loss.  An    IGMP based broadcast area must exhibit these characteristics.  In    practice this will tend to constrain IGMP broadcast areas to a campus    of networks interconnected by high-speed routers and inter-router    links.  It is unlikely that transcontinental broadcast areas would    exhibit the required characteristics. 
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921. NetBIOS Working Group                                          [Page 61] 
  1922.  RFC 1001                                                      March 1987 
  1923.  
  1924.  APPENDIX B 
  1925.  
  1926.     This appendix contains supporting technical discussions.  It is not    an integral part of the NetBIOS-over-TCP specification. 
  1927.  
  1928. IMPLEMENTATION CONSIDERATIONS 
  1929.  
  1930. B-1.  IMPLEMENTATION MODELS 
  1931.  
  1932.    On any participating system, there must be some sort of NetBIOS    Service to coordinate access by NetBIOS applications on that system. 
  1933.  
  1934.    To analyze the impact of the NetBIOS-over-TCP architecture, we use    the following three models of how a NetBIOS service might be    implemented: 
  1935.  
  1936.    1.   Combined Service and Application Model 
  1937.  
  1938.         The NetBIOS service and application are both contained         within a single process.  No interprocess communication is         assumed within the system; all communication is over the         network.  If multiple applications require concurrent access         to the NetBIOS service, they must be folded into this         monolithic process. 
  1939.  
  1940.     2.   Common Kernel Element Model 
  1941.  
  1942.         The NetBIOS Service is part of the operating system (perhaps         as a device driver or a front-end processor).  The NetBIOS         applications are normal operating system application         processes.  The common element NetBIOS service contains all         the information, such as the name and listen tables,         required to co-ordinate the activities of the applications. 
  1943.  
  1944.     3.   Non-Kernel Common Element Model 
  1945.  
  1946.         The NetBIOS Service is implemented as an operating system         application process.  The NetBIOS applications are other         operating system application processes.  The service and the         applications exchange data via operating system interprocess         communication.  In a multi-processor (e.g.  network)         operating system, each module may reside on a different cpu.         The NetBIOS service process contains all the shared         information required to coordinate the activities of the         NetBIOS applications.  The applications may still require a         subroutine library to facilitate access to the NetBIOS         service. 
  1947.  
  1948.  
  1949.  
  1950.  NetBIOS Working Group                                          [Page 62] 
  1951.  RFC 1001                                                      March 1987 
  1952.  
  1953.     For any of the implementation models, the TCP/IP service can be    located in the operating system or split among the NetBIOS    applications and the NetBIOS service processes. 
  1954.  
  1955. B-1.1  MODEL INDEPENDENT CONSIDERATIONS 
  1956.  
  1957.    The NetBIOS name service associates a NetBIOS name with a host.  The    NetBIOS session service further binds the name to a specific TCP port    for the duration of the session. 
  1958.  
  1959.    The name service does not need to be informed of every Listen    initiation and completion.  Since the names are not bound to any TCP    port in the name service, the session service may use a different tcp    port for each session established with the same local name. 
  1960.  
  1961.    The TCP port used for the data transfer phase of a NetBIOS session    can be globally well-known, locally well-known, or ephemeral.  The    choice is a local implementation issue.  The RETARGET mechanism    allows the binding of the NetBIOS session to a TCP connection to any    TCP port, even to another IP node. 
  1962.  
  1963.    An implementation may use the session service's globally well- known    TCP port for the data transfer phase of the session by not using the    RETARGET mechanism and, rather, accepting the session on the initial    TCP connection.  This is permissible because the caller always uses    an ephemeral TCP port. 
  1964.  
  1965.    The complexity of the called end RETARGET mechanism is only required    if a particular implementation needs it.  For many real system    environments, such as an in-kernel NetBIOS service implementation, it    will not be necessary to retarget incoming calls.  Rather, all    NetBIOS sessions may be multiplexed through the single, well-known,    NetBIOS session service port.  These implementations will not be    burdened by the complexity of the RETARGET mechanism, nor will their    callers be required to jump through the retargetting hoops. 
  1966.  
  1967.    Nevertheless, all callers must be ready to process all possible    SESSION RETARGET RESPONSEs. 
  1968.  
  1969. B-1.2  SERVICE OPERATION FOR EACH MODEL 
  1970.  
  1971.    It is possible to construct a NetBIOS service based on this    specification for each of the above defined implementation models. 
  1972.  
  1973.    For the common kernel element model, all the NetBIOS services, name,    datagram, and session, are simple.  All the information is contained    within a single entity and can therefore be accessed or modified    easily.  A single port or multiple ports for the NetBIOS sessions can    be used without adding any significant complexity to the session    establishment procedure.  The only penalty is the amount of overhead    incurred to get the NetBIOS messages and operation requests/responses 
  1974.  
  1975.  
  1976.  
  1977. NetBIOS Working Group                                          [Page 63] 
  1978.  RFC 1001                                                      March 1987 
  1979.  
  1980.     through the user and operating system boundary. 
  1981.  
  1982.    The combined service and application model is very similar to the    common kernel element model in terms of its requirements on the    NetBIOS service.  The major difficulty is the internal coordination    of the multiple NetBIOS service and application processes existing in    a system of this type. 
  1983.  
  1984.    The NetBIOS name, datagram and session protocols assume that the    entities at the end-points have full control of the various well-    known TCP and UDP ports.  If an implementation has multiple NetBIOS    service entities, as would be the case with, for example, multiple    applications each linked into a NetBIOS library, then that    implementation must impose some internal coordination.    Alternatively, use of the NetBIOS ports could be periodically    assigned to one application or another. 
  1985.  
  1986.    For the typical non-kernel common element mode implementation, three    permanent system-wide NetBIOS service processes would exist: 
  1987.  
  1988.      -  The name server      -  the datagram server      -  and session server 
  1989.  
  1990.    Each server would listen for requests from the network on a UDP or    TCP well-known port.  Each application would have a small piece of    the NetBIOS service built-in, possibly a library.  Each application's    NetBIOS support library would need to send a message to the    particular server to request an operation, such as add name or send a    datagram or set-up a listen. 
  1991.  
  1992.    The non-kernel common element model does not require a TCP connection    be passed between the two processes, session server and application.    The RETARGET operation for an active NetBIOS Listen could be used by    the session server to redirect the session to another TCP connection    on a port allocated and owned by the application's NetBIOS support    library.  The application with either a built-in or a kernel-based    TCP/IP service could then accept the RETARGETed connection request    and process it independently of the session server. 
  1993.  
  1994.    On Unix(tm) or POSIX(tm), the NetBIOS session server could create    sub-processes for incoming connections.  The open sessions would be    passed through "fork" and "exec" to the child as an open file    descriptor.  This approach is very limited, however.  A pre- existing    process could not receive an incoming call.  And all call-ed    processes would have to be sub-processes of the session server. 
  1995.  
  1996. B-2.  CASUAL AND RESTRICTED NetBIOS APPLICATIONS 
  1997.  
  1998.    Because NetBIOS was designed to operate in the open system    environment of the typical personal computer, it does not have the 
  1999.  
  2000.  
  2001.  
  2002. NetBIOS Working Group                                          [Page 64] 
  2003.  RFC 1001                                                      March 1987 
  2004.  
  2005.     concept of privileged or unprivileged applications.  In many multi-    user or multi-tasking operating systems applications are assigned    privilege capabilities.  These capabilities limit the applications    ability to acquire and use system resources.  For these systems it is    important to allow casual applications, those with limited system    privileges, and privileged applications, those with 'super-user'    capabilities but access to them and their required resources is    restricted, to access NetBIOS services.  It is also important to    allow a systems administrator to restrict certain NetBIOS resources    to a particular NetBIOS application.  For example, a file server    based on the NetBIOS services should be able to have names and TCP    ports for sessions only it can use. 
  2006.  
  2007.    A NetBIOS application needs at least two local resources to    communicate with another NetBIOS application, a NetBIOS name for    itself and, typically, a session.  A NetBIOS service cannot require    that NetBIOS applications directly use privileged system resources.    For example, many systems require privilege to use TCP and UDP ports    with numbers less than 1024.  This RFC requires reserved ports for    the name and session servers of a NetBIOS service implementation.  It    does not require the application to have direct access these reserved    ports. 
  2008.  
  2009.    For the name service, the manager of the local name table must have    access to the NetBIOS name service's reserved UDP port.  It needs to    listen for name service UDP packets to defend and define its local    names to the network.  However, this manager need not be a part of a    user application in a system environment which has privilege    restrictions on reserved ports. 
  2010.  
  2011.    The internal name server can require certain privileges to add,    delete, or use a certain name, if an implementer wants the    restriction.  This restriction is independent of the operation of the    NetBIOS service protocols and would not necessarily prevent the    interoperation of that implementation with another implementation. 
  2012.  
  2013.    The session server is required to own a reserved TCP port for session    establishment.  However, the ultimate TCP connection used to transmit    and receive data does not have to be through that reserved port.  The    RETARGET procedure the NetBIOS session to be shifted to another TCP    connection, possibly through a different port at the called end.    This port can be an unprivileged resource, with a value greater than    1023.  This facilitates casual applications. 
  2014.  
  2015.    Alternately, the RETARGET mechanism allows the TCP port used for data    transmission and reception to be a reserved port.  Consequently, an    application wishing to have access to its ports maintained by the    system administrator can use these restricted TCP ports.  This    facilitates privileged applications. 
  2016.  
  2017.    A particular implementation may wish to require further special 
  2018.  
  2019.  
  2020.  
  2021. NetBIOS Working Group                                          [Page 65] 
  2022.  RFC 1001                                                      March 1987 
  2023.  
  2024.     privileges for session establishment, these could be associated with    internal information.  It does not have to be based solely on TCP    port allocation.  For example, a given NetBIOS name may only be used    for sessions by applications with a certain system privilege level. 
  2025.  
  2026.    The decision to use reserved or unreserved ports or add any    additional name registration and usage authorization is a purely    local implementation decision.  It is not required by the NetBIOS    protocols specified in the RFC. 
  2027.  
  2028. B-3.  TCP VERSUS SESSION KEEP-ALIVES 
  2029.  
  2030.    The KEEP-ALIVE is a protocol element used to validate the existence    of a connection.  A packet is sent to the remote connection partner    to solicit a response which shows the connection is still    functioning.  TCP KEEP-ALIVES are used at the TCP level on TCP    connections while session KEEP-ALIVES are used on NetBIOS sessions.    These protocol operations are always transparent to the connection    user.  The user will only find out about a KEEP-ALIVE operation if it    fails, therefore, if the connection is lost. 
  2031.  
  2032.    The NetBIOS specification[2] requires the NetBIOS service to inform    the session user if a session is lost when it is in a passive or    active state.  Therefore,if the session user is only waiting for a    receive operation and the session is dropped the NetBIOS service must    inform the session user.  It cannot wait for a session send operation    before it informs the user of the loss of the connection. 
  2033.  
  2034.    This requirement stems from the management of scarce or volatile    resources by a NetBIOS application.  If a particular user terminates    a session with a server application by destroying the client    application or the NetBIOS service without a NetBIOS Hang Up, the    server application will want to clean-up or free allocated resources.    This server application if it only receives and then sends a response    requires the notification of the session abort in the passive state. 
  2035.  
  2036.    The standard definition of a TCP service cannot detect loss of a    connection when it is in a passive state, waiting for a packet to    arrive.  Some TCP implementations have added a KEEP-ALIVE operation    which is interoperable with implementations without this feature.    These implementations send a packet with an invalid sequence number    to the connection partner.  The partner, by specification, must    respond with a packet showing the correct sequence number of the    connection.  If no response is received from the remote partner    within a certain time interval then the TCP service assumes the    connection is lost. 
  2037.  
  2038.    Since many TCP implementations do not have this KEEP-ALIVE function    an optional NetBIOS KEEP-ALIVE operation has been added to the    NetBIOS session protocols.  The NetBIOS KEEP-ALIVE uses the    properties of TCP to solicit a response from the remote connection 
  2039.  
  2040.  
  2041.  
  2042. NetBIOS Working Group                                          [Page 66] 
  2043.  RFC 1001                                                      March 1987 
  2044.  
  2045.     partner.  A NetBIOS session message called KEEP-ALIVE is sent to the    remote partner.  Since this results in TCP sending an IP packet to    the remote partner, the TCP connection is active.  TCP will discover    if the TCP connection is lost if the remote TCP partner does not    acknowledge the IP packet.  Therefore, the NetBIOS session service    does not send a response to a session KEEP ALIVE message.  It just    throws it away.  The NetBIOS session service that transmits the KEEP    ALIVE is informed only of the failure of the TCP connection.  It does    not wait for a specific response message. 
  2046.  
  2047.    A particular NetBIOS implementation should use KEEP-ALIVES if it is    concerned with maintaining compatibility with the NetBIOS interface    specification[2].  Compatibility is especially important if the    implementation wishes to support existing NetBIOS applications, which    typically require the session loss detection on their servers, or    future applications which were developed for implementations with    session loss detection. 
  2048.  
  2049. B-4.  RETARGET ALGORITHMS 
  2050.  
  2051.    This section contains 2 suggestions for RETARGET algorithms.  They    are called the "straight" and "stack" methods.  The algorithm in the    body of the RFC uses the straight method.  Implementation of either    algorithm must take into account the Session establishment maximum    retry count.  The retry count is the maximum number of TCP connect    operations allowed before a failure is reported. 
  2052.  
  2053.    The straight method forces the session establishment procedure to    begin a retry after a retargetting failure with the initial node    returned from the name discovery procedure.  A retargetting failure    is when a TCP connection attempt fails because of a time- out or a    NEGATIVE SESSION RESPONSE is received with an error code specifying    NOT LISTENING ON CALLED NAME.  If any other failure occurs the    session establishment procedure should retry from the call to the    name discovery procedure. 
  2054.  
  2055.    A minimum of 2 retries, either from a retargetting or a name    discovery failure.  This will give the session service a chance to    re-establish a NetBIOS Listen or, more importantly, allow the NetBIOS    scope, local name service or the NBNS, to re-learn the correct IP    address of a NetBIOS name. 
  2056.  
  2057.    The stack method operates similarly to the straight method.  However,    instead of retrying at the initial node returned by the name    discovery procedure, it restarts with the IP address of the last node    which sent a SESSION RETARGET RESPONSE prior to the retargetting    failure.  To limit the stack method, any one host can only be tried a    maximum of 2 times. 
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  NetBIOS Working Group                                          [Page 67] 
  2064.  RFC 1001                                                      March 1987 
  2065.  
  2066.  B-5.  NBDD SERVICE 
  2067.  
  2068.    If the NBDD does not forward datagrams then don't provide Group and    Broadcast NetBIOS datagram services to the NetBIOS user.  Therefore,    ignore the implementation of the query request and, when get a    negative response, acquiring the membership list of IP addresses and    sending the datagram as a unicast to each member. 
  2069.  
  2070. B-6.  APPLICATION CONSIDERATIONS 
  2071.  
  2072. B-6.1  USE OF NetBIOS DATAGRAMS 
  2073.  
  2074.    Certain existing NetBIOS applications use NetBIOS datagrams as a    foundation for their own connection-oriented protocols.  This can    cause excessive NetBIOS name query activity and place a substantial    burden on the network, server nodes, and other end- nodes.  It is    recommended that this practice be avoided in new applications. 
  2075.  
  2076.  
  2077.  
  2078.  
  2079.  
  2080.  
  2081.  
  2082.  
  2083.  
  2084.  
  2085.  
  2086.  
  2087.  
  2088.  
  2089.  
  2090.  
  2091.  
  2092.  
  2093.  
  2094.  
  2095.  
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112. NetBIOS Working Group                                          [Page 68] 
  2113.  
  2114.