nmbd & netbios name -> many addreses

[Christopher R. Hertel]

> 
> Christopher R. Hertel wrote:
> > It makes sense that a multi-homed host would register multiple IPs per
> > unique name.  The name represents a service, and NetBIOS is only being
> > emulated over TCP/IP.  So, the Service exists on multiple emulated
> > NetBIOS networks, all sharing a single WINS server.  Uhhhrrgh.
> 
> 	Yup: the semantic gap is rather gaping here (:-))
> 	However, if the client makes the PC assumption that
> 	it's on a single LAN, and that it only could have one
> 	address, it's only going to try registering what it
> 	thinks is it's primary address.

The line between the NetBIOS LAN and the TCP/IP network(s) is easy to
blurr.  As I work toward a clearer understanding of RFC1001/1002, the 
distinction becomes more clear.

In a NetBIOS LAN, a NetBIOS name is the address of a client or service
port.  It is analogous to an IP address *plus* port number in the IP
world, because it identifies both the machine and the piece of software
that is communicating on the network. 

The RFCs describe a means of emulating a NetBIOS LAN (emphasize LAN) over 
TCP/IP.  The emulated LAN exists over the union of the IP Broadcast 
domain and the set of systems sharing the same NBNS.

NetBIOS itself doesn't know or need to know anything about multiple
interfaces.  The IP layer handles that.  The NetBIOS layer only knows (and
only needs to know) about the NetBIOS names (i.e., NetBIOS services and
clients) it can reach. 

> 	A wins server that knows this is false can take certain
> 	actions, including discovering all the adresses the
> 	machine has, IFF it's in the dns as having multiple 
> 	adresses per dns name, by doing a reverse lookup
> 	to go from ip adress to dns name and then a forward one
> 	to see if it has multiple A records.

I had to re-read that a couple of times, but I've got it now.  You're
describing a mechanism for listing all of the interfaces associated with a
given machine.  (I always get nervous when NBNS and DNS are listed
together, as the name spaces are separate.)

> 	I'd be disinclined to do so!  It would only work if
> 	the dns person put fred is as (bogus example)
> 		fred	A	129.155.8.39
> 		fred	A	129.155.9.67
> 	instead of
> 		fred-8	A	129.155.8.39	
> 		fred-9	A	129.155.9.67
> 		fred	CNAME	fred-8

Right.  The mechanism is interesting for discussion, but not practical for
an NBNS.  If the multi-homed client only registers one IP address per
name, then we have no problem (since the problem was NBNS servers handing
back multiple IPs in response to a query).  Looking for additional IPs 
isn't something we want/need to do.

> 	A very smart smb server, knowing it was on a multihosted machine,
> 	might arrange to register itself with an equivalently smart wins
> 	server on multiple interfaces, so we might arrange to support but
> 	not require such behavior, and plan on making Samba smarter...

The real key when it comes to multi-homed hosts is routing.  If you have
an SMB server which is multi-homed, you want your clients to get the IP
address of the server interface which is "closest" (in hops and cost) to
them. 

  (   )       +---+       (   )
( Net A )-----1 s 2-----( Net B )
  (   )       | m |       (   )
              | b |
              +---+

You would want nodes attached to Net B to get the IP address of interface 
2, and nodes attached to Net A to get the IP address of interface 1.  (Of 
course, I assume that Net A and Net B are routed internets, otherwise you 
could just use broadcast name resolution to find the closest interface, 
since it's on the same wire.)

(A really, really smart smb server would be able to register each IP
address with a different NBNS.)

> 	A different kind of wins server, one which was designed to
> 	be integrated with a dns server, might use the lookup method,

Urrrgh!  No no no.  The NetBIOS name space and the DNS name space are 
*separate things*.  Many people, and MS too, have tried to map NetBIOS 
names to DNS names.  They don't map.  You can, for convenience, use the 
same letters (eg. "FRED" and "fred") for your NetBIOS machine name and 
your DNS node name.  The fact that both are called Fred is just a surface 
similarity.  The two are very different names.

Having said that (and I'm sure I'll be saying it again), the desire for the
convenience of using the same name is great.  So much so that I've spent 
a long, long time trying to get it to work.  It is fudgeable, but only if 
you first understand the underlying separation between the two names.

> 	and keep track of the dns names of the machines, too: if we wanted
> 	we could design such. I'd be tempted to prototype it on top
> 	of an ldap server and a dns client, though: I think the complexity
> 	would grow really fast (;-))

Yes.  Really fast.  And, of course, it doesn't scale.  The NBNS system 
maps a LAN on top of a routed inter-network.  NetBIOS doesn't scale to 
the same degree as that inter-network does.

> > I think that the right way for the WINS server to behave is to look at the
> > query packet and figure out, as best it can which of the IPs would be on
> > the same TCP/IP LAN.  
>
> 	If we want to support multiple adresses, that would be a sane
> 	approach.

I believe so but, as Jeremy points out, that's not what NT does.  Still, 
it might be nice to make it a configurable option.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services