Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

From: Damien Neil <[email-masked]>
Date: Mon, 5 Oct 2009 15:29:23 -0700

Apologies to the authors for the amount of time it took for me to get  
to this.

This draft defines four DHCPv6 options that convey information related  
to network booting a node.  There is a clear use case for these  
options, and the information they convey seems reasonable to me.  I  
have no concerns there.

I do have some concerns about the format of the Boot File URL Option  
and the Boot File Parameters Option.

My first issue is the use of multiple occurrences of these options in  
a single DHCPv6 message.

This is an issue that is more general than just this draft.  At this  
time, there are two separate mechanisms used to convey lists of  
information in DHCPv6: Multiple occurrences of an option (e.g., the IA  
Address Option), and concatenated values within a single occurrence of  
an option (e.g., the DNS Recursive Name Server Option).

To my understanding, there is at this time no consistent policy on  
which of these approaches should be used in new options.

Speaking as a server implementor, I dislike having two entirely  
different and incompatible ways of defining a list of items in option  
data.  It adds complexity without offering any benefit that I can  
see.  As such, I would prefer to see new options use the traditional  
means of specifying a list of items, concatenating the items within a  
single option data section, rather than allowing multiple  
occurrences.  This follows with existing practice in DHCPv4, as well  
as with DHCPv6 options defined in RFCs 3319, 3636, 3898, 4075, 4280,  
5192, and 5007.

I realize that RFC 3315 makes extensive use of options which may have  
multiple occurrences in a message.  There is, however, one critical  
differences with these options: They are protocol-internal; none of  
them contain data that is likely to be directly specified or  
manipulated by the operator.

Moving beyond the question of whether permitting multiple occurrences  
of user-specified options is a good idea or not, I have concerns about  
the usage of the 'precedence' field in the Boot File URL Option and  
the Boot File Parameters Option.

Each of these options contains an 8-bit integer 'precedence' value.   
This value indicates the order in which clients should process these  
fields.  This value also links the two options together.  To quote  
from the draft:

>    o  If the precedence field of the Bootfile Parameters option is  
> zero,
>       the client SHOULD provide these parameters when it attempts to
>       execute any Bootfile it has loaded using any of the provided
>       Bootfile URL options.
>
>    o  If the precedence field of the Bootfile Parameters option is
>       nonzero, the client SHOULD provide these parameters only when it
>       attempts to execute a Bootfile it loaded using a Bootfile URL
>       option with a precedence field that has the same value.
>
>    o  In the event that the client receives both a Bootfile Parameters
>       option with a precedence field of zero and one with a precedence
>       field that matches a certain Bootfile URL option, the client  
> MUST
>       use the Bootfile Parameters option whose predence matches the
>       precedence of the Bootfile URL option.

I am very dubious about linking options in this fashion.  This seems  
fragile, and potentially difficult to specify in server  
configurations.  I would prefer to see related data simply contained  
within the same option data section.

I'm now going to undercut my first point a bit:

Merging the content of the Boot File URL option and the Boot File  
Parameters Option into a single option will result in a fairly complex  
option structure.  Furthermore moving from multiple occurrences of  
these options to a list contained in a single option will result in a  
yet more complex structure.  I think that one might reasonably  argue  
that multiple occurrences of an option should be allowed when the  
alternative is a list of complex elements.

Myself, I still prefer using a list contained within a single option  
rather than multiple occurrences.  But I do see the opposing argument.

Whichever way this goes, however, I think there should be some general  
policy on when multiple occurrences of an option should be allowed.   
If we do go down the route of adding this additional protocol  
complexity, I would prefer that we do so with intention rather than  
accidentally.

Finally, a nit: The draft is inconsistent about using "boot file" vs.  
"bootfile".  Pick one and stick to it. :>

                - Damien

---

From: Thomas Huth <[email-masked]>
Date: Tue, 6 Oct 2009 16:03:55 +0200

> as with DHCPv6 options defined in RFCs 3319, 3636, 3898, 4075, 4280,

Damien,

thanks for your feedback. In fact, we used a single-option approach first
(see the early version of our draft, e.g.
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-netboot-01.html), but
then we've been told to better split up this big option into parts, for
simplicity reasons... and honestly, I now also like this new way better
since it's really easier to understand than a nested single option.

> within the same option data section.

