Subject: DHCP Server MIB Comments

From: Ryan Troll <[email-masked]>
Date: Tue, 12 Jan 1999 01:15:23 -0500 (EST)

The recent version of the DHCP MIB has made a bunch of good changes
since the last version.  While many of the scenarios that I originally 
commented on to the authors were addressed, a few were not.  To help
with these, I figured I'd bring them up on the list.

After reading through many of the DHCP drafts and RFCs, I've come to
the conclusion that DHCP is expandable enough to allow network
administrators to select IP addresses (and other options) for clients
based on any number of factors:

- Client Identifier
- Vendor Class
- HType Information
- Gateway Address (Subnet Information)

and some new ones on the horizon:

- User Class
- Identifiers that allow the server to determine what relay agent was
  used

With the suggested changes below, I've tried to make sure that the MIB 
may be augmented (without further changes) to support any of these
scenarios.

Our existing setup uses DHCP to hand out static bindings.  [ You may
ask why we don't use dynamics everywhere yet, and that's being looked
into.  However, until then, we're handing out static addresses. :) ]
All of our address assignments are performed solely on the htype
information.  In our environment, this is always an ethernet MAC
address.  When our servers receive BOOTP/DHCP requests from clients
that are unregistered (and thus don't have a static IP address
assigned to them), the request is ignored.

Client Request Tracking
#######################

Currently, we are able to track whether or not a client request was
received in the server, and what was done to that request.  This
functionality is not fully present in the current MIB draft.  For my
environment, I'd suggest adding a table such as:

   IMPORTS
     DateAndTime from SNMPv2-TC;
   
   dhcpClientHtypeTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF DhcpClientHtypeEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
       "This table contains information on the last DHCP packet received
        by the server, indexed by the contents of the htype field.  If
        the server is using information other than the htype field to
        determine address assignment, this table will be empty, and an
        alternate table used instead."
     ::= { dhcpClients 2 }
   
   dhcpClientHtypeEntry OBJECT-TYPE
     SYNTAX      ClientHtypeRequestEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
       "A logical row in the dhcpClientHtypeTable."
     INDEX       { dhcpClientHType }
     ::= { dhcpClientHtypeTable 1 }
   
   dhcpClientHtypeEntry ::= SEQUENCE {
       dhcpClientHtype			OCTET STRING,
       dhcpClientAddress		IpAddress,
       dhcpClientTimeOfLastRequest	DateAndTime,
       dhcpClientLastRequestType	Integer,
       dhcpClientLastResponse		Integer
   }
   
   dhcpClientHtype OBJECT-TYPE
     SYNTAX       OCTET STRING (SIZE (0..255))
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
       "The hardware type and hardware address of the client that has
        been assigned this lease.  The first octet of this object
        contains the hardware type from the 'htype' field of the BOOTP
        packet and the remaining octets contain the hardware address from
        the 'chaddr' field of the BOOTP packet."
     ::= { dhcpClientHtypeEntry 1 }
   
   dhcpClientAddress OBJECT-TYPE
     SYNTAX       IpAddress
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
       "IP Address last handed out to this client."
     ::= { dhcpClientHtypeEntry 2 }
   
   dhcpClientTimeOfLastRequest OBJECT-TYPE
     SYNTAX       DateAndTime
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
       "The time of the last request received containing this rows'
        htype information."
     ::= { dhcpClientHtypeEntry 3 }
   
   dhcpClientLastRequestType OBJECT-TYPE
     SYNTAX       Integer
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
       "The value of option 53 in the last DHCP packet received from
        this client."
     ::= { dhcpClientHtypeEntry 4 }

   dhcpClientLastResponse OBJECT-TYPE
     SYNTAX       Integer
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
       "The value of option 53 in the server's response to the last
        DHCP packet received from this client, listed in
        dhcpClientLastRequestType.  If the server did not respond to
        this client, the value of this entry MUST be 0.."
     ::= { dhcpClientHtypeEntry 5 }

This table could be followed by similar tables that use vendor class, 
user class, or relay agent information to help determine which address 
was handed out to a specific client.  (For example, if this was used
in a cable-modem environment, the table may use the relay agent
extension information as part of the index, so that administrators can 
see what MAC addresses attempted to get an address from behind any
relay agent by walking the table.)

With this table in place, I can determine whether or not a user's
machine actually attempted to use DHCP; whether or not we answered it;
and where the machine was when it booted.  If it was given a lease
(static or dynamic), the address is present, and additional
information may be looked up in the serverAddressTable.  Whether or
not this lease is still active may be determined by comparing the
htype information used to index this table with the MacAddress entry
in the serverAddressTable row specified by the dhcpClientAddress.  If
they are identical, the serverAddressTable entry is correct for this
host.  If they are not, it has been reallocated to another client.

dhcpClientTable
###############

Not all clients specify a client identifier -- the DHCP spec does not
say this is a required option.  This table will be useful for
administrative domains in which the admins have full control over the
clients, and may configure client identifiers.  However, this is not
always the case, and sometimes clients will not use them.

In these environments, administrators (and the servers) will be using
some other piece of information to lookup lease information.  The
table I described above would solve this in one possible environment:
one that only uses MAC address information.  As I stated above, other
tables may be added to address other environments.

read-write values
#################

Some of the values within the MIB are labeled as read-write, and I
guess I'm at a loss as to what being able to write these values would
be useful for, other than resetting them to 0.  If that's the case,
there are some other values that are currently read-only, which could
benefit from being read-write in order to reset the values to 0.

The data in question appears in the bootpStatistics and dhcpStatistics 
tables.

range vs. subnet
################

What's the difference between a range and a subnet?  It looks like
range is supposed to refer to the addresses that are handed out on a
subnet, and a subnet is the routed infrastructure in which address
ranges work.

According to section 2.3, a range is a member of a subnet.  The range
is a list of addresses (specified by listing the first and last
addresses), which are either reserved or dynamicly assigned.

Since a range is a subset of a subnet, I guess I'm wondering what's in 
a subnet but not a range?

And why is it advantageous to keep these two pieces of information
separate?

Thanks, and keep up the good work,
-Ryan

---

From: [email-masked] (Glenn Waters)
Date: Tue, 12 Jan 1999 12:46:25 -0500 (EST)

comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ryan Troll
> Sent: Tuesday, January 12, 1999 01:17
> To: Multiple recipients of list
> Subject: DHCP Server MIB Comments
>
> Client Request Tracking
> #######################
>

the above table is OK but there is one problem and i would like to change a
few things.

first, the table needs to have the subnet as a second index since a hardware
address is only subnet unique.  this would prevent two entries from clashing
(however unlikely that may be).

second, the table is dhcp specific.  i would like to change that to contain
dhcp and bootp clients. that means the lastRequestType and the lastResponse
object would need some rework.  i believe that rework should not be too
hard.

third, i would change the timeOfLastRequest object to be a TimeTicks and the
object would contain the value of sysUpTime at the time the last request was
received.  this is the way that the other MIB WGs design objects of this
type and i believe we should follow their lead.

> dhcpClientTable

i agree there is a problem there.  i would propose that we remove both the
bootClientTable and the dhcpClientTable and replace them with the new table
above.  we may need some additional tweaking and wordsmithing to accomplish
this task, but i think it the right approach.

> read-write values

the only reason the stats table are read-write is so that the stats can be
reset.   the stats are dynamic (i.e.: non-configuration) data.  one non-goal
that is explicitly stated is that we do NOT want to accomplish the ability
to change configuration data (the first paragraph of section 2.3 says this
and explains why).  i still believe this to be a valid restraint on this
work, hence i do not think that changing the configuration objects from
read-only to read-write is warranted.

> range vs. subnet

you are correct that ranges are subsets of subnets, however they have enough
different attributes that i believe it is warranted to keep them separate. i
think that if we merged the two tables then we end with attributes that are
only meaningful in certain instances of the ranges.

the other note of interest here is the both the ISC dhcp server and our dhcp
server model our data with ranges and subnets -- not a reason but just
indicates that maybe it is a OK way to model the data.

> Thanks, and keep up the good work,

thanks for keep on reviewing.

/gww

---

From: "Ryan Troll" <[email-masked]>
Date: Tue, 12 Jan 1999 12:53:05 -0500 (EST)

> (however unlikely that may be).

Hm.  I thought that MAC addresses were globally unique, per the IEEE
definition.

> object would need some rework.  i believe that rework should not be too

No problem.

> type and i believe we should follow their lead.

I'm still concerned about the use of sysUpTime in a distributed SNMP
infrastructure, such as AgentX.  The definition of sysUpTime is rather
misleading in this scenario, as it refers to the management entity.  When
the management entity is distributed across multiple processes, some of
which may reboot while the others are running, sysUpTime cannot be used to
reliably state an epoch for all management subagents on the system.

Also, using sysUpTime to represent this does not help keep track of things
that were received before the system was restarted.  The choice of time
value I selected would allow this to work.  I'm very open to other
suggestions, as long as it allows a management agent to determine the time
(in the management agent's timezone) of the last received packet, regardless
of whether or not the dhcp server (or any other part of the SNMP subsystem)
has been restarted.

> this task, but i think it the right approach.

Cool.

> read-only to read-write is warranted.

Ok.  I guess I wondered why some of the other stats were not resetable as
well (not the configuration information), but if everybody's happy, I'm
happy. :)

> only meaningful in certain instances of the ranges.

What are the different attributes that would be lost by merging the tables?
Knowing this would help me see what I'm mising.

-Ryan

---

From: Greg Althaus <[email-masked]>
Date: Tue, 12 Jan 1999 14:02:37 -0500 (EST)

> > indicates that maybe it is a OK way to model the data.

I know in the IBM DHCP servers (on various platforms), the DHCP administrator
has the ability to assign different attributes to ranges of addresses with
in an address pool.  A subnet may be defined by multiple address pools.  So,
I think there is value in maintaining ranges separate from the subnet 
definitions.

Greg Althaus

AIX TCPIP Development and Support

---

From: Ryan Troll <[email-masked]>
Date: Tue, 12 Jan 1999 14:03:56 -0500 (EST)

> I think there is value in maintaining ranges separate from the subnet 

Ah, that makes sense.  The different attributes aren't necessarily
present in the table we're looking at, but could easily be displayed
via a vendor specific MIB that uses this table to index it.

Now I understand why ranges would be separate.  In the table that I
asked about, there isn't really any reason to keep them seperate based 
on the content there.  However, in the context of the server itself,
and data outside of the scope of that data, keeping the ranges
seperate makes a lot of sense.

Thanks,
-Ryan

---

From: [email-masked] (by way of Ralph Droms)
Date: Tue, 12 Jan 1999 17:33:19 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------------

> Hm.  I thought that MAC addresses were globally unique, per the IEEE

They're globally unique to a CPU, not a network.  Sun machines
generally have (or had) one ethernet address per machine, and that
would be used by all ethernet cards installed in that machine.  It's
also perfectly legal for a DHCP client to roam between networks
without cancelling its leases, and if it remembers its old, unexpired
leases when it moves back, it's not stretching things very far to
suggest that it should be allowed to use them.  So it wouldn't even be
that surprising to find the same mac address on more than one subnet.

			       _MelloN_

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Tue, 12 Jan 1999 18:34:55 -0500 (EST)

Glenn, Ryan, Greg, et al.,

Here I'm commenting on Ryan's responses to Glenn's note (is everybody
confused yet?)

