Subject: RE: [dhcwg] IDs on remote boot support for DHCP

From: "Bernie Volz" <[email-masked]>
Date: Tue, 4 Nov 2003 23:05:44 -0500

Vijay:

I don't understand the suboption (1) encoding for the multiple servers (ts
field) and the bootfiles (fn fields). Perhaps something happened with this
document or it is incomplete? Please look it over. Perhaps it is my problem,
but if it isn't clear, I'm sure others will have similar issues. Why don't
you just use two suboptions, one for the list of TFTP servers to use and
another for the bootfile names? Also, can the TFTP server names be IP
addresses? Perhaps you should consider using the DNS wire format instead of
ASCII?

I have a similar issue with the DHCPv6 draft. Seems to me if makes more
sense to have two options - one to list the TFTP servers and another to list
the bootfiles? (I guess there could be an argument made that different
bootfiles might be used with different servers???) It is also odd that you
would want to allow multiple TFTP server addresses in the DHCPv4 case, but
only allow one in the DHCPv6 case. Or have I missed something? One way
around this problem might be to allow multiple OPTION_REMOTE_BOOT and for
each of these, one can have a list of server (OPTION_REMOTE_BOOT_SERVERS)
and one or more boot files (OPTION_REMOTE_BOOT_FILES). For each instances of
the OPTION_REMOTE_BOOT, the servers would all use the same boot files.
However, if you want servers to use different boot files, you simply specify
multiple OPTION_REMOTE_BOOTs.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijayabhaskar A K
Sent: Friday, October 31, 2003 10:16 AM
To: [email-masked]
Subject: [dhcwg] IDs on remote boot support for DHCP

Hi All

I am attaching two new drafts dealing with remote boot support for DHCP.
I could not submit the draft to ID queue, as the deadline has crossed.
Please go through these drafts and let me know your comments. The
abstract of these drafts are given below

* The Extended Remote Boot Option for DHCPv4

Single TFTP server for huge number of diskless clients is prone
to single point of failure.  So, Multiple TFTP servers are needed for
high availability.  Moreover, some of the clients need multiple
bootfiles for boot up.  This document provides a new DHCPv4 option
for clients to obtain information about multiple TFTP servers and
bootfiles.

* DHCPv6 Support for Remote Boot

This document provides new DHCPv6 (Dynamic Host Configuration
protocol version 6) options for clients, to obtain information about
TFTP servers and bootfiles needed for booting.

Vijay

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 5 Nov 2003 20:47:06 +0530

Bernie

Thanks for your comments. My reply inline.. 

Vijay

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernie Volz
> Sent: Wednesday, November 05, 2003 9:36 AM
> To: 'Vijayabhaskar A K'
> Cc: [email-masked]
> Subject: RE: [dhcwg] IDs on remote boot support for DHCP
> 
> 
> Vijay:
> 
> field) and the bootfiles (fn fields). Perhaps something 
> happened with this document or it is incomplete? 

No. There is no problem with the draft. Option 66 and 67 are are used as
suboption to the suboption (1). Thus, 2 levels of suboptions are used
here.. The parsing of these suboptions should be done similar to the
other suboptions..

>Please look 
> it over. Perhaps it is my problem, but if it isn't clear, I'm 
> sure others will have similar issues. Why don't you just use 
> two suboptions, one for the list of TFTP servers to use and 
> another for the bootfile names? 

I want to associate files with the tftp servers.. If I define them as
you have suggested, the servers and files will be disjoint..

> Also, can the TFTP server 
> names be IP addresses?

Yes. It's a nice idea. A new suboption (op code: 1) can be defined for
Remote Boot Information suboption to carry a tftp server address. Either
this option or option 66 can appear in the ts field...

> Perhaps you should consider using the 
> DNS wire format instead of ASCII?

Both can co-exist with the model defined above..
> 
> I have a similar issue with the DHCPv6 draft. Seems to me if 
> makes more sense to have two options - one to list the TFTP 
> servers and another to list the bootfiles? (I guess there 
> could be an argument made that different bootfiles might be 
> used with different servers???) 

Same reason as that of DHCPv4

> It is also odd that you would 
> want to allow multiple TFTP server addresses in the DHCPv4 
> case, but only allow one in the DHCPv6 case. Or have I missed 
> something? 