Well, by separating the parameters from the boot file option, it's enough
to specify the parameters once for all boot images (if all take the same
parameters). That's much easier to maintain than if copies of the
parameters would be put into the same options as the boot file name (you
would then have to change all options in your DHCP server configuration
file if you want to change only the parameters).>

All in all, I think we're doing the right approach with the latest version
of our draft already. It's also available for more than half a year now,
and so far nobody complained about this yet.

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Erich Baier          
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294

---

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Oct 2009 15:18:05 -0400

Hi Damien.

> options, and the information they convey seems reasonable to me.  I  

I concur.

> which of these approaches should be used in new options.

I agree with the spirit of your concern here, but I think there are
distinctions here that are relevant.

IMO, the IA option is very different from other ones. Each IA option
has its own lifetime field for that instance of the option. You can
have some IAs timing out before others. Each IA option is treated
independently of the others, and they don't need to be processed
"together". You just process the option when you see it in a
message. So putting them in different options doesn't really add
complexity (in terms of processing them).

On the other hand, when you can have multiple instances of an option,
and you have to process them all together at the same time (in order
to process them correctly), that adds complexity and suggests it might
be better to stuff all the info into a single option (so an
implementation doesn't have to hunt around the DHCP message to find
all the relevant options that must be processed together).

> the Boot File Parameters Option.

I strongly share these concerns.

> fields.  This value also links the two options together.

Right.

I know of no DHCP option that has ever been defined where you can have
multiple instances of two different options (say 1 and 2), where there
is a key/cookie that ties an instance of option 1 with a specific
instance of option 2 (that is what the precedence field seems to do).

Seems to me that the far cleaner way to do this is to combine the two
options into one. That way, any options that pertain to a particular
BOOTFILE_URL are just included with that option.

You could still define a separate BOOTFILE_PARAM option that would
only be used as a default, when no BOOTFILE_PARAM stuff was included
with a particular URL option. (i.e., to serve the purpose a precedence
of 0 seems to fill). But I'm not sure how important that is.

> complexity, I would prefer that we do so with intention rather than  

Would a resonable criteria be that multiple options are OK if you can
process them in whatever order you find them easily, without having to
go through the entire message and find other related options that must
be processed together?

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 12:26:22 -0700

> go through the entire message and find other related options that must

I'm a little puzzled by this particular concern.   Why is it a problem  
that you have to "go through the entire message" to find multiple  
instances of a particular option?

---

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Oct 2009 15:28:53 -0400

> instances of a particular option?

I'm not saying its necessarily a big problem, but it's surely more
work (we can argue how much more) to have to go through an entire
message to find all the related options before being able to actually
process them, compared with just processing them in order, without
doing any lookahead.

And for very simple clients, this kind of work savings might well be a
considered a good thing.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 12:31:23 -0700

> process them, compared with just processing them in order, without

Nope, I'm still not getting it.   How is it more complicated than  
unpacking the data out of an individual option?   Don't you have to go  
through the entire packet to find that individual option?   You  
already have code that knows how to unpack options, so it seems like  
it's actually more general to encapsulate the data in options than to  
define an option format that has to be parsed specially.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Oct 2009 15:41:36 -0400

Ted Lemon <[email-masked]> writes:

> unpacking the data out of an individual option?  Don't you have to
> go through the entire packet to find that individual option?  You
> it's actually more general to encapsulate the data in options than
> to define an option format that has to be parsed specially.

The issue that I see is that a simple implementation might want to
process DHCP options one at a time in order. Find first option,
process, discard. Go to next option, repeat.

The way the netboot options are defined, you can't do that. Before you
process the BOOTFILE_URL option, you have to scan the entire rest of
the DHCP message to find the corresponding BOOTFILE_PARAM option. (And
more specifically, the one with the same precedence key.)

That seems like gratuitous complexity, if we can avoid it.

Hence, I was suggesting that one possible way to decide whether to
encode stuff in one option vs. multiple instances (with different data
in it) would be the following. if an implementation could just process
them one at at time without having to find them all before processing,
encoding them as multiple options is fine.  But if you needed to have
all the instances of that option together, before being able to
process one of them, perhaps then it would be better to just encode
all the data in one option so its all in one place. That way the
client doesn't have to hunt around for it.

Thomas

---

From: Damien Neil <[email-masked]>
Date: Tue, 6 Oct 2009 13:03:45 -0700

> go through the entire message and find other related options that must

