The NetBIOS Datagram Distribution Server (NBDD) compliments the NBNS. It assists in extending the virtual NetBIOS LAN across a routed IP internetwork by relaying multicast and broadcast NetBIOS datagrams to nodes on remote subnets. The NBDD’s job is to make sure that the datagrams get to where they’re supposed to go. It works something like a lawn sprinkler — one input leads to a spray of outputs. Here’s what happens:

That seems simple enough, but we claimed earlier that the Datagram Service is the second least well understood aspect of NBT. What are we missing?

A closer inspection reveals an obvious problem. If the number of destination nodes is large, a whole bigbunch of traffic will be generated — possibly enough to bring the NBT virtual LAN to its knees (which might really, really annoy people). The NBDD design will work well enough for small, trusted networks but it simply does not scale.

Another problem is that RFC 1001 offers a loophole for implementors: the NBDD is permitted to silently ignore requests to relay datagrams. If, for any reason (including laziness on the implementor’s part) the NBDD will not or can not relay a datagram, it simply discards the message without sending any sort of error message back to the originating node.

Node MICK wants to send a message to all members of group LINDISFARNE, but the NetBIOS LAN is distributed across a routed IP internetwork. MICK sends the datagram to the NBDD which relays the message to all group members.

Figure 5.1. The Datagram Distribution Server

This loophole might make the NBDD so unreliable as to be useless, except that the Datagram Service also supports a query operation that allows the client to ask the NBDD whether or not it will relay a message. If the NBDD answers the query with a “yes,” then the client can send the datagram with the assurance that it will be relayed to all intended recipients. A negative reply means that the NBDD will not relay the message.

Reminder Alert

Datagrams are not considered reliable. As with the UDP service in an IP network, it is expected that some NetBIOS datagrams may be lost.

By allowing the NBDD to silently discard datagrams, however, the lack of reliability is amplified well beyond what would be expected from simple network packet loss.

One more monkey-wrench to throw into the works... Given a multicast (not broadcast) datagram, if the NBDD will not relay the message, the client can give it another shot. The client has already performed a Name Service NAME QUERY REQUEST operation, and received a NAME QUERY RESPONSE from the NBNS. It did this to determine that the destination name was, in fact, a group name rather than a unique name. If the NBNS is RFC-compliant, then the NAME QUERY RESPONSE will contain a list of all the IP addresses of the group members. If the NBDD won’t relay the message, then the client can unicast the datagram to each entry in the list.

To summarize:

Confused? Don’t be surprised if you are. It isn’t a pretty system... and it gets worse. Because of the potential network problems and the awkwardness of the design, very few implementations even try to match the RFC specification. Unfortunately, no one has come up with a better solution... which means that what actually exists in the wild is worse than what was just described.

To be blunt, Microsoft messed up the Datagram Service. Their NBNS implementation (WINS) does not report all of the IP addresses associated with a group name. Instead, group names are mapped to a single IP address — the limited broadcast address: 255.255.255.255. This is contrary to the RFCs, and it causes a few problems.

Without a list of IPs for each group name, the NBDD cannot be implemented at all. With no NBDD and no IP list, there is no way to ensure that multicast and broadcast datagrams will be sent to all group members. This breaks the continuity of the NetBIOS virtual LAN. On a “real” NetBIOS LAN, a message sent to a group name would actually reach all members of that group. That is what should happen under NBT as well, but it doesn’t. The best that can be done is to broadcast on the local subnet, in which case some members of the group may get the message.

Microsoft must have realized their mistake, because they later created what they call “Internet Group” names (also called “Special Group” names). For names in this category, WINS comes close to behaving like a proper NBNS; it will store up to 25 IP addresses per name, deleting the oldest entry to make room if necessary. For these names, a POSITIVE NAME QUERY RESPONSE from a WINS server will list up to 25 valid IP addresses.

Internet Group names are identified by their suffix. Originally only group names with the 0x1C suffix were given special treatment, but more recently (with W2K?) group names with a suffix value of 0x20 can be defined as having Internet Group status. Note that unique names may also have these suffixes but, since they are not group names, no special handling is required.

Sadly, most non-Microsoft implementations (including Samba) follow Microsoft’s example. They map group names to the 255.255.255.255 IP address, store only 25 IPs for Special Group names, and fail to implement the NBDD.^[1] This can cause trouble for some clients (OS/2, for example) which expect RFC behavior.

Sigh.

That last section was a bit of a rant. Sorry. Time to pick up the pieces and move on. Let’s talk about how the parts that work actually work.

As with the Name Service, each Datagram Service packet has a header. The datagram header is 10 bytes long, arranged as follows:

Here is a quick rundown of the fields:

MSG_TYPE (1 byte)

FLAGS (1 byte)

DGM_ID (2 bytes)

SOURCE_IP (4 bytes)

SOURCE_PORT (2 bytes)

The above fields are common to all Datagram Service messages. RFC 1002 includes two more fields in its header layout: the DGM_LENGTH and PACKET_OFFSET fields. It is kind of silly to have those fields in the header, as they are specific to the messages which actually carry a data payload: the DIRECT_UNIQUE, DIRECT_GROUP, and BROADCAST DATAGRAM message types.

Since the DGM_LENGTH and PACKET_OFFSET fields are associated with the datagram transport messages, we will break with tradition and put those fields together with the message structure. Here is a record layout:

DGM_LENGTH (2 bytes)

PACKET_OFFSET (2 bytes)

SOURCE_NAME (34..255 bytes)

DESTINATION_NAME (34..255 bytes)

USER_DATA (0..512 bytes)

That’s basically all there is to it, with the exception of fragmentation. The example packet below describes an unfragmented message.

DATAGRAM_HEADER (unfragmented)
  {
  MSG_TYPE = <10 = unicast, 11 = multicast, 12 = broadcast>
  FLAGS
    {
    SNT = <Node type, as shown above>
    F   = TRUE   (This is the first in the series)
    M   = FALSE  (No additional fragments follow)
    }
  DGM_ID      = <Datagram identifier>
  SOURCE_IP   = <IP address of the originating node>
  SOURCE_PORT = <Originating UDP port>
  }
DATAGRAM_DATA
  {
  DGM_LENGTH       = <Name lengths plus USER_DATA length>
  PACKET_OFFSET    = 0
  SOURCE_NAME      = <Fully encoded NBT name of the sender>
  DESTINATION_NAME = <Fully encoded NBT name of the receiver>
  USER_DATA        = <Datagram payload>
  }

Some quick notes:

   10 bytes (Header)
+   2 bytes (DGM_LENGTH)
+   2 bytes (PACKET_OFFSET)
+ 255 bytes (maximum size of SOURCE_NAME)
+ 255 bytes (maximum size of DESTINATION_NAME)
+ 512 bytes (maximum size of USER_DATA)
-----
 1036 bytes

    0x82 == DESTINATION NAME NOT PRESENT
    0x83 == INVALID SOURCE NAME FORMAT
    0x84 == INVALID DESTINATION NAME FORMAT

DATAGRAM_HEADER
  {
  MSG_TYPE = 0x14 (DATAGRAM QUERY REQUEST)
  FLAGS
    {
    SNT = <Node type>
    F   = TRUE
    M   = FALSE
    }
  DGM_ID      = <Datagram identifier>
  SOURCE_IP   = <IP address of the originating node>
  SOURCE_PORT = <Originating UDP port>
  }
DATAGRAM_DATA
  {
  DESTINATION_NAME = <Encoded NBT name of the intended receiver>
  }