Section 5 says:

This option can only appear in the OPTION_REMOTE_BOOT. If multiple
Remote Boot Parameters Options are present in OPTION_REMOTE_BOOT,
then they should be listed in the increasing order of preferences.

Doesn't this convey that mutiple tftp servers can be sent?
OPTION_REMOTE_BOOT can encapsulate mutiple OPTION_REMOTE_BOOT_PARAMS,
which inturn contain a tftp server address and one or more boot files..
Thus OPTION_REMOTE_BOOT can carry multiple boot server addresses and
associated boot files...

> One way around this problem might be to allow 
> multiple OPTION_REMOTE_BOOT and for each of these, one can 
> have a list of server (OPTION_REMOTE_BOOT_SERVERS) and one or 
> more boot files (OPTION_REMOTE_BOOT_FILES). For each 
> instances of the OPTION_REMOTE_BOOT, the servers would all 
> use the same boot files. However, if you want servers to use 
> different boot files, you simply specify multiple OPTION_REMOTE_BOOTs.

The same thing can be achieved using my design with the additional
advantages of conveying preference of one tftp server over the other.

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 5 Nov 2003 13:18:26 -0800

> for clients to obtain information about multiple TFTP servers and

First, I'd like to clarify the precedence of DHCP options and fields:

	order		option or field name
	-------	-----------------------------
	highest	proposed Extended Remote Boot
	medium	options 66 and 67
	lowest	'sname' and 'fname'

Does my understanding match the intent of this draft?  If so, I'd like to
see a clarification to RFC 2132 options 66 and 67 in this draft, as well as
wording to  make the precedence unequivocal.

Second, although options 66 and 67 were intended to simply provide a way to
represent the contents of the BOOTP 'sname' and 'fname' fields in options, I
question the appropriateness of using a name rather than IP address for the
server:  in other words, I'd like to see option 66 changed to use IP address
rather than name to identify the server, and I'd also like to see the same
convention used in this draft.

I'll go even further and strongly suggest that we deprecate options 66 and
67 and have only a single [new] Extended Remote Boot option to replace them.

I'm not sure that I agree that file name(s) should be coupled to a specific
server name:  shouldn't the boot file name(s) be identical for all servers
that offer the remote bootstrap service?  There is an implicit understanding
with all other options offering multiple servers (for example, DNS servers)
that the data offered by each server identified in a multiple option is
essentially identical to every other identified server.  Coupling file
name(s) to server name seems to invalidate this concept.

--Barr

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 5 Nov 2003 16:44:16 -0500

If a DNS name is used for the TFTP server, that name could resolve into
several addresses and therefore some level of failover/redundancy is
possible (even today) - provided of course that the TFTP client is set up to
support this. I agree that using IP addresses is better, as this information
may be needed at an early stage when a DNS resolver may not be available
(the DHCP server could do the DNS lookup).

There is an argument that the boot file names might be different on TFTP
servers - for example, the paths where the files are located could be
different. Though I would expect this to be rare?

I agree that clarifying the precedence is important. RFC 2132 says:

   This option is used to identify a TFTP server when the 'sname' field
   in the DHCP header has been used for DHCP options.

A similar statement exists for the bootfile name. So, I suspect that this
implies that both are not allowed.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barr
Hibbs
Sent: Wednesday, November 05, 2003 4:18 PM
To: Vijayabhaskar A K; [email-masked]
Subject: RE: [dhcwg] IDs on remote boot support for DHCP

--Barr

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 5 Nov 2003 14:20:30 -0800

comments inline

--Barr

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernie Volz
> Sent: Wednesday, November 05, 2003 13:44
>
> possible (even today) - provided of course that the TFTP client
> is set up to support this. I agree that using IP addresses is better,
> as this information may be needed at an early stage when a DNS resolver
> may not be available (the DHCP server could do the DNS lookup).
>
...Bernie, you're right about the built-in redundancy of multiple
resolutions of a TFTP server name to IP address, but as far as I recall,
this is the only DHCP option (66) that uses a host name instead of IP
address for reference to a network resource.  Besides, if multiple servers
are identified, then the need for host name to host address transformations
to provide redundancy is a moot issue.