I think that ordering of options should not be significant, although  
I'm not convinced that non-significant ordering is sufficient reason  
to use multiple instances of an option.

One of my concerns is the complexity of presenting option data to a  
user--to a server administrator specifying what to send to a client,  
or to a network configuration script executed by a client.

With DHCPv4 single-instance options, you can say "the value of option  
<foo> is <bar>".  For example, in ISC dhcpd:

   option domain-name-servers = 10.0.0.1, 10.0.0.2;

When you introduce multiple-instance options, this becomes more  
complicated.  There are various means of presenting this to the user,  
but I don't find any of them truly satisfactory.

I note that ISC dhcpd doesn't appear to support defining multiple  
instances of an option at this time.  The dhcp-options(5) manpage  
states, "normally [multiply-instanced options] are options which are  
digested by the DHCP protocol software, and not by users or  
applications."  (If I'm wrong about this, and such support does exist  
in ISC dhcpd, my apologies.)

I'm not absolutely opposed to multiply-instanced options, but I do  
think there's more implementation complexity to them than may first  
meet the eye.  The existing multiple-instanced IA* options don't  
trigger that complexity as much, since they don't need to be directly  
exposed to users.

I'd be very interested to hear what other implementors of generic  
servers or clients think; it's possible that my view is an outlier, in  
which case I withdraw the objection.

               - Damien

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 13:23:03 -0700

> process, discard. Go to next option, repeat.

Okay, I can see your point, and this (netboot) would certainly be the  
case where that would be most likely to be desired.   However, when I  
think about how I'd implement this in practice, I'm skeptical that  
your observation holds, because it seems unlikely to me that the  
client would, in practice, also be the thing evaluating these options.

In practice, I would expect the client to be one module, and the boot  
loader to be another module.   The client would probably parse all the  
options and store them somewhere, and then trigger whatever other  
modules needed to run after first acquiring an IP address.   One of  
these would be the boot loader.

I would not expect the DHCP client to invoke the boot loader in the  
middle of the option parsing process.   In fact it's impossible that  
it could, since there's no guarantee that the IP address, which must  
be processed prior to doing the boot loading, would appear prior to  
the netboot option.

Practically speaking, what's going to happen is that each module that  
has to run prior to the boot loader is, like the boot loader, going to  
have to make one or more passes across the list of options received by  
the client.   Then the boot loader will have to do the same thing.    
So the client is going to have to present the options in such a way  
that it's easy to iterate across them.

This means that by the time the boot loader is triggered, the code  
iterating across client options is going to have been run several  
times.   It's no problem for the boot loader to run it several more  
times, once for each possible netboot object.   It's certainly not a  
performance problem, and I don't think it adds to code complexity.

So while I agree in principle that the way this works feels a little  
weird, in practice I don't see this as a problem with the protocol.

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 6 Oct 2009 13:39:52 -0700

> file if you want to change only the parameters).>

How common do you think it will be to /both/:

	(1) have multiple boot images
    AND
	(2) have them all (or several) share the same boot parameters?

It feels to me like your draft introduces significant complexity
in order to optimize (not even to support -- it would already
be possible; just with duplication of information) for this one
case. In every other case, it is significant added complexity for
no benefit.

It may not seem particularly complex, but as someone involved in
writing the server side I am glad that it seems like I would not
have to be on the receiving end of these options (and could just
send to clients what was administratively configured, thus avoiding
having to do a lot of special-case work). Introducing a new form of
linkage between options seems like it could be a bit of a pain for
implementors, especially of clients.

> and so far nobody complained about this yet.

Strictly speaking, Damien just did, so somebody has ... however I
suspect that you didn't mean to discount what he said. :) I imagine
this is a subtle translation issue.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Thomas Huth <[email-masked]>
Date: Wed, 7 Oct 2009 17:47:00 +0200

>    (2) have them all (or several) share the same boot parameters?

In the past years, I've seen a couple of cluster installations with _a lot_
of computers, ... so the scenario is really valid (though it's something
that you might not use at home ;-) )

> implementors, especially of clients.

Well, network booting is not always a straight forward job, so there will
certainly be a a little bit of complexity in these settings, no matter
which way you do it. But the current version of the draft has been
discussed with the folks from the UEFI forum already, and there are
certainly a lot of client firmware implementors there, so I think the
current version can't be that wrong...

> this is a subtle translation issue.

