Windows Internet Naming Service (WINS)

Introduction

NetBIOS was invented by IBM and is used extensively by Microsoft in the Windows environment to provide a more intuitive method of networking using device names instead of meaningless addresses. NetBIOS is described in some detail in the document NetBIOS where you will see how NetBIOS can use NetBEUI, IPX or IP to traverse a network. IPX and IP are required as transport protocols if you require NetBIOS to operate across a routed network since NetBEUI is not routable. On an IP network NetBIOS names have to be mapped to IP addresses. This can be achieved with static mappings or with a dynamic method such as WINS that use the P-node server (NBNS) concept. Click on NetBIOS over IP for more background.

The LMHOSTS File

In order to cut out the chance of broadcasts occurring when resolving IP addresses to names you can create a file on a node called an LMHOSTS (LAN Manager Hosts) file where IP addresses and NetBIOS names have been mapped manually. Each entry in the LMHOSTS file contains an IP address, a tab and the NetBIOS name with perhaps a hash character (#) followed by a comment, an example might be:

10.10.1.1 HTTP # HTTP server

The number of bytes assigned for NetBIOS names is 16. The 16th byte is reserved by IBM and Microsoft and is often used to identify things such as services by SMB/CIFS (analogous to TCP/UDP ports). One station could have a number of names. There is a special name called NETBIOS_NAME_1 which consists of 10 zeros and the MAC address of the NIC. Certain rules apply to the LMHOSTS file such as NetBIOS names are limited to 15 characters (bytes), the 16th one being reserved. In addition, hex characters in a name are preceded by \0x. An exception to the use of the hash character is if you want to preload an entry into the NBT cache on startup. You do this preloading on a per entry basis using the tag #PRE after the entry. Any comments can still be added afterwards. As an example, if we wanted to preload the web server entry just discussed, then the entry would change to the following:

10.10.1.1 HTTP #PRE # HTTP server

LMHOSTS files can only be locally maintained, not centrally like DHCP or DNS servers.

WINS

A more scalable method for NetBIOS to IP address resolution, is to use WINS servers which are effectively P-nodes servers that have large lists of NetBIOS names mapped to IP addresses. WINS is proprietary to Microsoft and it is an example of NBNS that uses TCP/UDP port 137 and the NBT datagram format, however nodes that run SAMBA can also act as P-node servers. A WINS server has a number of methods of dynamically populating its database, chiefly through WINS clients registering themselves with their designated server (configured manually on the client or given via DHCP). Another method, if DHCP is also running on the WINS server, is for the WINS server to query the DHCP database that has hostname to IP address mappings. DNS can also be used, however DNS names include more than just the NetBIOS hostname e.g. the DNS name such as 'web.rware.com', where the NetBIOS name is 'web'.

You can have up to 100 WINS server peers amongst which database information is exchanged allowing replication of local networks on a more global scale, this gives resilience and load balancing. Each entry in the database has a state associated with it can either be in the ACTIVE, RELEASED, or EXTINCT (also known as TOMBSTONE) state. Entries are also assigned a Version ID. This number is used in the replication process. As well as having Dynamic name registration, Static name registration is also allowable for legacy systems that do not support Dynamic names.

WINS servers hold on to local NetBIOS broadcasts so that they can answer on behalf of other nodes so letting the WINS database to be used with legacy NetBIOS applications that do not support WINS. When a B-node advertises its presence on the network, any local WINS servers will store the information in their database and will respond to lookup queries from remote systems on behalf of the local node. The WINS server will only pick up on broadcasts issued on the network segments that it is physically attached to, since the legacy system does not know how to forward the name and address pair to remote WINS servers on other networks.

You can configure your PCs to be WINS Proxy servers that will respond to broadcasts, although they cannot be used as formal P-node servers. When a local broadcast is issued by a non-WINS client, the WINS proxy server will issue a query on behalf of the client to a predefined WINS server. The WINS proxy then stores the responses in its local NBT cache and responds to any subsequent requests for that particular NetBIOS node name. Since most clients issue multiple broadcasts, the WINS proxy can generally respond to the original query prior to the client's broadcast timing out. The particular entry is held in the cache until it expires or the cache space is needed for new entries.

Name Registration and Release

A device on the network is configured with a WINS server IP address, either directly or via DHCP. This device then requests the use of a NetBIOS name, either a Unique name or a Group name by sending a Name Registration Request dirctly to the server. The device may request more than one name.

If the name does not exist in the database, then it is considered to be a new name registration. The name for the device is entered with a new version ID, the name is also given a time stamp, and marked with the owner ID of the WINS server. The time stamp is calculated based on adding the value of the Renew interval (which by default, is 6 days) set on the WINS server. A Positive Registration Response is sent back to the device with a TTL value equal to the time stamp recorded for the name on the server.

If the name does exist and has the same IP address within the database then there are two options:

If the state of the entry is ACTIVE and the entry is owned by that WINS server, then the timestamp is updated and a Positive Registration Response send back to the client.
If the state of the entry is RELEASED or TOMBSTONED, or it is owned by another WINS server, then a new entry is created and Positive Registration Response send back to the client.

If the name exists in the database but with a different IP address then if the name is in the RELEASE or TOMBSTONE state, it can be reassigned. If it is in ACTIVE state then in order to avoide duplicate names the following takes place:

The server sends a Wait For Acknowledgement (WACK) packet to the client with a Time-to-Live (TTL) which defines how long the client should wait for a response.
The server then sends a Name Query Request to the current owner of the name.
If the owner exists, it then sends a Positive Response back.
The server then sends a Negative Response back to the original requesting client.
If there is no response from the owner after three attempts, then the new client is sent a Positive Response and the database is updated with the new Name to IP address mapping.

If a WINS server is shut down, then the names are released by the server.

When a client shuts down, it sends a Release Request to the Server. A Release Request is also sent when the nbstat -RR command is issued. The server marks the name as in the RELEASE state until a period of time has elapsed when the ID is updated and the entry is changed to the TOMBSTONED state. The Server also sends a Release Confirmation message to the client.

If the client does not receive a Release Confirmation message, then it may broadcast the Release Request.

Name Renewal

NetBIOS names need to be renewed regularly according to the Time-to-Live (TTL) parameter set by the server. This is also called the Renewal Interval and defaults to 6 days. If you have multiple WINS servers it is important that this Renewal Interval be consistent throughout the network.

Clients start the Renewal process when 50% of their Renewal Interval has elapsed, this 3 days by default. Names are refreshed by sending a Name Refresh Request to the WINS server. If the server does not respond the client usually increases the rate at which it sends the requests. If the client does not renew its name within the renewal Interval then the server will release the name.

Resolving NetBIOS Names

Name Resolution in a Windows environment generally follows this sequence of steps:

Check if the name is longer than 15 characters or if it contains periods, if it does, then query DNS for the name.
Check if the name is stored in the remote name cache at the client.
Contact and try configured WINS servers to attempt to resolve the name using WINS.
Use local IP broadcasts to the subnet.
Check an LMhosts file if Enable LMHOSTS Lookup is enabled in the Internet Protocol (TCP/IP) properties for the connection.
Check a Hosts file.
Query a DNS server.

Static Name Mappings

Statically mapping names to addresses is useful for clients that cannot communicate with WINS servers. Alternatives include using an LMHOSTS files (see earlier), or a DNS server since most IP clients are able to make use of DNS.

Mapped name-to-address entries can be added to WINS in one of two ways:

Dynamically - by WINS-enabled clients directly contacting a WINS server to Register, Release, or Renew their NetBIOS names in the server database.
Manually - by an administrator using the WINS console or command-line tools to add or delete statically mapped entries in the server database. This includes importing an LMHOSTS file.

Static mappings remain in the database indefinitely and do not age out or get replaced, even if the client attempts to update the name associated with that IP address. Static mappings can be removed manually, or they can be migrated to Dynamic entries by use of the feature Overwrite unique static mappings which allows to update a static entry with a new name. The entry then becomes a dynamic entry.

Communication Between WINS servers

NetBIOS Databases are shared using the concept of Push Partners and Pull Partners. When you configure a server as a Push Partner, it will replicate database entries on startup, at regular intervals or when changes occur to the IP address to name mappings or the Version ID. Push Replication occurs only with servers configured as Pull Partners.

By default, there are required to be 20 changes in Version ID before Push Replication occurs. This can be changed if the server is configured for Persistent Connections where a Push Replication occurs every time that there is a change.

Windows NT Commands

Some Windows NT commands related to NetBIOS are listed below:

nbstat -a <name> - list the NetBIOS name table (HOSTS file) for the remote computer specified.
nbstat -A <ip address> - as above but specified by IP address.
nbstat -c - list names and IP addresses in the local NetBIOS cache.
nbstat -n - list all the NetBIOS names for the local computer (those used by the various services). This is called the Local NetBIOS Names Table.
nbstat -r - NetBIOS statistics.
nbstat -R - reloads the local NetBIOS cache.
nbstat -RR - releases and refreshes registration of the local NetBIOS names of the client with WINS.
nbstat -s - lists currently open NetBIOS sessions by name.
nbstat -S - lists currently open NetBIOS sessions by IP address

Home

Disclaimer