Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When a higher-layer protocol or application requests that a NetBIOS name be registered on a given interface, processing MUST be done as specified in [RFC1002] section 5.1 and [HYBRID] according to its Node Type, except as follows.
If the name begins with an asterisk (*), then the request MUST be completed successfully with the name added to the Local Name Table, without attempting to register the name or check for conflicts.
An NBT implementation SHOULD NOT enforce the use of the convention specified in section 1.8.
If the name already exists in the Local Name Table and the Conflict Detected Flag is set on any interface in the Interface List, then the node MUST immediately fail the request.
If the end node is multihomed, the name to be registered is unique, and the end node is configured with an NBNS, then the end node SHOULD send a MULTIHOMED NAME REGISTRATION REQUEST (UNIQUE).
If the registration completes successfully and no entry exists in the Local Name Table, then one MUST be added with the Interface List set to contain the given interface, with its Conflict Detected Flag cleared. The Refresh Timeout MUST be set to the TTL in the POSITIVE NAME REGISTRATION RESPONSE, or to 5 minutes if the TTL is less than 5 minutes.
If the registration completes successfully and an entry already exists in the Local Name Table, then the given interface MUST be added to the entry's Interface List, with its Conflict Detected Flag cleared. The Refresh Timeout MUST then be set, unless its value would increase by doing so, to the TTL in the POSITIVE NAME REGISTRATION RESPONSE, or to 5 minutes if the TTL is less than 5 minutes.
If the registration fails and an entry already exists in the Local Name Table, then the given interface MUST be added to the entry's Interface List, with its Conflict Detected Flag set.