No offense! Sorry if I expressed that wrong ... as you might have noticed,
English is not my native language... of course I meant to say, that nobody
complained until the point in time right before Damien did.>

---

From: Bud Millwood <[email-masked]>
Date: Wed, 7 Oct 2009 21:39:12 +0200

> or to a network configuration script executed by a client.

I prefer this:

OPTION_NETBOOT
  SUBOPT_BOOTFILE_URL
  SUBOPT_BOOTFILE_PARAMS
  SUBOPT_CLIENT_ARCH_TYPE
  SUBOPT_NII

I think Damien has a point about presentation. I also think it's easier to 
present a subencoded option to the user with multiple (possibly required) 
suboptions than to present top-level options (just because there are so many 
top-level options).

The way our GUI works, for example, you define a subencoded option, 
then "inside it" you can only define the suboptions declared for that parent. 
So the list of data you can put in the suboption is short and easy to 
comprehend.

The big issue with encoding, as I understand it, is that this one 
configuration setting has multiple kinds of data associated with it. So 
either we cram different kinds of data into one option (ie, "boot=mykernel 
acpi=off"), which is not pretty, or we encode the data separately and 
associate the encodings together. Subencoding will make an implicit 
association between the encodings, nicely tucked away inside a parent 
container specifically for net booting.

Then the issue is whether or not to support multiple OPTION_NETBOOT options.

> that you might not use at home ;-) )

How does that work in practice today with DHCPv4? Are they configured to have 
multiple boot files somehow, or is this an attempt to solve a need that 
wasn't solved in DHCPv4?

- Bud

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

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: Thomas Huth <[email-masked]>
Date: Sat, 10 Oct 2009 14:42:17 +0200

>From a user point of view (I am only a user of dhcp servers, never wrote
one on my own), I would be fine with specifying multiple "option boot-url
= ..." lines in the configuration file. Please excuse my ignorance, but I
can't see a real problem with this, so I'd like to know what are your exact
concerns about this?

> meet the eye.

Well, according to the RFC 3315:

"Unless otherwise noted, each option may appear only in the options
 area of a DHCP message and may appear only once.  If an option does
 appear multiple times, each instance is considered separate and the
 data areas of the options MUST NOT be concatenated or otherwise
 combined."

For me, that sounds like multiple-instance options are allowed if there is
a reason for using them. So I think your dhcp server should somehow support
that in its configuration file, too...?

---

From: Thomas Huth <[email-masked]>
Date: Sat, 10 Oct 2009 16:16:56 +0200

> So the list of data you can put in the suboption is short and easy to

Ok, these "sub-options" might work fine with a GUI, but I think the plain
text configuration files of the DHCP server gets more complicated with
sub-options. The settings then have to specified in a nested way like:

option netboot = {
   url = http://...
   params = "acpi = off ..."
   ...
}

> multiple boot files somehow, or is this an attempt to solve a need that

With DHCPv4, the only way to work-around overloaded TFTP servers was:
1) Introduce a random delay in the boot process of the nodes, so that they
don't try to contact the TFTP server at the same time.
2) Add new TFTP servers and then hard-code a given set of nodes to always
boot from these servers.

There was no way to specify redundant boot servers in the DHCPv4 protocol,
so this would be a new feature in DHCPv6 which makes the configuration of
large networks much easier (you don't have to assign a given set of MAC
addresses to only one of the available server which still might to fail.
You could simply say, that all nodes should try to boot from either
server1, or if it fails try server2, then server3, etc.).

---

From: Jarrod Johnson <[email-masked]>
Date: Sat, 10 Oct 2009 15:53:12 -0400

One new question for the discussion, how does one ensure a consistent
network identity/configuration between the firmware DHCP activity and
the target OS DHCP activity?  In DHCPv4, it was common to just match
on the hw type and address, but in v6, all that is guaranteed is DUID
which gives clients the liberty to choose.  The OSes tend to prefer
DUID-LLT, which will never match a firmware solicit even if it picks
the same scheme.  Even if everyone dropped DUID-LLT for some reason,
DUID-LL rules allow for the OS and firmware to pick whichever
interface they like within the constraints.  PXE had the same problems
as they put forth UUID as a host selector, which worked fine for PXE
firmware but OS discover's wouldn't generally not populate that field.
 More commentary about my approach for active-active boot redundancy
in a layer 2 segment below.

> 2) Add new TFTP servers and then hard-code a given set of nodes to always

