Subject: Re: [dhcwg] DHCPv6 remote boot options

From: Jens Freimann <[email-masked]>
Date: Sun, 24 Feb 2008 18:44:10 +0100

Hello,

Am Freitag, den 18.01.2008, 09:51 -0500 schrieb Bernie Volz (volz):
> Jens:
> 
> We figured that when someone had the need for using TFTP for booting via
> DHCPv6 that they would develop an Internet-Draft which then could be
> reviewed by the DHC WG and hopefully become an RFC. Without having a
> specific use case and someone actually interested in making use of the
> options, we figured it was not worth spending the time and effort to
> define them (and perhaps define them in a what that doesn't actually
> benefit people that do want to do this). Reviving the expired draft
> might be a good start.

can you tell me what"s wrong with the last draft?

	http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-rboot-00

I'd like to avoid making the same mistakes again. I couldn't find
something about it in the minutes of the WG meetings, except that it has
been discussed.

with kind regards,

Jens Freimann

> -----Original Message-----
> From: Jens Freimann [mailto:[email-masked]] 
> Sent: Friday, January 18, 2008 3:01 AM
> To: [email-masked]
> Subject: [dhcwg] DHCPv6 remote boot options
> 
> 
> Hello,
> 
> RFC 3736 [0] doesn't say anyting about TFTP server and filename options.
> Is
> there really no way to do this with DHCPv6?
> 
> I found and old IETF draft "DHCPv6 Support for Remote Boot -
> draft-ietf-dhc-dhcpv6-opt-rboot-00.txt" [1] but it expired in 2004.
> 
> If there is no such option yet, how could one tell clients about tftp
> server and bootfile name? 
> 
> I am new to DHCP and especially DHCPv6. It would be nice if somebody
> could 
> give me a hint.
> 
> 
> With kind regards
> 
> Jens
> 
> [0] http://www3.tools.ietf.org/html/rfc3736
> [1] http://www3.tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-rboot-00
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 24 Feb 2008 22:42:04 -0500

Jens:

Yes, that was the old draft I was talking about.

You might see:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg03060.html

I couldn't find more discussion, but I vaguely recall there was some
discussion about whether there was a need for more than one file path
and exactly how the multiple server/paths worked (what if the first
server has 3 files, and the first two are downloaded but the server
stops responding during the 3rd; how should the client continue)? It
also isn't clear how other options that might be defined in the future
work with the existing ones - suppose you wanted to define options for a
specific server? How does that get mixed in the the list of
server/paths?

I think there was some discussion about a more hierarchical approach.

	Boot Option 1
		- Server Address Option and/or Server Domain Name Option
		- Path name Option(s) - one path per option.
		- <future options that apply to this server>
	Boot Option 2
		- Server Address Option and/or Server Domain Name Option
		- Path name Option(s)
		- <future options that apply to this server>

All of the items in the Boot Option N apply to that server. By having
both a server address and server domain name option, either one or both
could be supplied and a client that didn't support doing DNS could use
the address; otherwise it uses the name. (One could even have multiple
addresses in the server address option to provide redundancy - the
length of the option would then be multiples of 16 depending on the
number of addresses).

The above would require defining 3 or 4 options:
	- Boot Container Option (contains other options)
	- Boot server address list option (one or more addresses)
	- Boot server domain name option (single FQDN)
	- Boot path name option (single name)

There are other designs as well (such as the one in the draft).

- Bernie

-----Original Message-----
From: Jens Freimann [mailto:[email-masked]] 
Sent: Sunday, February 24, 2008 12:44 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: RE: [dhcwg] DHCPv6 remote boot options

Hello,

with kind regards,

Jens Freimann

---

From: Ralph Droms <[email-masked]>
Date: Mon, 25 Feb 2008 14:39:49 -0500

I think there has also been some discussion about whether it's  
possible to define a "generic" use of these options, or whether the  
use by specific classes devices is sufficiently distinct to warrant  
different options.  That observation is related to Bernie's comments  
about the overall booting model and semantics for specific options.

F- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 25 Feb 2008 14:49:21 -0800

> about the overall booting model and semantics for specific options.

Right, it seems to me the sort of thing done in DHCPv4 before
the VIV[CS]O options existed, and in DHCPv6 it seems more like we want
to evaluate if this is the sort of thing you'd do in DHCPv6's V[CS]IO
options.  My gut feeling is there is some utility to a generic option
(so your overworked server operator doesn't need to enter in a lot of
extra option code definitions for every single vendor), but I don't
like to make decisions based on my gut.

Maybe a simple answer is that a DHCPv6 level "simple" option could
exist, and vendors can use the vendor options for anything more
"tuned."

I'd shoot for the median common denominator, if we knew what that was,
or the least common denominator otherwise.  What is the mainstream
epistemology these days on how a network boot should "go"?  Surely
not TFTP?

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg