rfc1001.txt

NBTSTAT 获取 MAC GROUP

   part of the underlying NetBIOS mechanism.

   NetBIOS name and datagram distribution servers are the focus of name
   and datagram activity for P and M nodes.

   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.

   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.

   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.

11.1.  NetBIOS NAME SERVER (NBNS) NODES

   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.

   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.

   A single NBNS may be implemented as a distributed entity, such as the
   Domain Name Service.  However, this RFC does not attempt to define



NetBIOS Working Group                                          [Page 18]

RFC 1001                                                      March 1987


   the internal communications which would be used.

11.1.1.  RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM

   The NBNS design attempts to align itself with the Domain Name System
   in a number of ways.

   First, the NetBIOS names are encoded in a form acceptable to the
   domain name system.

   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.

   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.

   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.

   Among the areas in which the domain name service must be extended
   before it may be used as an NBNS are:

     -  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

11.2.  NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES

   The internet does not yet support broadcasting or multicasting.  The
   NBDD extends NetBIOS datagram distribution service to this
   environment.

   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.

   The design of NetBIOS-over-TCP lends itself to the use of Internet
   Group Multicast.  For details see Appendix A.






NetBIOS Working Group                                          [Page 19]

RFC 1001                                                      March 1987


11.3.  RELATIONSHIP OF NBNS AND NBDD NODES

   This RFC defines the NBNS and NBDD as distinct, separate entities.

   In the absence of NetBIOS name information, a NetBIOS datagram
   distribution server must send a copy to each end-node within a
   NetBIOS scope.

   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.

   NOTE: Implementations containing private NBNS-NBDD protocols or
         combined NBNS-NBDD functions must be clearly identified.

11.4.  RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES

   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.

   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.

12.  TOPOLOGIES

   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.

   There are three classes of operation:

     -  Class 0:  B nodes only.
     -  Class 1:  P nodes only.
     -  Class 2:  P and M nodes together.

   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.

12.1.  LOCAL

   A NetBIOS scope is operating locally when all entities are within the
   same broadcast area.





NetBIOS Working Group                                          [Page 20]

RFC 1001                                                      March 1987


12.1.1.  B NODES ONLY

   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.

   ====+=========+=====BROADCAST AREA=====+==========+=========+====
       |         |                        |          |         |
       |         |                        |          |         |
    +--+--+   +--+--+                  +--+--+    +--+--+   +--+--+
    |  B  |   |  B  |                  |  B  |    |  B  |   |  B  |
    +-----+   +-----+                  +-----+    +-----+   +-----+

12.1.2.  P NODES ONLY

   This configuration would typically be used when the network
   administrator desires to eliminate NetBIOS as a source of broadcast
   activity.


   ====+=========+==========+=B'CAST AREA=+==========+=========+====
       |         |          |             |          |         |
       |         |          |             |          |         |
    +--+--+   +--+--+    +--+--+       +--+--+    +--+--+   +--+--+
    |  P  |   |  P  |    |NBNS |       |  P  |    |NBDD |   |  P  |
    +-----+   +-----+    +-----+       +-----+    +-----+   +-----+


   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.

   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.

12.1.3.  MIXED B AND P NODES

   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.

   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.







NetBIOS Working Group                                          [Page 21]

RFC 1001                                                      March 1987


12.2.  INTERNET

12.2.1.  P NODES ONLY

   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.

   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.

                   +-----+
                   |  P  |
                   +--+--+              |    +-----+
                      |                 |----+  P  |
                      |                 |    +-----+
                /-----+-----\           |
   +-----+      |           |  +------+ |    +-----+
   |  P  +------+  INTERNET +--+G'WAY |-+----+  P  |
   +-----+      |           |  +------+ |    +-----+
                /-----+-----/           |
              /       |                 |    +-----+
            /         |                 |----+  P  |
     +-----+       +--+--+              |    +-----+
     |NBNS +       |NBDD |
     +-----+       +--+--+

   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.























NetBIOS Working Group                                          [Page 22]

RFC 1001                                                      March 1987


12.2.2.  MIXED M AND P NODES

   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.

                         +-----+
                         |  P  |
                         +--+--+
                            |
                            |
                      /-----+-----\
         +-----+      |           |      +-----+
         |  P  +------+  INTERNET +------+NBDD |
         +-----+      |           |      +-----+
                      /-----+-----/
                    /       |
                  /         |
           +-----+       +--+--+
           |NBNS +       |G'WAY|
           +-----+       +--+--+
                            |
                            |
   ====+=========+==========+=B'CAST AREA=+==========+=========+====
       |         |          |             |          |         |
       |         |          |             |          |         |
    +--+--+   +--+--+    +--+--+       +--+--+    +--+--+   +--+--+
    |  M  |   |  P  |    |  M  |       |  P  |    |  M  |   |  P  |
    +-----+   +-----+    +--+--+       +-----+    +-----+   +-----+


   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.

13.  GENERAL METHODS

   Overlying the specific protocols, described later, are a few general
   methods of interaction between entities.

13.1.  REQUEST/RESPONSE INTERACTION STYLE

   Most interactions between entities consist of a request flowing in
   one direction and a subsequent response flowing in the opposite
   direction.

   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