FYI, when faced with the task of a broadcast domain of thousands of
servers and deploying all of them via netboot, I took a little
different strategy that involved no delays.  But it requires multiple
DHCP servers.  Specifically:
-The deployment manager manages several servers
-Each server has one 'standalone' DHCP server and download server
-The deployment manager ensures each standalone DHCPv4 server has
synced up host declarations and non-overlapping dynamic ranges.
-When a netboot client boots, things are set up to make sure that it
takes the first DHCPOFFER that comes in (at least the first that gets
through ACK).
-Each DHCP server points to itself as the download server.

It's interesting to watch the results, 95% of the time if just one
server is booting, it will pick the server with the fewest switch
hops.  If all of the ones that tend to prefer that server try to boot,
they will spread out more due to the load on that server making it
less responsive than further away servers.  Anyway, they can pull any
of the deployment servers and the network is none the wiser, so you
can have redundant boot servers with DHCPv4, just not with a single
DHCP server instance (besides, it wouldn't be redundant if there was
only one DHCP server anyway)

For dynamic pools, one would have to divide the pool amongst the
servers to avoid overlap.  This is actually a lot more trivial in IPv6
since your segment would never be lacking for addresses.

> server1, or if it fails try server2, then server3, etc.).

One thing I like about the approach I employ is that it isn't an
ordered list, it is unordered with no preference, winner chosen by
network responsiveness.  However, to fit in more general environments,
the DHCP serving step and the file serving entities being separate
would be helpful.  Of course, DHCP servers with only boot information
(I think that was the whole point of ProxyDHCP servers in PXE, but
that aspect of PXE I avoid when possible in favor of the more
straightforward configuration) could live on the network to augment
the 'normal' DHCP server.

---

From: Jarrod Johnson <[email-masked]>
Date: Mon, 12 Oct 2009 08:42:45 -0400

On Sun, Oct 11, 2009 at 8:55 PM, Ted Lemon <[email-masked]> wrote:
>> There are two problems with RFC 4361 section 7 for me:
>> -Practically speaking, I see no specific standards in place for the
>> various architectures to implement the prescribed communication path
>> between OS and firmware.
>
> That's because we can't do anything about that.   We can't tell firmware vendors what to do.   Indeed, generally speaking, they don't even follow the protocol specifications anyway - we're lucky if what they do roughly interoperates with conforming implementations.
>
> It wasn't my intention in RFC4361 to say that the O.S. or the firmware should be in charge, but rather to say that they should collude to present the same identifier.   As far as I know nobody's implemented that, though.
>

FYI, the wording that made me feel it implied OS control was:
"Such clients should  provide a way for the operating system DHCP
client to configure a DUID to use in subsequent boots" which I took to
mean that if the OS mismatched, that it should be considered that it
is the firmware that needs to be rectified.  After some thought, I
actually think precisely the opposite would be true.

Anyway, perhaps with some specific recommendations, this draft should
reference RFC4361 to ensure that firmware developers have this in mind
and hopefully some standards get pushed in the correct places (just
like iBFT exists to facilitate RFC4173).