----------
From:  Ryan Troll [SMTP:[email-masked]]
Sent:  Tuesday, January 12, 1999 9:53 AM
To:  Multiple recipients of list
Subject:  RE: DHCP Server MIB Comments

[while it is true that the IEEE requirements are for global uniqueness of
the sequence number portion of a MAC address for  any given manufacturer
number and hardware type, the DHCP rfc only requires subnet uniqueness of
the client hardware address -- this is to permit a client to "roam" from one
subnet to another.  Ryan, you may recall that we discussed very briefly the
matter of global uniqueness for the client identifier both in Chicago and
Orlando, but the client hardware address remains only unique per subnet]

No problem.

[here, I agree with Glenn]

[we may have to revisit the basis for our timers as a general matter before
advancing this draft -- one thing I would like is for this MIB to be
consistent with the general practice and also to not knowingly introduce
problems in its use, as the possible confusion over time values suggests]

--Barr

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Tue, 12 Jan 1999 18:33:37 -0500 (EST)

Ryan, Glenn, Greg, et al.,

My comments to Ryan's original message are included inline....

----------
From:  Ryan Troll [SMTP:[email-masked]]
Sent:  Monday, January 11, 1999 10:17 PM
To:  Multiple recipients of list
Subject:  DHCP Server MIB Comments

