docs/Samba3-Developers-Guide/NetBIOS.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
   3 <chapter id="netbios">
   4 <chapterinfo>
   5         <author>
   6                 <firstname>Luke</firstname><surname>Leighton</surname>
   7         </author>
   8         <pubdate>12 June 1997</pubdate>
   9 </chapterinfo>
  10
  11 <title>Definition of NetBIOS Protocol and Name Resolution Modes</title>
  12
  13 <sect1>
  14 <title>NETBIOS</title>
  15
  16 <para>
  17 NetBIOS runs over the following transports: TCP/IP; NetBEUI and IPX/SPX.
  18 Samba only uses NetBIOS over TCP/IP.  For details on the TCP/IP NetBIOS
  19 Session Service NetBIOS Datagram Service, and NetBIOS Names, see
  20 rfc1001.txt and rfc1002.txt.
  21 </para>
  22
  23 <para>
  24 NetBEUI is a raw NetBIOS frame protocol implementation that allows NetBIOS
  25 datagrams to be sent out over the 'wire' embedded within LLC frames.
  26 NetBEUI is not required when using NetBIOS over TCP/IP protocols and it
  27 is preferable NOT to install NetBEUI if it can be avoided.
  28 </para>
  29
  30 <para>
  31 IPX/SPX is also not required when using NetBIOS over TCP/IP, and it is
  32 preferable NOT to install the IPX/SPX transport unless you are using Novell
  33 servers.  At the very least, it is recommended that you do not install
  34 'NetBIOS over IPX/SPX'.
  35 </para>
  36
  37 <para>
  38 [When installing Windows 95, you will find that NetBEUI and IPX/SPX are
  39 installed as the default protocols.  This is because they are the simplest
  40 to manage: no Windows 95 user-configuration is required].
  41 </para>
  42
  43 <para>
  44 NetBIOS applications (such as samba) offer their services (for example,
  45 SMB file and print sharing) on a NetBIOS name.  They must claim this name
  46 on the network before doing so.  The NetBIOS session service will then
  47 accept connections on the application's behalf (on the NetBIOS name
  48 claimed by the application).  A NetBIOS session between the application
  49 and the client can then commence.
  50 </para>
  51
  52 <para>
  53 NetBIOS names consist of 15 characters plus a 'type' character.  This is
  54 similar, in concept, to an IP address and a TCP port number, respectively.
  55 A NetBIOS-aware application on a host will offer different services under
  56 different NetBIOS name types, just as a host will offer different TCP/IP
  57 services on different port numbers.
  58 </para>
  59
  60 <para>
  61 NetBIOS names must be claimed on a network, and must be defended.  The use
  62 of NetBIOS names is most suitable on a single subnet; a Local Area Network
  63 or a Wide Area Network.
  64 </para>
  65
  66 <para>
  67 NetBIOS names are either UNIQUE or GROUP.  Only one application can claim a
  68 UNIQUE NetBIOS name on a network.
  69 </para>
  70
  71 <para>
  72 There are two kinds of NetBIOS Name resolution: Broadcast and Point-to-Point.
  73 </para>
  74
  75 </sect1>
  76
  77 <sect1>
  78 <title>BROADCAST NetBIOS</title>
  79
  80 <para>
  81 Clients can claim names, and therefore offer services on successfully claimed
  82 names, on their broadcast-isolated subnet.  One way to get NetBIOS services
  83 (such as browsing: see ftp.microsoft.com/drg/developr/CIFS/browdiff.txt; and
  84 SMB file/print sharing: see cifs4.txt) working on a LAN or WAN is to make
  85 your routers forward all broadcast packets from TCP/IP ports 137, 138 and 139.
  86 </para>
  87
  88 <para>
  89 This, however, is not recommended.  If you have a large LAN or WAN, you will
  90 find that some of your hosts spend 95 percent of their time dealing with
  91 broadcast traffic.  [If you have IPX/SPX on your LAN or WAN, you will find
  92 that this is already happening: a packet analyzer will show, roughly
  93 every twelve minutes, great swathes of broadcast traffic!].
  94 </para>
  95
  96 </sect1>
  97
  98 <sect1>
  99 <title>NBNS NetBIOS</title>
 100
 101 <para>
 102 rfc1001.txt describes, amongst other things, the implementation and use
 103 of, a 'NetBIOS Name Service'.  NT/AS offers 'Windows Internet Name Service'
 104 which is fully rfc1001/2 compliant, but has had to take specific action
 105 with certain NetBIOS names in order to make it useful.  (for example, it
 106 deals with the registration of &lt;1c&gt; &lt;1d&gt; &lt;1e&gt; names all in different ways.
 107 I recommend the reading of the Microsoft WINS Server Help files for full
 108 details).
 109 </para>
 110
 111 <para>
 112 The use of a WINS server cuts down on broadcast network traffic for
 113 NetBIOS name resolution.  It has the effect of pulling all the broadcast
 114 isolated subnets together into a single NetBIOS scope, across your LAN
 115 or WAN, while avoiding the use of TCP/IP broadcast packets.
 116 </para>
 117
 118 <para>
 119 When you have a WINS server on your LAN, WINS clients will be able to
 120 contact the WINS server to resolve NetBIOS names.  Note that only those
 121 WINS clients that have registered with the same WINS server will be
 122 visible.  The WINS server _can_ have static NetBIOS entries added to its
 123 database (usually for security reasons you might want to consider putting
 124 your domain controllers or other important servers as static entries,
 125 but you should not rely on this as your sole means of security), but for
 126 the most part, NetBIOS names are registered dynamically.
 127 </para>
 128
 129 <para>
 130 This provides some confusion for lots of people, and is worth mentioning
 131 here:  a Browse Server is NOT a WINS Server, even if these services are
 132 implemented in the same application.  A Browse Server _needs_ a WINS server
 133 because a Browse Server is a WINS client, which is _not_ the same thing].
 134 </para>
 135
 136 <para>
 137 Clients can claim names, and therefore offer services on successfully claimed
 138 names, on their broadcast-isolated subnet.  One way to get NetBIOS services
 139 (such as browsing: see ftp.microsoft.com/drg/developr/CIFS/browdiff.txt; and
 140 SMB file/print sharing: see cifs6.txt) working on a LAN or WAN is to make
 141 your routers forward all broadcast packets from TCP/IP ports 137, 138 and 139.
 142 You will find, however, if you do this on a large LAN or a WAN, that your
 143 network is completely swamped by NetBIOS and browsing packets, which is why
 144 WINS was developed to minimise the necessity of broadcast traffic.
 145 </para>
 146
 147 <para>
 148 WINS Clients therefore claim names from the WINS server.  If the WINS
 149 server allows them to register a name, the client's NetBIOS session service
 150 can then offer services on this name.  Other WINS clients will then
 151 contact the WINS server to resolve a NetBIOS name.
 152 </para>
 153
 154 </sect1>
 155
 156 </chapter>