If appropriate, I have some thoughts on how it can be resolved to my
satisfaction (but not Chuck's) and probably keep people who like the
DUID moving with the hard drive happy:
-Firmware should provide a DUID of it's choosing (likely DUID-EN) at
any time through a mechanism of their choosing (i.e. openfirmware
properties, DMI tables in x86, whatever is appropriate).  However,
unless specifically configured to do otherwise, DHCP clients should
ignore this information.
-If netboot firmware actually executes a boot, it should make the
DHCPv6 reply packet available in some form that the OS and bootloader
can read. (openfirmware, for example, would almost certainly do it
just like they stick the bootp-response in /chosen today).  In x86,
maybe they'd implement it in a similar way they do iBFT, but the
format should be just the raw packet, since the consuming software
would certainly already have code to parse a DHCP reply packet, and an
intermediate format would just be a headache for everyone).
-If netboot is started, but ultimately aborted (i.e. pxelinux.cfg's
'localboot' directive, or a non-existant boot file), it should not
retain any DHCPv6 reply packet and the OS need not try coordinating
with boot firmware.
-If the OS dhcp implementation sees that the firmware has populated
the DHCPv6 reply structure, it should ignore (but may retain for
future use) any DUID it might have saved and instead configure itself
to always read DUID from firmware structures instead of system disk
(this way, if a hard drive is deployed in this manner, it won't clone
a DUID-EN and risk making it non-unique by moving it to a system that
isn't deployed in the same fashion).  If that drive appears in a
system with no firmware provided DUID, it would have to generate a new
DUID or revert to the DUID it had generated previously.
-The OS need not have a way to write back a DUID in a standard way as
it is not very important and further mitigates the risk of duplicate
DUIDs by avoiding cloning them with the risk of future disassociation.

The thoughts behind this are that the scenario for netboot include:
-network boot of the OS.  In this case, the layer2<->layer3 identity
mapping has already been proven to make the correct association.  So
if the OS sees that firmware has one, and it happens to have a
different one, it knows one has been proven and one has not been, so
it makes sense to always use the one already validated.
-network deploy of the OS.  A no brainer here, there is/should be no
meaningful DUID other than the firmware.  If image deployment is being
done, they would already have to wipe DUID to make it a generalized
image anyway.
-network boot starts, but chain to a local disk (i.e. syslinux
chain.c32).  This could be the most controversial case, but I think it
fair to presume that the network loader infrastructure implying it has
that much knowledge of the managed system means it is pre-configured
specifically for this, and therefore the boot time DUID should be
considered the correct one.
-network boot, but exit to local boot instead.  I think it's fair to
say this could imply that the DUID in use is not specifically
validated and therefore is not worth implying it should be used over
other DUID.  In my case, when this occurs, the OS had previously
recorded the DUID from the boot firmware and is using it, so I don't
lose control.

An alternative would be for OS to always source DUID from firmware
tables if available (i.e. DMI tables in x86) regardless of boot state,
however I think that would be detrimental to those who enjoy retaining
their IPv6 identity when they move their hard drives to a new set of
equipment in a decentralized scenario.

---

From: Bud Millwood <[email-masked]>
Date: Mon, 12 Oct 2009 14:48:17 +0200

On Saturday 10 October 2009, Thomas Huth wrote:
> > I think Damien has a point about presentation. I also think it's easier
>
> to
>
> > suboptions than to present top-level options (just because there are so
>
> many
>
> > top-level options).
> >
> > then "inside it" you can only define the suboptions declared for that
>
> parent.
>

I think that text format is... beautiful. :)