[stuff deleted]

-	Client Identifier

	[yes]

-	Vendor Class

	[no, as I read the Vendor Class option description, it is NOT a
determinant of IP address to be offered a client, although it DOES influence
the selection of other option values]

-	HType Information

	[no, the hardware type information is not a determinant of IP
address, despite its suggested use in creating Client Identifiers -- while I
tend to agree that the hardware type octet should be considered for future
adoption as a means for disambiguating the client hardware address, it is
not now appropriate to use it in that way]

	[again, I must disagree:  the possibility of aggregating multiple
subnets on a single network segment demands some means of identifying these
shared network segments, but the Gateway Address should not be the key....
the problem is again one of ambiguity:  assuming multiple gateways are
defined for a network segment, which should be the key?]

-	User Class

[agreed that it is a factor in selecting other options, but not client IP
addresses]

[I don't see this, but am willing to yield the point....]

[stuff deleted]

   IMPORTS

[first, I must raise an objection to the naming that you've suggested:  this
is not a sequence of hardware type objects, but rather an invented
meta-object consisting of the hardware type octet prepended to the client
hardware address.  Glenn raises the issue of uniqueness in a later note as
the RFC does not require global uniqueness for the client hardware address
(nor for the client identifier either!).  Since you are proposing an
meta-object, in order to guarantee the uniqueness that is required for this
table to be useful, either multiple indices are required (i.e., subnet,
hardware type, MAC address), or tables must be nested to provide the
uniqueness necessary.  I would oppose constructing an even larger index by
simply concatenating the three items because that confuses and hides their
individual characteristics....

[second, the existence of this table presupposes that for each client the
server must keep some state information.  Certainly the ISC server (and my
variant of it) does not presently retain client state information, and also
does not keep any state information about "static" IP address assignments.
While I won't oppose inclusion of this table in the server MIB, I will
insist on a clear statement of the response that can be expected from a
server that does not record state information]
   
[stuff deleted]

[an editorial note:  the client hardware address is limited to 16 octets, so
the size of the octet string should be adjusted to match]
   
[stuff deleted]

[before including other such tables in the server MIB, I would want to see
some indication of need or desirability from other implementors -- with
supporting requests there is no reason why other tables couldn't be
included]

With this table in place, I can determine whether or not a user's
machine actually attempted to use DHCP; whether or not we answered it;
and where the machine was when it booted.  

[how do you know where the machine was located?  You've not provided for
capture and reporting of gateway from which the request originated.]

If it was given a lease (static or dynamic), the address is present, and
additional

[yeah, I suppose so, but if this information is important to you for the
management of your client population, why not capture and report it in a
more direct fashion?]

[stuff deleted]

[as Glenn pointed out in his note, the idea is to permit reset of the
statistics and not the reconfiguration of the server....  we'll look at the
read-write status of individual items to ensure consistency....] 

[stuff deleted]

[the idea is that multiple, disjoint ranges of IP addresses may exist within
a subnet in order to simplify the configuration of that subnet.  In my case,
certain ranges of IP addresses within a given subnet are reserved for
gateways, name servers (both DNS and WINS), applications servers, testing,
and to account for certain fixed uses.  For example, the dynamic address
pool for one of my subnets is:  129.245.198.16 -- 129.245.198.191  and
129.245.198.208 -- 129.245.198.231.  Also, we typically assign multiple
subnets to a single network segment, for example, 129.245.139.xxx,
129.245.197.xxx, and 129.245.198.xxx are all on the same LAN (as represented
by hub/router), so we would really like to have three elements....  Again,
if we did not clearly specify the definition of subnet and address range,
Glenn and I will commit to clarifying the definitions.]

Thanks for your comments!

--Barr

---

From: "Ryan Troll" <[email-masked]>
Date: Wed, 13 Jan 1999 12:04:35 -0500 (EST)

>
> that is supposed to be the case for ethernet.  i my past experience i have
> seen the same ethernet address come out of two devices on the same wire.
>
> the real answer though is what about other hardware types.  i just don't
> know the answer.
>
> the question is, do you object to the second index?
>

Not really.  What I want to do can be done with the second index, just not
as efficiently.  But the second index does give you more information, like
the ability to track a host across subnets, which is really cool.  Looks
good to me.

>
> i am going on what the agentx developers have recommended to me.  part of
> the agentx protocol is to pass sysUpTime to the subagents.  all clocks are
> supposed to be relative to the sysUpTime.  i will reconfirm with
> one of the
> agentx authors on this particular issue.

That would be really cool.

Personally, the use of sysUpTime doesn't allow me to keep historical
information around, which is a little distressing.  Using sysUpTime as a
root for all future times (IE: lease expiration) works, but using it for
things that happened in the past (IE: when was this client heard from last)
brings up the question of what to do when sysUpTime resets to 0.

-Ryan

---

From: "Ryan Troll" <[email-masked]>
Date: Wed, 13 Jan 1999 12:12:22 -0500 (EST)

>
> sysUpTime is sufficient to keep historical information.  it works as
> follows:  when the management platform retrieves an object that
> is based on
> sysUpTime it looks at the current value of the sysUpTime object and at the
> current clock on the management platform. subtract the sysUpTime from the
> current clock to get the time when the agent started. add to that
> the value
> of the object that is based on sysUpTime.  you now have a time that is no
> longer relative.  so for example to get the absolute time of the object
> dhcpClientLastResponse:
>
>     current_time_on_mgmt_platform - sysUpTime + dhcpClientLastResponse

That's understood.  The problem I have is when sysUpTime resets to 0.

> i agree this could be a problem, however this is a general SNMP agent
> problem.  i don't think that we should try to solve this.  there have been
> many long discussions on the SNMPv3 list about this.

That's good to hear.

-Ryan

---

From: "Ryan Troll" <[email-masked]>
Date: Wed, 13 Jan 1999 12:13:42 -0500 (EST)

> not now appropriate to use it in that way]

I meant to say the combination of htype and client address information.  So,
for MAC addresses, this would be the usual '\006 aa:bb:cc:dd:ee:ff'.  (I
believe \006 was the octet for ethernet.)

This information, along with the gateway address, is exactly what we use to
determine what IP address a user should receive.

> defined for a network segment, which should be the key?]

