RFC - NBT2

[Luke Kenneth Casson Leighton]

netbios never died, it only went away.

i am greatly concerned that key people in microsoft
are retiring, leaving behind critical infrastructure
and extremely valuable work that is being misunderstood
by too many cooks and [relatively] short-lived employees.

this draft document is a first step in the first layer
to address this quite serious problem [that is becoming
apparent through moves like "Not dET"].

netbios [and the network neighbourhood] is a classic example
of very valuable work that, due to implementation mistakes,
is not being updated - lost by the wayside when it can be
put to use in unexpected ways to solve numerous quite
important and real computing problems.

i'm putting out draft-lkcl-nbt2-00.txt for review.
if you understand the need for netbios to be modernised,
your comments are welcome.  if you can think of unexpected
adverse issues that may affect netbios' future over the
next twenty years or so, your comments are welcome.  if
you wish to just bitch about netbios, please do so somewhere
else.

for want of a better location, discussion to take place on
the microsoft cifs list - for preference but not a hard and
fast rule.

please also bear in mind that you know full well that i have
very little time and money to spare, so i will most likely
read, lurk and update as-and-when over the weeks: your
valuable input will not, however, be ignored.

thank you.

lkcl

p.s. Document to be updated at:
     http://cb1.com/~lkcl/cifs/draft-lkcl-nbt2-00.txt


NetBIOS Version 2 - 5th Dec 2001
-----------------

NetBIOS, often mistaken for NETBEUI, is now a little-known
and extremely useful transport that provides dynamic
robustness in the face of network disruption, abuse, and
mis-configuration.

NetBIOS over TCP/IP was introduced to us in rfc1001 and
1002.  It has limitations.

The first limitation is that data transfers are restricted
by a 17 bit length field (131072 bytes).  The second
limitation is that NetBIOS's dynamic capabilities, based
on extensions to DNS, have been hampered by name "mangling",
by poor implementation of naming, and zero security.
The third limitation is that NetBIOS is ageing, and
therefore being forgotten.

This proposal aims to address these limitations.

1) Use port 445 (not 137, 138, 139).

	- UDP on port 445 is NetBIOS Datagram
	  (equivalent to rfc1001/2 port 138.
	  see rfc1002 section 5.3 Page 73).

	- TCP on port 445 is NetBIOS Session
	  (equivalent to rfc1001/2 port 139.
	  see rfc1002 section 5.2 Page 66).

	  Special consideration is given to
	  "special" compatibility with CIFS over
	  TCP on port 445, which can easily
	  coexist with NBT2).

	- A new Session Packet Type (see rfc1002
	  section 4.3.1 Page 29) of 0xA0 indicates a
	  NetBIOS Name Service request or response
	  (equivalent to rfc1001/2 port 137.
	  see rfc1002 section 5.1 Page 34).

	  0xA0 -  NetBIOS NAME SERVICE MESSAGE

	- A new Session Packet Type (see rfc1002
	  section 4.3.1 Page 29) of 0xA1 indicates 
	  DNS Name Service request or response
	  (equivalent to rfc1001/2 port 137.
	  see rfc1002 section 5.1 Page 34).

	  0xA1 -  DNS     NAME SERVICE MESSAGE

	Note:

	  The DNS and NetBIOS Name Service data is
	  encapsulated in the Trailer of a Session Packet 
	  (see rfc1002 section 4.3.1 Page 29).

	  The DNS and NetBIOS Name Service data can
	  be transmitted either over UDP (which is
	  what is normally implemented) or over TCP
	  (which is less common).  Regardless: they
	  are both transmitted encapsulated as
	  outlined above (in contrast to rfc1002
	  section 4.2.1 Page 6, Paragraph 2).

	  
	Recommended Reading:

	  see rfc1001 section 11.1.1 Page 18.

	Rationale:

	  allowing either DNS or NetBIOS Name Service to
	  be used provides an upgrade path to the preferred
	  (and more secure) system - Dynamic DNS.


2) Getting Unique and Group Names and the Name Type
into DNS.

	The DNS Name Format, when used over port 445,
	must be extended to allow NetBIOS Name-related
	features to be used.
	
	The octothorpe character "#" and the character "*" are used
	to separate the NetBIOS "Name" from the NetBIOS "Name Type"
	(in hexadecimal).  The octothorpe is used to separate Unique
	NetBIOS Names from their Type, and the "*" character is used
	to separate Group NetBIOS Names from their Type, as follows:

	Group Name bdc1.microsoft.com. and type 0x1c:

		bdc1.microsoft.com.*1C

	Unique Name pdc.microsoft.com. and type 0x1b:

		pdc.microsoft.com.#1B


3) TODO: Length Field extension (and compatibility
with CIFS over TCP length usage)