Re: [dhcwg] Am I missing something?

Erik Guttman <> Tue, 22 January 2002 08:44 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id DAA13857 for <>; Tue, 22 Jan 2002 03:44:26 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id DAA26857 for; Tue, 22 Jan 2002 03:44:29 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id DAA26746; Tue, 22 Jan 2002 03:36:08 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id DAA26721 for <>; Tue, 22 Jan 2002 03:36:07 -0500 (EST)
Received: from (patan.Sun.COM []) by (8.9.1a/8.9.1a) with ESMTP id DAA13770 for <>; Tue, 22 Jan 2002 03:36:04 -0500 (EST)
Received: from ehdb03-home.Germany.Sun.COM ([]) by (8.9.3+Sun/8.9.3) with ESMTP id BAA23334; Tue, 22 Jan 2002 01:36:05 -0700 (MST)
Received: from (vpn-129-159-0-15.EMEA.Sun.COM []) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id JAA02926; Tue, 22 Jan 2002 09:36:03 +0100 (MET)
Message-ID: <>
Date: Tue, 22 Jan 2002 09:34:25 +0100
From: Erik Guttman <>
Organization: Sun Microsystems, GmbH
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jim Bound <>
CC: Ralph Droms <>, dhcwg <>
Subject: Re: [dhcwg] Am I missing something?
References: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit


 > I believe the IETF wants to move to SLP for this.  I think we need to
 > check.  I just don't want to build competing functions.  If we do it
 > fine but I think this requires some discussions iwth SLP folks too.

I must admit it's hard for me to conceive of DHCP without boot
parameter options.  I guess I'm showing my age.

SLP is great for discoving 'differentiated' services - that is
services which are not generic.  Boot images that can be found
by look-up-by-name are generic.  This does require that DHCP
servers be configured to know about TFTP servers and their
contents, but in practice, this has worked out fairly well.

Boot images which require multiple round trips between client
and server (as per PXE) are NOT generic and would be better
discovered via SLP.  [Aside:  PXE uses a hacked set of non-
standard DHCP messages to perform iterative queries to
configure a client to boot.]

Further examples of non-generic services include, say, peer to
peer file sharing services.  There is no standard way to update
the DHCP server dynamically, to know which service are available
on the network, or what (characteristics) differentiates them.
Clients seeking non-generic services don't want *just any* file
server, they want the file server with the name, description,
access permissions, etc. that they are seeking.  This is a great
application for SLP and an inappropriate one for DHCP.


>>We've taken an "on-demand" approach to adding options to DHCPv6 - that is, 
>>as options are requested, we've added them.  There hasn't been any 
>>intentional oversight; to avoid carrying forward unnecessary options (e.g., 
>>"Impress server"), we've simply started with a clean (or almost clean) 
>>slate.  'bootfile' and 'TFTP server' seem like good candidates for 
>>inclusion in DHCPv6.

I would like to see option 78 and 79 for DHCPv6 as well (SLPv2 DA
and SLPv2 scope list options.)  We are revising RFC2610 as part of
bringing SLPv2 to draft standard.  I guess we should include a
description of the DHCPv6 options there as well?  Are there any
examples of how to do that?  How do you suggest we proceed?



dhcwg mailing list