Re: [Etherboot-users] Re: [Ltsp-discuss] DHCP V. 3 support in etherboot rom

[Eric W B. <ebi...@ln...>]

Peter Lister <P.L...@sy...> writes:

> [ I Cc ltsp-discuss, but let's take this back to etherboot-users. ]
> 
> > Does the etherboot ROM image support DHCP V3 options? Namely I am
> > interested in passing what is called the "DHCP Class ID" where a client
> > passes a parameter that the DHCP V3 server recognizes and assign some
> > stuff based on it. We need it to use it with Win2k DHCP User class
> > options. 
> 
> A good question, if not the one your subject line described. :)
> 
> First, you can differentiate Etherboot from other dhcp traffic using the
> *Vendor* Class ID, which encodes the string "Etherboot" and a version
> number in every request.  Is there any reason you cannot use this?
> 
> If the MS dhcp server likes to use *User* Class IDs then this is
> interesting and probably helpful to those in a MS environment.
> 

This is interesting there are currently a whole raft of RFCs that deal with
the issue of dividing dhcp clients into classes.  Skimming through
them so far I have seen:

RFC3004 The user Class option
RFC3011 The IPv4 Subnet Selection Option for DHCP
RFC3046 DHCP Relay Agent Information Option
RFC3118 Authentication for DHCP Messages
RFC3255 DOCSIS Device Class DHCP Relay Agent Information Sub-option

Roughly this is all of the DHCP RFC submitted since 2000.

For the etherboot case RFC3046/RFC3255 is nice because the upstream
router takes care of specifying the information, and etherboot can
ignore it.

RFC3011 is likely much to specific to subnets to be useful.

RFC3004 and RFC3118 are both canidates for this kind of thing.  And
if the encryption isn't difficult to implment RFC3118 is probably
better in a wireless environment.

The big question is how do we get the magic keys into the ROMs.  The
ideal case is where everyone's romimage can be the same.

Eric