> different. Though I would expect this to be rare?
...again, yes, this is true, but we have to ask ourselves how likely this
will be?  Maybe we should poll the mailing list and known vendors?  I tend
to favor the position of most flexibility, but only if justified, and would
strongly suggest a means to say, "the following list of file names is
identical for all servers," saving a considerable amount of options space in
the DHCPACK packet.

I'd like to point out that there is no requirement that a client would use
the TFTP boot server information in any specific state, although I can't
imagine a client requesting the information would not use it in the INIT
state, and probably also the INIT-REBOOT state.  As I read RFC 2132, it's
not clear to me how options 66 and 67 are actually used:  with BOOTP (and
DHCP without overloading the 'sname' and 'fname' fields) the server would
apparently fill-in both fields if it had been configured with the data for
the particular client requesting an address, but what about options 66 and
67?  If configured with remote boot information AND the 'sname' and 'fname'
fields ARE overlaid, should the server insert these options without being
requested?

I'll add this to the list of clarifications needed for RFC 2131.

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Thu, 6 Nov 2003 12:03:24 +0530

Barr

Thanks for your comments.. My commments inline..

> From: Barr Hibbs [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2003 2:48 AM
> > Single TFTP server for huge number of diskless clients is prone to 
> > single point of failure.  So, Multiple TFTP servers are needed for 
> > bootfiles for boot up.  This document provides a new DHCPv4 
> option for 
> > clients to obtain information about multiple TFTP servers and 
> > bootfiles.
> >
> 
> Does my understanding match the intent of this draft?  If so, 
> I'd like to see a clarification to RFC 2132 options 66 and 67 
> in this draft, as well as wording to  make the precedence unequivocal.

Yes, you are correct. I will add appropriate text..

> 
> Second, although options 66 and 67 were intended to simply 
> provide a way to represent the contents of the BOOTP 'sname' 
> and 'fname' fields in options, I question the appropriateness 
> of using a name rather than IP address for the
> server:  in other words, I'd like to see option 66 changed to 
> use IP address rather than name to identify the server, and 
> I'd also like to see the same convention used in this draft.

I agree with you that dns name is not very appropriate here.. Since, RFC
2131 defines sname as name and the representation of tftp server as name
is deployed and widely used in many bootp servers without any
complaints, I really didn't want to change the widely used model... But,
the provision to represent tftp server as IP address can be added.. 

A new suboption (op code: 1) can be defined for Remote Boot Information
suboption to carry a tftp server address. Either this option or option
66 can appear in the ts field...

> 
> I'll go even further and strongly suggest that we deprecate 
> options 66 and 67 and have only a single [new] Extended 
> Remote Boot option to replace them.

Yes, I strongly recommend that..

> 
> I'm not sure that I agree that file name(s) should be coupled 
> to a specific server name:  shouldn't the boot file name(s) 
> be identical for all servers that offer the remote bootstrap 
> service?  

The one reason I could think of is, as bernie told, the path may be
different in different servers.. I believe, there is nothing wrong in
keeping in providing this flexibility... In the case, where the file
names are same, the provision can be made in this option to specify only
the tftp server/name and take the file names from its previous Remote
Boot Information suboption, which has the file names.. In this way, we
can keep both the flexibility and the save space in the bootp message..

> There is an implicit understanding with all other 
> options offering multiple servers (for example, DNS servers) 
> that the data offered by each server identified in a multiple 
> option is essentially identical to every other identified 
> server.  

I guess, you are talking about DNS server addresses and the domain
name.. In the most of the cases, the domain name will be unique on the
link, even we can say, it will be unique on the site.. If not, atleast
all the bootp server should be configured to give the same domain name
for *this* client.. Similar case for NIS, NIS+ and NetBIOS.. Apart from
this, I could not see any <servers, data provided by server>
relationship in any other options.. Here, the boot file option is
altogether different and the client needs just a file and the location
of the file is not an issue..  the location MAY vary on different tftp
servers.. 

> Coupling file

The coupling was not needed till now, because, we provide only a single
tftp server and file name.. Now, there is a need for it..

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 6 Nov 2003 10:50:22 -0800

clarifications....

--Barr

> > and 'file' fields in options, I question the appropriateness
...see the other message exchange with Bernie:  his point was that by its
very nature, using a DNS name for the 'sname' field ensures a degree of
redundancy, in that the resolver permits a degree of abstraction.  If a list
of IP addresses is supplied, I contend that is equivalent to the DNS name
redundancy.  Certainly a topic for further discussion.

> 66 can appear in the ts field...
....interesting point -- I'd assumed that when you said "option 66" you
meant "a DNS name, just as [current] option 66 uses."  What I'd like is for
ALL DHCP options that contain addresses to carry them as IP addresses for
consistency across the entire option space.  Looks like another discussion
item for the RFC 2131 review!

> can keep both the flexibility and the save space in the bootp message..
...yes, Bernie's point was well-taken:  I've changed my view slightly and
think that we ought to be able to supply:

   o  a [set of] file name[s] specific to each server identified as offering
      TFTP remote boot services appropriate for the client,

   -- OR --

   o  a single [set of] file name[s] that is correct for all servers
identified
      as offering TFTP remote boot services appropriate for the client.

This might take the form of a simple marker [suboption code] that carries
the meaning "file name(s) for this server are identical to the list supplied
with the first server address supplied.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Nov 2003 13:51:00 -0600

> redundancy.  Certainly a topic for further discussion.

I've never heard of anybody using the sname field for anything.   I'd 
like to see its use deprecated, along with the server-name option.   I 
think we should have a single way of getting the identity of the server 
to contact, not fifteen different ways (okay, I'm exaggerating, but you 
get the idea).   Otherwise, neither the administrator nor the client 
implementor has any real way of anticipating which method to implement, 
or which to prefer if multiple methods are offered and multiple methods 
are implemented.   So you wind up with the sysadmin playing a big 
guessing game.   Yuck.   Frankly, I'm skeptical about any proposal to 
add a new method  in DHCPv4 for determining what file to load, or where 
to load it - we should have a good reason for doing this, not just 
"this way is better."

---

From: Vijayabhaskar A K <[email-masked]>
Date: Fri, 07 Nov 2003 03:18:34 +0530

>with the first server address supplied.
how about multiple set of servers with their distinct file names? In this case, the simple marker wont be useful.. the solution 
could be, the tftp server option w/o file name will be assumed to have the same file name of the preceding server with some file name..

-- 
__________________________________________________________
Vijayabhaskar A K            Phone : +91-80-2053085
Hewlett Packard              Mobile: +91-9845241382
29 Cunningham Road           Telnet: 847-3085
Bangalore 52                 Email : [email-masked]

Until you have the courage to lose sight of the shore,
you will not know the terror of being forever lost at sea. 
__________________________________________________________

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 6 Nov 2003 14:19:16 -0800

>
> how about multiple set of servers with their distinct file names?
> In this case, the simple marker wont be useful.. the solution
> could be, the tftp server option w/o file name will be assumed to
> have the same file name of the preceding server with some file name..
>
...perhaps I didn't express myself clearly:  I think that we should be able
to accommodate either a file name list OR a simple marker that indicates
"use the previous file name list" on a per-server basis

--Barr

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 6 Nov 2003 15:07:58 -0800

Ted--

Rob and I have already suggested that the use of the 'sname' and 'file'
fields be not just deprecated, but removed from the DHCP packet format (see
our I-D on RFC 2131 implementation issues that was discussed this morning in
the WG meeting) to expand the 'options' field and eliminate all of that muck
about overloading the 'sname' and 'file' fields.

The big question is "are there ANY DHCP clients that use 'sname' and 'file'
or options 66 and 67 to locate part of their boot images, or are all users
of this feature BOOTP clients?

--Barr

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
> Lemon
> Sent: Thursday, November 06, 2003 11:51
>

---

From: "Kevin A. Noll" <[email-masked]>
Date: Fri, 07 Nov 2003 10:21:27 -0500

To the best of my knowledge, DOCSIS still specifies the use of the
'file' field for booting cable modems. I've never seen 'sname' used.

--kan--

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Barr Hibbs
Sent: Thursday, 06 November, 2003 6:08 PM
To: [email-masked]
Subject: RE: [dhcwg] IDs on remote boot support for DHCP

Ted--

--Barr