idnits 2.17.1 draft-ietf-dhc-schema-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 667 has weird spacing: '...This is encod...' == Line 997 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2000) is 8624 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 951 looks like a reference -- Missing reference section? 'DMTF' on line 918 looks like a reference -- Missing reference section? 'DEN' on line 920 looks like a reference -- Missing reference section? 'POLICY' on line 939 looks like a reference -- Missing reference section? 'DHCPOPT' on line 935 looks like a reference -- Missing reference section? 'RFC951' on line 949 looks like a reference -- Missing reference section? 'RFC2255' on line 947 looks like a reference -- Missing reference section? 'RFC2132' on line 916 looks like a reference -- Missing reference section? 'FAILOVR' on line 929 looks like a reference -- Missing reference section? 'AGENT' on line 932 looks like a reference -- Missing reference section? 'RFC2131' on line 914 looks like a reference -- Missing reference section? 'MSDHCP' on line 922 looks like a reference -- Missing reference section? 'NOVDHCP' on line 925 looks like a reference -- Missing reference section? 'RFC2251' on line 942 looks like a reference -- Missing reference section? 'RFC2252' on line 944 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Andy Bennett 2 INTERNET-DRAFT Bernie Volz 3 Process Software 5 March 2000 6 Expires September 2000 8 DHCP Schema for LDAP 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This document presents an LDAP schema to represent the configuration 39 of the DHCP protocol within a TCP/IP network. It can be used to 40 represent the configuration(s) of an entire enterprise network, a 41 subset of the network, or even a single server. 43 1. Terminology 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 In places where different sets of terminology are commonly used to 50 represent similar DHCP concepts, this schema uses the terminology of 51 the Internet Software Consortium's DHCP server reference implementa- 52 tion. For more information see www.isc.org. 54 2. Design Considerations 56 Some of the design considerations for this schema were: 58 o Heterogeneous server environment - This schema is not designed to 59 represent the configuration of a specific DHCP server implementa- 60 tion. The intent of this schema is to provide a basic framework 61 for the representation of the most common elements used in the con- 62 figuration of DHCP. This should allow other network services to 63 obtain and use basic DHCP configuration information in a server- 64 independent way. Also note that it is highly unlikely that this 65 schema will be able to represent every feature of every implementa- 66 tion (and it is not intended to do so). It is expected that some 67 implementations may need to extend the schema objects in order to 68 fully implement all their features. 70 o Use of the schema - This draft does not define any "minimal compli- 71 ance criteria" for using the schema. It is recommended that you 72 use the object classes defined in this draft if you are represent- 73 ing DHCP configuration information in an LDAP directory. Some 74 implementations may choose not to support all of the objects 75 defined here. In particular, the following two decisions are 76 explicitly left up to the implementation: 78 - it is up to the implementation to determine whether or not the 79 lease information will be stored in the directory. Some imple- 80 mentations may choose not to store this information. 82 - it is up to the implementation to determine if the data in the 83 directory is considered "authoritative", or if it is simply a 84 copy of data from an authoritative source. 86 o The schema is focused on the representation of configuration infor- 87 mation. It does not provide for the representation of statistical 88 data, or historical lease data, only the current state of the DHC 89 protocol's configuration. 91 o The information in this schema will be used primarily by two types 92 of applications: DHCP servers (for loading their configuration) 93 and Management Interfaces (for defining/editing configurations). 94 The schema should must be efficient for the needs of both types of 95 applications. 97 o The schema is designed to allow objects managed by DHCP (such as 98 computers, subnets, etc) to be present anywhere in a directory 99 hierarchy (to allow those objects to be placed in the directory for 100 managing administrative control and access to the objects). How- 101 ever, the schema also provides for the possibility that any given 102 object may have multiple sets of configuration parameters defined 103 for different servers. 105 o The schema uses a few naming conventions - all object classes and 106 attributes are prefixed with "dhcp" and there are no object classes 107 and attributes that have the same name. The schema also uses stan- 108 dard naming attributes ("cn", "ou", etc) for all objects. In some 109 cases it is recommended that the "cn" matches another attribute 110 value. 112 o Relationship to DEN/DMTF - This document takes into consideration 113 the object-oriented information model for representing Network 114 information (including DHCP information) currently under develop- 115 ment as part of the Common Information Model (CIM) activity in the 116 Distributed Management Task Force (DMTF). It should be noted that 117 the CIM schema is still under development and subject to change. 118 The DMTF efforts continue and draw upon the Directory-Enabled Net- 119 works (DEN) specification. The schema described in this Internet- 120 Draft is intended to be an LDAP implementation of the appropriate 121 objects in the DMTF model. The DMTF schema was used as a source 122 for defining certain terminology within this schema. For more 123 information see [DMTF] and [DEN]. Prior versions of this draft 124 included a mapping between the two schemas, but this has been 125 removed since the DMTF schema is still under development. When it 126 is complete a new draft may be published to document the mapping 127 between the schemas. 129 o Relationship to Policy Framework working group - Much of the infor- 130 mation in this schema could be represented using the generalized 131 schema being developed by the Policy Framework. However, there 132 were two issues that we felt would make this a very complex and 133 most likely inefficient representation: (1) the complexity of the 134 inheritance relationships between the dhcp policy objects defined 135 in this document and (2) the Policy Framework schema represents 136 each of the conditions and actions of a policy as separate objects. 137 However, it is still a fairly straightforward process to map the 138 objects from this schema into the Policy Framework Core Schema 139 objects. For more information see [POLICY]. 141 3. Common Attributes 143 Although DHCP manages several different types of objects, the config- 144 uration of those objects is often very similar. Consequently, most 145 of these objects have a common set of attributes. 147 The dhcpConfigurableObject class is an auxiliary class which can be 148 used to associate the basic set of configuration attributes with 149 another object. Since some directories do not provide auxiliary 150 classes we have also repeated these common attributes in the defini- 151 tion of each of the DHCP object class definitions. 153 An implementation of this schema is not required to provide this aux- 154 iliary object class, but it SHOULD provide it if auxiliary classes 155 are supported. This is useful for associating DHCP configuration 156 settings for objects that are not directly defined as part of this 157 schema. 159 3.1. dhcpConfigurableObject Object Class 161 NAME dhcpConfigurableObject 162 DESCRIPTION A class that provides attributes for configuring 163 options and server parameters for DHCP. 164 TYPE Auxiliary 165 DERIVED FROM Top 166 POSSIBLE SUPERIORS ( ) 167 MUST CONTAIN ( ) 168 MAY CONTAIN ( dhcpOptionSetting dhcpParameterSetting 169 dhcpFieldSetting dhcpForcedOptions 170 dhcpIncludeOptionSet ) 172 3.2. Common Attribute Definitions 174 NAME dhcpOptionSetting 175 DESCRIPTION Encoded option values to be sent to clients. Each value 176 represents a single option and contains (OptionTag, 177 Length, OptionValue) encoded in the 16-bit format used 178 by DHCP. For more information see [DHCPOPT]. 179 SYNTAX OctetString MULTI-VALUE 181 NAME dhcpParameterSetting 182 DESCRIPTION Encoded values of parameters that control server behav- 183 ior. Each value represents a single parameter setting 184 in the form (ParameterName, ParameterValue) where the 185 parameter name is a set of ASCII characters followed by 186 a space followed by the parameter value as a string. 187 SYNTAX IA5String MULTI-VALUE 188 NAME dhcpFieldSetting 189 DESCRIPTION Encoded settings of fields (such as siaddr, file) in the 190 DHCP message whose values may be configurable for send- 191 ing back to a client. For more information see 192 [RFC951]. Encoded in the form (FieldName, FieldValue) 193 where the field name is a set of ASCII characters fol- 194 lowed by a space followed by the field value as a 195 string. 196 SYNTAX IA5String MULTI-VALUE 198 NAME dhcpForcedOptions 199 DESCRIPTION This is a list of DHCP option tags that MUST be sent to 200 clients. If not specified, the server only sends the 201 options back to the client which were requested. 202 SYNTAX Integer MULTI-VALUE 204 NAME dhcpIncludeOptionSet 205 DESCRIPTION The distinguished name(s) of dhcpNamedOptionSet objects 206 whose settings should be included for this object. If 207 there are multiple option sets, the order is important 208 so each value is preceded by it's precedence, followed 209 by a colon as in "1:dn1", "2:dn2", etc. Settings 210 defined on the object take precedence over any settings 211 found in an included option set. 212 SYNTAX IA5String MULTI-VALUE 214 4. Configurations and Services 216 The DHC working group is currently considering several proposals for 217 failover and redundancy of DHCP servers. These may require the shar- 218 ing of configuration information between servers. This schema pro- 219 vides a generalized mechanism for supporting any of these proposals, 220 by separating the definition of a server from the definition of the 221 configuration being provided by the server. 223 By separating these two concepts, a configuration may be provided by 224 one or by several servers, and similarly, a server may provide one or 225 more configurations. The schema does allow for a server to be config- 226 ured as either a primary or secondary provider of a configuration. 228 Configurations are also defined so that one configuration can include 229 some of the objects that are defined in another configuration (see 230 "dhcpIncludeObjects" attribute). This allows for sharing and/or a 231 hierarchy of related configuration items. 233 4.1. dhcpService Object Class 235 A "dhcpService" is a single instance of DHC server software running 236 on a computer system that provides the DHCP service defined by a 237 "dhcpConfiguration". 239 NAME dhcpService 240 DESCRIPTION This represents a single DHCP server. 241 TYPE Structural 242 DERIVED FROM Top 243 POSSIBLE SUPERIORS ( ) 244 MUST CONTAIN ( cn ) 245 MAY CONTAIN ( dhcpConfigurationDn dhcpImplementation ) 247 4.1.1. dhcpService Attribute Definitions 249 NAME cn 250 DESCRIPTION The "common name" of the server. This does not have any 251 significance to the server process that provides the 252 DHCP service - it is simply a unique name used to refer 253 to the server. This attribute should be used as the 254 naming attribute when constructing the dn. 256 NAME dhcpConfigurationDn 257 DESCRIPTION The distinguished name(s) of the configurations provided 258 by the server. 259 SYNTAX DN MULTI-VALUE 261 NAME dhcpImplementation 262 DESCRIPTION This is a string value that identifies the hard- 263 ware/software platform and version which is providing 264 the service. 265 SYNTAX IA5String SINGLE-VALUE 267 4.2. dhcpConfiguration Object Class 269 A "dhcpConfiguration" is the collection of configuration information 270 that represents everything a server would need to know to provide DHC 271 service to some set of clients. 273 From the perspective of the schema, it is basically a collection of 274 objects. This object class is used to capture information common to 275 all the objects in a configuration. The algorithm used to locate all 276 the objects in a configuration is discussed later. 278 NAME dhcpConfiguration 279 DESCRIPTION This represents a configuration, or a collection 280 of settings for related objects. A single ser- 281 vice may have multiple configurations. A config- 282 uration may be provided by multiple services, but 283 only one can be primary. 284 TYPE Structural 285 DERIVED FROM Top 286 POSSIBLE SUPERIORS ( ) 287 MUST CONTAIN ( cn ) 288 MAY CONTAIN ( dhcpPrimaryService dhcpSecondaryService 289 dhcpIncludeObjects dhcpOptionSetting 290 dhcpParameterSetting dhcpFieldSetting 291 dhcpForcedOptions dhcpIncludeOptionSet ) 293 4.2.1. dhcpConfiguration Attribute Definitions 295 NAME cn 296 DESCRIPTION The "common name" of the configuration. This should be 297 used as the naming attribute when constructing the dn. 299 NAME dhcpPrimaryService 300 DESCRIPTION The "dhcpService" which is the primary for the configu- 301 ration. 302 SYNTAX DN SINGLE-VALUE 304 NAME dhcpSecondaryService 305 DESCRIPTION The "dhcpService(s)" which provide backup for the con- 306 figuration. 307 SYNTAX DN MULTI-VALUE 309 NAME dhcpIncludeObjects 310 DESCRIPTION This attribute defines objects that are included in a 311 configuration. Each value is an LdapURL [RFC2255] 312 (specifying search criteria) that is evaluated to find 313 other objects that are included in this configuration. 314 Note that in addition to these objects, all objects that 315 are children of the configuration object in the direc- 316 tory are automatically included in the configuration. 317 SYNTAX IA5String MULTI-VALUE 319 5. Objects that represent Assignment Rules 321 Most of a DHCP configuration is the definition of rules that govern 322 the assignment of DHCP options and addresses to clients. This schema 323 defines a set of object classes which are common to most server 324 implementations for defining these rules. All of these object 325 classes are based on a higher level abstraction that represents a 326 dhcp assignment rule. 328 This is done for several reasons: it simplifies the organization of 329 the data and it also facilitates the mapping of the dhcp schema to 330 other schemas being developed in other working groups (see [POLICY] 331 for example). 333 This schema separates the definition of an assignment rule for an 334 object from the object itself. This allows for the definition of 335 multiple rules for a single object (possibly in different dhcp con- 336 figurations). However, each assignment rule does maintain a link 337 back to the definition of the object (see the "dhcpSourceObject" 338 attribute). 340 The structure of a "source object" is not defined in this schema. It 341 can be any LDAP object, and it is not required to even exist. How- 342 ever, if it does exist that object can use the "dhcpConfigurableOb- 343 ject" auxiliary class to directly associate dhcp configuration infor- 344 mation with that object. If an object is defined in this way, this 345 information is used on every assignment rule that references the 346 object. 348 The assignment rule objects in the directory can be organized in a 349 hierarchical fashion. If objects are organized this way, the "child" 350 rule object inherits settings from the "parent" rule object. This 351 can be done recursively. Furthermore, the "child" rule object inher- 352 its any conditions from the "parent" rule as well. This means that 353 the "child" rule's settings will only be used when both sets of con- 354 ditions are met. 356 As an example, if a "dhcpClass" is a child of a "dhcpSubnet" then the 357 settings for that class will only be used if the client request is a 358 member of that class AND it is also from the specified subnet. 360 The algorithm for resolving which option settings are applied for a 361 policy object is defined in a later section. 363 5.1. dhcpRule Object Class 365 The "dhcpRule" class is an abstract class that defines attributes 366 that are common to the DHCP configuration objects that define these 367 rules. 369 This class is the base class from which others are derived. Also 370 note that it includes all the attributes from the dhcpConfigurableOb- 371 ject class. 373 NAME dhcpRule 374 DESCRIPTION The base class for defining rules for address and 375 option assignment. 376 TYPE Abstract 377 DERIVED FROM Top 378 POSSIBLE SUPERIORS ( ) 379 MUST CONTAIN ( cn dhcpRuleType ) 380 MAY CONTAIN ( dhcpVendorCondition dhcpSourceObject 381 dhcpOptionSetting dhcpParameterSetting 382 dhcpFieldSetting dhcpForcedOptions 383 dhcpIncludeOptionSet ) 385 5.2. dhcpRule Attribute Definitions 387 NAME cn 388 DESCRIPTION The "common name" of the rule. This should be used as 389 the naming attribute when constructing the dn. 391 NAME dhcpRuleType 392 DESCRIPTION The type of assignment rule. This should be one of 393 'POOL', 'SUBNET', 'SHAREDNETWORK', 'CLIENT', 'CLASS' 394 unless the server implementation extends this with a new 395 type of rule. 396 SYNTAX IA5String SINGLE-VALUE 398 NAME dhcpVendorCondition 399 DESCRIPTION If the server extends the rule types, this attribute MAY 400 be used to specify the conditions under which the rule 401 should be applied. The content of this attribute is 402 defined by the vendor/server implementation. 403 SYNTAX IA5String MULTI-VALUE 405 NAME dhcpSourceObject 406 DESCRIPTION If the rule applies to an object that is defined else- 407 where in the directory, this attribute has the distin- 408 guished name of that object. The source object SHOULD 409 be a dhcpConfigurableObject. Also note that the source 410 object is used to determine option & parameter settings 411 (see the algorithm discussed later in this document). 412 SYNTAX DN SINGLE-VALUE 414 5.3. dhcpPool Object Class 416 A "dhcpPool" represents a rule for a collection of addresses speci- 417 fied by one or more ranges of addresses. If there are multiple 418 ranges specified, they do not need to be contiguous, and it is not 419 required that all the addresses be contained on the same IP subnet. 421 The "dhcpRuleType" attribute MUST be set to 'POOL', and the "cn" 422 SHOULD be set to the value of the "dhcpPoolName" attribute". 424 NAME dhcpPool 425 DESCRIPTION This stores configuration information about one 426 (or more) ranges of addresses. 427 TYPE Structural 428 DERIVED FROM dhcpRule 429 POSSIBLE SUPERIORS ( OrganizationalUnit dhcpRule ) 430 MUST CONTAIN ( cn dhcpPoolName dhcpAddressRange ) 431 MAY CONTAIN ( ) 433 5.3.1. dhcpPool Attribute Definitions 435 NAME dhcpPoolName 436 DESCRIPTION A descriptive name of the pool. 437 SYNTAX IA5String SINGLE-VALUE 439 NAME dhcpAddressRange 440 DESCRIPTION The starting & ending IP Addresses in the range (inclu- 441 sive), separated by a hyphen; if the range only contains 442 one address, then just the address can be specified with 443 no hyphen. Each range is defined as a separate value. 444 SYNTAX IA5String MULTI-VALUE 446 5.4. dhcpSubnet Object Class 448 A "dhcpSubnet" represents an assignment rule for an IP subnet. 450 The "dhcpRuleType" attribute MUST be set to 'SUBNET', and the "cn" 451 SHOULD be set to the value of the "dhcpSubnetName" attribute". 453 NAME dhcpSubnet 454 DESCRIPTION This class defines a subnet. 455 TYPE Structural 456 DERIVED FROM dhcpRule 457 POSSIBLE SUPERIORS ( OrganizationalUnit dhcpRule ) 458 MUST CONTAIN ( cn dhcpSubnetAddress dhcpSubnetMaskLength 459 dhcpSubnetName ) 460 MAY CONTAIN ( ) 462 5.4.1. dhcpSubnet Attribute Definitions 464 NAME dhcpSubnetAddress 465 DESCRIPTION The network address for the subnet. 466 SYNTAX IA5String SINGLE-VALUE 467 NAME dhcpSubnetMaskLength 468 DESCRIPTION The subnet mask length for the subnet. The mask can be 469 easily computed from this length. 470 SYNTAX Integer SINGLE-VALUE 472 NAME dhcpSubnetName 473 DESCRIPTION A descriptive name of the subnet. 474 SYNTAX IA5String SINGLE-VALUE 476 5.5. dhcpSharedNetwork Object Class 478 A "dhcpSharedNetwork" represents an assignment rule for multiple sub- 479 nets on the same physical cabling. 481 The "dhcpRuleType" attribute MUST be set to 'SHAREDNETWORK', and the 482 "cn" SHOULD be set to the value of the "dhcpSharedNetworkName" 483 attribute". 485 NAME dhcpSharedNetwork 486 DESCRIPTION This represents multiple subnets on the same 487 physical cabling. 488 TYPE Structural 489 DERIVED FROM dhcpRule 490 POSSIBLE SUPERIORS ( OrganizationalUnit dhcpRule ) 491 MUST CONTAIN ( cn dhcpSharedNetworkName ) 492 MAY CONTAIN ( ) 494 5.5.1. dhcpSharedNetwork Attribute Definitions 496 NAME dhcpSharedNetworkName 497 DESCRIPTION A descriptive name of the shared network. 498 SYNTAX IA5String SINGLE-VALUE 500 5.6. dhcpClient Object Class 502 The "dhcpClient" object class is used to store configuration informa- 503 tion related to a specific host. 505 The "dhcpRuleType" attribute MUST be set to 'CLIENT'. 507 NAME dhcpClient 508 DESCRIPTION This represents client-specific DHCP assignments. 509 TYPE Structural 510 DERIVED FROM dhcpRule 511 POSSIBLE SUPERIORS ( OrganizationalUnit dhcpRule ) 512 MUST CONTAIN ( cn dhcpClientIdentifier ) 513 MAY CONTAIN ( dhcpClassMember dhcpReservedAddress ) 515 5.6.1. dhcpClient Attribute Definitions 517 NAME dhcpClientIdentifier 518 DESCRIPTION A unique identifier for the client. This is encoded as 519 follows: the first two octets represent a type and sub- 520 type for the identifier. If the type field has a value 521 of 0, then the subtype is a dhcp option tag, and the 522 remainder of the octets are the value of that option to 523 use as an id (represented as it would be sent using the 524 DHCP protocol, including the bytes for the length). If 525 the type field has a value of 1, then the subtype octet 526 is the ARP hardware type (see [RFC2132]) and the remain- 527 der of the bytes are the hardware address. Server 528 implementations may choose to extend the set of types, 529 but these two MUST be recognized. Note that a client 530 can have more than one unique identifier specified - it 531 is left to the server implementation to decide if one or 532 all identifiers must be matched or which take precedence 533 over others. 534 SYNTAX OctetString MULTI-VALUE 536 NAME dhcpClassMember 537 DESCRIPTION This attribute indicates that the client is a member of 538 the specified class(es). 539 SYNTAX IA5String MULTI-VALUE 541 NAME dhcpReservedAddress 542 DESCRIPTION This attribute indicates the reserved (aka fixed) 543 address(es) for this client (if there are any). There 544 MAY be corresponding "dhcpAddress" objects created for 545 tracking this reservation. 546 SYNTAX IA5String MULTI-VALUE 548 5.7. dhcpClass Object Class 550 A "dhcpClass" represents information about a collection of clients. 551 The DHC protocol provides 2 mechanisms for managing this information 552 (User Class and Vendor Class). The schema also provides 2 additional 553 mechanisms for configuring groups of clients that are supported by 554 some servers. Clients may be explicitly added to a class by setting 555 the "dhcpClassMember" attribute in the "dhcpClient" object class. 556 Some servers also support forms of dynamic class membership beyond 557 the User Class and Vendor Class mechanisms - the "dhcpVendorCondi- 558 tion" attribute allows for the definition of dynamic classes. 560 The "dhcpRuleType" attribute MUST be set to 'CLASS', and the "cn" 561 SHOULD be set to the value of the "dhcpClassName" attribute". 563 NAME dhcpClass 564 DESCRIPTION Represents information about a collection of 565 related clients. 566 TYPE Structural 567 DERIVED FROM dhcpRule 568 POSSIBLE SUPERIORS ( OrganizationalUnit dhcpRule ) 569 MUST CONTAIN ( cn dhcpClassName dhcpClassType) 570 MAY CONTAIN ( ) 572 5.7.1. dhcpClass Attribute Definitions 574 NAME dhcpClassName 575 DESCRIPTION A descriptive name for the class. 576 SYNTAX IA5String SINGLE-VALUE 578 NAME dhcpClassType 579 DESCRIPTION This attribute indicates the type of the class. It 580 should be one of 'USERCLASS', 'VENDORCLASS', 'STATIC' 581 (the only members of the class are enumerated clients), 582 'DYNAMIC' (membership is determined by some vendor-spe- 583 cific conditions). 584 SYNTAX IA5String SINGLE-VALUE 586 6. Other Configuration objects 588 Many server implementations provide other objects that simplify the 589 configuration of the DHCP protocol. One example is the ability to 590 assign a name to a group of option settings and then to refer to the 591 entire group of settings by referencing the name. This is addressed 592 by the "dhcpNamedOptionSet" object class. 594 It is also fairly common for server implementations to allow users to 595 extend the default set of options with site specific option defini- 596 tions. This is addressed by the "dhcpDictionary" object class. This 597 object class is also used to define the implementation-specific 598 parameters (and their values) that can be specified in the "dhcpPa- 599 rameterSetting" attribute. 601 6.1. dhcpNamedOptionSet Object Class 603 A "dhcpNamedOptionSet" is an object class for associating a name with 604 a collection of option settings. The entire set of options can be 605 associated with a DHCP object by referring to the name. This allows 606 a common set of option settings to be re-used without repeating the 607 option settings on each configured object. To see how an option set 608 is referenced, see the "dhcpIncludeOptionSet" attribute. 610 NAME dhcpNamedOptionSet 611 DESCRIPTION This is a named collection of settings for 612 options and/or server parameters. 613 TYPE Structural 614 DERIVED FROM Top 615 POSSIBLE SUPERIORS ( OrganizationalUnit ) 616 MUST CONTAIN ( cn ) 617 MAY CONTAIN ( dhcpOptionSetting dhcpParameterSetting 618 dhcpFieldSetting dhcpForcedOptions 619 dhcpIncludeOptionSet ) 621 6.1.1. dhcpDictionary Object Class 623 "dhcpDictionary" objects define the options and/or parameters that 624 can be set when configuring various DHCP entities. 626 NAME dhcpDictionary 627 DESCRIPTION This class defines an option or parameter that 628 can have a value. 629 TYPE Structural 630 DERIVED FROM Top 631 POSSIBLE SUPERIORS ( OrganizationalUnit ) 632 MUST CONTAIN ( cn dhcpTag ) 633 MAY CONTAIN ( dhcpDisplayName dhcpDataType dhcpDefault 634 dhcpMultiValued dhcpLegalValues 635 dhcpTypeRestriction dhcpImplementation ) 637 6.2. dhcpDictionary Attribute Definitions 639 NAME cn 640 DESCRIPTION The "common name" of the option or parameter. This will 641 usually be the same as the "dhcpTag" attribute. 642 SYNTAX Integer SINGLE-VALUE 644 NAME dhcpTag 645 DESCRIPTION A unique value that identifies an option or parameter 646 and that is encoded in the values of the "dhcpOptionSet- 647 ting" and "dhcpParameterSetting" attributes. For 648 options this SHOULD be the numeric tag for the option 649 (stored as a string). 650 SYNTAX IA5String SINGLE-VALUE 652 NAME dhcpDisplayName 653 DESCRIPTION This is a string identifier for the option or parameter. 654 This is intended for display by a management tool or 655 GUI. 656 SYNTAX IA5String SINGLE-VALUE 657 NAME dhcpDataType 658 DESCRIPTION The data type for values of this option. One of the 659 following: 'INT8', 'INT16', 'INT32', 'UINT8', 'UINT16', 660 'UINT32' , 'ADDRESS', 'ADDRESS-MASK-PAIR', 'BOOLEAN', 661 'STRING', 'BINARY'. Other values may be specified if 662 the server implementation provides them. 663 SYNTAX IA5String SINGLE-VALUE 665 NAME dhcpDefault 666 DESCRIPTION Indicates the default value of a parameter or option 667 definition in a dictionary object. This is encoded as 668 it would be in the "dhcpOptionSetting" or "dhcpParame- 669 terSetting" attribute. 670 SYNTAX OctetString SINGLE-VALUE 672 NAME dhcpMultiValued 673 DESCRIPTION Indicates whether the parameter or option can have more 674 than one value. 675 SYNTAX Boolean SINGLE-VALUE 677 NAME dhcpLegalValues 678 DESCRIPTION The list of allowed values for the option or parameter. 679 Each "legal value" is stored as a separate value for the 680 attribute, and is encoded based on the "dhcpDataType" 681 attribute setting. 682 SYNTAX OctetString MULTI-VALUE 684 NAME dhcpTypeRestriction 685 DESCRIPTION This attribute is used to specify that the option or 686 parameter should only be used with specific types of 687 assignment rules. This is restricted to the same set of 688 values as the "dhcpRuleType" attribute. If not speci- 689 fied it is assumed that the definition applies to all 690 types. 691 SYNTAX IA5String MULTI-VALUE 693 NAME dhcpImplementation 694 DESCRIPTION This attribute is used to specify that the option or 695 parameter should only be used with specific server 696 implementations. If not specified it is assumed that 697 the definition applies to all implementations. 698 SYNTAX IA5String MULTI-VALUE 700 7. Tracking Addresses 702 The behavior of a DHCP server is influenced by two factors - it's 703 configuration and the current state of the addresses that have been 704 assigned to clients. This schema defined a set of objects for 705 storing the configuration of the server, and the following object 706 class provides the ability to record how addresses are used. 708 7.1. dhcpAddress Object Class 710 This class represents an IP address. It may or may not be leaseable, 711 and the object may exist even though a lease is not currently active 712 for the associated IP address. 714 Note that this object class has some of the "Settings" attributes 715 that are defined for the "dhcpConfigurableObject", but they are not 716 used for configuration - only for tracking the settings that were 717 assigned to the client. It is not required that the server implemen- 718 tation record options that were offered to the client. 720 NAME dhcpAddress 721 DESCRIPTION This class represents an IP Address, which may or 722 may not have been leased. 723 TYPE Structural 724 DERIVED FROM Top 725 POSSIBLE SUPERIORS ( ) 726 MUST CONTAIN ( cn dhcpAddressState ) 727 MAY CONTAIN ( dhcpExpirationTime dhcpStartTimeOfState 728 dhcpLastTransactionTime dhcpBootpFlag 729 dhcpDomainName dhcpDnsStatus 730 dhcpRequestedHostName dhcpAssignedHostName 731 dhcpReservedForClient dhcpAssignedToClient 732 dhcpRelayAgentInfo dhcpOptionSetting 733 dhcpParameterSetting dhcpFieldSetting ) 735 7.2. dhcpAddress Attribute Definitions 737 NAME cn 738 DESCRIPTION The IP address, as a string. 739 SYNTAX IA5String SINGLE-VALUE 740 NAME dhcpAddressState 741 DESCRIPTION This stores information about the current binding-status 742 of an address. For dynamic addresses managed by DHCP, 743 the values should be restricted to the states defined in 744 the safe-failover draft: 'FREE', 'ACTIVE', 'EXPIRED', 745 'RELEASED', 'RESET', 'ABANDONED', 'BACKUP'. For more 746 information on these states see [FAILOVR]. For other 747 addresses, it SHOULD be one of the following: 'UNKNOWN', 748 'RESERVED' (an address that is managed by DHCP that is 749 reserved for a specific client), 'RESERVED-ACTIVE' (same 750 as reserved, but address is currently in use), 751 'ASSIGNED' (assigned manually or by some other mecha- 752 nism), 'UNASSIGNED', 'NOTASSIGNABLE'. 753 SYNTAX IA5String SINGLE-VALUE 755 NAME dhcpExpirationTime 756 DESCRIPTION This is the time the current lease for an address 757 expires. 758 SYNTAX DateTime SINGLE-VALUE 760 NAME dhcpStartTimeOfState 761 DESCRIPTION This is the time of the last state change for a leased 762 address. 763 SYNTAX DateTime SINGLE-VALUE 765 NAME dhcpLastTransactionTime 766 DESCRIPTION This is the last time a valid DHCP packet was received 767 from the client. 768 SYNTAX DateTime SINGLE-VALUE 770 NAME dhcpBootpFlag 771 DESCRIPTION This indicates whether the address was assigned via 772 BOOTP 773 SYNTAX Boolean SINGLE-VALUE 775 NAME dhcpDomainName 776 DESCRIPTION This is the name of the domain sent to the client by the 777 server. It is essentially the same as the value for 778 DHCP option 15 sent to the client, and represents only 779 the domain - not the full FQDN. To obtain the full FQDN 780 assigned to the client you must prepend the "dhcpAs- 781 signedHostName" to this value with a ".". 782 SYNTAX IA5String SINGLE-VALUE 783 NAME dhcpDnsStatus 784 DESCRIPTION This indicates the status of updating DNS resource 785 records on behalf of the client by the DHCP server for 786 this address. The value is a 16-bit bitmask that has 787 the same values as specified by the Failover-DDNS option 788 (see [FAILOVR]). 789 SYNTAX Integer SINGLE-VALUE 791 NAME dhcpRequestedHostName 792 DESCRIPTION This is the hostname that was requested by the client. 793 SYNTAX IA5String SINGLE-VALUE 795 NAME dhcpAssignedHostName 796 DESCRIPTION This is the actual hostname that was assigned to a 797 client. It may not be the name that was requested by the 798 client. The fully qualified domain name can be deter- 799 mined by appending the value of "dhcpDomainName" (with a 800 dot separator) to this name. 801 SYNTAX IA5String SINGLE-VALUE 803 NAME dhcpReservedForClient 804 DESCRIPTION The distinguished name of a "dhcpClient" that an address 805 is reserved for. This may not be the same as the "dhc- 806 pAssignedToClient" attribute if the address is being 807 reassigned but the current lease has not yet expired. 808 SYNTAX DN SINGLE-VALUE 810 NAME dhcpAssignedToClient 811 DESCRIPTION This is the distinguished name of a "dhcpClient" that an 812 address is currently assigned to. This only has a value 813 when the address is leased. 814 SYNTAX DN SINGLE-VALUE 816 NAME dhcpRelayAgentInfo 817 DESCRIPTION If the client request was received via a relay agent, 818 this contains information about the relay agent that was 819 available from the DHCP request. This is a hex-encoded 820 option value. For more information see [AGENT]. 821 SYNTAX OctetString SINGLE-VALUE 823 8. Object Containment 825 These diagrams depict the containment hierarchy of the objects. 826 can be any LDAP object. 828 829 | 830 +---dhcpConfiguration 831 | 832 +--- ou = OptionDictionary 833 | | 834 | +---dhcpDictionary 835 | 836 +--- ou = ParameterDictionary 837 | | 838 | +---dhcpDictionary 839 | 840 +--- ou = NamedOptionSets 841 | | 842 | +---dhcpNamedOptionSet 843 | 844 +--- ou = Rules 845 | | 846 | +---dhcpRule 847 | | 848 | +---dhcpRule . . . 849 | 850 +--- ou = Addresses 851 | 852 +---dhcpAddress 854 855 | 856 +---dhcpService 858 9. Object Class Inheritance 860 The following diagram shows the inheritance hierarchy of the classes: 862 Top 863 | 864 +---dhcpDictionary 865 | 866 +---dhcpService 867 | 868 +---dhcpConfiguration (aux: dhcpConfigurableObject) 869 | 870 +---dhcpNamedOptionSet (aux: dhcpConfigurableObject) 871 | 872 +---dhcpAddress (aux: dhcpConfigurableObject) 873 | 874 +---dhcpRule (aux: dhcpConfigurableObject) 875 | 876 +---dhcpClass 877 | 878 +---dhcpClient 879 | 880 +---dhcpPool 881 | 882 +---dhcpSharedNetwork 883 | 884 +---dhcpSubnet 886 10. Determining Assignment Rule settings 888 This section of the document defines the algorithm that should be 889 used for determining the settings for options and/or parameters for 890 an assignment rule. Most DHCP server implementations provide for 891 some degree of inheritance of options between configuration objects. 892 This algorithm is flexible enough to allow server implementations to 893 represent their existing behavior. 895 The option settings directly associated with a "dhcpRule" object MUST 896 take precedence over all other option settings. The rule also inher- 897 its options from the following objects (in order of precedence): 898 - options from one or more included "dhcpNamedOptionSet" objects, as 899 defined in the "dhcpIncludeOptionSet" attribute. If there is more 900 than one option set, the attribute values define the order in which 901 the option sets should be included. 902 - options from the "dhcpSourceObject" for the rule. 903 - options from "dhcpNamedOptionSet" objects associated with the 904 "dhcpSourceObject" for the rule. 905 - options from the "parent" rule (only if the object's parent in the 906 directory is also a "dhcpRule" object. 907 - options from "dhcpNamedOptionSet" objects associated with the "par- 908 ent" rule. 910 - options from walking up the directory hierarchy inheriting from 911 ancestor rules until the "dhcpConfiguration" object is reached. 913 11. References 914 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 915 March 1997. 916 [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 917 Extensions", RFC 2132, March 1997. 918 [DMTF] Distributed Management Task Force, "Common Information 919 Model (CIM) Specification", Version 2.0, Mar 1998. 920 [DEN] Strassner, J., "Directory-Enabled Networks, Information 921 Model and Base Schema", DEN Specification v3.0c, July 1998. 922 [MSDHCP] Gu, Y., Vyaghrapuri, R., "An LDAP Schema for Dynamic Host 923 Configuration Protocol Service", Internet Draft 924 , August 1998. 925 [NOVDHCP] Miller, T., Patel, A., Rao, P., "Lightweight Directory 926 Access Protocol (v3): Schema for Dynamic Host Configuration 927 Protocol (DHCP)", Internet Draft 928 , June 1998. 929 [FAILOVR] Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, S., 930 Volz, B., "DHCP Failover Protocol", Internet Draft 931 , October 1999. 932 [AGENT] Patrick, M., "DHCP Relay Agent Information Option", Inter- 933 net Draft , March 934 2000. 935 [DHCPOPT] Carney, M., "New Option Review Guidelines and Additional 936 Option Namespace", Internet Draft 937 , Octo- 938 ber 1999. 939 [POLICY] Strassner, J., Elleson, E., Moore, B., "Policy Framework 940 LDAP Core Schema", Internet Draft 941 , November 1999. 942 [RFC2251] Wahl, M., Howes, T., Kille, S., "Lightweight Directory 943 Access Protocol (v3)", RFC 2251, December 1997. 944 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight 945 Directory Access Protocol (v3) Attribute Syntax Defini- 946 tions", RFC 2252, December 1997. 947 [RFC2255] Howes, T., Smith, M., "The LDAP URL Format", RFC 2255, 948 December 1997. 949 [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 950 951, September 1985. 951 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate Require- 952 ment Levels", RFC 2119, March 1997. 954 12. Acknowledgements 956 This document is closely aligned with the work being done in the 957 Distributed Management Task Force (DMTF) Networks working group. 959 Design ideas included in this document are primarily based on dis- 960 cussions during two meetings with some members of the IETF DHC 961 Working Group and the DMTF Networks working group. The contribu- 962 tions of these individuals is gratefully acknowledged. 964 Special thanks to Andrea Westerinen, Lee Rafalow, Steve Gonczi, 965 Steve Chirokas, Kim Kinnear, Ellen Stokes, Tom Miller, Ye Gu, 966 Glenn Waters, Mike Carney, Ralph Droms, Greg Rabil, Ted Lemon and 967 Steve Bazyl for their contributions. 969 Thanks also to Ester Burwell, Andy Sudduth, Fred Hunter, Paul Rai- 970 son, Josh Littlefield, Peter Heitman, Neil Russell and Linda Scobo 971 for their participation in these meetings. 973 13. Author information 975 Andy Bennett 976 Bernie Volz 977 Process Software Corporation 978 959 Concord St. 979 Framingham, MA 01701 980 Phone: (508) 879-6994 981 Email: bennett@process.com 982 Email: volz@process.com 984 14. Full Copyright Statement 986 Copyright (C) The Internet Society (1999). All Rights Reserved. 988 This document and translations of it may be copied and furnished 989 to others, and derivative works that comment on or otherwise 990 explain it or assist in its implementation may be prepared, 991 copied, published and distributed, in whole or in part, without 992 restriction of any kind, provided that the above copyright notice 993 and this paragraph are included on all such copies and derivative 994 works. However, this document itself may not be modified in any 995 way, such as by removing the copyright notice or references to the 996 Internet Society or other Internet organizations, except as needed 997 for the purpose of developing Internet standards in which case 998 the procedures for copyrights defined in the Internet Standards 999 process must be followed, or as required to translate it into lan- 1000 guages other than English. 1002 The limited permissions granted above are perpetual and will not 1003 be revoked by the Internet Society or its successors or assigns. 1005 This document and the information contained herein is provided on 1006 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1007 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1008 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1009 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1010 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.