Subject: [dhcwg] Am I missing something?

From: Michael Johnston <[email-masked]>
Date: Mon, 21 Jan 2002 00:22:31 GMT

There is no bootfile or TFTP server information in the DHCPv6 draft.  Maybe 
this is intentional.  Is there another mechanism that is to be used by 
network boot clients to locate image servers and download images?

%%michael 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Jim Bound <[email-masked]>
Date: Sun, 20 Jan 2002 20:39:39 -0500 (EST)

Michael,

This as a note showed up in some work I did for Infinband engineers who
chose IPv6 as the address to do that DL/API layer.  We may need an option
for a path to the boot file image but the approach we took for AD proto
code was as follows (back at about draft 15 with mini dhc6 code base)

Use dhc6 to find the SLP server.
Use SLP protocol and servers to find the image file.

So the question is with dhc6 is this the job of SLP now as we have
transfered other things to SLP within the thinking model of dhc6?

Also most server vendors that will build dhc6 will have SLP for IPv6 too?

/jim

---

From: Mark Stapp <[email-masked]>
Date: Mon, 21 Jan 2002 09:48:09 -0500

Michael,

I agree with you. I don't think that we should force our users to deploy 
and configure any additional protocols in order to locate their ftp 
servers. Those servers are a fundamental part of the boot process in some 
environments, and that's what DHCP is for, right? FTP and TFTP server 
options should be part of the base option set.

-- Mark

---

From: [email-masked]
Date: Mon, 21 Jan 2002 10:39:26 -0500

From: Mark Stapp <[email-masked]>

I'm not that familiar with DHCP usage, but my belief is that the most
common use for DHCP is distributing IPv4 addresses, and the
second-most-common use is for distributing TFTP addresses and file
names for fetching boot images.  If so, we would need a very strong
reason for eliminating the FTP server options.

Also, if the DHCP FTP server information is to be distributed by
another mechanism, we must ensure that existing boot ROMs will be able
to hold the code for the additional mechanism.  If not, a vendor will
recreate the FTP server options as a vendor-specific option, and 1,000
other vendors will copy it.

Dale
-- 
Dale R. WORLEY    Director, ABU Engineering     <[email-masked]>
GlobespanVirata	  Applications Infrastructure   http://emweb.com

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jan 2002 14:19:36 -0500

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.

For WG discussion - should the 'bootfile' and 'TFTP server' options be 
carried over verbatim to DHCPv6 or are there changes that should be made?

- Ralph

At 12:22 AM 1/21/2002 +0000, Michael Johnston wrote:
>There is no bootfile or TFTP server information in the DHCPv6 
>draft.  Maybe this is intentional.  Is there another mechanism that is to 
>be used by network boot clients to locate image servers and download images?
>
>%%michael

---

From: Jim Bound <[email-masked]>
Date: Mon, 21 Jan 2002 20:27:04 -0500 (EST)

Ralph,

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. 

/jim

---

From: Erik Guttman <[email-masked]>
Date: Tue, 22 Jan 2002 09:34:25 +0100

Jim,

 > 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.

Ralph,

>>slate.  'bootfile' and 'TFTP server' seem like good candidates for 

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?

Thanks,

Erik

---

From: Jim Bound <[email-masked]>
Date: Tue, 22 Jan 2002 19:25:06 -0500 (EST)

Eric,

Yourone of the tech leads for SLP and first driver in the IETF for this so
thats fine with me.  ACK.   

Lets put it in DHC6 then.

/jim