draft-ietf-dhc-server-mib-08.txt   draft-ietf-dhc-server-mib-09.txt 
Network Working Group Barr Hibbs Network Working Group Barr Hibbs
INTERNET-DRAFT (no affiliation) INTERNET-DRAFT (no affiliation)
Category: Standards Track Glenn Waters Category: Standards Track Glenn Waters
Nortel Networks Nortel Networks
March 2003 October 2003
Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB
<draft-ietf-dhc-server-mib-08.txt> <draft-ietf-dhc-server-mib-09.txt>
Saved Sunday, March 02, 2003, 10:42:16 AM Saved Monday, October 27, 2003, 5:08:01 PM
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3.1.3. DHCP Client MIB Extensions............................4 3.1.3. DHCP Client MIB Extensions............................4
3.1.4. DHCP Relay Agent MIB Extensions.......................5 3.1.4. DHCP Relay Agent MIB Extensions.......................5
3.1.5. DHCPv6 MIB Extensions.................................5 3.1.5. DHCPv6 MIB Extensions.................................5
3.2. Textual Conventions Introduced in this MIB.................5 3.2. Textual Conventions Introduced in this MIB.................5
3.2.1. DhcpTimeInterval......................................5 3.2.1. DhcpTimeInterval......................................5
3.2.2. DhcpPhysicalAddress...................................5 3.2.2. DhcpPhysicalAddress...................................5
3.3. BOOTP and DHCP Counter Groups..............................5 3.3. BOOTP and DHCP Counter Groups..............................5
3.4. BOOTP and DHCP Optional Statistics Group...................6 3.4. BOOTP and DHCP Optional Statistics Group...................6
3.5. Response Times and ICMP Echo...............................8 3.5. Response Times and ICMP Echo...............................8
4. Definitions....................................................9 4. Definitions....................................................9
5. Intellectual Property.........................................44 5. Intellectual Property.........................................43
6. Notes.........................................................44 6. Acknowledgements..............................................43
6.1. Issues....................................................44 7. IANA Considerations...........................................43
6.2. Changes from Prior Drafts.................................45 8. Security Considerations.......................................44
7. Acknowledgements..............................................47 9. References....................................................45
8. IANA Considerations...........................................47 9.1. Normative References......................................45
9. Security Considerations.......................................48 9.2. Informative References....................................46
10. References...................................................49 10. Editors' Addresses...........................................46
10.1. Normative References.....................................49 11. Full Copyright Statement.....................................46
10.2. Informative References...................................50
11. Editors' Addresses...........................................50
12. Full Copyright Statement.....................................50
1. Introduction 1. Introduction
This memo is a product of the DHCP Working Group and defines a This memo is a product of the DHCP Working Group and defines a
portion of the Management Information Base (MIB) for use with network portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community. In particular, it management protocols in the Internet community. In particular, it
describes a set of extensions that DHCPv4 and Bootstrap Protocol describes a set of extensions that DHCPv4 and Bootstrap Protocol
(BOOTP) servers implement. Many implementations support both DHCPv4 (BOOTP) servers implement. Many implementations support both DHCPv4
and BOOTP within a single server and hence this memo describes the and BOOTP within a single server and hence this memo describes the
MIB for both DHCPv4 and BOOTP servers. MIB for both DHCPv4 and BOOTP servers.
skipping to change at page 3, line 23 skipping to change at page 3, line 19
capabilities using the Applications MIB [RFC2287]. capabilities using the Applications MIB [RFC2287].
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The Internet-Standard Management Framework 2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].Managed objects are accessed via a virtual RFC 3410 [RFC3410], Managed objects are accessed via a virtual
information store, termed the Management Information Base or MIB. information store, termed the Management Information Base or MIB.
MIB objects are generally accessed through the Simple Network MIB objects are generally accessed through the Simple Network
Management Protocol (SNMP). Objects in the MIB are defined using the Management Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information (SMI). mechanisms defined in the Structure of Management Information (SMI).
This memo specifies a MIB module that is compliant to the SMIv2, This memo specifies a MIB module that is compliant to the SMIv2,
which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD
58, [RFC2580]. 58, [RFC2580].
3. Overview 3. Overview
skipping to change at page 6, line 13 skipping to change at page 6, line 13
"dhcpv4CountRequests," "dhcpv4CountReleases," "dhcpv4CountDeclines," "dhcpv4CountRequests," "dhcpv4CountReleases," "dhcpv4CountDeclines,"
"dhcpv4CountInforms," and "dhcpv4CountLeaseQueries objects." The "dhcpv4CountInforms," and "dhcpv4CountLeaseQueries objects." The
total number of valid packets (BOOTP and DHCP) received is computed total number of valid packets (BOOTP and DHCP) received is computed
as the total number of valid DHCP packets plus the value of the as the total number of valid DHCP packets plus the value of the
"bootpCountRequests" object. The total number of packets received is "bootpCountRequests" object. The total number of packets received is
computed as the total number of valid packets plus the sum of computed as the total number of valid packets plus the sum of
"bootpCountInvalids" and "dhcpv4CountInvalids." "bootpCountInvalids" and "dhcpv4CountInvalids."
Similar to the received computations, the total number of DHCP Similar to the received computations, the total number of DHCP
packets sent by the server is computed as the sum of the packets sent by the server is computed as the sum of the
"dhcpv4CountOffers," "dhcpv4CountAcks," "dhcpv4CountNacks," "dhcpv4CountOffers," "dhcpv4CountAcks," and "dhcpv4CountNaks"
"dhcpv4CountForcedRenews," "dhcpv4CountKnowns," objects. The number of packets (BOOTP and DHCP) sent by the server
"dhcpv4CountUnknowns," "dhcpv4CountActives," and is computed as the total number of DHCP packets sent plus the value
"dhcpv4CountUnimplemented" objects. The number of packets (BOOTP and of the "bootpCountReplies" object.
DHCP) sent by the server is computed as the total number of DHCP
packets sent plus the value of the "bootpCountReplies" object.
3.4. BOOTP and DHCP Optional Statistics Group 3.4. BOOTP and DHCP Optional Statistics Group
This section describes some of the management information that may be This section describes some of the management information that may be
derived from the objects provided in the optional statistics group. derived from the objects provided in the optional statistics group.
Given time 1 (t1) and time 2 (t2) greater than t1, the mean inter- Given time 1 (t1) and time 2 (t2) greater than t1, the mean inter-
arrival time of valid DHCP messages for the interval t1 to t2 can be arrival time of valid DHCP messages for the interval t1 to t2 can be
computed as (dhcpv4StatLastArrivalTime at t2 minus computed as (dhcpv4StatLastArrivalTime at t2 minus
dhcpv4StatLastArrivalTime at t1) divided by (valid DHCP received dhcpv4StatLastArrivalTime at t1) divided by (valid DHCP received
skipping to change at page 9, line 25 skipping to change at page 9, line 25
SnmpAdminString FROM SNMP-FRAMEWORK-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB
InetAddressIPv4, InetAddressPrefixLength InetAddressIPv4, InetAddressPrefixLength
FROM INET-ADDRESS-MIB FROM INET-ADDRESS-MIB
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF; FROM SNMPv2-CONF;
dhcp MODULE-IDENTITY dhcp MODULE-IDENTITY
LAST-UPDATED "200303021042Z" LAST-UPDATED "200310271708Z"
ORGANIZATION ORGANIZATION
"IETF DHC Working Group "IETF DHC Working Group
General Discussion: dhcwg@ietf.org General Discussion: dhcwg@ietf.org
Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg
Archive: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www1.ietf.org/mailman/listinfo/dhcwg
Chair: Ralph Droms, rdroms@cisco.com" Chair: Ralph Droms, rdroms@cisco.com"
CONTACT-INFO CONTACT-INFO
" Richard Barr Hibbs " Richard Barr Hibbs
Postal: 952 Sanchez Street Postal: 952 Sanchez Street
San Francisco, California 94114-3362 San Francisco, California 94114-3362
skipping to change at page 10, line 12 skipping to change at page 10, line 12
the Bootstrap Protocol (BOOTP) and the Dynamic Host the Bootstrap Protocol (BOOTP) and the Dynamic Host
Configuration protocol (DHCP) for Internet Protocol version Configuration protocol (DHCP) for Internet Protocol version
4(IPv4). This MIB does not include support for Dynamic DNS 4(IPv4). This MIB does not include support for Dynamic DNS
(DDNS) updating nor for the DHCP Failover Protocol. (DDNS) updating nor for the DHCP Failover Protocol.
Copyright (C) The Internet Society (2003). This version of Copyright (C) The Internet Society (2003). This version of
this MIB module is part of RFC xxxx; see the RFC itself for this MIB module is part of RFC xxxx; see the RFC itself for
full legal notices." full legal notices."
-- RFC Editor assigns xxxx and removes this comment -- RFC Editor assigns xxxx and removes this comment
REVISION "200303021042Z" -- 2 March 2003 REVISION "200310271708Z" -- 27 October 2003
DESCRIPTION "Initial Version, published as RFC xxxx." DESCRIPTION "Initial Version, published as RFC xxxx."
-- RFC Editor assigns xxxx and removes this comment -- RFC Editor assigns xxxx and removes this comment
::= { mib-2 TBD } -- IANA will make official assignment ::= { mib-2 TBD } -- IANA will make official assignment
-- Textual conventions defined by this memo -- Textual conventions defined by this memo
DhcpTimeInterval ::= TEXTUAL-CONVENTION DhcpTimeInterval ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of milliseconds that has elapsed since some epoch. "The number of milliseconds that has elapsed since some epoch.
skipping to change at page 15, line 36 skipping to change at page 15, line 36
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of DHCPINFORM (option 53 with value 8) packets "The number of DHCPINFORM (option 53 with value 8) packets
received." received."
REFERENCE REFERENCE
"RFC2131; RFC2132, section 9.6." "RFC2131; RFC2132, section 9.6."
::= { dhcpv4RecvdPacketCounters 5 } ::= { dhcpv4RecvdPacketCounters 5 }
dhcpv4CountLeaseQueries OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of DHCPLEASEQUERY (option 53 with value TBD)
packets received."
-- value to be assigned by IANA
REFERENCE
"draft-ietf-dhc-leasequery-04.txt."
::= { dhcpv4RecvdPacketCounters 6 }
-- dhcpv4SentPacketCounterObjects Group -- dhcpv4SentPacketCounterObjects Group
dhcpv4CountOffers OBJECT-TYPE dhcpv4CountOffers OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of DHCPOFFER (option 53 with value 2) packets "The number of DHCPOFFER (option 53 with value 2) packets
sent." sent."
REFERENCE REFERENCE
skipping to change at page 16, line 22 skipping to change at page 16, line 10
dhcpv4CountAcks OBJECT-TYPE dhcpv4CountAcks OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of DHCPACK (option 53 with value 5) packets sent." "The number of DHCPACK (option 53 with value 5) packets sent."
REFERENCE REFERENCE
"RFC2131; RFC2132, section 9.6." "RFC2131; RFC2132, section 9.6."
::= { dhcpv4SentPacketCounters 2 } ::= { dhcpv4SentPacketCounters 2 }
dhcpv4CountNacks OBJECT-TYPE dhcpv4CountNaks OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of DHCPNACK (option 53 with value 6) packets sent." "The number of DHCPNACK (option 53 with value 6) packets sent."
REFERENCE REFERENCE
"RFC2131; RFC2132, section 9.6." "RFC2131; RFC2132, section 9.6."
::= { dhcpv4SentPacketCounters 3 } ::= { dhcpv4SentPacketCounters 3 }
dhcpv4CountForcedRenews OBJECT-TYPE dhcpv4CountForcedRenews OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of DHCPFORCERENEW (option 53 with value 9) packets "The number of DHCPFORCERENEW (option 53 with value 9) packets
sent." sent."
REFERENCE REFERENCE
" RFC 3203, DHCP reconfigure extension." " RFC 3203, DHCP reconfigure extension."
::= { dhcpv4SentPacketCounters 4 } ::= { dhcpv4SentPacketCounters 4 }
dhcpv4CountKnowns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of DHCPLEASEKNOWN (option 53 with value TBD)
packets sent."
-- value to be assigned by IANA.
REFERENCE
"draft-ietf-dhc-leasequery-04.txt."
::= { dhcpv4SentPacketCounters 5 }
dhcpv4CountUnknowns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of DHCPLEASEUNKNOWN (option 53 with value TBD)
packets sent."
-- value to be assigned by IANA.
REFERENCE
"draft-ietf-dhc-leasequery-04.txt."
::= { dhcpv4SentPacketCounters 6 }
dhcpv4CountActives OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of DHCPLEASEACTIVE (option 53 with value TBD)
packets sent."
-- value to be assigned by IANA.
REFERENCE
"draft-ietf-dhc-leasequery-04.txt."
::= { dhcpv4SentPacketCounters 7 }
dhcpv4CountUnimplementeds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of DHCPUNIMPLEMENTED (option 53 with value TBD)
packets sent."
-- value to be assigned by IANA.
REFERENCE
"draft-ietf-dhc-leasequery-04.txt."
::= { dhcpv4SentPacketCounters 8 }
-- dhcpv4ErrorPacketCounterObjects Group -- dhcpv4ErrorPacketCounterObjects Group
dhcpv4CountInvalids OBJECT-TYPE dhcpv4CountInvalids OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of DHCP packets received whose DHCP message type "The number of DHCP packets received whose DHCP message type
(i.e., option number 53) is not understood or handled by the (i.e., option number 53) is not understood or handled by the
server." server."
skipping to change at page 24, line 46 skipping to change at page 23, line 37
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The high threshold for available free addresses in this shared "The high threshold for available free addresses in this shared
network. If a dhcpv4ServerFreeAddressLow event was generated network. If a dhcpv4ServerFreeAddressLow event was generated
for this subnet, and the value for available free addresses has for this subnet, and the value for available free addresses has
exceeded the value of dhcpv4ServerSubnetFreeAddrHighThreshold, exceeded the value of dhcpv4ServerSubnetFreeAddrHighThreshold,
then a dhcpv4ServerFreeAddressHigh event will be generated. No then a dhcpv4ServerFreeAddressHigh event will be generated. No
more dhcpv4ServerFreeAddressHigh events will be generated for more dhcpv4ServerFreeAddressHigh events will be generated for
this subnet during this execution of the DHCP server until the this subnet during this execution of the DHCP server until the
value for available free addresses becomes equal to or less value for available free addresses becomes equal to or less
than the value of dhcpv4ServerSubnetFreeAddrHighThreshold." than the value of dhcpv4ServerSubnetFreeAddrLowThreshold."
::= { dhcpv4ServerSharedNetEntry 3 } ::= { dhcpv4ServerSharedNetEntry 3 }
dhcpv4ServerSharedNetFreeAddresses OBJECT-TYPE dhcpv4ServerSharedNetFreeAddresses OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify MAX-ACCESS accessible-for-notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of IP addresses which are available within this "The number of IP addresses which are available within this
shared network. If the server does not count free addresses by shared network. If the server does not count free addresses by
shared network segment, this value will be zero." shared network segment, this value will be zero."
skipping to change at page 27, line 20 skipping to change at page 26, line 11
DESCRIPTION DESCRIPTION
"The high threshold for available free addresses in this "The high threshold for available free addresses in this
subnet. If a dhcpv4ServerSubnetFreeAddrLowThreshold event has subnet. If a dhcpv4ServerSubnetFreeAddrLowThreshold event has
been generated for this subnet, and the value for available been generated for this subnet, and the value for available
free addresses has exceeded the value of free addresses has exceeded the value of
dhcpv4ServerSubnetFreeAddrHighThreshold, then a dhcpv4ServerSubnetFreeAddrHighThreshold, then a
dhcpv4ServerFreeAddressHigh event will be generated. No more dhcpv4ServerFreeAddressHigh event will be generated. No more
dhcpv4ServerFreeAddressHigh events will be generated for this dhcpv4ServerFreeAddressHigh events will be generated for this
subnet during this execution of the DHCP server until the value subnet during this execution of the DHCP server until the value
for available free addresses becomes equal to or less than the for available free addresses becomes equal to or less than the
value of dhcpv4ServerSubnetFreeAddrHighThreshold." value of dhcpv4ServerSubnetFreeAddrLowThreshold."
::= { dhcpv4ServerSubnetEntry 5 } ::= { dhcpv4ServerSubnetEntry 5 }
dhcpv4ServerSubnetFreeAddresses OBJECT-TYPE dhcpv4ServerSubnetFreeAddresses OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify MAX-ACCESS accessible-for-notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of free IP addresses which are available in this "The number of free IP addresses which are available in this
subnet." subnet."
::= { dhcpv4ServerSubnetEntry 6 } ::= { dhcpv4ServerSubnetEntry 6 }
skipping to change at page 35, line 5 skipping to change at page 33, line 46
precision if available on the server." precision if available on the server."
::= { dhcpv4ServerClientEntry 4 } ::= { dhcpv4ServerClientEntry 4 }
dhcpv4ServerClientLastRequestType OBJECT-TYPE dhcpv4ServerClientLastRequestType OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
bootprequest(0), bootprequest(0),
dhcpdiscover(1), dhcpdiscover(1),
dhcprequest(3), dhcprequest(3),
dhcpdecline(4), dhcpdecline(4),
dhcprelease(7), dhcprelease(7),
dhcpinform(8), dhcpinform(8)
dhcpleasequery(TBD) -- IANA will assign this value
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The type of the last request message received for this client. "The type of the last request message received for this client.
If the server does not capture this information, the value If the server does not capture this information, the value
32,767 is returned." 32,767 is returned."
REFERENCE REFERENCE
"RFC2131; RFC2132, section 9.6; draft-ietf-dhc-leasequery- "RFC2131; RFC2132, section 9.6; draft-ietf-dhc-leasequery-
04.txt." 04.txt."
::= { dhcpv4ServerClientEntry 5 } ::= { dhcpv4ServerClientEntry 5 }
dhcpv4ServerClientLastResponseType OBJECT-TYPE dhcpv4ServerClientLastResponseType OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
bootpreply(1), bootpreply(1),
dhcpoffer(2), dhcpoffer(2),
dhcpack(5), dhcpack(5),
dhcpnak(6), dhcpnak(6),
dhcpforcerenew(9), dhcpforcerenew(9)
dhcpknown(TBD), -- value to be assigned by IANA
dhcpunknown(TBD), -- value to be assigned by IANA
dhcpactive(TBD), -- value to be assigned by IANA
dhcpunidentified(TBD) -- value to be assigned by IANA
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The type of the last response message sent to this client. If "The type of the last response message sent to this client. If
the server does not capture this information, the value 32,767 the server does not capture this information, the value 32,767
is returned." is returned."
REFERENCE REFERENCE
"RFC2131; RFC2132, section 9.6; draft-ietf-dhc-leasequery- "RFC2131; RFC2132, section 9.6; draft-ietf-dhc-leasequery-
04.txt" 04.txt"
skipping to change at page 40, line 14 skipping to change at page 38, line 49
DESCRIPTION DESCRIPTION
"Objects belonging to the bootpBounterObjects group." "Objects belonging to the bootpBounterObjects group."
::= { dhcpv4ServerGroups 2 } ::= { dhcpv4ServerGroups 2 }
dhcpv4RecvdPacketCounterObjects OBJECT-GROUP dhcpv4RecvdPacketCounterObjects OBJECT-GROUP
OBJECTS { OBJECTS {
dhcpv4CountDiscovers, dhcpv4CountDiscovers,
dhcpv4CountRequests, dhcpv4CountRequests,
dhcpv4CountReleases, dhcpv4CountReleases,
dhcpv4CountDeclines, dhcpv4CountDeclines,
dhcpv4CountInforms, dhcpv4CountInforms
dhcpv4CountLeaseQueries
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Objects belonging to the dhcpv4RecvdPacketCounterObjects "Objects belonging to the dhcpv4RecvdPacketCounterObjects
group." group."
::= { dhcpv4ServerGroups 3 } ::= { dhcpv4ServerGroups 3 }
dhcpv4SentPacketCounterObjects OBJECT-GROUP dhcpv4SentPacketCounterObjects OBJECT-GROUP
OBJECTS { OBJECTS {
dhcpv4CountOffers, dhcpv4CountOffers,
dhcpv4CountAcks, dhcpv4CountAcks,
dhcpv4CountNacks, dhcpv4CountNaks,
dhcpv4CountForcedRenews, dhcpv4CountForcedRenews
dhcpv4CountKnowns,
dhcpv4CountUnknowns,
dhcpv4CountActives,
dhcpv4CountUnimplementeds
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Objects belonging to the dhcpv4SentPacketCounterObjects "Objects belonging to the dhcpv4SentPacketCounterObjects
group." group."
::= { dhcpv4ServerGroups 4 } ::= { dhcpv4ServerGroups 4 }
dhcpv4ErrorPacketCounterObjects OBJECT-GROUP dhcpv4ErrorPacketCounterObjects OBJECT-GROUP
OBJECTS { OBJECTS {
dhcpv4CountInvalids, dhcpv4CountInvalids,
skipping to change at page 44, line 27 skipping to change at page 43, line 27
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
6. Notes 6. Acknowledgements
This section will be removed when this memo goes to Working Group
Last Call.
6.1. Issues
Not all of these issues have been resolved, even in the latest (-08)
draft. Some may become items for future study, while some will
probably be dropped.
o Ryan Troll proposed four or five traps that Nathan Lane
enthusiastically supported, but it has been difficult to achieve
any consensus (or, for that matter, much interest) in them.
o What is the best way to reset counters and statistics? Is it
necessary to reset them at all? The -08 draft does not declare any
counters as read-write or read-create, primarily to avoid these
questions, as well as to provide fundamental security over objects.
o -- Do we need to reset them individually, as groups, or as a whole?
o -- Do we need a timestamp of when they were reset?
o Should all invalid packets received be collapsed into a single
counter for each protocol type (BOOTP and DHCPv4), or broken out by
type of error?
o If counted by error type, what is the set of errors that we should
use?
o Perhaps we should develop a common vocabulary (and glossary) for
terms such as "abandoned" so that the objects defined and
implementers don't misinterpret their descriptions.
o Do we need to be concerned about the potential size of some of the
configuration data tables? Wouldn't it be better to maintain
counters for things like number of leases assigned than to expect
the management station to calculate the values by reading very
large tables to count the number of leases in that state?
o The dhcpv4ServerSystemObjects, dhcpv4OptionalStatistics,
dhcpv4ServerClientObjects, dhcpv4ServerNotifyObjects, and
dhcpv4ServerNotifications groups may be sufficiently generic that
they could be renamed, re-specified, and moved from the
dhcpv4Server subtree to the dhcp subtree. This warrants some
discussion, especially if there is interest in client and relay
agent MIBs, or in adding extensions to support DHCPv6.
6.2. Changes from Prior Drafts
The "-01" revision removed the Server Identity section from the
proposed MIB, relying on the Application MIB to accomplish the same
result.
The "-02" revision changed the min/max (inter-arrival and response
times) to Unsigned32 so that they could be reset. Sums of inter-
arrival and response times were deleted since the management station
can easily calculate them. The last arrival time objects were added.
The "-03" version incorporated the proposed configuration tables
suggested by Ryan Troll of CMU. The "01" revision of this version
added three elements to the server subnet table, number of
outstanding offers, number of addresses in use, and number of free
addresses, as well as changing subnet address to subnet mask in the
server address, server range, and client address tables. The client
MAC address element of the client address table was separated into a
1-octet hardware type and a 16-octet client hardware address, causing
a renumbering of the elements in this table. Clarifying text was
added to several element descriptions, and limitations on values, and
the reported value when the server did not support the data element
were also specified. This version also incorporated an address
change for one of the authors, revisions to standard text required by
the IETF, and some editorial clarifications.
The "-04" version changed the maximum size of the object
dhcpv4ServerAddressHostName from 64 to 255 octets, and added
clarifying text to both that object and to
dhcpv4ServerAddressDomainName regarding the practical values for the
length of both objects.
The "-05" version added a number of traps suggested by Kim Kinnear,
made a number of small renaming and renumbering changes (annotated in
the MIB itself) and added the Shared Network concept to describe
shared network segments: several subnetworks that coexist on one
medium. This was done partly because the Address Range concept did
not adequately describe the "scoping" of address pools as is common
with many current server implementations. Also updated the author's
address and contact information, and incorporated a number of
corrections and amplifications suggested by various readers of the "-
04" draft, including a missing OID for dhcpv4ServerNotifyObjects and
a syntax error for DhcpPhysicalAddress.
The "-06" version corrects a number of flaws reported by Rick Geesen
and Jin Tao, mostly caused by typographical errors in the "-05"
version as well as some unintentionally omitted text for
dhcpv4ServerNotifyObjects. The "-06" version also changes BOOTP and
DHCP statistics from mandatory to optional, renaming object
identifiers as required to match. All objects, tables, and groups in
previous drafts for Dynamic DNS updating and Failover have been
removed. All tables were carefully examined to be certain that they
really could be simply implemented. Many items were renamed or
renumbered. Placeholder definitions of message types (both requests
and responses) were added to support DHCPFORCERENEW, DHCPQUERY,
DHCPKNOWN, and DHCPUNKNOWN. A few [more] typographical errors were
found and fixed. Finally, some of the boilerplate text was brought
in line with standard requirements for Internet-Drafts.
The "-07" version includes a number of small fixes, but is mostly to
correct a version numbering error.
The "-08" version fixes a few typographical errors (wrong
capitalization of object identifiers and table entry values, spacing
of comments, and misspelled words) in preparation for Working Group
Last Call. Many thanks to Rich Woundy for his detailed and extremely
helpful suggestions on the prior draft. The standard boilerplate
("The SNMP Management Framework") for all new MIBs was added as
section 2 and the standard references not previously included in
section 9 were added. DisplayString objects were recast as
SnmpAdminString types to be consistent with current practice. The
DhcpLabel textual convention was dropped entirely. InetAddressIPv4,
and InetAddressPrefixLength replaced the IpAddress type as
appropriate for Internetaddresses and subnet masks throughout the
MIB. Numbering of OIDs was made consistent, and dhcpv4Counters was
subdivided into dhcpv4RecvdPacketCounters, dhcpv4SentPacketCounters,
and dhcpv4ErrorPacketCounters to eliminate the need for placeholders
for anticipated new DHCP message type codes, eliminating gaps in the
OID numbering scheme. Two notification types,
dhcpv4ServerNotifyServerStart and dhcpv4ServerNotifyServerStop, were
added. Compliance and object groups were extensively reworked to
match other changes to the MIB. The proposed MIB itself was verified
by using smilint as required before submittal. Object names were
revised to uniformly begin with "dhcpv4" or "bootp" to provide a
clear visual indication of their purpose. A few objects were renamed
slightly to reflect their use, for example, serverServerStart and
serverServerStop were renamed dhcpv4ServerStartTime and
dhcpv4ServerStopTime. All object groups were reorganized to better
reflect the structure of the MIB. A few very long names were
shortened for improved readability.
7. Acknowledgements
This document is the result of work undertaken the by DHCP working This document is the result of work undertaken the by DHCP working
group. The editors would like to particularly acknowledge the group. The editors would like to particularly acknowledge the
development team from Carnegie-Mellon University whose work creating development team from Carnegie-Mellon University whose work creating
a private MIB for their DHCP server inspired the development of this a private MIB for their DHCP server inspired the development of this
proposal. In particular, many thanks to Ryan Troll who provided a proposal. In particular, many thanks to Ryan Troll who provided a
great deal of useful feedback during the initial development of this great deal of useful feedback during the initial development of this
MIB. MIB.
Thanks to Nathan Lane, Kim Kinnear, Yannick Koehler, Rick Geesen, Jin Thanks to Nathan Lane, Kim Kinnear, Yannick Koehler, Rick Geesen, Jin
Tao, James Brister, Alan Hackert, Patrick Cosmo, Taeko Saito, and Tao, James Brister, Alan Hackert, Patrick Cosmo, Taeko Saito, and
Devrapratap Baul for their review, comments, and contributions. Devrapratap Baul for their review, comments, and contributions.
Special thanks to Rich Woundy for his excellent suggestions that Special thanks to Rich Woundy for his excellent suggestions that
contributed to the --08 draft: any lingering errors are to be blamed contributed to the --08 draft: any lingering errors are to be blamed
solely on the editors. solely on the editors.
8. IANA Considerations 7. IANA Considerations
Several specific values for MIB objects require completion before
this memo can advance to RFC status. These are:
o OID value for "dhcp" see MODULE-IDENTITY
o Value of DHCPLEASEQUERY for "dhcpv4CountLeaseQueries" and
"dhcpv4ServerClientLastRequestType" objects
o Value of DHCPLEASEKNOWN for "dhcpv4CountKnowns" and IANA must fill in the value of the RFC number when it is assigned to
"dhcpv4ServerClientLastResponseType" objects this memo. It is represented as "xxxx" in the DESCRIPTION section of
o Value of DHCPLEASEUNKNOWN for "dhcpv4CountUnknowns" and MODULE-IDENTITY.
"dhcpv4ServerClientLastResponseType" objects
o Value of DHCPLEASEACTIVE for "dhcpv4CountActives" and One specific value for a MIB object requires completion before this
"dhcpv4ServerClientLastResponseType" objects memo can advance to RFC status. It is:
o Value of DHCPUNIMPLEMENTED for "dhcpv4CountUnimplementeds" and o OID value for "dhcp" see MODULE-IDENTITY
"dhcpv4ServerClientLastResponseType" objects
9. Security Considerations 8. Security Considerations
There are no management objects defined in this MIB that have a MAX- There are no management objects defined in this MIB that have a MAX-
ACCESS clause of read-write or read-create. Such objects may be ACCESS clause of read-write or read-create. Such objects may be
considered sensitive or vulnerable in some environments. The support considered sensitive or vulnerable in some environments. The support
for SET operations in a non-secure environment without proper for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. protection can have a negative effect on network operations.
Therefore, if this MIB is implemented correctly, there is no risk Therefore, if this MIB is implemented correctly, there is no risk
that an intruder can alter or create any management objects of this that an intruder can alter or create any management objects of this
MIB via direct SNMP SET operations. MIB via direct SNMP SET operations.
skipping to change at page 49, line 27 skipping to change at page 45, line 25
the objects only to those principals (users) that have legitimate the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them. rights to indeed GET or SET (change/create/delete) them.
Denial of Service attacks on a DHCP server are conceivable by Denial of Service attacks on a DHCP server are conceivable by
flooding the SNMP (sub-)agent with requests, tying up host system and flooding the SNMP (sub-)agent with requests, tying up host system and
server resources processing SNMP messages. The authors know of no server resources processing SNMP messages. The authors know of no
way to wholly prevent such attacks, but have attempted to construct way to wholly prevent such attacks, but have attempted to construct
relatively simple tables to minimize the work required to respond to relatively simple tables to minimize the work required to respond to
messages. messages.
10. References 9. References
One normative reference is currently an Internet-Draft, nearly ready One normative reference is currently an Internet-Draft, nearly ready
for Working Group Last Call. This reference MUST be updated when the for Working Group Last Call. This reference MUST be updated when the
draft advances to RFC status. draft advances to RFC status.
10.1. Normative References 9.1. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol," RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol," RFC 2131,
March 1997. March 1997.
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions," RFC 2132, March 1997. Extensions," RFC 2132, March 1997.
[RFC2578] Case, J., McCloghrie, K., Perkins, D., Rose, M., [RFC2578] Case, J., McCloghrie, K., Perkins, D., Rose, M.,
Schoenwaelder, J., and S. Waldbusser, "Structure of Management Schoenwaelder, J., and S. Waldbusser, "Structure of Management
Information for Version 2 of the Simple Network Management Protocol Information for Version 2 of the Simple Network Management Protocol
skipping to change at page 50, line 15 skipping to change at page 46, line 11
[RFC2580] Case, J., McCloghrie, K., Rose, M., Schoenwaelder, J., and [RFC2580] Case, J., McCloghrie, K., Rose, M., Schoenwaelder, J., and
S. Waldbusser, "Conformance Statements for Version 2 of the Simple S. Waldbusser, "Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)," RFC 2580, April 1999. Network Management Protocol (SNMPv2)," RFC 2580, April 1999.
[RFC3203], Yves T'Joens and Christian Hublet, Peter De Schrijver, [RFC3203], Yves T'Joens and Christian Hublet, Peter De Schrijver,
"The DHCP Reconfigure Extension," July 2001 "The DHCP Reconfigure Extension," July 2001
<draft-ietf-dhc-leasequery-04.txt> Rich Woundy and Kim Kinnear, "DHCP <draft-ietf-dhc-leasequery-04.txt> Rich Woundy and Kim Kinnear, "DHCP
Lease Query," November 2003. Lease Query," November 2003.
10.2. Informative References 9.2. Informative References
[DEN] Directory Enabled Networks Working Group, [DEN] Directory Enabled Networks Working Group,
http://www.universe.digex.net/~murchiso/den. http://www.universe.digex.net/~murchiso/den.
[RFC1123] R. Braden, "Requirements for Internet Hosts -- Application [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
and Support," RFC 1123, October 1989. and Support," RFC 1123, October 1989.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-Standard "Introduction and Applicability Statements for Internet-Standard
Management Framework", RFC 3410, December 2002. Management Framework", RFC 3410, December 2002.
11. Editors' Addresses 10. Editors' Addresses
Richard Barr Hibbs Richard Barr Hibbs
952 Sanchez Street 952 Sanchez Street
San Francisco, California 94114-3362 San Francisco, California 94114-3362
USA USA
Phone: +1-(415)-648-3920 Phone: +1-(415)-648-3920
Fax: +1-(415)-648-9017 Fax: +1-(415)-648-9017
Email: rbhibbs@pacbell.net Email: rbhibbs@pacbell.net
Glenn Waters Glenn Waters
Nortel Networks Nortel Networks
310-875 Carling Avenue, 310-875 Carling Avenue,
Ottawa, Ontario K1S 5P1 Ottawa, Ontario K1S 5P1
Canada Canada
Phone: +1-(613)-798-4925 Phone: +1-(613)-798-4925
Email: gww@NortelNetworks.com Email: gww@NortelNetworks.com
12. Full Copyright Statement 11. Full Copyright Statement
Copyright (C), 2003, The Internet Society. All Rights Reserved. Copyright (C), 2003, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/