The list I presented were things that could be used, and this is definately
something that could be used.  We use this to determine where a client is
when it requests an IP address.  In our dorms, we have multiple subnets on a
single network, and the DHCPD setup knows which subnets are valid behind any
one gateway, and assigns information appropriately.

This may not work for other sites, but it does work well for us.

> [agreed that it is a factor in selecting other options, but not client IP

Hm.  I thought this was what Microsoft was using to implement QoS-like stuff
in Windows 2000.  At the PDC over a year ago, they demonstrated QoS
functionality by having machines change IP addresses to ranges that had
better performance charactoristics on the local wire based on who logged in.

> [I don't see this, but am willing to yield the point....]

This is what the Cable Modem guys wanted to use.  Based on which house the
request is starting in, they can determine what IP address to assign the
request.  Assuming that they wanted to give only 5 addresses per house, this
would allow them to give one of the dynamic addresses for the house the
request eminates from.  They could also use this information to determine
whether or not a machine should receive a DHCP lease, based on current
registration or household usage.

[ I'm using house to refer to an actual site, which could be an apartment,
etc. ]

> individual characteristics....

No problem with the name.  Given my previous assumption of MAC address
global uniqueness, this would have worked.  But, as others have pointed out,
this isn't the case, so the presented table won't work.

Adding the subnet field to the index will solve this, and does present more
data to the administrator that will be helpful.

> server that does not record state information]

That's fine.  I'm just thinking about what I need to do to remotely manage a
DHCP server, and being able to determine these things are part of that.  And
it's what we do now.

We are going to implement this in the ISC server, using an external logging
mechanism, so that the existing ISC server doesn't get bloated with all of
the SNMP stuff.  It will also keep the number of changes to the ISC server
at a minimum.  Just a few printf - like functions here and there.

> supporting requests there is no reason why other tables couldn't be

Exactly.

> capture and reporting of gateway from which the request originated.]

You are right, I'd only have that for successful responses.  Not for things
that were unanswered.  Adding subnet information to the OID would solve
this.

> management of your client population, why not capture and report it in a

I was trying to come up with a way to do this with the data present, rather
than introduce another table.

Unless others have a better suggestion.  :)

Thanks again,
-Ryan

---

From: [email-masked] (by way of Ralph Droms)
Date: Thu, 14 Jan 1999 17:42:36 -0500 (EST)

message sent to [email-masked] by
[email-masked] follows.
-------------------------------------------------------------------------------
with regards to DateAndTime... uncle :)

i will change all appropriate TimeTicks objects to DateAndTime.

the SNMPv3 guys used to recommend using a TimeTicks object based on
sysUpTime.  now they are divided, so, if they don't care which we use then i
will go with the DateAndTime syntax.

/gww

> Sent: Wednesday, January 13, 1999 12:13