Subject: Finding servers

From: Rajeev Chawla <[email-masked]>
Date: Thu, 24 Aug 2000 09:37:52 -0400 (EDT)

Hi,

I am new to DHCP and have a few basic questions:

Can I use DHCP to find all servers of a certain type, if I manually
configure the IP addresses of these servers on the DHCP server?  My
understanding is that I will have to modify the DHCP client on my client
devices to get these addresses from the DHCP server using ‘Vendor Specific
Information’ option and 'dhcpinform'.
Is there any other way in DHCP to do this?
Can the servers dynamically register with the DHCP server (so that they 
don’t have to be manually configured and if they crash or become
unreachable, DHCP server can age out that information)?

Thanks,

Rajeev

-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com

---

From: Ralph Droms <[email-masked]>
Date: Mon, 28 Aug 2000 17:15:48 -0400

At 09:37 AM 8/24/00 -0400, Rajeev Chawla wrote:
>configure the IP addresses of these servers on the DHCP server?

Depending on the option (some options can only carry the address of one 
server), the DHCP server will send back a list of the servers configured 
for that option.

>   My
>devices to get these addresses from the DHCP server using 'Vendor Specific
>Information' option and 'dhcpinform'.

You may need to do a little research to find out how your particular client 
makes the parameters in DHCP options available to application 
programs.  You shouldn't need to use the vendor specific option and DHCPINFORM.

>don't have to be manually configured and if they crash or become

Getting the addresses of other servers into the DHCP server is outside the 
scope of the DHCP spec...

- Ralph Droms

---

From: Erik Guttman <[email-masked]>
Date: Tue, 29 Aug 2000 13:48:19 +0200 (MET DST)

> scope of the DHCP spec...

You can discover services with the service location protocol (SLPv2 -
RFC 2608).  This protocol handles dynamic registration and allows a 
client to request not only service 'by type,' but also 'by characteristic.'
The client can issue a request with a 'search filter' so that only services
which have the right software version, are in the right location, have an
account for the given user, etc. will match the request.  Most important,
only those services which are *actually available* on the network will be
discovered.

DHCP provides a subset of these features.  On a network where administrators
can keep track of which services are up or down at any given time, and which
services each client should be assigned DHCP is a great solution.  

On networks where decentralized operation is desirable or there are many
services of the same kind but with different characteristics SLP is a 
good alternative.

Erik Guttman

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 29 Aug 2000 11:01:50 -0700

> client to request not only service 'by type,' but also 'by
> characteristic.' The client can issue a request with a 'search filter'
> so that only services which have the right software version, are in
> the right location, have an account for the given user, etc. will
> match the request.  Most important, only those services which are
> *actually available* on the network will be discovered.

It might be a useful feature for somebody to put an SLP listener into a
DHCP server, which would also solve the original poster's objective.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Erik Guttman <[email-masked]>
Date: Wed, 30 Aug 2000 13:01:41 +0200 (MET DST)

> DHCP server, which would also solve the original poster's objective.

SLP has 3 entities:  A 'UA' which *actively* requests services, a 'SA'
which *passively* listens for requests, a 'DA' which - if it exists -
announces itself (this is the only entity which announces itself).  If
there is a DA, the UAs unicast requests to it, and the SAs register with
it.  A DHCP server could be collocated with a 'DA' so that it could list
services which were 'actually present' on the network.  There are three
problems with this model, all of which are *minor*:

 (1) DHCP servers receive only requests for services 'by type'
     Which services should be returned to DHCP clients when SLP
     registers different services of the same type.  All?  Some?

 (2) SLP security would be advisable, so that DHCP servers couldn't
     be trivially tricked into configuring DHCP clients with bogus
     services.  As DHCP itself is insecure this is not a big issue.

 (3) SLP registrations are soft state - that is a service advertisement
     is only good for some time.  The only soft state configuration
     which DHCP manages is address configuration.  SLP returns how long
     service locations can be cached.  DHCP has no mechanism to do this.
     So there is a possibility that service configuration obtained by
     DHCP would be 'stale' - the client should then ask for the config
     information again.  The client would have no way to detect this
     except by trying to contact the service and failing.  

It is a *very good idea* to allow access to service location information
consistently across different protocols.  I propose writing a draft for
'BCP' RFC status which describes how a single back-end can be used to 
store service locations for consistent retrieval using SLP, DHCP, LDAP
and DNS SRV RRs.  This might lead to a common 'SLP service template' and
'LDAP schema' for Internet Services to aid in interoperability between
these different protocols.

Is there interest in this draft in the DHC WG?  Should I write this as
an individual contribution or seek to do it in another WG?

Erik