>
> > Thomas, you said:
> > > In the past years, I've seen a couple of cluster installations with _a
>
> lot_
>
> > > of computers, ... so the scenario is really valid (though it's
>
> something
>
> > How does that work in practice today with DHCPv4? Are they configured to
>
> have
>

By overloaded TFTP server you mean a server with too much traffic, right?

This may be an implementation thing. Another way to distribute booting nodes 
across multiple TFTP servers is to vary the "Next server" or "Overload TFTP 
server name" by time, mac hash, ip hash, shoe size, etc. A DHCP server should 
be able to let you vary the TFTP server location (name or address) in 
realtime. Even better, the server should maintain a list of TFTP servers and 
only rotate between those that are online and under a certain work 
threshhold.

- Bud

---

From: Jarrod Johnson <[email-masked]>
Date: Mon, 12 Oct 2009 11:15:38 -0400

>   params = "acpi = off ..."

FYI, at least in ISC dhcpd, the convention for encapsulated options
that I'm familiar would look more like:
netboot.url="http://...."
netboot.params="acpi = off ..."

The downside that could occur to me is it could be a little awkward if
two fields are linked together by spec that ultimately could be
interpreted by different pieces of client code.  For example, presume
that you had 'netboot.ipl='http://some/kernel/' and
'netboot.rootpath='iscsi:etc'.  It may be conceivable that disparate
code is used to get that rootpath ready from the code that is
responsible for executing the kernel.  Still wouldn't be
insurmountable, but it's the largest downside I could come up with
since I think the textual option declaration could look pretty much
the same as separate options.

---

From: Thomas Huth <[email-masked]>
Date: Sun, 18 Oct 2009 11:47:40 +0200

> Jarrod Johnson <[email-masked]> wrote on 12/10/2009
> DUID moving with the hard drive happy:
[...]

Jarod,

thanks for this very interesting description. However, I also think our
draft is the wrong place to address these issues. Our draft should focus on
describing the new options, not the generic netboot process. For example,
we originally had a big chapter that discussed the advantages and
disadvantages of the various boot protocols (TFTP, HTTP, iSCSI), but we've
been told that this does not belong to an RFC document that describes new
DHCP options.

So if you want to discuss DUID usage, I'd suggest that you either create a
new draft for "netboot DUID best practices" which can be used as a basis
for this discussion, or that you try to address this issue on the
appropriate firmware/operating system mailing lists (e.g. the UEFI mailing
list about network booting), since most of the firmware / OS people might
not read this mailing list here.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Oct 2009 13:18:54 -0700

On Oct 12, 2009, at 5:42 AM, Jarrod Johnson wrote:
> probably keep people who like the
> DUID moving with the hard drive happy: [...]

The reason why DUID is the way it is is not to make your life  
difficult, or because there is some conspiracy on the part of lovers  
of DUIDs that move with the hard drive.   It is because your situation  
is unusual.   The DUID is targeted at the vast majority of devices on  
the Internet, which are not managed the way you manage your devices.    
It's important that the IETF accommodate your needs if possible, and  
indeed the existing protocol does accommodate your needs, and there  
have been several extensions proposed that further accommodate your  
needs, which I will describe in a moment.   But it's important to  
understand the context in which you are making this request.   The  
context is that your situation is unusual - not typical.

You proposed changing the DUID so that it is tied to some hardware  
address configured on the device, or possibly to the hardware address  
of the interface that you are configuring.   We didn't do it this way  
because this behavior makes it more difficult to keep track of the  
relationship between clients and their IP addresses, and between  
clients and their domain names.   We also anticipated that similar  
problems would crop up in the future.   The DUID-LLT DUID type, which  
is the one you are complaining about, also resolves a problem that  
cropped up fairly frequently where several devices would wind up, due  
to firmware bugs, with the same MAC address.

If we were to make the change that Chuck is proposing, which I think  
you were also advocating previously, it would break this  
functionality.   It would break it for the people least able to  
identify the problem - end users of individual computers connected to  
the Internet.   When a device behaves badly on your network, you (a  
skilled network administrator) are in a position to do something about  
it.   When an end-user's device behaves badly, they are not.   They  
call their ISP, and the guy they talk to probably hasn't a clue, and a  
lot of time is wasted before anybody with a clue talks to them, if  
anyone with a clue ever does.   This is what DUID-LLT was designed to  
prevent.

This brings me to my next point, which is that in fact the DHCP  
protocol already supports DUIDs of the type you want - DUID-EN and  
DUID-LL.   The reason your device doesn't support these address types  
is probably that you bought the wrong type of device, and that the  
vendor of your device's firmware did not read RFC4361, and that the  
hardware vendor provided no way for the software vendor to know that  
the device is eligible to use, e.g., DUID-LL.

The IETF is not in a position to do anything about this.   Vendors  
don't typically listen to us.   They implement the RFCs their  
customers look for on the feature list.   Often they implement them  
badly or incompletely.   If you want that to change, you have to talk  
to your vendors.   You are the one with the money.   Everybody has  
some degree of interest in doing things right, and but they also have  
lots of other priorities.   Their highest priority is making sure that  
you buy as much of their product as possible.   So if you want them to  
implement DUID-LL or DUID-EN (correctly, I hope), you need to talk to  
them about it.   If you want them to implement RFC4361's  
recommendations, you need to talk to them.   This is not the venue in  
which to solve your problem.

If you read RFC3315, there is no indication in it that DUID-EN is in  
any way less good than DUID-LLT.   That's because DUID-EN is actually  
better than DUID-LLT.   The reason DUID-EN isn't specifically  
recommended is that it requires effort on the part of both your  
hardware vendor and your software vendor to use it.   If they can  
support it in compliance with the RFC, they should use it.   If you  
want them to support it, don't talk to us.   Talk to them.

Now, absent your ability to convince your vendors to implement DUID-EN  
correctly, which I admit may be problematic for you, what else can you  
do?   As it happens, there are several drafts being worked on right  
now that solve aspects of your problem without requiring any changes  
to the way your DHCP client uses the DUID.   These are the lightweight  
DHCP relay agent (LDRA) draft and the relay agent ID draft.   The  
whole motivation behind these drafts is to help you to identify the  
physical port to which a particular device is connected.   You could  
then propagate this information up into your device management system  
and clearly connect the (varying) DUID-LLT to the device's physical  
location.   I would encourage you to read these drafts and comment on  
them.