idnits 2.17.1 draft-hall-ldap-whois-01.txt: ** The Abstract section seems to be numbered -(3775): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 388 has weird spacing: '...in-addr dc=i...' == Line 692 has weird spacing: '...ny/path descr...' == Line 1262 has weird spacing: '...ied the inetD...' == Line 3215 has weird spacing: '...ny/path descr...' -- 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 (February 2002) is 8103 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Eric A. Hall 3 Consultant 4 INTERNET-DRAFT Andrew Newton 5 Document: draft-hall-ldap-whois-01.doc VeriSign, Inc. 6 Expires: August, 2002 February 2002 8 The Internet Resource Query Service 9 and the WHOIS Resource Schema 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 RFC 2026. 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 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1. Abstract 35 This document describes an architectural framework for locating 36 and retrieving information about network resources, using LDAPv3 37 for the data-formatting and query-processing services. This 38 document also defines LDAP schema and searching rules for four 39 Internet resource types: DNS domains, IPv4 addresses, IPv6 40 address, and AS numbers. The framework specified in this document 41 also allows additional documents to define additional Internet 42 resource types and their handling rules. 44 Table of Contents 46 1. Abstract..................................................1 47 2. Definitions and Terminology...............................3 48 3. Background, Objectives and Overview.......................4 49 3.1. Background..............................................4 50 3.2. Overview................................................5 51 4. The LDAP-WHOIS Namespace..................................6 52 4.1. Namespace Example.......................................7 53 4.2. The domainComponent LDAP Hierarchy......................9 54 4.3. The inetResources Container............................10 55 4.4. Resource-Specific Entries..............................11 56 4.5. Redirects and Referrals................................12 57 5. The LDAP-WHOIS Object Classes and Attributes.............17 58 5.1. The inetResources Object Class.........................18 59 5.2. The inetDnsDomain Object Class.........................24 60 5.3. The inetIpv4Network Object Class.......................31 61 5.4. The inetIpv6Network Object Class.......................36 62 5.5. The inetAsNumber Object Class..........................42 63 5.6. The inetAssociatedResources Object Class...............47 64 5.7. The inetOrgPerson Object Class.........................52 65 5.8. The referral Object Class..............................52 66 5.9. Object Class and Attribute Permissions.................53 67 6. Search and Match Filters.................................54 68 6.1. Search Filter Expressions..............................55 69 6.2. Matching Filter Definitions............................57 70 7. Query Processing Models..................................62 71 7.1. Top-Down Processing....................................63 72 7.2. Bottom-Up Processing...................................67 73 7.3. Targeted Search Processing.............................72 74 7.4. Supplemental Query Processing Mechanisms...............74 75 8. Internationalization and Localization....................80 76 9. DIT Replication..........................................81 77 10. Transition Issues........................................82 78 10.1. NIC Handles............................................82 79 10.2. Change-Logs............................................83 80 10.3. Open Issues............................................83 81 11. Security Considerations..................................84 82 12. IANA Considerations......................................85 83 13. Author's Addresses.......................................86 84 14. References...............................................86 85 15. Changes from Previous Versions...........................87 86 2. Definitions and Terminology 88 This document unites, enhances and clarifies several pre-existing 89 technologies. Readers are expected to be familiar with the 90 following specifications: 92 RFC 2247 - Using Domains in LDAP/X.500 DNs 94 RFC 2251 - Lightweight Directory Access Protocol (v3) 96 RFC 2252 - Lightweight Directory Access Protocol (v3): 97 Attribute Syntax Definitions. 99 RFC 2254 - The String Representation of LDAP Search Filters 101 RFC 2256 - A Summary of the X.500(96) User Schema for use 102 with LDAPv3 104 RFC 2798 - Definition of the inetOrgPerson LDAP Object 105 Class 107 [namedref] - - Named 108 Subordinate References in LDAP Directories 110 [ir-dir-req] - - 111 Internet Registry Directory Requirements 113 The following abbreviations are used throughout this document: 115 DIT (Directory Information Tree) - A DIT is a contained 116 branch of the LDAP namespace, having a root of a particular 117 distinguished name. "dc=example,dc=com" is used throughout 118 this document as one DIT, with many example entries being 119 stored in this DIT. 121 DN (Distinguished Name) - A distinguished name provides a 122 unique identifier for an entry, through the use of a multi- 123 level naming syntax. Entries are named according to their 124 location relevant to the root of their containing DIT. For 125 example, "cn=inetResources,dc=example,dc=com" is a DN which 126 uniquely identifies the "inetResources" entry within the 127 "dc=example,dc=com" DIT. 129 RDN (Relative DN) - An RDN provides a locally-scoped unique 130 identifier for an entry. A complete, globally-unique DN is 131 formed by concatenating the RDNs of an entry together. For 132 example, "cn=admins,cn=inetResources,dc=example,dc=com" 133 consists of two RDNs ("cn=admins" and "cn=inetResources") 134 within the "dc=example,dc=com" DIT. RDNs are typically only 135 referenced within their local scope. 137 OID (Object Identifier) - An OID is a globally-unique, 138 concatenated set of integers which provide a kind of 139 "serial number" to attributes, object classes, syntaxes and 140 other schema elements. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 143 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 144 in this document are to be interpreted as described in RFC 2119. 146 3. Background, Objectives and Overview 148 3.1. Background 150 The WHOIS information service was originally provided as a network 151 front-end to a centralized repository of ARPANET resources and 152 users. Over time, multiple WHOIS information servers have been 153 deployed which provide similar services for Internet resources. 155 For example, there are scores of WHOIS servers which serve one or 156 more of the top-level domains ("com", "jp", etc.), with each 157 server providing information about the sub-domains that have been 158 delegated beneath each of the managed TLDs, and which also provide 159 information about the human operators of those domains, among 160 other details. Similarly, there are WHOIS servers which provide 161 information about different portions of the IPv4 address space. 162 Similarly, there are WHOIS servers which are operated by service 163 providers which provide information about the resources in use by 164 that organization and its customers. All told, there are hundreds 165 of WHOIS servers available on the public Internet, with each 166 server providing general information about the particular network 167 resources under the control of each organization. 169 Unfortunately, the WHOIS specification does not define a strict 170 set of data-formatting requirements, and as a result, each of the 171 different implementations provide information in different data 172 formats. Some servers provide limited amounts of unstructured 173 information, while others provide information in a highly-detailed 174 and highly-structured form. Similarly, some servers provide 175 information in only one language and charset, while others support 176 multiple languages and charsets, and use input switches to control 177 the output format. Essentially, every WHOIS server has its own 178 data formats and syntaxes, with little consistency between them, 179 which has made programmatic processing of the data difficult. 181 Furthermore, each WHOIS server operates as a self-contained 182 entity, with no knowledge or linkage between the different 183 servers, meaning that WHOIS servers cannot redirect clients to 184 other servers for additional information. 186 Another concern is that the WHOIS services which are being 187 operated today offer no means of client authentication, requiring 188 that server operators essentially publish all data with a single 189 "world-readable" permission. However, this single permission 190 conflicts with the privacy and security policies of specific 191 jurisdictions. A more flexible mechanism for controlling the 192 release of physical and personal information is required in order 193 to meet the requirements of the varying constituencies. 195 There are many other secondary issues with the WHOIS service as it 196 exists in current form. However, the largest problems are a lack 197 of standardized data formats, a lack of widely-supported referral 198 mechanisms, and lack of privacy and security controls, as 199 described in the preceding text. 201 This document attempts to address these issues by defining 202 operational and protocol guidelines for a distributed and highly- 203 structured WHOIS-like service, using the LDAP protocol for the 204 query/response transfer service, and using LDAP schema for the 205 search inputs, answer data, and redirection mechanisms. In short, 206 the intention of this approach is to provide an extensible and 207 scalable WHOIS service, leveraging the capabilities of LDAP. 209 3.2. Overview 211 This document defines four basic service components and their 212 interaction as part of a distributed resource-locator service. 213 Each of these components work together to provide a structured and 214 distributed resource-locator service. 216 The four components of this service are: 218 * Structured Namespace. This document makes use of an LDAP 219 namespace which is built upon the existing DNS delegation 220 hierarchy, and which is supplemented by a layered namespace 221 consisting of service-specific containers and resource- 222 specific entries. This namespace and the associated naming 223 rules facilitate the programmatic formation of queries, 224 structured data, and referrals. 226 * Schema Definitions. This document reuses many existing LDAP 227 schema definitions, but also introduces several new object 228 classes, attributes, syntaxes and matching filters. Some of 229 these definitions apply to the overall architecture, while 230 others are concerned with specific resource types. 232 * Searching Rules. This document defines several rules for 233 forming queries which are designed to facilitate consistent 234 answer sets, and to improve interoperability between 235 compliant clients and servers. 237 * Query Processing Models. This document defines three 238 distinct query-processing models which may be used for 239 locating the authoritative servers associated with a named 240 resource. These include a "top-down" model which is 241 designed for querying centrally-managed Internet resources, 242 a "bottom-up" model which is designed for querying user- 243 managed resources, and a "targeted search" model which is 244 designed for querying known servers for information about 245 known resources. This document also specifies protocol 246 behavior for following subordinate reference referrals, 247 continuation reference referrals, and attribute references. 249 It is the intention of the authors that additional resource types 250 will be added to this framework over time. As such, the 251 architecture and protocols defined in this specification are 252 purposefully designed to be capable of accommodating a variety of 253 different data-types and usage models, including future uses which 254 are not defined here. 256 4. The LDAP-WHOIS Namespace 258 A critical aspect of this service is the use of a predictable 259 naming syntax, both for the automatic creation of programmatic 260 searches for data, and for publishing structured data and 261 referrals. In order to ensure this predictability, this document 262 defines a multi-layered syntax which MUST be used by all compliant 263 implementations. 265 The LDAP-WHOIS service also makes provisions for the use of 266 multiple referral services for the purpose of redirecting LDAP 267 clients to foreign directory information trees (DITs). This allows 268 organizations to redirect queries to external service providers, 269 consolidate DITs within a single server, maintain foreign objects 270 within a private DIT (such as allowing a third-party router to 271 exist as a separately managed resource within an end-user DIT), 272 and allows answer sets to contain responses from multiple servers. 274 4.1. Namespace Example 276 Figure 1 below shows a subset example of the LDAP-WHOIS namespace. 277 This namespace will be used throughout this document to illustrate 278 many of the concepts from this specification. 280 Figure 1: Namespace for Example Widgets' domain and network. 282 DIT: dc=example,dc=com 283 | 284 +-cn=inetResources,dc=example,dc=com 285 [top object class] 286 [inetResources object class] 287 | 288 +-attribute: o 289 | value: "Example Widgets, Inc. public network resources" 290 | 291 +-cn=example.com,cn=inetResources,dc=example,dc=com 292 | [top object class] 293 | [inetResources object class] 294 | [inetDnsDomain object class] 295 | | 296 | +-attribute: inetDnsContacts 297 | value: "ldap://ldap.example.com/cn=hostmaster, 298 | ou=admins,dc=example,dc=com" 299 | 300 +-cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com 301 | [top object class] 302 | [inetResources object class] 303 | [inetDnsDomain object class] 304 | | 305 | +-attribute: description 306 | | value: "Example Widgets' reverse-lookup domain" 307 | | 308 | +-cn=cref1,cn=2.0.192.in-addr.arpa, 309 | cn=inetResources,dc=example,dc=com 310 | [top object class] 311 | [inetResources object class] 312 | [inetDnsDomain object class] 313 | [referral object class] 314 | | 315 | +-attribute: ref 316 | value: "ldap://ldap.example.com/cn=example.com, 317 | cn=inetResources,dc=example,dc=com" 318 | 319 +-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 320 [inetResources object class] 321 [inetIpv4Network object class] 322 | 323 +-attribute: inetIpv4Contacts 324 value: "ldap://ldap.example.com/cn=hostmaster, 325 ou=admins,dc=example,dc=com" 327 DIT: dc=2,dc=0,dc=192,dc=in-addr,dc=arpa 328 | 329 +-cn=inetResources 330 [top object class] 331 [inetResources object class] 332 [referral object class] 333 | 334 +-attribute: ref 335 value: "ldap://ldap.example.com/cn=inetResources, 336 dc=example,dc=com" 338 Figure 1 shows different DITs, both of which are managed by the 339 Example Widgets company. The "dc=example,dc=com" DIT is 340 authoritative for the DNS domain of "example.com", while the 341 "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is authoritative for the 342 reverse-lookup DNS domain of 2.0.192.in-addr.arpa and the IPv4 343 network of "192.0.2.0/24". 345 Both DITs have container entries called "cn=inetResources". This 346 container entry is responsible for holding all of the entries 347 which are associated with the Internet resources that are being 348 managed by the LDAP-WHOIS service. For example, the 349 "cn=inetResources,dc=example,dc=com" entry contains a subordinate 350 entry for "cn=example.com", which is a DNS domain that is being 351 managed through the LDAP-WHOIS service, and also contains entries 352 for the 2.0.192.in-addr.arpa reverse-lookup DNS domain and the 353 192.0.2.0/24 IPv4 network. 355 The "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" entry 356 only exists as a referral which will cause queries to be 357 redirected to the "cn=inetResources,dc=example,dc=com" hierarchy. 359 The naming syntax and rules are described throughout the remainder 360 of this section 4.1. Figure 1 is only provided as an example a 361 relatively complete namespace, for illustration and subsequent 362 discussion purposes. 364 4.2. The domainComponent LDAP Hierarchy 366 The top-level of the namespace defined for use with this service 367 uses the domainComponent naming syntax specified in RFC 2247, 368 which maps DNS domain names to domainComponent ("dc=") labels to 369 form a DIT. Each DIT represents a primary identifier for the 370 management body that is offering an LDAP server, and as such, 371 provides a primary identifier for the Internet resources under the 372 control of that organization. The DITs will be used to build LDAP 373 queries for specific resources, and will also be used to locate 374 the LDAP servers associated with the controlling organization. 376 Examples of the RFC 2247 syntax are shown in Figure 2 below. 378 Figure 2: The LDAP-WHOIS domainComponent Namespace. 380 dc=. 381 | 382 +----------------+---------------+ 383 / | \ 384 dc=arpa dc=com dc=[...] 385 | | 386 +--+--+ dc=example 387 / \ 388 dc=in-addr dc=ip6 390 A complete sequence of domainComponent DNs represents the scope of 391 the DIT. For example, a DIT with the distinguished name (DN) of 392 "dc=com" is authoritative for all of the LDAP resources within the 393 "com" DNS domain (for many LDAP-WHOIS queries, this will also 394 include any sub-domains under the "com" domain). Meanwhile, a DIT 395 with the DN of "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is 396 authoritative for domain name resources within the reverse-lookup 397 "2.0.192.in-addr.arpa" DNS domain, as well as the IPv4 network 398 addresses within the 192.0.2.0/24 network. At the other extreme, 399 the dc="." DIT is responsible for all Internet resources (although 400 this DIT is rarely used). 402 Since the DIT determines the scope of control over a set of 403 resources, DITs that overlap also have overlapping scopes of 404 control. For example, the "dc=com" and "dc=example,dc=com" DITs 405 can both provide information about the "www.example.com" domain 406 name resource. In order to allow end-users to specify which scope 407 they wish to work with for any given query, this document defines 408 three different query models (these are described in section 7). 410 When the LDAP servers associated with the chosen DIT need to be 411 located, the domainComponent DNs from the DIT are mapped to a DNS 412 domain name, and a query is issued for the LDAP servers associated 413 with that domain name (this process is also described in section 414 7). This means that the authority to process LDAP searches for a 415 DIT comes directly from the portion of the DNS namespace already 416 under the control of that management body. For example, the LDAP 417 servers which are used to process queries for the "dc=com" DIT 418 will be located by querying the DNS zone responsible for the "com" 419 portion of the DNS namespace, and so forth. 421 4.3. The inetResources Container 423 This specification requires the use of a mandatory LDAP container 424 entry with the well-known relative distinguished name (RDN) of 425 "cn=inetResources", which MUST exist in the root of every DIT that 426 provides LDAP-WHOIS services. All resource-specific entries which 427 are provided on public LDAP-WHOIS servers MUST be stored in the 428 cn=inetResources container entry. 430 The primary motivation for this naming is for predictability, in 431 that it allows searches to be formed programmatically (a search 432 base for resources in the "dc=example,dc=com" DIT can be 433 programmatically formed as "cn=inetResources,dc=example,dc=com", 434 for example). However, there are several other motivating factors 435 for this naming syntax. 437 For example, it is easier to apply a single anonymous read-only 438 permission to the inetResources container than it is to apply the 439 same permission to multiple discrete entries, which in turn means 440 that it is more likely that the appropriate restrictions will be 441 defined. Furthermore, the use of a single container entry for all 442 of an organization's Internet resources allows that branch of the 443 DIT to be redirected to another DIT through the use of a single 444 referral operation (this will be particularly important when the 445 LDAP servers that are located by DNS lookups are not the same 446 servers that provide LDAP-WHOIS services). Another reason to use 447 this naming syntax is that it shelters clients from server-side 448 vagaries with DIT entries (where different vendors use different 449 object classes to define the DITs). 451 All told, the use of the "cn=inetResources" RDN facilitates smooth 452 operations, and is important enough to justify the MANDATORY usage 453 of this naming syntax. 455 4.4. Resource-Specific Entries 457 This document defines four Internet resource types, each of which 458 have their own naming rules. However, each resource type has a 459 consistent naming principle, in that the specific managed resource 460 has an RDN which uniquely identifies that resource, with the RDN 461 residing within the inetResources container entry. 463 For example, an entry for the "www.example.com" domain name 464 resource stored in the "dc=example,dc=com" DIT would have a DN of 465 "cn=www.example.com,cn=inetResources,dc=example,dc=com", while an 466 entry for the "192.0.2.0/24" IPv4 network resource would have a DN 467 of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although 468 the relative naming syntax is different for each resource type, 469 the resource naming is consistent for each type, and the position 470 of the RDN within the DN is also predictable. 472 Most resource types cannot be located through simple LDAP browsing 473 and equality matches. Instead, resource-specific entries use 474 structured naming rules in order to facilitate the extensible 475 match search operations which are specific to each of the defined 476 resource types. For example, there is not likely to be a specific 477 entry for every possible IPv4 address. In order to allow the 478 appropriate entry to be located, however, the client can use the 479 inetIpv4NetworkMatch extensible matching search operation, which 480 locates the appropriate entry based on the search input. 482 The naming rules associated with each resource type are provided 483 in section 5, along with the schema definitions for each of the 484 resource types. The extensible matching filters associated with 485 each resource type are described in section 6. 487 4.5. Redirects and Referrals 489 A critical objective behind this service is for servers to be able 490 to redirect clients to other servers, entries, or DITs, when this 491 is necessary or desirable. Towards this end, this document 492 specifies three methods for generating and processing redirects 493 and referrals: subordinate reference referrals, continuation 494 reference referrals, and attribute references. 496 Subordinate reference referrals indicate that the queried entry is 497 an alias for some other entry, and that the query has to be 498 restarted in order for the current operation to be completed. 499 Meanwhile, continuation references indicate that the search was 500 successfully initiated, but that additional queries are required 501 for the original query to be completely exhausted. Finally, 502 attribute references simply indicate that supplemental data is 503 available at some other location, but that no additional queries 504 are required to satisfy the current operation. 506 NOTE: RFC 2251 defines a superior reference referral which 507 is used as a "default referral" for out-of-scope searches. 508 However, this application specifically excludes support for 509 superior reference referrals. Any superior reference 510 referrals which are encountered as a part of this service 511 are to be treated as errors. 513 Subordinate references and continuation references use the ref 514 attribute and referral object class defined in [namedref]. 515 Attribute references use a superset of the formatting rules 516 associated with the labeledURI attribute, as defined in RFC 2079. 517 All of these mechanisms use LDAP URLs as their input data, 518 although these URLs have service-specific restrictions that are 519 somewhat tighter than the source specifications allow. 521 Among these rules: 523 * All referenced entries MUST comply with the naming syntax 524 rules specified in this document. This means that all 525 entries MUST use the domainComponent ("dc=") naming syntax 526 for their DITs, resource-specific entries MUST reside in 527 the inetResources container entry, and resource-specific 528 entries MUST comply with the naming rules for the resource 529 type in question. 531 * Referral sources and targets MUST have the same resource- 532 specific object classes defined (for example, the referral 533 source and target for a DNS domain resource would both have 534 the inetDnsDomain object class defined). This is a 535 prerequisite for the proper handling of the search filters 536 specified in this document. Attribute references are not 537 referrals, so they are exempt from this requirement. 539 * Referenced entries MAY exist as referrals to other entries, 540 but recursive referrals are discouraged. 542 * Except where otherwise noted, the protocol identifier of a 543 URL MUST specify either the LDAP or LDAPS (LDAP over 544 TLS/SSL) service types. Although general-purpose LDAP 545 referrals are allowed to specify any URL, LDAP-WHOIS 546 referrals and references are intended to be used for 547 automated queries, so the use of other protocols or 548 services is expressly forbidden. 550 * The host identifier of a URL MUST specify either an IP 551 address or a domain name. URLs which do not provide host 552 identifiers are invalid in all cases. 554 * URLs MUST be provided and stored in a URL-safe format. For 555 example, the IPv4 and IPv6 network address syntaxes defined 556 in this document make use of the forward-slash ("/") 557 character to indicate a subnet prefix, and if this 558 character needs to be provided in a URL, it must be 559 provided in the escaped form ("%2F" in this example). 560 Furthermore, some of the matching rules described in this 561 document require that the URLs also be stored in this 562 format in order for the searches to succeed. 564 * Implementations MUST NOT restrict URL values to verifiable 565 entries from local partitions. Implementations MAY validate 566 targets when the partition is known and accessible, but a 567 lack of knowledge regarding a target MUST NOT be cause to 568 prevent the entry from being specified. 570 Clients MAY implement support for additional protocol identifiers 571 if they wish to act upon URLs which are provided in conflict with 572 the requirements above. However, clients MUST NOT violate any 573 other mandates in this document while doing so (in particular, 574 clients MUST NOT break the query-processing procedures defined in 575 section 7 of this document). 577 Each of the supported redirection mechanisms are discussed in more 578 detail below. 580 4.5.1. Subordinate reference referrals 582 Subordinate reference referrals are returned when the search base 583 specified in a query names an entry which exists as a referral 584 object class that points to some other entry. 586 Any of the named entries specified in section 4 of this document 587 MAY be defined as subordinate reference referrals which point to 588 other entries. However, almost all of the search functions defined 589 for use by this service use the inetResources container entry as 590 the search base (the exceptions to this rule are targeted searches 591 for explicit entries), so subordinate reference referrals will 592 most commonly be seen when an inetResources container entry has 593 been redirected to an inetResources container in another DIT. 595 For example, the namespace shown in Figure 1 has an entry of 596 "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" defined 597 with the referral object class, with the ref attribute value 598 pointing to the LDAP server of "ldap.example.com" and the DN of 599 "cn=inetResources,dc=example,dc=com". Any queries for resources 600 within "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" 601 would be answered with that subordinate reference referral, and 602 these queries would have to be restarted using the specified 603 search base and server before they would be processed. 605 Servers MUST support the use of subordinate reference referrals 606 for this purpose, and clients MUST be prepared to accept and 607 process any subordinate reference referrals in answer sets. 609 When subordinate reference referrals are used for this purpose, 610 the referral source MUST be defined with the referral object 611 class, and MUST also be defined with the appropriate object class 612 for that resource type. For example, a "cn=inetResources" entry 613 which provided a subordinate reference referral would need to have 614 both the referral and inetResources object classes defined, while 615 a DNS domain resource such as "dc=example.com" would need to have 616 both the referral and inetDnsDomain object classes defined (among 617 the other object class definitions which were required for that 618 entry). Referral targets need to use whatever object classes are 619 appropriate for the resource in question, and MAY also be 620 referrals to other entries. 622 Client rules for processing subordinate reference referrals are 623 given in section 7.4.1. 625 4.5.2. Continuation reference referrals 627 Continuation reference referrals are returned when a search 628 operation has been successfully processed by the queried server, 629 but the answer data also includes referrals to other entries. 630 These referrals are often provided as supplemental data to an 631 answer set, although this is not required (a continuation 632 reference referral can be the only response, but it won't be the 633 only response in the common case). 635 For example, the namespace shown in Figure 1 has an entry of 636 "cn=cref1,cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example, 637 dc=com" defined with the referral object class, with the ref 638 attribute value pointing to the LDAP server of "ldap.example.com" 639 and the DN of "cn=example.com,cn=inetResources,dc=example,dc=com". 640 Any answers to any queries about "cn=2.0.192.in-addr.arpa" would 641 also include the continuation reference referral, and new queries 642 for the referral target would have to be issued before the 643 original queries were completely processed. 645 Servers MUST support the use of continuation reference referrals 646 for this purpose, and clients MUST be prepared to accept and 647 process any subordinate reference referrals in answer sets. 649 When continuation reference referrals are used for this purpose, 650 entries MAY exist for the queried resource, but one or more 651 entries MUST exist with the referral object class defined, and 652 which provide LDAP URLs that point to other entries which have 653 additional information about the resource in question. 655 Continuation reference referrals are returned in response to 656 specific extensible match queries, and have specific naming 657 requirements which are necessary for the matching functions to 658 work properly. These considerations are described in 7.4.3. 660 Client rules for processing continuation reference referrals are 661 also given in section 7.4.3. 663 4.5.3. Attribute references 665 This document defines attribute references as attribute values 666 which provide LDAP or LDAPS URLs, for the purpose of providing 667 pointers to contextually-related information regarding the entry 668 currently being viewed. Attribute references use the same basic 669 syntax as the labeledURI attribute defined in RFC 2079, although 670 there are additional restrictions, as described above. 672 The contact attributes defined in this document use the attribute 673 reference rules and formats to provide role-specific pointers to 674 inetOrgPerson entries. Whenever one of these attributes is 675 encountered, it is up to the client to deconstruct the provided 676 URLs in order to locate and read the inetOrgPerson entries, 677 although such actions are secondary to the original query process, 678 and will typically only be performed at the user's request. 680 For example, the namespace shown in Figure 1 has an entry of 681 "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" defined with 682 the inetIpv4Network object class, with the inetIpv4Contacts 683 attribute value pointing to the LDAP server of "ldap.example.com" 684 and the DN of "cn=hostmaster,ou=admins,dc=example,dc=com". When 685 this attribute is provided as part of an answer to a query, a 686 client MAY choose to follow this URL for information about that 687 contact, although this would be considered a new and separate 688 query, and would not be required to satisfy the original query. 690 Note that the attribute reference URLs are similar to the URLs 691 defined in RFC 2079, and use a two-part notation of 692 "url://any.host:port/any/path description", with the 693 "description" string providing a free-text description of the 694 target specified by the URL. When the descriptive text is provided 695 in an attribute reference, it SHOULD be displayed to the user as 696 potentially informative data. 698 Client rules for processing attribute references are given in 699 section 7.4.4. 701 4.5.4. labeledURI references 703 Some of the object classes defined in this document make use of 704 the labeledURI attribute, as defined by RFC 2079. These attributes 705 (and their values) are not governed by this document, but instead 706 are governed by RFC 2079. As such, the rules set forth in RFC 2079 707 always apply to those attributes. In particular, this means that 708 those attribute values may reference any protocol (such as 709 http://) and are not restricted to LDAP protocol targets. 711 5. The LDAP-WHOIS Object Classes and Attributes 713 This document defines a general framework for locating information 714 about public network resources in a distributed environment, and a 715 critical element of this definition are schema definitions for the 716 object classes and attributes that provide this information. 718 Towards that end, this document defines a schema for the global 719 inetResources object class which is inherited by all of the 720 resource-specific types, defines four resource-specific object 721 classes, and defines a generalized object class for cross- 722 referencing resources. This document also takes advantage of some 723 pre-existing schema definitions (in particular, the inetOrgPerson 724 object class), where suitable schema were available. Each of the 725 schema definitions provided in this document include attribute 726 definitions, naming rules, and other definitions which are 727 designed to facilitate searching and browsing Internet resources. 729 The following resource definitions are provided in this section: 731 * Organizational and summary data. The inetResources object 732 class defines a variety of general-purpose attributes for 733 describing an organization and its resources. For example, 734 there is a free-text attribute which may be used to provide 735 general comments about the organization or the resources 736 under its control, attributes for providing general-use 737 postal and email addresses, and so forth. The inetResources 738 object class also defines several attributes which may be 739 used to provide attribute references for a variety of 740 administrative roles. 742 * DNS domains. The inetDnsDomain object class is subordinate 743 to the inetResources object class, providing attributes for 744 describing a particular DNS domain, and inheriting 745 attributes from the inetResources object class. 747 * IPv4 address blocks. The inetIpv4Network object class is 748 also subordinate to the inetResources object class, and 749 provides attributes related to the management of IPv4 750 networks in particular. 752 * IPv6 address blocks. The inetIpv6Network object class 753 provides summary data about IPv6 networks, similar to the 754 data provided by the inetIpv4Network object class. 756 * Autonomous system (AS) identifiers. IPv4 and IPv6 networks 757 can be collectively identified as a single autonomous 758 system (AS), thereby allowing groups of discontiguous 759 address blocks to be treated as a single managed entity. 760 The inetAsNumber object class provides attributes for these 761 AS numbers, and is also subordinate to the inetResources 762 object class. 764 * Associated objects. Internet resources are typically 765 assigned by independent entities, although there is often 766 an extensive amount of cross-pollination. For example, AS 767 Numbers are typically associated with IPv4 and IPv6 address 768 blocks, with this association being considered as a 769 mandatory linkage. However, less-formal associations also 770 often exist, such as a private organization associating an 771 IP address block with a specific DNS domain, or where a 772 regional authority is responsible for all domain name and 773 IP address delegations. Due to this flexibility, the LDAP- 774 WHOIS service provides an auxiliary object class for 775 associated objects which may be used with any of the 776 resource-specific object classes defined in this document. 778 * Persons. This document makes use of the inetOrgPerson 779 object class definition for the purpose of describing 780 people and administrative roles. 782 Each of the attributes and object classes listed above represent 783 the Internet-wide network resources which MAY be offered by an 784 LDAP-WHOIS server. It is expected that additional network resource 785 definitions will be provided by other documents. 787 5.1. The inetResources Object Class 789 The inetResources object class is a structural object class which 790 defines the attributes associated with a "cn=inetResources" 791 container entry, and which provides general information about the 792 network resources associated with the current DIT. 794 5.1.1. Naming syntax 796 This document requires the presence of an entry named 797 "cn=inetResources" in the root of every DIT which provides LDAP- 798 WHOIS services. 800 5.1.2. Schema definition 802 Every DIT which provides public LDAP-WHOIS data MUST have a 803 "cn=inetResources" entry in the root of the DIT. The inetResources 804 entry MUST exist with the top and inetResources object classes 805 defined. If the entry exists as a referral, the entry MUST also be 806 defined with the referral object class, in addition to the above 807 requirements. 809 The inetResources object class is a structural object class which 810 is subordinate to the top abstract class, and which MUST be 811 treated as a container class capable of holding additional 812 subordinate entries. The inetResources object class has one 813 mandatory attribute which is "cn" (the naming attribute), and also 814 has several optional attributes. Each of the other object classes 815 defined by this document are subordinate to the inetResources 816 object class and inherit the attributes defined for the 817 inetResources object class. 819 The inetResources object class is intended to provide summary 820 information about a collection of resources under the control of a 821 single organization or management body. For example, the mail 822 attribute is intended to be used as a general-purpose email 823 address for the organization as a whole (such as 824 "info@example.com"), rather than being used as an email address 825 for a particular administrative role. Because this object class is 826 also inherited by the resource-specific object classes, these 827 attributes can be defined at each of the subordinate entries if a 828 global set of values is undesirable or unfeasible. 830 The inetResources object class provides several multi-valued 831 contact-related attributes for a variety of well-known 832 administrative roles. This model allows the inetResources entry 833 and each of the subordinate managed resources to share a common 834 set of administrative roles, or to have unique roles for each 835 resource, as seen fit by the managing entity. The contact 836 attribute values follow the same rules as the labeledURI attribute 837 defined in RFC 2079, with additional restrictions as described in 838 section 4.5 of this document. 840 The various ModifiedBy and ModifiedDate attributes SHOULD be 841 treated as operational attributes. Their values SHOULD be filled 842 in automatically by the database management application, and 843 SHOULD NOT be returned except when explicitly requested. 845 Since multiple directory trees can share a single inetResources 846 entry (through the use of subordinate reference referrals), it is 847 important for the associated data to be applicable for all of the 848 objects which refer to it. For example, it would be effective for 849 a small private company to use a shared set of inetResources 850 attributes for their DNS domain names and IP network blocks, but 851 it would probably be counter-productive for a global ISP to share 852 contact data across all of their hosted domains and routed 853 networks. If separate contacts are required for each resource, the 854 contact data should be specified within each entry, rather than 855 being linked to the inetResources entry. 857 The schema definition for the inetResources object class is as 858 follows: 860 inetResources 861 ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The 862 inetResources container for the LDAP-WHOIS service' SUP top 863 STRUCTURAL MUST cn MAY ( o $ ou $ description $ 864 inetResourceComments $ businessCategory $ telephoneNumber $ 865 facsimileTelephoneNumber $ mail $ labeledURI $ 866 preferredDeliveryMethod $ physicalDeliveryOfficeName $ 867 postOfficeBox $ postalAddress $ postalCode $ street $ l $ 868 st $ c $ inetAbuseContacts $ inetAbuseContactsModifiedBy $ 869 inetAbuseContactsModifiedDate $ inetGeneralContacts $ 870 inetGeneralContactsModifiedBy $ 871 inetGeneralContactsModifiedDate $ inetSecurityContacts $ 872 inetSecurityContactsModifiedBy $ 873 inetSecurityContactsModifiedDate $ inetTechContacts $ 874 inetTechContactsModifiedBy $ inetTechContactsModifiedDate $ 875 inetGeneralDisclaimer ) ) 877 The attributes from the inetResources object class are described 878 below: 880 businessCategory, see RFC 2256, section 5.16 882 c (country), see RFC 2256, section 5.7 884 cn (commonName), see RFC 2256, section 5.4 886 description, see RFC 2256, section 5.14 888 facsimileTelephoneNumber, see RFC 2256, section 5.24 889 inetAbuseContacts 890 ( 1.3.6.1.4.1.7161.1.0.1 NAME 'inetAbuseContacts' DESC 891 'Contacts for reporting abusive behavior or acceptable-use 892 policy violations.' EQUALITY caseExactMatch SYNTAX 893 1.3.6.1.4.1.1466.115.121.1.15 ) 895 inetAbuseContactsModifiedBy 896 ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContactsModifiedBy' 897 DESC 'Person who last modified the inetAbuseContacts 898 attribute.' EQUALITY distinguishedNameMatch SYNTAX 899 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 900 distributedOperation ) 902 inetAbuseContactsModifiedDate 903 ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetAbuseContactsModifiedDate' 904 DESC 'Last modification date of the inetAbuseContacts 905 attribute.' EQUALITY generalizedTimeMatch ORDERING 906 generalizedTimeOrderingMatch SYNTAX 907 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 908 distributedOperation ) 910 inetGeneralContacts 911 ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetGeneralContacts' DESC 912 'Contacts for general administrative issues.' EQUALITY 913 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 915 inetGeneralContactsModifiedBy 916 ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetGeneralContactsModifiedBy' 917 DESC 'Person who last modified the inetGeneralContacts 918 attribute.' EQUALITY distinguishedNameMatch SYNTAX 919 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 920 distributedOperation ) 922 inetGeneralContactsModifiedDate 923 ( 1.3.6.1.4.1.7161.1.0.6 NAME 924 'inetGeneralContactsModifiedDate' DESC 'Last modification 925 date of the inetGeneralContacts attribute.' EQUALITY 926 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 927 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 928 distributedOperation ) 929 inetGeneralDisclaimer 930 ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC 931 'General disclaimer text regarding this data' EQUALITY 932 caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 933 ) 935 inetResourceComments 936 ( 1.3.6.1.4.1.7161.1.0.8 NAME 'inetResourceComments' DESC 937 'General comments about this entry' EQUALITY 938 caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 939 ) 941 inetSecurityContacts 942 ( 1.3.6.1.4.1.7161.1.0.9 NAME 'inetSecurityContacts' DESC 943 'Contacts for general security issues.' EQUALITY 944 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 946 inetSecurityContactsModifiedBy 947 ( 1.3.6.1.4.1.7161.1.0.10 NAME 948 'inetSecurityContactsModifiedBy' DESC 'Person who last 949 modified the inetSecurityContacts attribute.' EQUALITY 950 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 951 SINGLE-VALUE USAGE distributedOperation ) 953 inetSecurityContactsModifiedDate 954 ( 1.3.6.1.4.1.7161.1.0.11 NAME 955 'inetSecurityContactsModifiedDate' DESC 'Last modification 956 date of the inetSecurityContacts attribute.' EQUALITY 957 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 958 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 959 distributedOperation ) 961 inetTechContacts 962 ( 1.3.6.1.4.1.7161.1.0.12 NAME 'inetTechContacts' DESC 963 'Contacts for general technical issues.' EQUALITY 964 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 966 inetTechContactsModifiedBy 967 ( 1.3.6.1.4.1.7161.1.0.13 NAME 'inetTechContactsModifiedBy' 968 DESC 'Person who last modified the inetTechContacts 969 attribute.' EQUALITY distinguishedNameMatch SYNTAX 970 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 971 distributedOperation ) 972 inetTechContactsModifiedDate 973 ( 1.3.6.1.4.1.7161.1.0.14 NAME 'inetTechContactsModifiedDate' 974 DESC 'Last modification date of the inetTechContacts 975 attribute.' EQUALITY generalizedTimeMatch ORDERING 976 generalizedTimeOrderingMatch SYNTAX 977 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 978 distributedOperation ) 980 l (locality), see RFC 2256, section 5.8 982 labeledURI, see RFC 2079 984 mail, see RFC 2798, section 9.1.3 986 o (organization), see RFC 2256, section 5.11 988 ou (organizational unit), see RFC 2256, section 5.12 990 physicalDeliveryOfficeName, see RFC 2256, section 5.20 992 postalAddress, see RFC 2256, section 5.17 994 postalCode, see RFC 2256, section 5.18 996 postOfficeBox, see RFC 2256, section 5.19 998 preferredDeliveryMethod, see RFC 2256, section 5.29 1000 st (stateOrProvinceName), see RFC 2256, section 5.9 1002 street (streetAddress), see RFC 2256, section 5.10 1004 telephoneNumber, see RFC 2256, section 5.21 1006 5.1.3. Example 1008 An example of the inetResources object class in use is shown in 1009 Figure 3 below. 1011 Figure 3: The Example Widgets inetResources container entry. 1013 cn=inetResources,dc=example,dc=com 1014 [top object class] 1015 [inetResources object class] 1016 | 1017 +-attribute: o 1018 | value: "Example Widgets' network resources" 1019 | 1020 +-attribute: inetGeneralContacts 1021 | value: "ldap://ldap.example.com/cn=admins,ou=admins, 1022 | dc=example,dc=com" 1023 | 1024 +-attribute: telephoneNumber 1025 | value: "1-800-555-1212" 1026 | 1027 +-attribute: mail 1028 | value: "info@example.com" 1029 | 1030 +-attribute: inetResourceComments 1031 value: "Please don't send complaints to the 1032 postmaster@example.com mailbox." 1034 5.2. The inetDnsDomain Object Class 1036 The inetDnsDomain object class is a structural object class which 1037 provides administrative information about a specific DNS domain 1038 name resource, such as a zone, a well-known host, or some other 1039 network resource which is primarily identified by a domain name. 1041 5.2.1. Naming syntax 1043 The naming syntax for DNS domain entries MUST follow the form of 1044 "cn=,cn=inetResources,". Each DNS 1045 domain name which is managed as a discrete LDAP-WHOIS resource 1046 MUST have a dedicated entry in each of the DITs which provide 1047 public LDAP-WHOIS data for that resource. 1049 The inetDnsDomainSyntax component of an entry is subject to DN 1050 rules, although the inetDnsDomainSyntax is also used for extended 1051 search operations, and is therefore subject to specific syntax 1052 rules. The basic rules for this format are that domain names MUST 1053 be stored as sequences of labels, where each label consists of a 1054 maximum of 63 characters, with each label being separated by a 1055 full-stop (period) character, and with the entire domain name 1056 sequence being a maximum of 255 characters. 1058 For example, the "www.example.com" DNS domain name resource stored 1059 in the "dc=example,dc=com" DIT would be represented as an entry 1060 named "cn=www.example.com,cn=inetResources,dc=example,dc=com", 1061 while the "2.0.192.in-addr.arpa" reverse-lookup domain which was 1062 stored in the "dc=example,dc=com" DIT would be named 1063 "cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com". 1065 Note that the domain name syntax rules defined by STD 13 allow any 1066 eight-bit character code to be used within any domain name, 1067 although the host naming rules defined by RFC 952, STD 13 and STD 1068 3 only allow a subset of the printable characters from US-ASCII to 1069 be used for domain names which specify connection targets. 1070 However, many domain names will need to be queried which will not 1071 conform to the host naming rules ("_ldap._tcp.example.com" might 1072 be specified in a search, for example), so any eight-bit character 1073 MUST be considered valid for this service. 1075 RFC 2253 defines several escaping mechanisms for use when handling 1076 certain "special" characters, and these mechanisms MUST be used 1077 whenever a character in a domain name needs to be escaped in order 1078 for an assertion value to be parsed. However, STD 13 also allows 1079 the use of special characters, and also provides several 1080 mechanisms for escaping special characters in DNS domain names, 1081 and these rules MUST also be accommodated if valid DNS names are 1082 to be supported. 1084 In order to facilitate this potential overlap while minimizing 1085 confusion during handling, LDAP-WHOIS clients MUST allow DNS 1086 domain name query strings to be entered as raw eight-bit data, but 1087 if any of the characters need to be escaped for the assertion 1088 value to be properly built, then the client MUST escape these 1089 characters before the search is submitted. 1091 Secondarily, if the user needs to search for a DNS domain name 1092 which would normally require escaping or other special handling in 1093 order for the domain name to be processed, then the user MUST 1094 provide the domain name in its escaped form. By extension, this 1095 also means that these DNS domain names MUST be stored as RDNs in 1096 their escaped form. 1098 STD 13 and RFC 2253 both use a common method of escaping special 1099 characters with a reverse solidus (backslash) character, with 1100 either the special character or a two-digit decimal code for that 1101 character immediately following the reverse solidus. 1103 For example, if a user needs to specify the domain name of 1104 "weird name.example.com" (where "weird name" is a valid domain 1105 name label with an embedded space), then the domain name would 1106 have an RDN of "cn=weird\32name.example.com" in the directory, and 1107 would have to be entered into the client as a search for 1108 "weird\32name.example.com". The client would then perform a 1109 secondary escape to form "weird\\32name.example.com" as the 1110 assertion value, and this secondary escape would be removed by the 1111 LDAP-WHOIS server upon receipt. Thus a match would be found. 1113 NOTE: Remember that IPv4 addresses are also stored in DNS 1114 for reverse-lookup purposes, and the associated zones and 1115 PTR domain names may also require escaping, particularly 1116 when used with site-specific CIDR notation. 1118 The common reference to the root domain is a single full-stop 1119 (".") character, and this usage is also endorsed by this document 1120 when the root domain name needs to be explicitly queried. For any 1121 domain name which contains a non-root label, the trailing period 1122 which normally signifies the root domain MUST be omitted. The 1123 maximum size of a valid DNS domain name is 255 characters (this 1124 limit applies to the unescaped assertion value). Clients MUST 1125 restrict input to this range, prior to submitting the LDAP query. 1127 The domain name component of the DN MUST match the domain name of 1128 the managed resource exactly as the domain name exists in the DNS 1129 namespace. For example, if an organization wishes to provide 1130 information about "www.example.com", then a RDN entry would need 1131 to exist for "cn=www.example.com". If an organization wishes to 1132 provide information about the "www.example.com" canonical target 1133 "server1.example.net", then a RDN for "cn=server1.example.net" 1134 would need to exist. If an organization wishes to provide 1135 information about "server1.example.net" whenever a query is 1136 received for "www.example.com", then the "cn=www.example.com" 1137 entry would need to be defined as a subordinate reference 1138 referral, with the ref attribute pointing to the 1139 "cn=server1.example.net" entry. 1141 This usage model also applies to reverse-lookup domains. If an 1142 organization is the authority for the "2.0.192.in-addr.arpa" 1143 reverse-lookup domain associated with an IPv4 network (this is 1144 different from providing information about the network block in 1145 particular, as is discussed separately in section 5.3), then that 1146 syntax would also be used to form the RDN for the associated 1147 inetDnsDomain entry. 1149 Note that reverse-lookup domain names are mapped directly as they 1150 exist in the public DNS namespace. If a /24 IPv4 network block 1151 such as 192.0.2.0 has been delegated to an organization, the 1152 default controlling domain name of the reverse-lookup zone will be 1153 2.0.192.in-addr.arpa, and the name of the associated LDAP-WHOIS 1154 entry would be "cn=2.0.192.in-addr.arpa". However, if that network 1155 had been delegated to an ISP who had in turn delegated the 1156 192.0.2.0/29 address block and an associated reverse-lookup zone 1157 of 29-0.2.0.192.in-addr.arpa to a user, then the associated LDAP- 1158 WHOIS entry for that zone would be "cn=29-0.2.0.192.in-addr.arpa". 1160 5.2.2. Schema definition 1162 DNS domain name entries MUST exist with the top, inetResources and 1163 inetDnsDomain object classes defined. If an entry exists as a 1164 referral, the entry MUST also be defined with the referral object 1165 class, in addition to the above requirements. 1167 The inetDnsDomain object class is a structural object class which 1168 is subordinate to the inetResources object class, and which MUST 1169 be treated as a container class capable of holding additional 1170 subordinate entries. The inetDnsDomain object class has no 1171 mandatory attributes, although it does have several optional 1172 attributes. 1174 The inetDnsDomain object class defines attributes which are 1175 specific to DNS domains, particularly as this relates to domain 1176 delegation (DNS operational information is available through DNS 1177 itself). This includes information such as the delegation date and 1178 the status of the delegation. The inetDnsDomain object class is 1179 subordinate to the inetResources object class, so it inherits 1180 those attributes as well. 1182 Some of the inetDnsDomain object class attributes define contact- 1183 related referrals which provide LDAP URLs that refer to 1184 inetOrgPerson entries, and these entries will need to be queried 1185 separately if detailed information about a particular contact is 1186 required. The contact attribute values follow the same rules as 1187 the labeledURI attribute defined in RFC 2079, with additional 1188 restrictions as described in section 4.5 of this document. 1190 The various ModifiedBy and ModifiedDate attributes SHOULD be 1191 treated as operational attributes. Their values SHOULD be filled 1192 in automatically by the database management application, and 1193 SHOULD NOT be returned except when explicitly requested. 1195 The schema definition for the inetDnsDomain object class is as 1196 follows: 1198 inetDnsDomain 1199 ( 1.3.6.1.4.1.7161.1.1.0 NAME 'inetDnsDomain' DESC 'DNS 1200 domain attributes.' SUP inetResources STRUCTURAL MAY ( 1201 inetDnsDelegationStatus $ inetDnsDelegationDate $ 1202 inetDnsDelegationModifiedDate $ inetDnsDelegationModifiedBy 1203 $ inetDnsContacts $ inetDnsContactsModifiedBy $ 1204 inetDnsContactsModifiedDate $ inetDnsAuthServers ) ) 1206 The attributes from the inetDnsDomain object class are described 1207 below: 1209 inetDnsAuthServers 1210 ( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsAuthServers' DESC 1211 'Authoritative DNS servers for this domain.' EQUALITY 1212 caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1214 The inetDnsAuthServers attribute provides a read-only 1215 summary of the authoritative servers associated with the 1216 zone. The attribute is defined as multi-valued, with each 1217 attribute value currently (tentatively) being defined as: 1219 domain.dom [address/prefix] 1221 where "domain.dom" is the domain name of the authoritative 1222 server, written as an inetDnsDomainSyntax string, and where 1223 "address/prefix" is an IPv4 or IPv6 host-specific network 1224 address, written as either an inetIpv4NetworkSyntax or 1225 inetIpv6NetworkSyntax string. Clients that wish to obtain 1226 additional information about the listed servers can issue 1227 new queries for either the domain name or address syntax. 1229 NOTE: THIS IS A TEMPORARY ATTRIBUTE WHICH WILL EVENTUALLY 1230 BE REPLACED WITH GENERALIZED RESOURCE-RECORD ENTRIES AND 1231 ATTRIBUTES. 1233 inetDnsContacts 1234 ( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContacts' DESC 1235 'Contacts for reporting problems with this domain name.' 1236 EQUALITY caseExactMatch SYNTAX 1237 1.3.6.1.4.1.1466.115.121.1.15 ) 1239 inetDnsContactsModifiedBy 1240 ( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsContactsModifiedBy' 1241 DESC 'Person who last modified the inetDnsContacts 1242 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1243 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1244 distributedOperation ) 1246 inetDnsContactsModifiedDate 1247 ( 1.3.6.1.4.1.7161.1.1.5 NAME 'inetDnsContactsModifiedDate' 1248 DESC 'Last modification date of the inetDnsContacts 1249 attribute.' EQUALITY generalizedTimeMatch ORDERING 1250 generalizedTimeOrderingMatch SYNTAX 1251 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1252 distributedOperation ) 1254 inetDnsDelegationDate 1255 ( 1.3.6.1.4.1.7161.1.1.6 NAME 'inetDnsDelegationDate' DESC 1256 'Date of original delegation.' EQUALITY 1257 GeneralizedTimeMatch ORDERING generalizedTimeOrderingMatch 1258 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 1260 inetDnsDelegationModifiedBy 1261 ( 1.3.6.1.4.1.7161.1.1.7 NAME 'inetDnsDelegationModifiedBy' 1262 DESC 'Person who last modified the inetDnsDelegationStatus 1263 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1264 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1265 distributedOperation ) 1267 inetDnsDelegationModifiedDate 1268 ( 1.3.6.1.4.1.7161.1.1.8 NAME 'inetDnsDelegationModifiedDate' 1269 DESC 'Last modification date of the inetDnsDelegationStatus 1270 attribute.' EQUALITY generalizedTimeMatch ORDERING 1271 generalizedTimeOrderingMatch SYNTAX 1272 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1273 distributedOperation ) 1275 inetDnsDelegationStatus 1276 ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDelegationStatus' DESC 1277 'Current delegation status code for this domain.' EQUALITY 1278 numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} 1279 SINGLE-VALUE ) 1281 NOTE: In an effort to facilitate internationalization and 1282 programmatic processing, the current status of a delegation 1283 is identified by a 16-bit integer. The values and status 1284 mapping is as follows: 1286 0 Reserved delegation (permanently inactive) 1287 1 Assigned and active (normal state) 1288 2 Assigned but not yet active (new delegation) 1289 3 Assigned but on hold (disputed) 1290 4 Assignment revoked (database purge pending) 1292 Additional values for the inetDnsDelegationStatus attribute 1293 are reserved for future use, and are to be administered by 1294 IANA. Note that there is no status code for "unassigned"; 1295 unassigned entries SHOULD NOT exist, and SHOULD NOT be 1296 returned as answers. 1298 The inetDnsDomainSyntax syntax is as follows: 1300 inetDnsDomainSyntax 1301 ( 1.3.6.1.4.1.7161.1.1.1 NAME 'inetDnsDomainSyntax' DESC 'A 1302 fully-qualified DNS domain name.' ) 1304 5.2.3. Example 1306 An example of the inetDnsDomain object class in use is shown in 1307 Figure 4 below, with some additional attributes inherited from the 1308 parent inetResources entry. This query is most likely being sent 1309 to the LDAP servers responsible for operating the "example.com" 1310 DNS domain. 1312 Figure 4: The example.com inetDnsDomain entry. 1314 cn=example.com,cn=inetResources,dc=example,dc=com 1315 [top object class] 1316 [inetResources object class] 1317 [inetDnsDomain object class] 1318 | 1319 +-attribute: description 1320 | value: "The example.com DNS domain" 1321 | 1322 +-attribute: inetDnsContacts 1323 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 1324 | dc=example,dc=com" 1325 | 1326 +-attribute: inetGeneralContacts 1327 value: "ldap://ldap.example.com/cn=admins,ou=admins, 1328 dc=example,dc=com" 1330 5.3. The inetIpv4Network Object Class 1332 The inetIpv4Network object class is a structural object class 1333 which provides administrative information about a specific IPv4 1334 address and an associated subnet prefix (this pairing is most 1335 often used to represent the starting address of an IPv4 network, 1336 but can also be used to identify a specific host). 1338 5.3.1. Naming syntax 1340 The naming syntax for IPv4 network entries MUST follow the form of 1341 "cn=,cn=inetResources,". Each IPv4 1342 network address which is managed as a discrete LDAP-WHOIS network 1343 resource MUST have a dedicated entry in each of the DITs which 1344 provide public LDAP-WHOIS data regarding that network address. 1346 The inetIpv4NetworkSyntax component of an entry is subject to DN 1347 rules, although the inetIpv4NetworkSyntax is also used for 1348 extended search operations, and is therefore subject to specific 1349 syntax rules. The inetIpv4NetworkSyntax specifically requires the 1350 use of the starting address from a range of inclusive addresses, 1351 and specifically requires the use of CIDR prefix annotation. In 1352 this manner, it is possible to create an inetIpv4Network entry for 1353 a range of addresses (by specifying the starting address and the 1354 network prefix size), or a single host (by specifying the host- 1355 specific address and a /32 prefix). 1357 In this definition, inetIpv4NetworkSyntax uses the traditional 1358 "dotted-quad" notation, where each of four sub-components provide 1359 a decimal value that represents one octet from a 32-bit IPv4 1360 address, with the sub-components being separated by a full-stop 1361 (period) character, and with the four-part sequence being followed 1362 by a "/" character and a three-digit decimal "prefix" value. An 1363 augmented BNF for this syntax is as follows: 1365 inetIpv4NetworkSyntax = vFourPart "." vFourPart "." vFourPart 1366 "." vFourPart "/" vFourPrefix 1368 vFourPart = decimal value between "0" and "255" inclusive, 1369 with the non-affective leading zeroes removed 1371 vFourPrefix = decimal value between "1" and "32" inclusive, 1372 with the non-affective leading zeroes removed 1374 For example, an IPv4 network with a range of addresses between 1375 "10.0.0.0" and "10.0.255.255" inclusive would be written as 1376 "10.0.0.0/16", and would appear with an RDN of "cn=10.0.0.0/16". 1377 Similarly, a host address of "192.0.2.14" would have the RDN of 1378 "cn=192.0.2.14/32". 1380 The leading zeroes from each octet MUST be removed during query 1381 string formation. Octets which have a value of zero MUST be 1382 represented by the single-digit numeric value of "0". 1384 Note that the use of "/" is illegal in LDAP URLs when it is 1385 provided as data (in particular, URLs use this character as a part 1386 delimiter). This character MUST be escaped as "%2F" when it is 1387 provided as part of an inetIpv4Network entry in a ref attribute. 1389 5.3.2. Schema definition 1391 IPv4 network entries MUST exist with the top, inetResources and 1392 inetIpv4Network object classes defined. If an entry exists as a 1393 referral, the entry MUST also be defined with the referral object 1394 class, in addition to the above requirements. 1396 The inetIpv4Network object class is a structural object class 1397 which is subordinate to the inetResources object class, and which 1398 MUST be treated as a container class capable of holding additional 1399 subordinate entries. The inetIpv4Network object class has no 1400 mandatory attributes, although it does have several optional 1401 attributes. 1403 The inetIpv4Network object class defines attributes which are 1404 specific to IPv4 networks, such as the delegation date and the 1405 status of the delegation. The inetIpv4Network object class is 1406 subordinate to the inetResources object class, so it inherits 1407 those attributes as well. 1409 Some of the inetIpv4Network object class attributes define 1410 contact-related referrals which provide LDAP URLs that refer to 1411 inetOrgPerson entries, and these entries will need to be queried 1412 separately if detailed information about a particular contact is 1413 required. The contact attribute values follow the same rules as 1414 the labeledURI attribute defined in RFC 2079, with additional 1415 restrictions as described in section 4.5 of this document. 1417 The various ModifiedBy and ModifiedDate attributes SHOULD be 1418 treated as operational attributes. Their values SHOULD be filled 1419 in automatically by the database management application, and 1420 SHOULD NOT be returned except when explicitly requested. 1422 The schema definition for the inetIpv4Network object class is as 1423 follows: 1425 inetIpv4Network 1426 ( 1.3.6.1.4.1.7161.1.2.0 NAME 'inetIpv4Network' DESC 'IPv4 1427 network attributes.' SUP inetResources STRUCTURAL MAY ( 1428 inetIpv4DelegationStatus $ inetIpv4DelegationDate $ 1429 inetIpv4DelegationModifiedDate $ 1430 inetIpv4DelegationModifiedBy $ inetIpv4Contacts $ 1431 inetIpv4ContactsModifiedBy $ inetIpv4ContactsModifiedDate $ 1432 inetIpv4RoutingContacts $ inetIpv4RoutingContactsModifiedBy 1433 $ inetIpv4RoutingContactsModifiedDate ) ) 1435 The attributes from the inetIpv4Network object class are described 1436 below: 1438 inetIpv4Contacts 1439 ( 1.3.6.1.4.1.7161.1.2.2 NAME 'inetIpv4Contacts' DESC 1440 'Contacts for reporting problems with this IPv4 network.' 1441 EQUALITY caseExactMatch SYNTAX 1442 1.3.6.1.4.1.1466.115.121.1.15 ) 1444 inetIpv4ContactsModifiedBy 1445 ( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4ContactsModifiedBy' 1446 DESC 'Person who last modified the inetIpv4Contacts 1447 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1448 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1449 distributedOperation ) 1450 inetIpv4ContactsModifiedDate 1451 ( 1.3.6.1.4.1.7161.1.2.4 NAME 'inetIpv4ContactsModifiedDate' 1452 DESC 'Last modification date of the inetIpv4Contacts 1453 attribute.' EQUALITY generalizedTimeMatch ORDERING 1454 generalizedTimeOrderingMatch SYNTAX 1455 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1456 distributedOperation ) 1458 inetIpv4DelegationDate 1459 ( 1.3.6.1.4.1.7161.1.2.5 NAME 'inetIpv4DelegationDate' DESC 1460 'Date of original delegation.' EQUALITY 1461 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 1462 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 1464 inetIpv4DelegationModifiedBy 1465 ( 1.3.6.1.4.1.7161.1.2.6 NAME 'inetIpv4DelegationModifiedBy' 1466 DESC 'Person who last modified the inetIpv4DelegationStatus 1467 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1468 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1469 distributedOperation ) 1471 inetIpv4DelegationModifiedDate 1472 ( 1.3.6.1.4.1.7161.1.2.7 NAME 1473 'inetIpv4DelegationModifiedDate' DESC 'Last modification 1474 date of the inetIpv4DelegationStatus attribute.' EQUALITY 1475 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 1476 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1477 distributedOperation ) 1479 inetIpv4DelegationStatus 1480 ( 1.3.6.1.4.1.7161.1.2.8 NAME 'inetIpv4DelegationStatus' DESC 1481 'Current delegation status code for this network.' EQUALITY 1482 numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} 1483 SINGLE-VALUE ) 1484 NOTE: In an effort to facilitate internationalization and 1485 programmatic processing, the current status of a delegation 1486 is identified by a 16-bit integer. The values and status 1487 mapping is as follows: 1489 0 Reserved delegation (permanently inactive) 1490 1 Assigned and active (normal state) 1491 2 Assigned but not yet active (new delegation) 1492 3 Assigned but on hold (disputed) 1493 4 Assignment revoked (database purge pending) 1495 Additional values for the inetIpv4DelegationStatus 1496 attribute are reserved for future use, and are to be 1497 administered by IANA. Note that there is no status code for 1498 "unassigned"; unassigned entries SHOULD NOT exist, and 1499 SHOULD NOT be returned as answers. 1501 inetIpv4RoutingContacts 1502 ( 1.3.6.1.4.1.7161.1.2.9 NAME 'inetIpv4RoutingContacts' DESC 1503 'Contacts for routing issues with this IPv4 network.' 1504 EQUALITY caseExactMatch SYNTAX 1505 1.3.6.1.4.1.1466.115.121.1.15 ) 1507 inetIpv4RoutingContactsModifiedBy 1508 ( 1.3.6.1.4.1.7161.1.2.10 NAME 1509 'inetIpv4RoutingContactsModifiedBy' DESC 'Person who last 1510 modified the inetIpv4RoutingContacts attribute.' EQUALITY 1511 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1512 SINGLE-VALUE USAGE distributedOperation ) 1514 inetIpv4RoutingContactsModifiedDate 1515 ( 1.3.6.1.4.1.7161.1.2.11 NAME 1516 'inetIpv4RoutingContactsModifiedDate' DESC 'Last 1517 modification date of the inetIpv4RoutingContacts 1518 attribute.' EQUALITY generalizedTimeMatch ORDERING 1519 generalizedTimeOrderingMatch SYNTAX 1520 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1521 distributedOperation ) 1522 The inetIpv4NetworkSyntax syntax is as follows: 1524 inetIpv4NetworkSyntax 1525 ( 1.3.6.1.4.1.7161.1.2.1 NAME 'inetIpv4NetworkSyntax' DESC 1526 'An IPv4 address and prefix.' ) 1528 5.3.3. Example 1530 An example of the inetIpv4Network object class is shown in Figure 1531 5 below, with attributes from the inetResources object class also 1532 being used to provide administrative contacts. This data is a 1533 result of a query which was sent to the LDAP servers responsible 1534 for operating the "192.0.2.0/24" network block. 1536 Figure 5: The 192.0.2.0/24 inetIpv4Network entry. 1538 cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 1539 [top object class] 1540 [inetResources object class] 1541 [inetIpv4Network object class] 1542 | 1543 +-attribute: description 1544 | value: "The example.com network" 1545 | 1546 +-attribute: inetIpv4Contacts 1547 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 1548 | dc=example,dc=com" 1549 | 1550 +-attribute: inetGeneralContacts 1551 value: "ldap://ldap.example.com/cn=admins,ou=admins, 1552 dc=example,dc=com" 1554 As stated earlier, reverse-lookup DNS domains for IPv4 address 1555 blocks are managed as inetDnsDomain object class entries. These 1556 are entirely different network resources, and should not be 1557 confused with inetIpv4Network object class entries. 1559 5.4. The inetIpv6Network Object Class 1561 The inetIpv6Network object class is a structural object class 1562 which provides administrative information about a specific IPv6 1563 address and an associated subnet prefix (this pairing is most 1564 often used to represent the starting address of an IPv6 network, 1565 but can also be used to identify a specific host). 1567 5.4.1. Naming syntax 1569 The naming syntax for IPv6 network entries MUST follow the form of 1570 "cn=,cn=inetResources,". Each IPv6 1571 network address which is managed as a discrete LDAP-WHOIS network 1572 resource MUST have a dedicated entry in each of the DITs which 1573 provide public LDAP-WHOIS data regarding that network address. 1575 The inetIpv6NetworkSyntax component of an entry is subject to DN 1576 rules, although the inetIpv6NetworkSyntax is also used for 1577 extended search operations, and is therefore subject to specific 1578 syntax rules. This syntax specifically requires the use of the 1579 starting address from a range of inclusive addresses, and 1580 specifically requires the use of the common IPv6 prefix 1581 annotation. In this manner, it is possible to create an 1582 inetIpv6Network entry for a range of addresses (by specifying the 1583 starting address and the network prefix size), or a single host 1584 (by specifying the host-specific address and a /128 prefix). 1586 In this definition, the inetIpv6NetworkSyntax uses the 1587 uncompressed, 32-nibble IPv6 addressing syntax, where the network 1588 address consists of eight sub-components, with each sub-component 1589 consisting of four hexadecimal values that represent one nibble, 1590 with each sub-component being separated by a colon character, and 1591 with the entire sequence being followed by a "/" character and a 1592 three-digit decimal "prefix" value. An augmented BNF for this 1593 syntax is as follows: 1595 inetIpv6NetworkSyntax = vSixPart ":" vSixPart ":" vSixPart 1596 ":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":" 1597 vSixPart "/" vSixPrefix 1599 vSixPart = 4*4nibblePart 1601 nibblePart = hexadecimal digit between "0" and "F" inclusive 1603 vSixPrefix = decimal value between "1" and "128" inclusive, 1604 with the non-affective leading zeroes removed 1605 For example, an IPv6 network with a range of addresses between 1606 "3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff" 1607 inclusive would have a RDN of 1608 "cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". Similarly, a host 1609 address of "3ffe:ffff::1:2:3:4" would have the RDN of 1610 "cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128". 1612 Each of the 16-bit colon-separated values MUST be written in the 1613 uncompressed form. Nibbles with a value of zero MUST be 1614 represented by the hexadecimal sequence of "0000". 1616 Note that the use of "/" is illegal in LDAP URLs when it is 1617 provided as data (in particular, URLs use this character as a part 1618 delimiter). This character MUST be escaped as "%2F" when it is 1619 provided as part of an inetIpv6Network entry in a ref attribute. 1621 5.4.2. Schema Definition 1623 IPv6 network entries MUST exist with the top, inetResources and 1624 inetIpv6Network object classes defined. If an entry exists as a 1625 referral, the entry MUST also be defined with the referral object 1626 class, in addition to the above requirements. 1628 The inetIpv6Network object class is a structural object class 1629 which is subordinate to the inetResources object class, and which 1630 MUST be treated as a container class capable of holding additional 1631 subordinate entries. The inetIpv6Network object class has no 1632 mandatory attributes, although it does have several optional 1633 attributes. 1635 The inetIpv6Network object class defines attributes which are 1636 specific to IPv6 networks, such as the delegation date and the 1637 status of the delegation. The inetIpv6Network object class is 1638 subordinate to the inetResources object class, so it inherits 1639 those attributes as well. 1641 Some of the inetIpv6Network object class attributes define 1642 contact-related referrals which provide LDAP URLs that refer to 1643 inetOrgPerson entries, and these entries will need to be queried 1644 separately if detailed information about a particular contact is 1645 required. The contact attribute values follow the same rules as 1646 the labeledURI attribute defined in RFC 2079, with additional 1647 restrictions as described in section 4.5 of this document. 1649 The various ModifiedBy and ModifiedDate attributes SHOULD be 1650 treated as operational attributes. Their values SHOULD be filled 1651 in automatically by the database management application, and 1652 SHOULD NOT be returned except when explicitly requested. 1654 The schema definition for the inetIpv6Network object class is as 1655 follows: 1657 inetIpv6Network 1658 ( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetIpv6Network' DESC 'IPv6 1659 network attributes.' SUP inetResources STRUCTURAL MAY ( 1660 inetIpv6DelegationStatus $ inetIpv6DelegationDate $ 1661 inetIpv6DelegationModifiedDate $ 1662 inetIpv6DelegationModifiedBy $ inetIpv6Contacts $ 1663 inetIpv6ContactsModifiedBy $ inetIpv6ContactsModifiedDate $ 1664 inetIpv6RoutingContacts $ inetIpv6RoutingContactsModifiedBy 1665 $ inetIpv6RoutingContactsModifiedDate ) ) 1667 The attributes from the inetIpv6Network object class are described 1668 below: 1670 inetIpv6Contacts 1671 ( 1.3.6.1.4.1.7161.1.3.2 NAME 'inetIpv6Contacts' DESC 1672 'Contacts for reporting problems with this network.' 1673 EQUALITY caseExactMatch SYNTAX 1674 1.3.6.1.4.1.1466.115.121.1.15 ) 1676 inetIpv6ContactsModifiedBy 1677 ( 1.3.6.1.4.1.7161.1.3.3 NAME 'inetIpv6ContactsModifiedBy' 1678 DESC 'Person who last modified the inetIpv6Contacts 1679 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1680 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1681 distributedOperation ) 1683 inetIpv6ContactsModifiedDate 1684 ( 1.3.6.1.4.1.7161.1.3.4 NAME 'inetIpv6ContactsModifiedDate' 1685 DESC 'Last modification date of the inetIpv6Contacts 1686 attribute.' EQUALITY generalizedTimeMatch ORDERING 1687 generalizedTimeOrderingMatch SYNTAX 1688 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1689 distributedOperation ) 1690 inetIpv6DelegationDate 1691 ( 1.3.6.1.4.1.7161.1.3.5 NAME 'inetIpv6DelegationDate' DESC 1692 'Date of original delegation.' EQUALITY 1693 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 1694 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 1696 inetIpv6DelegationModifiedBy 1697 ( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6DelegationModifiedBy' 1698 DESC 'Person who last modified the inetIpv6DelegationStatus 1699 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1700 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1701 distributedOperation ) 1703 inetIpv6DelegationModifiedDate 1704 ( 1.3.6.1.4.1.7161.1.3.7 NAME 1705 'inetIpv6DelegationModifiedDate' DESC 'Last modification 1706 date of the inetIpv6DelegationStatus attribute.' EQUALITY 1707 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 1708 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1709 distributedOperation ) 1711 inetIpv6DelegationStatus 1712 ( 1.3.6.1.4.1.7161.1.3.8 NAME 'inetIpv6DelegationStatus' DESC 1713 'Current delegation status code for this network.' EQUALITY 1714 numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} 1715 SINGLE-VALUE ) 1717 NOTE: In an effort to facilitate internationalization and 1718 programmatic processing, the current status of a delegation 1719 is identified by a 16-bit integer. The values and status 1720 mapping is as follows: 1722 0 Reserved delegation (permanently inactive) 1723 1 Assigned and active (normal state) 1724 2 Assigned but not yet active (new delegation) 1725 3 Assigned but on hold (disputed) 1726 4 Assignment revoked (database purge pending) 1728 Additional values for the inetIpv6DelegationStatus 1729 attribute are reserved for future use, and are to be 1730 administered by IANA. Note that there is no status code for 1731 "unassigned"; unassigned entries SHOULD NOT exist, and 1732 SHOULD NOT be returned as answers. 1734 inetIpv6RoutingContacts 1735 ( 1.3.6.1.4.1.7161.1.3.9 NAME 'inetIpv6RoutingContacts' DESC 1736 'Contacts for routing issues with this network.' EQUALITY 1737 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1739 inetIpv6RoutingContactsModifiedBy 1740 ( 1.3.6.1.4.1.7161.1.3.10 NAME 1741 'inetIpv6RoutingContactsModifiedBy' DESC 'Person who last 1742 modified the inetIpv6RoutingContacts attribute.' EQUALITY 1743 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1744 SINGLE-VALUE USAGE distributedOperation ) 1746 inetIpv6RoutingContactsModifiedDate 1747 ( 1.3.6.1.4.1.7161.1.3.11 NAME 1748 'inetIpv6RoutingContactsModifiedDate' DESC 'Last 1749 modification date of the inetIpv6RoutingContacts 1750 attribute.' EQUALITY generalizedTimeMatch ORDERING 1751 generalizedTimeOrderingMatch SYNTAX 1752 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1753 distributedOperation ) 1755 The inetIpv6NetworkSyntax syntax is as follows: 1757 inetIpv6NetworkSyntax 1758 ( 1.3.6.1.4.1.7161.1.3.1 NAME 'inetIpv6NetworkSyntax' DESC 1759 'An IPv6 address and prefix.' ) 1761 5.4.3. Example 1763 An example of the inetIpv6Network object class is shown in Figure 1764 6 below, with attributes from the inetResources object class also 1765 being used to provide administrative contacts. This data is a 1766 result of a query which was sent to the LDAP servers responsible 1767 for operating the ip6.arpa delegation domain. 1769 Figure 6: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32 1770 inetIpv6Network delegation entry. 1772 cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32, 1773 cn=inetResources,dc=ip6,dc=arpa 1774 [top object class] 1775 [inetResources object class] 1776 [inetIpv6Network object class] 1777 | 1778 +-attribute: description 1779 | value: "The example.net top-level network" 1780 | 1781 +-attribute: inetIpv6Contacts 1782 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 1783 | dc=example,dc=net" 1784 | 1785 +-attribute: inetGeneralContacts 1786 value: "ldap://ldap.example.com/cn=admins,ou=admins, 1787 dc=example,dc=net" 1789 Reverse-lookup DNS domains for IPv6 address blocks are managed as 1790 inetDnsDomain object class entries which are entirely different 1791 network resources, and which should not be confused with the 1792 inetIpv6Network object class entries. Note that due to the 128-bit 1793 address size and the structuring rules defined in RFC 1886, a 1794 fully-formed IPv6 reverse-lookup domain name will have 34 labels, 1795 which can result in very large distinguished names. 1797 5.5. The inetAsNumber Object Class 1799 The inetAsNumber object class is a structural object class which 1800 provides administrative information about a specific autonomous 1801 system (AS) number. AS numbers are used to identify routing 1802 domains, allowing multiple discontiguous IPv4 and IPv6 network 1803 blocks to be referenced with a single, globally-unique identifier. 1805 5.5.1. Naming syntax 1807 The naming syntax for AS number entries MUST follow the form of 1808 "cn=,cn=inetResources,". Each AS 1809 number which is managed as a discrete LDAP-WHOIS network resource 1810 MUST have a dedicated entry in each of the DITs which provide 1811 public LDAP-WHOIS data regarding that autonomous system. 1813 The inetAsNumberSyntax component of an entry is subject to DN 1814 rules, although the inetAsNumberSyntax is also used for search and 1815 compare operations, and is therefore subject to specific syntax 1816 rules. The AS number syntax uses the decimal equivalent of a 16- 1817 bit autonomous system number, with the non-affective leading 1818 zeroes removed. An augmented BNF for this syntax is as follows: 1820 inetAsNumberSyntax = decimal value between "0" and "65535" 1821 inclusive, with the non-affective leading zeroes removed 1823 For example, an entry for AS number "1" from the "dc=arin,dc=net" 1824 DIT would have a DN of "cn=1,cn=inetResources,dc=arin,dc=net", 1825 while an entry for AS number "65535" from the same DIT would have 1826 a DN of "cn=65535,cn=inetResources,dc=arin,dc=net". 1828 5.5.2. Schema definition 1830 AS number entries MUST exist with the top, inetResources and 1831 inetAsNumber object classes defined. If an entry exists as a 1832 referral, the entry MUST also be defined with the referral object 1833 class, in addition to the above requirements. 1835 The inetAsNumber object class is a structural object class which 1836 is subordinate to the inetResources object class, and which MUST 1837 be treated as a container class capable of holding additional 1838 subordinate entries. The inetAsNumber object class has no 1839 mandatory attributes, although it does have several optional 1840 attributes. 1842 The inetAsNumber object class defines attributes which are 1843 specific to autonomous systems and their associated routing 1844 domains, such as the delegation date, and the status of the 1845 delegation. The inetAsNumber object class is subordinate to the 1846 inetResources object class, so it inherits those attributes as 1847 well. 1849 Some of the inetAsNumber object class attributes define contact- 1850 related referrals which provide LDAP URLs that refer to 1851 inetOrgPerson entries, and these entries will need to be queried 1852 separately if detailed information about a particular contact is 1853 required. The contact attribute values follow the same rules as 1854 the labeledURI attribute defined in RFC 2079, with additional 1855 restrictions as described in section 4.5 of this document. 1857 The various ModifiedBy and ModifiedDate attributes SHOULD be 1858 treated as operational attributes. Their values SHOULD be filled 1859 in automatically by the database management application, and 1860 SHOULD NOT be returned except when explicitly requested. 1862 The network-specific attributes MUST only contain network 1863 addresses which are directly associated with the AS number, and 1864 MUST use the largest superior prefix delegated to those networks 1865 (using the inetIpv4NetworkSyntax and inetIpv6NetworkSyntax rules); 1866 these attributes MUST NOT contain host or subnet addresses which 1867 are subordinate to another value which is already listed, and 1868 these attributes MUST NOT contain network addresses of networks 1869 which are associated with any other AS number. 1871 The schema definition for the inetAsNumber object class is as 1872 follows: 1874 inetAsNumber 1875 ( 1.3.6.1.4.1.7161.1.4.0 NAME 'inetAsNumber' DESC 'Autonomous 1876 system attributes.' SUP inetResources STRUCTURAL MAY ( 1877 inetAsnDelegationStatus $ inetAsnDelegationDate $ 1878 inetAsnDelegationModifiedDate $ inetAsnDelegationModifiedBy 1879 $ inetAsnContacts $ inetAsnContactsModifiedBy $ 1880 inetAsnContactsModifiedDate $ inetAsnRoutingContacts $ 1881 inetAsnRoutingContactsModifiedBy $ 1882 inetAsnRoutingContactsModifiedDate ) ) 1884 The attributes from the inetIpv4Network object class are described 1885 below: 1887 inetAsnContacts 1888 ( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAsnContacts' DESC 1889 'Contacts for reporting problems with this routing domain.' 1890 EQUALITY caseExactMatch SYNTAX 1891 1.3.6.1.4.1.1466.115.121.1.15 ) 1893 inetAsnContactsModifiedBy 1894 ( 1.3.6.1.4.1.7161.1.4.3 NAME 'inetAsnContactsModifiedBy' 1895 DESC 'Person who last modified the inetAsnContacts 1896 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1897 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1898 distributedOperation ) 1899 inetAsnContactsModifiedDate 1900 ( 1.3.6.1.4.1.7161.1.4.4 NAME 'inetAsnContactsModifiedDate' 1901 DESC 'Last modification date of the inetAsnContacts 1902 attribute.' EQUALITY generalizedTimeMatch ORDERING 1903 generalizedTimeOrderingMatch SYNTAX 1904 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1905 distributedOperation ) 1907 inetAsnDelegationDate 1908 ( 1.3.6.1.4.1.7161.1.4.5 NAME 'inetAsnDelegationDate' DESC 1909 'Date of original delegation.' EQUALITY 1910 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 1911 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 1913 inetAsnDelegationModifiedBy 1914 ( 1.3.6.1.4.1.7161.1.4.6 NAME 'inetAsnDelegationModifiedBy' 1915 DESC 'Person who last modified the inetAsnDelegationStatus 1916 attribute.' EQUALITY distinguishedNameMatch SYNTAX 1917 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 1918 distributedOperation ) 1920 inetAsnDelegationModifiedDate 1921 ( 1.3.6.1.4.1.7161.1.4.7 NAME 'inetAsnDelegationModifiedDate' 1922 DESC 'Last modification date of the inetAsnDelegationStatus 1923 attribute.' EQUALITY generalizedTimeMatch ORDERING 1924 generalizedTimeOrderingMatch SYNTAX 1925 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1926 distributedOperation ) 1928 inetAsnDelegationStatus 1929 ( 1.3.6.1.4.1.7161.1.4.8 NAME 'inetAsnDelegationStatus' DESC 1930 'Current delegation status code for this AS number.' 1931 EQUALITY numericStringMatch SYNTAX 1932 1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE ) 1933 NOTE: In an effort to facilitate internationalization and 1934 programmatic processing, the current status of a delegation 1935 is identified by a 16-bit integer. The values and status 1936 mapping is as follows: 1938 0 Reserved delegation (permanently inactive) 1939 1 Assigned and active (normal state) 1940 2 Assigned but not yet active (new delegation) 1941 3 Assigned but on hold (disputed) 1942 4 Assignment revoked (database purge pending) 1944 Additional values for the inetIpv6DelegationStatus 1945 attribute are reserved for future use, and are to be 1946 administered by IANA. Note that there is no status code for 1947 "unassigned"; unassigned entries SHOULD NOT exist, and 1948 SHOULD NOT be returned as answers. 1950 inetAsnRoutingContacts 1951 ( 1.3.6.1.4.1.7161.1.4.9 NAME 'inetAsnRoutingContacts' DESC 1952 'Contacts for routing issues with this IPv4 network.' 1953 EQUALITY caseExactMatch SYNTAX 1954 1.3.6.1.4.1.1466.115.121.1.15 ) 1956 inetAsnRoutingContactsModifiedBy 1957 ( 1.3.6.1.4.1.7161.1.4.10 NAME 1958 'inetAsnRoutingContactsModifiedBy' DESC 'Person who last 1959 modified the inetAsnRoutingContacts attribute.' EQUALITY 1960 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1961 SINGLE-VALUE USAGE distributedOperation ) 1963 inetAsnRoutingContactsModifiedDate 1964 ( 1.3.6.1.4.1.7161.1.4.11 NAME 1965 'inetAsnRoutingContactsModifiedDate' DESC 'Last 1966 modification date of the inetAsnRoutingContacts attribute.' 1967 EQUALITY generalizedTimeMatch ORDERING 1968 generalizedTimeOrderingMatch SYNTAX 1969 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 1970 distributedOperation ) 1972 The inetAsNumberSyntax syntax is as follows: 1974 inetAsNumberSyntax 1975 ( 1.3.6.1.4.1.7161.1.4.1 NAME 'inetAsNumberSyntax' DESC 'An 1976 autonomous system number.' ) 1977 5.5.3. Example 1979 An example of the inetAsNumber object class is shown in Figure 7 1980 below, with attributes from the inetResources object class also 1981 being used to provide administrative contacts. This data is a 1982 result of a query which was sent to the LDAP servers associated 1983 with the "arin.net" domain. 1985 Figure 7: The inetAsNumber delegation entry for AS 65535. 1987 cn=65535,cn=inetResources,dc=arin,dc=net 1988 [top object class] 1989 [inetResources object class] 1990 [inetAsNumber object class] 1991 | 1992 +-attribute: description 1993 | value: "The example.net network" 1994 | 1995 +-attribute: inetAsnContacts 1996 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 1997 | dc=example,dc=net" 1998 | 1999 +-attribute: inetGeneralContacts 2000 value: "ldap://ldap.example.com/cn=admins,ou=admins, 2001 dc=example,dc=net" 2003 5.6. The inetAssociatedResources Object Class 2005 The inetAssociatedResources object class defines cross-reference 2006 attributes which may be used with any of the object classes 2007 defined in this document. For example, it allows inetDnsDomain 2008 object class entries to be associated with IPv4 networks, or even 2009 to other DNS domains, if that information is known (this 2010 information may be useful if a single organization has multiple 2011 DNS domains registered). Furthermore, it allows inetOrgPerson 2012 object classes to be associated with managed resources such as IP 2013 networks or DNS domains. In short, any resource can be associated 2014 with any other resource through the use of this object class. 2016 The inetAssociatedResources object class MUST NOT be associated 2017 with an entry that only exists as a referral source. 2019 5.6.1. Naming syntax 2021 The inetAssociatedResources object class is an auxiliary object 2022 class, and not a structural object class. Entries which use this 2023 object class definition are primarily defined under the rules 2024 associated with the structural object class that defines the 2025 Internet resource in question. As such, the naming rules 2026 associated with the structural object class in use with that entry 2027 take precedence. Therefore, the inetAssociatedResources object 2028 class does not define a naming syntax. 2030 5.6.2. Schema definition 2032 The inetAssociatedResources object class is an auxiliary object 2033 class which is subordinate to the top object class. The 2034 inetAssociatedResources object class has no mandatory attributes, 2035 although it does have several optional attributes. 2037 Although the inetAssociatedResources object class is subordinate 2038 to the top object class, it is intended to only be associated with 2039 the resource-specific structural object classes defined in this 2040 document. For example, the inetAssociatedResources object class is 2041 not likely to provide much value when it is associated with the 2042 inetResources object class, since the inetResources object class 2043 does not specifically define any resources (and since it does not 2044 define resources, it cannot define any associated resources). On 2045 the other hand, it is reasonable for the inetAssociatedResources 2046 object class to be associated with an inetOrgPerson object class 2047 entry, particularly if the referenced person (or role) is 2048 responsible for the management of multiple resources. 2050 Each of the associated resource attributes provide multi-valued 2051 data, using the syntax notations which are specific to the 2052 resource in question. For example, the inetAssociatedDnsDomain 2053 attribute provides associated DNS domain name resources using a 2054 multi-valued array, with each DNS domain name using the 2055 inetDnsDomainSyntax naming rules. 2057 The various ModifiedBy and ModifiedDate attributes SHOULD be 2058 treated as operational attributes. Their values SHOULD be filled 2059 in automatically by the database management application, and 2060 SHOULD NOT be returned except when explicitly requested. 2062 The schema definition for the inetAssociatedResources object class 2063 is as follows: 2065 inetAssociatedResources 2066 ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC 2067 'Network resources associated with this entry.' SUP top 2068 AUXILIARY MAY ( inetAssociatedDnsDomains $ 2069 inetAssociatedDnsDomainsModifiedBy $ 2070 inetAssociatedDnsDomainsModifiedDate $ 2071 inetAssociatedIpv4Networks $ 2072 inetAssociatedIpv4NetworksModifiedBy $ 2073 inetAssociatedIpv4NetworksModifiedDate $ 2074 inetAssociatedIpv6Networks $ 2075 inetAssociatedIpv6NetworksModifiedBy $ 2076 inetAssociatedIpv6NetworksModifiedDate $ 2077 inetAssociatedAsNumbers $ 2078 inetAssociatedAsNumbersModifiedBy $ 2079 inetAssociatedAsNumbersModifiedDate ) ) 2081 The attributes from the inetAssociatedResources object class are 2082 described below: 2084 inetAssociatedAsNumbers 2085 ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC 2086 'The autonomous system numbers associated with this entry.' 2087 EQUALITY caseIgnoreMatch SYNTAX inetAsNumberSyntax ) 2089 inetAssociatedAsNumbersModifiedBy 2090 ( 1.3.6.1.4.1.7161.1.5.3 NAME 2091 'inetAssociatedAsNumbersModifiedBy' DESC 'Person who last 2092 modified the inetAssociatedAsNumbers attribute.' EQUALITY 2093 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2094 SINGLE-VALUE USAGE distributedOperation ) 2096 inetAssociatedAsNumbersModifiedDate 2097 ( 1.3.6.1.4.1.7161.1.5.4 NAME 2098 'inetAssociatedAsNumbersModifiedBy' DESC 'Last modification 2099 date of the inetAssociatedAsNumbers attribute.' EQUALITY 2100 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 2101 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 2102 distributedOperation ) 2103 inetAssociatedDnsDomains 2104 ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedDnsDomains' DESC 2105 'The DNS domains associated with this entry.' EQUALITY 2106 caseIgnoreMatch SYNTAX inetDnsDomainSyntax ) 2108 inetAssociatedDnsDomainsModifiedBy 2109 ( 1.3.6.1.4.1.7161.1.5.6 NAME 2110 'inetAssociatedDnsDomainsModifiedBy' DESC 'Person who last 2111 modified the inetAssociatedDnsDomains attribute.' EQUALITY 2112 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2113 SINGLE-VALUE USAGE distributedOperation ) 2115 inetAssociatedDnsDomainsModifiedDate 2116 ( 1.3.6.1.4.1.7161.1.5.7 NAME 2117 'inetAssociatedDnsDomainsModifiedBy' DESC 'Last 2118 modification date of the inetAssociatedDnsDomains 2119 attribute.' EQUALITY generalizedTimeMatch ORDERING 2120 generalizedTimeOrderingMatch SYNTAX 2121 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 2122 distributedOperation ) 2124 inetAssociatedIpv4Networks 2125 ( 1.3.6.1.4.1.7161.1.5.8 NAME 'inetAssociatedIpv4Networks' 2126 DESC 'The IPv4 networks associated with this entry.' 2127 EQUALITY caseIgnoreMatch SYNTAX inetIpv4NetworkSyntax ) 2129 inetAssociatedIpv4NetworksModifiedBy 2130 ( 1.3.6.1.4.1.7161.1.5.9 NAME 2131 'inetAssociatedIpv4NetworksModifiedBy' DESC 'Person who 2132 last modified the inetAssociatedIpv4Networks attribute.' 2133 EQUALITY distinguishedNameMatch SYNTAX 2134 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 2135 distributedOperation ) 2137 inetAssociatedIpv4NetworksModifiedDate 2138 ( 1.3.6.1.4.1.7161.1.5.10 NAME 2139 'inetAssociatedIpv4NetworksModifiedDate' DESC 'Last 2140 modification date of the inetAssociatedIpv4Networks 2141 attribute.' EQUALITY generalizedTimeMatch ORDERING 2142 generalizedTimeOrderingMatch SYNTAX 2143 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 2144 distributedOperation ) 2145 inetAssociatedIpv6Networks 2146 ( 1.3.6.1.4.1.7161.1.5.11 NAME 'inetAssociatedIpv6Networks' 2147 DESC 'The IPv6 networks associated with this entry.' 2148 EQUALITY caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax ) 2150 inetAssociatedIpv6NetworksModifiedBy 2151 ( 1.3.6.1.4.1.7161.1.5.12 NAME 2152 'inetAssociatedIpv6NetworksModifiedBy' DESC 'Person who 2153 last modified the inetAssociatedIpv6Networks attribute.' 2154 EQUALITY distinguishedNameMatch SYNTAX 2155 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 2156 distributedOperation ) 2158 inetAssociatedIpv6NetworksModifiedDate 2159 ( 1.3.6.1.4.1.7161.1.5.13 NAME 2160 'inetAssociatedIpv6NetworksModifiedDate' DESC 'Last 2161 modification date of the inetAssociatedIpv6Networks 2162 attribute.' EQUALITY generalizedTimeMatch ORDERING 2163 generalizedTimeOrderingMatch SYNTAX 2164 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 2165 distributedOperation ) 2167 5.6.3. Example 2169 An example of the inetAssociatedResources object class is shown in 2170 Figure 8 below. 2172 Figure 8: The inetAssociatedResources attributes associated with 2173 the 192.0.2.0/24 IPv4 network entry. 2175 cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 2176 [top object class] 2177 [inetResources object class] 2178 [inetIpv4Network object class] 2179 [inetAssociatedResources object class] 2180 | 2181 +-attribute: description 2182 | value: "The example.com network" 2183 | 2184 +-attribute: inetAssociatedAsNumbers 2185 | value: "65535" 2186 | 2187 +-attribute: inetAssociatedDnsDomains 2188 value: "example.com" 2190 5.7. The inetOrgPerson Object Class 2192 This document provides several contact-related attributes which 2193 use LDAP URLs to reference inetOrgPerson entries. Whenever one of 2194 these contact attributes are returned, a separate query for the 2195 inetOrgPerson entry associated with the contact attribute will be 2196 required if the details of that contact are needed. In order to 2197 facilitate programmatic access to this data, LDAP URLs provided in 2198 contact attributes MUST refer to entries which use the 2199 inetOrgPerson object class, MUST refer to an entry in a DIT which 2200 uses the domainComponent object class syntax ("dc="), and MUST 2201 specify the LDAP or LDAPS protocol-types for the URL. 2203 The model put forth in this document allows each contact attribute 2204 to refer to a variable number of contacts. In this model, a query 2205 for a contact attribute MAY return a variable number of LDAP URLs, 2206 and each of these contacts can then be queried individually. This 2207 allows for multiple explicit contacts per role, while also 2208 providing predictable naming and query structures. 2210 The target entries MAY exist anywhere in the LDAP hierarchy (as 2211 long as they follow the domainComponent naming syntax). It is 2212 expected that pre-existing inetOrgPerson entries will be used for 2213 this purpose. If this is not desirable or feasible, then an entry 2214 MUST be created which meets the minimum requirements defined in 2215 this document. Regardless of where the entry is located, the 2216 target inetOrgPerson entries MUST conform with the schema 2217 specification defined in RFC 2798. 2219 The target inetOrgPerson entries MAY have any number of attributes 2220 defined, with any number of access restrictions, as required by 2221 local security policies, government regulations or personal 2222 privacy concerns. However, the mail attribute MUST be defined, 2223 MUST be valid, and MUST have anonymous read permissions. 2224 Furthermore, all of the attributes MUST be secured against 2225 anonymous add, delete and modify permissions. 2227 5.8. The referral Object Class 2229 This document allows the use of the referral object class to 2230 define subordinate reference referrals and continuation reference 2231 referrals for inetResources container entries and all of the 2232 resource-specific entries. 2234 Referral entries MUST conform to the schema specification defined 2235 in [namedref]. In particular, referral entries MUST NOT contain 2236 any user-definable attributes other than the mandatory "cn" naming 2237 attribute and the mandatory "ref" operational attribute. By 2238 extension, referral entries MUST be leaf nodes, and MUST NOT have 2239 any subordinate entries defined at the referral source. 2241 Furthermore, in order to facilitate programmatic access to this 2242 data, LDAP URLs provided in ref attributes MUST refer to entries 2243 which use the same object classes as the source entry, MUST refer 2244 to an entry in a DIT which uses the domainComponent object class 2245 syntax ("dc="), and MUST specify the LDAP or LDAPS protocol-types 2246 for the URL. 2248 5.9. Object Class and Attribute Permissions 2250 The information presented through the LDAP-WHOIS service will be 2251 used for many operational and problem-resolution purposes. In 2252 order for this information to be suitable for this purpose, it 2253 must be accurate. In order to ensure the veracity of the 2254 information, a minimal set of operational guidelines are provided 2255 in this section. For the most part, these rules are designed to 2256 prevent unauthorized modifications to the data. 2258 Note that these rules only apply to data which is willingly 2259 provided; no data is required to be entered, but where the data is 2260 provided, it MUST be accurate, and it MUST be secured against 2261 unauthorized modifications. 2263 * The inetResources container entry and all of the resource- 2264 specific subordinate entries within every public DIT that 2265 provides LDAP-WHOIS resources SHOULD have anonymous read- 2266 only access permissions, and SHOULD NOT have anonymous add, 2267 delete or modify permissions. 2269 * With the exception of contact-related attributes from the 2270 inetOrgPerson object class, each attribute MAY have 2271 whatever restrictions are necessary in order to suit local 2272 security policies, government regulations or personal 2273 privacy concerns. When the inetOrgPerson object class is 2274 used to provide contact details, the mail attribute MUST be 2275 defined, SHOULD be valid, SHOULD have read-only anonymous 2276 access, and SHOULD NOT have anonymous add, delete or modify 2277 permissions. 2279 By using the inetOrgPerson object class, it is expected 2280 that existing contact-related entries can be reused. If 2281 reusing these entries is undesirable or unfeasible, entries 2282 with the necessary access SHOULD be made available. 2284 Note that contact pointers are entirely optional and are 2285 not required to exist. However, where they exist, they MUST 2286 comply with the above requirements. 2288 * End-users and implementers SHOULD provide anonymous access 2289 to the creatorsName, createTimestamp, modifiersName and 2290 modifyTimestamp operational attributes associated with each 2291 entry in the inetResources branch, since this information 2292 is useful for determining the age of the information. 2294 * Server managers MAY define additional add, delete or modify 2295 permissions for authenticated users, using any LDAPv3 2296 authentication mechanisms they wish. In particular, 2297 delegation entities MAY provide for the remote management 2298 of delegated resources (such as assigning modification 2299 privileges to the managers of a particular delegated domain 2300 or address block), although this is entirely optional, and 2301 is within the sole discretion of the delegation body. 2303 External applications SHOULD NOT make critical decisions based on 2304 the information provided through this service without having 2305 reason to trust the veracity of the information. Clients and users 2306 SHOULD limit the use of unknown or untrusted information to 2307 routine purposes. 2309 6. Search and Match Filters 2311 LDAP search filters are fairly flexible, in that they allow for a 2312 wide variety of configurable elements, such as the maximum number 2313 of entries which are returned, the type of comparison operation 2314 that needs to be performed, and other details. In order to promote 2315 interoperability, default values are defined here for many of 2316 these elements, although these defaults are only applicable when 2317 they are used with the LDAP-WHOIS service. 2319 In particular, this document defines several suggested and 2320 mandatory search filter qualifiers, which are described in detail 2321 in section 6.1. This document also defines extensibleMatch filter 2322 definitions which MUST be implemented whenever the associated 2323 resource types defined in this document are implemented by an 2324 LDAP-WHOIS client or server. These filter definitions are provided 2325 in section 6.2 below. 2327 6.1. Search Filter Expressions 2329 Section 4.5.1 of RFC 2251 defines the LDAP search request 2330 specification, although it does not provide guidelines or 2331 recommended values for the filter settings. In an effort to 2332 promote interoperability among LDAP-WHOIS clients and servers, 2333 this document defines some recommended and mandatory values for 2334 searches within the LDAP-WHOIS service. 2336 NOTE: These rules ONLY apply to the LDAP-WHOIS search 2337 operations in particular. Any queries for other resources 2338 (such as requests for inetOrgPerson contact entries) MUST 2339 NOT impose these restrictions. Also note that other 2340 documents which define additional resource types can also 2341 define different restrictions, and those definitions will 2342 take preference over these guidelines. 2344 Generic LDAP clients may be used to browse and search for data, 2345 and in those cases, these rules are not likely to be followed. As 2346 such, servers MUST be prepared to enforce these rules 2347 independently of the client settings. 2349 The values of an LDAP search filter should be as follows: 2351 * Search base. The DIT to be used in a search will vary for 2352 each query operation. The methodology for determining the 2353 current search base for a query is defined by the query- 2354 processing protocols described in section 7, although LDAP- 2355 WHOIS searches are normally constrained to the 2356 "cn=inetResources" container of a particular DIT. 2358 * Scope. In order to support continuation reference referrals 2359 (which are defined as referral entries beneath a resource- 2360 specific entry), clients MUST use a sub-tree scope for 2361 LDAP-WHOIS searches. Servers MUST NOT arbitrarily limit the 2362 scope of search operations. 2364 * Dereference aliases. Although the LDAP-WHOIS service does 2365 not make direct use of alias entries, they are not 2366 prohibited. Clients SHOULD set the Dereference Aliases 2367 option to "Always" for LDAP-WHOIS searches. Servers SHOULD 2368 dereference any aliases which are encountered, where this 2369 is feasible (in particular, where the alias refers to 2370 another DIT on the same server). 2372 * Size limit. The size limit field specifies the maximum 2373 number of entries that a server should return. For the 2374 LDAP-WHOIS service, this setting SHOULD be set to a value 2375 between 25 and 100. This range ensures that the client is 2376 capable of receiving a sufficient number of entries and 2377 continuation references in a single response, but also 2378 works to prevent runaway queries that match everything 2379 (such as searches for "com", which can match every 2380 inetDnsDomain entry in the "cn=inetResources,dc=com" 2381 container). Servers MAY truncate answer sets to 100 2382 responses if the client specifies a larger value. 2384 * Time limit. The time limit field specifies the maximum 2385 number of seconds that a server should process the search. 2386 For the LDAP-WHOIS service, this setting SHOULD be set to a 2387 value between 10 and 60 seconds. This range ensures that 2388 the server is able to process a sufficient number of 2389 entries, but also works to prevent runaway queries that 2390 match everything. Servers MAY stop processing queries after 2391 60 seconds if the client specifies a larger value. 2393 * Types-only. The types-only setting is a Boolean flag which 2394 controls whether or not attribute values are returned in 2395 the answer sets. Since excessive queries are likely to be 2396 more burdensome than larger answer sets, this setting 2397 SHOULD be set to FALSE. Resource-constrained clients (such 2398 as PDAs) MAY set this value to TRUE, but these clients MUST 2399 be prepared to issue the necessary subsequent queries. 2401 * Filter. The search operation will depend on the type of 2402 data being queried. For LDAP-WHOIS queries, the filter MUST 2403 use the matching rules defined in section 6.2 for the 2404 relevant resource type. Other resource-specific documents 2405 may define their own handling rules. 2407 Note that the extensible match filters defined in this 2408 document MUST be supported by LDAP-WHOIS clients and 2409 servers. LDAP-WHOIS servers MAY also support additional 2410 sub-string filters, soundex filters, or any other filters 2411 they wish (these may be required for generic LDAP clients), 2412 although LDAP-WHOIS clients MUST NOT expect any additional 2413 filters to be available. 2415 * Attribute list. Clients MAY restrict the list of attributes 2416 which are returned in searches, but are discouraged from 2417 doing so without cause. 2419 6.2. Matching Filter Definitions 2421 Each of the object classes defined in this document have their own 2422 search criteria which MUST be used whenever a collection of 2423 resource pools need to be searched. In this model, resource types 2424 are specified during the search operation, and most of the 2425 resource types have extensibleMatch definition which are used 2426 whenever the available resources need to be searched. 2428 For example, if a user wishes to find the inetIPv4network object 2429 class entry associated with a specific IPv4 address, then the 2430 inetIpv4NetworkMatch extensibleMatch filter MUST be specified by 2431 the client, and MUST be used by the server when attempting to 2432 locate the relevant inetIpv4Network entry. 2434 This document defines unique extensibleMatch filters for three of 2435 the four resource-specific object classes which are also defined 2436 herein: inetDnsDomain, inetIpv4Network, and inetIpv6Network. The 2437 inetResources, inetAsNumber and inetOrgPerson object classes can 2438 be searched with simple equalityMatch filters, and do not require 2439 dedicated extensibleMatch filters, although they do have specific 2440 handling rules which are discussed below. 2442 6.2.1. inetDnsDomainMatch 2444 The inetDnsDomainMatch filter provides an identifier and search 2445 string format which collectively inform a queried server that a 2446 specific DNS domain name should be searched for, and that any 2447 matching inetDnsDomain object class entries should be returned. 2449 The inetDnsDomainMatch extensibleMatch filter is defined as 2450 follows: 2452 inetDnsDomainMatch 2453 ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDomainMatch' SYNTAX 2454 inetDnsDomainSyntax ) 2455 The assertion value MUST be a valid DNS domain name, using the 2456 inetDnsDomainSyntax syntax rules defined in section 5.2. 2458 The server MUST compare the assertion value against the RDN of all 2459 entries in the inetResources container which have an object class 2460 of inetDnsDomain. Any entry for a DNS domain resource which is 2461 clearly superior to the DNS domain name provided in the input 2462 string MUST be returned to the client. Entries which do not 2463 encompass the queried domain name MUST NOT be returned. Entries 2464 which do not have an object class of inetDnsDomain MUST NOT be 2465 returned. 2467 For example, assume that the client has issued a query with the 2468 assertion value of "www.example.com". If the queried server has an 2469 inetDnsDomain object class entry with a DN of 2470 "cn=example.com,cn=inetResources,dc=com", then that entry would be 2471 returned to the client. Similarly, a continuation reference 2472 referral of "cn=cref1,cn=example.com,cn=inetResources,dc=com" 2473 would also be returned, since it has a "cn" component that is 2474 superior to the queried domain name, and has the inetDnsDomain 2475 object class. 2477 Domain names MUST be compared on label boundaries, and MUST NOT be 2478 qualified through simple character matching. Given two entries of 2479 "cn=example.com" and "cn=an-example.com", only the first would 2480 match an assertion value of "example.com". 2482 Using the notation format described in RFC 2254, the search filter 2483 expression for the inetDnsDomainMatch query above would be written 2484 as "(1.3.6.1.4.1.7161.1.1.9:=www.example.com)". 2486 Response entries MAY be fully-developed inetDnsDomain entries, or 2487 MAY be referrals generated from entries which have the 2488 inetDnsDomain and referral object classes defined. Any attribute 2489 values which are received MUST be displayed by the client. If a 2490 subordinate reference referral is received, the client MUST 2491 restart the query, using the provided data as the new search base. 2492 If any continuation reference referrals are received, the client 2493 SHOULD start new queries for each reference, and append the output 2494 of those queries to the original query's output. 2496 6.2.2. inetIpv4NetworkMatch 2498 The inetIpv4NetworkMatch filter provides an identifier and search 2499 string format which collectively inform a queried server that a 2500 specific IPv4 address should be searched for, and that any 2501 matching inetIpv4network object class entries should be returned. 2503 NOTE: IPv4 addresses are also stored in DNS for reverse- 2504 lookups, and those entries are treated as inetDnsDomain 2505 object class entries rather than being treated as 2506 inetIpv4Network object class entries (they are treated as 2507 DNS zones with their own operational administrators). As 2508 such, those entries use the inetDnsDomainMatch query 2509 described in section 6.2.1. 2511 The inetIpv4NetworkMatch extensibleMatch filter is defined as 2512 follows: 2514 inetIpv4NetworkMatch 2515 ( 1.3.6.1.4.1.7161.1.2.12 NAME 'inetIpv4NetworkMatch' SYNTAX 2516 inetIpv4NetworkSyntax ) 2518 The assertion value MUST be an IPv4 address, using the 2519 inetIpv4NetworkSyntax defined in section 5.3. Clients MUST provide 2520 assertion values in this syntax. If an input string does not match 2521 this syntax, the client MAY attempt to manipulate the input string 2522 such that an appropriate assertion value can be formed. For 2523 example, if a user enters a traditional IPv4 address without 2524 specifying a prefix value, the client MAY append "/32" to the end 2525 of the input string to form a valid assertion value. Similarly, if 2526 a user provides an octal or hexadecimal value, the client MAY 2527 attempt to convert the input string to the traditional dotted-quad 2528 IPv4 address notation. 2530 The server MUST compare the assertion value against the RDN of all 2531 entries in the inetResources container which have an object class 2532 of inetIpv4Network. Any entry for an IPv4 network resource which 2533 is clearly superior to the IPv4 address provided in the input 2534 string MUST be returned to the client. Superiority in this case 2535 means exactly what it sounds like: the address range specified by 2536 the inetIpv4Network object class entry (as determined by the 2537 network number and the prefix combination of the entry's RDN) MUST 2538 define a range of IPv4 addresses which encompasses the IPv4 2539 address specified in the query, and any such entry MUST be 2540 returned in the response message. Entries which do not encompass 2541 the queried address MUST NOT be returned. Entries which do not 2542 have an object class of inetIpv4Network MUST NOT be returned. 2544 For example, assume that the client is submitting a search for 2545 "192.0.2.14/32", with the search base of "dc=in-addr,dc=arpa". The 2546 queried server may only have an inetIpv4Network entry for 2547 "cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa", and as such 2548 that would be the only entry returned. However, the server could 2549 also have multiple entries which matched the queried IPv4 address, 2550 such as "cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa" and 2551 "cn=192.0.2.0/24,cn=inetResources,dc=in-addr,dc=arpa", both of 2552 which reflected specific delegations. 2554 Similarly, a query for this IPv4 address which was sent to the 2555 LDAP servers responsible for the operational network could result 2556 in "cn=192.0.2.8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" and 2557 "cn=192.0.2.14/32,dc=8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" 2558 entries being returned to the client (assuming the subnet 2559 allocation policy of the network reflected this usage, and that 2560 there was an explicit entry for the IPv4 address in question). 2562 Using the notation format described in RFC 2254, the search filter 2563 expression for the inetDnsDomainMatch query above would be written 2564 as "(1.3.6.1.4.1.7161.1.2.12:=192.0.2.14/32)". 2566 Response entries MAY be fully-developed inetIpv4Network entries, 2567 or MAY be referrals generated from entries which have the 2568 inetIpv4Network and referral object classes defined. Any attribute 2569 values which are received MUST be displayed by the client. If a 2570 subordinate reference referral is received, the client MUST 2571 restart the query, using the provided data as the new search base. 2572 If any continuation reference referrals are received, the client 2573 SHOULD start new queries for each reference, and append the output 2574 of those queries to the original query's output. 2576 6.2.3. inetIpv6NetworkMatch 2578 The inetIpv6NetworkMatch filter provides an identifier and search 2579 string format which collectively inform a queried server that a 2580 specific IPv6 address should be searched for, and that any 2581 matching inetIpv6network object class entries should be returned. 2583 NOTE: IPv6 addresses are also stored in DNS for reverse- 2584 lookups, and those entries are treated as inetDnsDomain 2585 object class entries rather than being treated as 2586 inetIpv6Network object class entries (they are treated as 2587 DNS zones with their own operational administrators). As 2588 such, those entries use the inetDnsDomainMatch query 2589 described in section 6.2.1. 2591 The inetIpv6NetworkMatch extensibleMatch filter is defined as 2592 follows: 2594 inetIpv6NetworkMatch 2595 ( 1.3.6.1.4.1.7161.1.4.19 NAME 'inetIpv6NetworkMatch' SYNTAX 2596 inetIpv6NetworkSyntax ) 2598 The assertion value MUST be an IPv6 address, using the 2599 inetIpv6NetworkSyntax defined in section 5.4. Clients MUST provide 2600 assertion values in this syntax. If an input string does not match 2601 this syntax, the client MAY manipulate the input string to form a 2602 valid assertion value. For example, if a user provides a zero- 2603 compressed IPv6 address such as 3ffe:ffff::, the client MAY 2604 convert the input value to the inetIpv6NetworkSyntax form of 2605 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32". 2607 The server MUST compare the assertion value against the RDN of all 2608 entries in the inetResources container which have an object class 2609 of inetIpv6Network. Any entry for an IPv6 network resource which 2610 is clearly superior to the IPv6 address provided in the input 2611 string MUST be returned to the client. Entries which do not 2612 encompass the queried address MUST NOT be returned. Entries which 2613 do not have an object class of inetIpv6Network MUST NOT be 2614 returned. 2616 Using the notation format described in RFC 2254, the search filter 2617 expression for the inetDnsDomainMatch query above would be written 2618 as "(1.3.6.1.4.1.7161.1.4.19:= 2619 3ffe:ffff:0000:0000:0000:0000:0000:0000/32)". 2621 Response entries MAY be fully-developed inetIpv6Network entries, 2622 or MAY be referrals generated from entries which have the 2623 inetIpv6Network and referral object classes defined. Any attribute 2624 values which are received MUST be displayed by the client. If a 2625 subordinate reference referral is received, the client MUST 2626 restart the query, using the provided data as the new search base. 2627 If any continuation reference referrals are received, the client 2628 SHOULD start new queries for each reference, and append the output 2629 of those queries to the original query's output. 2631 6.2.4. inetResources, inetAsNumber and inetOrgPerson equalityMatch 2633 DNS domains and IP addresses have specific subordinate delegation 2634 properties which require special processing rules as described 2635 above. Conversely, the inetResources, inetAsNumber and 2636 inetOrgPerson object classes do not have this inheritance problem, 2637 and these entries can be searched using relatively simple 2638 equalityMatch filters. 2640 In order to ensure that all of the relevant entries (including any 2641 referrals) are found, the search filters for these resources MUST 2642 specify two distinct elements: the object class of the resource 2643 being queried, and the naming element of the resource specified as 2644 a distinguished name attribute. 2646 For example, using the notation format described in RFC 2254, the 2647 search filter expression for the inetOrgPerson entry associated 2648 with "cn=admins,ou=admins,dc=example,dc=com" would be structured 2649 as "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", using 2650 "ou=admins,dc=example,dc=com" as the search base. This would find 2651 all entries with the object class of inetOrgPerson (including all 2652 of the referral entries for inetOrgPerson entries) where the 2653 distinguished name contained the "cn" attribute of "admins". 2655 Similarly, a query for "(&(objectclass=inetAsNumber)(cn:dn:1))" 2656 with a search base of "cn=inetResources,dc=example,dc=com" would 2657 find all of the inetAsNumber object class entries associated with 2658 AS number "1" in the LDAP-WHOIS branch of "dc=example,dc=com". 2660 The input source and search base for these matches will vary 2661 according to the query being processed, but whenever an 2662 equalityMatch is called for during query processing, the above 2663 methods MUST be used in order to ensure that all of the related 2664 entries are located. 2666 Response entries MAY be fully-developed entries, or MAY be 2667 referrals generated from entries which have the referral object 2668 class defined. Any attribute values which are received MUST be 2669 displayed by the client. If a subordinate reference referral is 2670 received, the client MUST restart the query, using the provided 2671 data as the new search base. If any continuation reference 2672 referrals are received, the client SHOULD start new queries for 2673 each reference, and append the output of those queries to the 2674 original query's output. 2676 7. Query Processing Models 2678 The LDAP-WHOIS service uses three different query-processing 2679 models. These are the "top-down" model which initiates the query 2680 process at the top-level of a DNS delegation hierarchy, a "bottom- 2681 up" model which directs queries to user-managed servers, and a 2682 "targeted" search model which is functionally identical to 2683 traditional LDAP searches. Furthermore, any of these mechanisms 2684 may be redirected to other servers, either through simple DNS 2685 query processing, or by way of LDAP redirections (including 2686 subordinate reference referrals, continuation reference referrals, 2687 attribute references, or labeledURI attributes). 2689 Each of the three query models are appropriate to different usage 2690 environments. For example, the top-down model is best suited for 2691 searches about global resources which are centrally managed and 2692 delegated (such as IP addresses and DNS domains), and where 2693 delegation information is a critical element of the resource data. 2694 Meanwhile, the bottom-up model is most appropriate for those 2695 resources which are managed by the end-users directly, and which 2696 are not managed from a centralized delegation authority (this 2697 includes information such as private keys, mail servers, and other 2698 leaf-node resources). Finally, the targeted model is best suited 2699 for explicit queries where a particular resource is supposed to 2700 exist with a known DN (such as with contact pointers). 2702 LDAP-WHOIS clients and servers MUST implement all three models. 2703 Clients MUST default to using the top-down model, but clients MUST 2704 also provide a user-selectable option for the disposition of 2705 individual queries. 2707 7.1. Top-Down Processing 2709 The top-down model is primarily suited for locating Internet 2710 resources which are centrally managed and delegated. The top-down 2711 model is similar to other distributed WHOIS protocols in this 2712 regard, with the principle difference being the use of LDAP for 2713 standardized syntaxes, data and referrals, rather than using a 2714 specialized protocol specifically for this application. 2716 The top-down model uses an input string to construct an LDAP 2717 assertion value and search base, with DNS queries being used to 2718 locate the LDAP servers associated with the appropriate top-level 2719 delegation entity. Once this process completes, an extensible 2720 match query is issued to the specified servers. The query may also 2721 be redirected through the use of LDAP referrals, if additional 2722 data is known to exist elsewhere. 2724 For example, a top-down search for the domain name of 2725 "www.example.com" would result in the client building an 2726 inetDnsDomainMatch extensible match query with the search base of 2727 "cn=inetResources,dc=com", and with the client issuing a DNS query 2728 for the LDAP servers associated with "com" domain. If the queried 2729 server had information about the "www.example.com" resource, it 2730 would be returned as answer data. If the server knew of other 2731 sources of information about the resource (such as the registrar 2732 for the domain, or the entity operating the domain, or both), 2733 continuation reference referrals could be returned. Any of the 2734 subsequent queries could return additional answers and/or 2735 referrals, according to the data they had. 2737 IP address blocks and AS numbers are processed in a similar 2738 fashion. If a client needed to locate information about the 2739 "192.0.2.14/32" IPv4 address, it would begin the process by 2740 building a reverse-lookup DNS domain name from the input string, 2741 and then issuing a DNS query for the LDAP servers associated with 2742 the "arpa" top-level domain. Once a server had been located, an 2743 LDAP query with the assertion value of "192.0.2.14/32" would be 2744 submitted with a search base of "cn=inetResources,dc=arpa". The 2745 server would return data and/or referrals, with this process 2746 repeating until the query string had been completely processed. 2748 Note that entries for the inetResources and inetOrgPerson object 2749 classes are not searchable with this model, since they do not have 2750 centralized delegation authorities. One of the other search models 2751 MUST be used for those resource types. 2753 7.1.1. Processing steps 2755 The steps for processing top-down queries are described below: 2757 a. Determine the input type (DNS Domain, IPv4 Address, etc.) 2759 b. Determine the authoritative domain name for the query. 2761 1. Separate the input string into discrete elements where 2762 this is possible. For a DNS domain name of 2763 "www.example.com", this would be "www", "example" and 2764 "com". For the IPv4 network number of "192.0.2.14", 2765 this would be "192", "0", "2" and "14". AS numbers 2766 only have a single value and require no separation. Do 2767 not discard the original query string. 2769 2. IP addresses and AS numbers require additional 2770 conversion. For IPv4 addresses, strip off the prefix 2771 and convert the input string into a reverse-lookup DNS 2772 domain name by reversing the order of the octets and 2773 appending "in-addr.arpa" to the right of the domain 2774 name. For IPv6 addresses, strip off the prefix and 2775 reverse the nibble order of the address (where each 2776 nibble is represented by a single hexadecimal 2777 character), and append "ip6.arpa". For AS numbers, 2778 append only the "arpa" domain name. 2780 c. Form the LDAP search base for the query. 2782 1. Convert the right-most element from the domain name 2783 formed in step 7.1.1.b above into a domainComponent DN 2784 (such as "dc=com" or "dc=arpa"). This represents the 2785 DIT for the current query. 2787 2. Append the "cn=inetResources" RDN to the front of the 2788 domainComponent syntax ("cn=inetResources,dc=com"). 2789 This will form the fully-qualified search base for the 2790 LDAP query. 2792 d. Locate the LDAP servers associated with the resource by 2793 processing the domain name formed in step 7.1.1.b above 2794 through the SRV query steps provided in section 7.4.5. 2796 e. If the SRV lookup succeeds: 2798 1. Choose the best LDAP server, using the weighting 2799 formula described in RFC 2782. 2801 2. Construct the LDAP search filter according to the 2802 rules specified in section 6.1, using the appropriate 2803 matching rule from section 6.2. 2805 3. Formulate the LDAP search using the search base and 2806 search filter constructed above. For example, if the 2807 input query string was for "www.example.com", then the 2808 client would begin the process by submitting an 2809 inetDnsDomainMatch extensibleMatch search with the 2810 assertion value of "www.example.com", and with a 2811 search base of "dc=inetResources,dc=com". Similarly, 2812 if the input query string was "192.0.2.14", then the 2813 client would begin the process by submitting an 2814 inetIpv4NetworkMatch extensibleMatch search with the 2815 assertion value of "192.0.2.14/32", and with the 2816 search base of "cn=inetResources,dc=arpa". 2818 4. Submit the search operation to the chosen server and 2819 port number. If the operation fails, report the 2820 failure to the user and exit. Otherwise, display any 2821 answer data which is returned. 2823 5. If the answer data contains a subordinate reference 2824 referral or a continuation reference referral, new 2825 query processes MUST be spawned. 2827 For subordinate reference referrals, process the URLs 2828 according to the rules described in section 7.4.1 and 2829 restart the query process at step 7.1.1.e.2. For each 2830 continuation reference referral, display the answer 2831 data received so far, process the LDAP URLs according 2832 to the rules described in section 7.4.3 and start new 2833 query processes for each referral at step 7.1.1.e.2, 2834 appending the output from these searches to the 2835 current output. 2837 Any additional subordinate reference referrals or 2838 continuation reference referrals which are encountered 2839 from any subsequent searches will need to be processed 2840 in the same manner as specified above, until no 2841 additional referrals are received. 2843 f. If the SRV lookup fails (where failure is defined as any 2844 DNS response message other than an answer), report the 2845 failure to the user and exit the current search operation. 2847 7.1.2. Top-Down example 2849 In the example below, the user has entered a search string of 2850 "www.example.com" and has indicated that the query is for a DNS 2851 domain name. 2853 a. The input string is broken into the discrete label 2854 components ("www", "example" and "com"). 2856 b. The right-most label ("com") is used to form the DNS SRV 2857 lookup ("_ldap._tcp.com"), in order to find the LDAP 2858 servers authoritative for the delegation hierarchy. 2860 c. One of the LDAP servers is contacted, and an 2861 inetDnsDomainMatch search filter is submitted with the 2862 assertion value of "www.example.com" and a search base of 2863 "cn=inetResources,dc=com". 2865 d. The server responds with a continuation reference referral 2866 URL of "ldap://ldap.netsol.com/cn=example.com, 2867 cn=inetResources,dc=netsol,dc=com", indicating that the 2868 domain delegation is managed under the "dc=netsol,dc=com" 2869 DIT, and is hosted at the "ldap.netsol.com" server. The 2870 client uses this information to start a new query. No 2871 additional data was provided for the client to display. 2873 e. An inetDnsDomainMatch extensibleMatch search is submitted 2874 to "ldap.netsol.com", using the search base of 2875 "cn=example.com,cn=inetResources,dc=netsol,dc=com". 2877 f. The queried server returns the information that it has. No 2878 additional referrals are provided. The client displays the 2879 data and exits the query. 2881 7.2. Bottom-Up Processing 2883 The bottom-up model is best used when a leaf-node resource needs 2884 to be queried, and where an LDAP-WHOIS server is expected to be 2885 able to answer the query. In this case, navigating down through a 2886 delegation hierarchy would be either fruitless or inefficient. For 2887 example, information about a mail domain would be more efficient 2888 in the bottom-up model, since there is no global delegation body 2889 for Internet mail (the DNS domains are delegated, but the message 2890 routing is specific to the operational entities responsible for 2891 the domain name). The bottom-up model can also be used for DNS 2892 domain names, IPv4 addresses, and IPv6 addresses, although this 2893 will generally prove to be less useful than top-down queries, 2894 given the limited number of user-managed servers deployed. 2896 The bottom-up model uses an input string to construct an LDAP 2897 assertion value and search base, with DNS queries being used to 2898 locate the LDAP servers which are associated with the management 2899 entity that is directly responsible for the resource in question. 2900 Once this process completes, an extensible match query is issued 2901 to the specified servers. The query may also be redirected through 2902 the use of LDAP referrals, if additional data is known to exist 2903 elsewhere. 2905 For example, a bottom-up search for the domain name of 2906 "www.example.com" would result in the client building an 2907 inetDnsDomainMatch extensible match query with the search base of 2908 "cn=inetResources,dc=www,dc=example,dc=com", and with the client 2909 issuing a DNS query for the LDAP servers associated with 2910 "www.example.com" domain. If the DNS lookup failed, the client 2911 would issue a subsequent query for the LDAP servers associated 2912 with the "example.com" domain, and so forth, until a server had 2913 been located. If the queried server had information about the 2914 "www.example.com" resource, it would be returned as answer data. 2915 If the server knew of other sources of information about the 2916 resource (such as the registrar for the domain, or the entity 2917 operating the domain, or both), continuation reference referrals 2918 could be returned. Any of the subsequent queries could return 2919 additional answers and/or referrals, according to the data they 2920 had. 2922 IP address blocks are processed in a similar fashion. If a client 2923 needed to locate information about the "192.0.2.14" IPv4 address, 2924 it would begin by issuing a DNS query for the LDAP servers 2925 responsible for the "14.2.0.192.in-addr.arpa" domain name, with 2926 the left-most labels being truncated as the search for an 2927 authoritative server was broadened. Once a server had been 2928 located, an inetIpv4NetworkMatch extensibleMatch search with the 2929 assertion value of "192.0.2.14/32" would be submitted. If the 2930 server knew of any information about that resource, it would 2931 return data or a referral, with this process repeating until the 2932 query string had been processed as completely as possible. 2934 Note that entries for inetAsNumber and inetOrgPerson object 2935 classes are not searchable with this model, since they are not 2936 represented in the DNS delegation hierarchy. One of the other 2937 search models MUST be used for those resource types. 2939 7.2.1. Processing steps 2941 The steps for processing bottom-up queries are described below: 2943 a. Determine the input type (DNS Domain, IPv4 Address, etc.) 2945 b. Determine the authoritative DNS domain for the resource. 2947 1. Separate the input string into discrete elements where 2948 this is possible. For a DNS domain name of 2949 "www.example.com", this would be "www", "example" and 2950 "com". For the IPv4 network number of "192.0.2.14", 2951 this would be "192", "0", "2" and "14". Do not discard 2952 the original query string. 2954 2. IP addresses require additional conversion. For IPv4 2955 addresses, strip off the prefix and convert the input 2956 string into a reverse-lookup DNS domain name by 2957 reversing the order of the octets and appending 2958 "in-addr.arpa" to the right of the resulting sequence. 2959 For IPv6 addresses, strip off the prefix and reverse 2960 the nibble order of the address (where each nibble is 2961 represented by a single hexadecimal character), and 2962 append "ip6.arpa" to the right of the resulting 2963 sequence. 2965 c. Form the LDAP search base for the query. 2967 1. Convert the domain name formed in step 7.2.1.b above 2968 into a domainComponent DN (such as 2969 "dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192, 2970 dc=in-addr,dc=arpa"). This represents the DIT for the 2971 current query. 2973 2. Append the "cn=inetResources" RDN to the left of the 2974 domainComponent syntax (perhaps resulting in 2975 "cn=inetResources,dc=www,dc=example,dc=com"). This 2976 will become the search base for the LDAP query. 2978 d. Locate the LDAP servers associated with the resource by 2979 processing the domain name formed in step 7.2.1.b above 2980 through the SRV query steps provided in section 7.4.5. 2982 e. If the SRV lookup fails with an NXDOMAIN response code (as 2983 described in RFC 2308), then the domain name used for the 2984 SRV lookup does not exist, and a substitute LDAP server and 2985 search base must be identified. This process involves 2986 determining the parent zone for the domain name in 2987 question, issuing an SRV lookup for that zone, and using 2988 the domain name of the zone as the new LDAP search base, 2989 with this process repeating until a search base can be 2990 located, or until a critical failure forces an exit. 2992 1. Remove the left-most label from the domain name formed 2993 in step 7.2.1.b. 2995 2. If this process has already resulted in a query domain 2996 name at a top-level domain such as "com" or "arpa", 2997 convert the query domain name to "." (to signify the 2998 root domain). 3000 3. If the queried domain name is already set to ".", the 3001 query can go no higher (this most likely indicates a 3002 malformed DNS configuration, a connectivity problem, 3003 or a typo in the query). Exit and report the failure 3004 to the user. 3006 4. Restart the process at step 7.1.1.c, using the domain 3007 name formed above. Repeat until a server is located or 3008 a critical failure forces an exit. 3010 For example, if the original input string of 3011 "www.example.com" resulted in a failed SRV lookup for 3012 "_ldap._tcp.www.example.com", then the first fallback 3013 SRV query would be for "_ldap._tcp.example.com", and 3014 the next fallback query would be for "_ldap._tcp.com", 3015 possibly being followed by "_ldap._tcp.", and possibly 3016 resulting in failure after that. 3018 f. If the SRV lookup succeeds: 3020 1. Choose the best LDAP server, using the weighting 3021 formula described in RFC 2782. 3023 2. Construct the LDAP search filter according to the 3024 rules specified in section 6.1, and choose the 3025 appropriate matching rule from section 6.2. 3027 3. Formulate the LDAP search using the search base and 3028 search filter constructed above. For example, if the 3029 input query string was for "www.example.com", then the 3030 client would begin the process by submitting an 3031 inetDnsDomainMatch extensibleMatch search with the 3032 assertion value of "www.example.com", with the search 3033 base of "cn=inetResources,dc=www,dc=example,dc=com". 3035 4. Submit the search operation to the chosen server and 3036 port number. If the operation fails, report the 3037 failure to the user and exit. Otherwise, display any 3038 answer data which is returned. 3040 5. If the answer data contains a subordinate reference 3041 referral or a continuation reference referral, new 3042 query processes MUST be spawned. 3044 For subordinate reference referrals, process the URLs 3045 according to the rules described in section 7.4.1 and 3046 restart the query process at step 7.2.1.f.2. For each 3047 continuation reference referral, display the answer 3048 data received so far, process the LDAP URLs according 3049 to the rules described in section 7.4.3 and start new 3050 query processes for each referral at step 7.2.1.f.2, 3051 appending the output from these searches to the 3052 current output. 3054 Any additional subordinate reference referrals or 3055 continuation reference referrals which are encountered 3056 from any subsequent queries will need to be processed 3057 in the same manner as specified above, until no 3058 additional referrals are received. 3060 g. If a fatal DNS error condition occurs, report the error to 3061 the user and stop processing the current query. A fatal DNS 3062 error is any response message with an RCODE of FORMERR, 3063 SERVFAIL, NOTIMPL, or REFUSED, or where a query results in 3064 NODATA (implying that an "_ldap._tcp" domain name exists 3065 but it doesn't have an SRV resource record associated with 3066 it, which is most likely a configuration error). 3068 7.2.2. Bottom-Up example 3070 In the example below, the user has entered a search string of 3071 "www.example.com" and has indicated that the query is for a DNS 3072 Domain Name. 3074 a. The query string is used to form the DNS SRV lookup 3075 ("_ldap._tcp.www.example.com"), in order to find the LDAP 3076 servers authoritative for that domain name. 3078 b. The SRV lookup fails with NXDOMAIN, indicating that the 3079 queried domain name does not exist. 3081 c. The client creates a new query for the parent domain 3082 ("_ldap._tcp.example.com"), which succeeds. 3084 d. The client contacts one of the servers, and issues an 3085 inetDnsDomainMatch extensibleMatch search with the 3086 assertion value of "www.example.com", and with the search 3087 base of "cn=inetResources,dc=example,dc=com". 3089 e. The server returns a continuation reference referral of 3090 "ldap://ldap.example.net/cn=server1.example.net, 3091 cn=inetResources,dc=example,dc=net", indicating that the 3092 queried resource is a referral for a web hosting server at 3093 Example Networks. The client uses this information to start 3094 a new query. No additional data was provided for the client 3095 to display. 3097 f. An inetDnsDomainMatch extensibleMatch search is submitted 3098 to the "ldap.example.net" server, using the search base of 3099 "cn=server1.example.net,cn=inetResources,dc=example,dc=net" 3101 g. The queried server returns the information that it has. No 3102 additional referrals are provided. The client displays the 3103 data and exits the query. 3105 7.3. Targeted Search Processing 3107 The targeted search model is similar to the bottom-up query model 3108 described in the preceding section, except that it does not 3109 provide fallback processing of DNS domain names. In this regard, 3110 the targeted search model is closely similar to the traditional 3111 LDAP searching model, in that a client queries a specified LDAP 3112 server for a specific entry, under the assumption that the 3113 resource exists at that location. If the server or resource does 3114 not exist, the entire query fails. 3116 For this reason, the targeted search model is not suitable for 3117 search operations against generic Internet resources, but instead 3118 is mostly suitable for searches against known entries which are 3119 presumed to exist at a known location. In terms of the LDAP-WHOIS 3120 service in particular, this includes inetOrgPerson entries which 3121 are provided in contact-related attributes. However, the targeted 3122 search model can be used for any resource type, and it can be 3123 useful for diagnosing problems with resource types. For this 3124 reason, clients SHOULD support this model for use with all known 3125 resource types. 3127 The targeted search takes an LDAP URL as the query input (along 3128 with the resource-type identifier), and uses the URL to determine 3129 the query server, the search base, and the assertion value. 3131 7.3.1. Processing steps 3133 The steps for processing targeted search queries are described 3134 below: 3136 a. Process the LDAP URLs according to the continuation 3137 reference referral handling rules described in section 3138 7.4.3. This process will determine the servers, search base 3139 and assertion value of the query. 3141 b. If this process succeeds: 3143 1. Construct the LDAP search filter according to the 3144 rules specified in section 6.1, and choose the 3145 appropriate matching rule from section 6.2. 3147 2. Submit the search operation to the chosen server and 3148 port number. If the operation fails, report the 3149 failure to the user and exit. Otherwise, display any 3150 answer data which is returned. 3152 3. If the answer data contains a subordinate reference 3153 referral or a continuation reference referral, new 3154 query processes MUST be spawned. 3156 For subordinate reference referrals, process the URLs 3157 according to the rules described in section 7.4.1 and 3158 restart the query process at step 7.3.1.b. For each 3159 continuation reference referral, display the answer 3160 data received so far, process the LDAP URLs according 3161 to the rules described in section 7.4.3 and start new 3162 query processes for each referral at step 7.3.1.b. 3164 Any additional subordinate reference referrals or 3165 continuation reference referrals which are encountered 3166 from any subsequent queries will need to be processed 3167 in the same manner as specified above, until no 3168 additional referrals are received. 3170 c. If this process fails, report the failure to the user and 3171 exit the current search operation. 3173 7.3.2. Targeted search example 3174 In the example below, the user has provided an LDAP URL of 3175 "ldap://ldap.example.com/cn=admins,ou=admins,dc=example,dc=com", 3176 and has indicated that the query is for an inetOrgPerson entry. 3178 a. The query string is used to form a DNS lookup of the 3179 specified server ("ldap.example.com"). 3181 b. The client contacts the servers, and issues a search for 3182 "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", with a 3183 search base of "ou=admins,dc=example,dc=com". 3185 c. The queried server returns the information that it has. No 3186 additional referrals are provided. The client displays the 3187 data and exits the query. 3189 7.4. Supplemental Query Processing Mechanisms 3191 During the course of normal query processing, an LDAP-WHOIS client 3192 may need to use additional mechanisms to complete an operation, 3193 such as processing a URL received from a redirect operation, or 3194 issuing DNS SRV lookups against a provided domain name. 3196 7.4.1. URL processing 3198 URL processing in this specification is a function of both content 3199 and context. Different attributes and result codes provide 3200 different types of URLs, and the disposition of these URLs will 3201 depend on the query-resolution process currently being executed. 3203 On the content front, this specification allows three different 3204 forms of URLs to appear throughout this service: labeledURI 3205 attribute values, attribute references, and referral messages. 3206 Each of these usage scenarios have slightly different restrictions 3207 and formats. 3209 * The labeledURI attribute is included with the inetResources 3210 object class for the purpose of informing end-users of a 3211 generic resource associated with an entry (such as an 3212 organization's home page). The labeledURI attribute is 3213 defined in RFC 2079 for the purpose of storing generic URLs 3214 as attribute values, and uses a two-part syntax of 3215 "url://any.host:port/any/path description", with the 3216 "description" string providing a free-text description of 3217 the target specified by the URL. 3219 * Attribute references also use the two-part format of the 3220 labeledURI attribute, but with some additional restrictions 3221 as described in section 4.5 of this document. 3223 * Subordinate and continuation reference referrals use URLs 3224 for the purpose of providing referral targets. The URL 3225 format specified in [namedref] is also an explicit subset 3226 of the labeledURI format, but without the "description" 3227 free-text block. When used with the LDAP-WHOIS service, 3228 subordinate and continuation referrals are subject to some 3229 additional rules as described in section 4.5 of this 3230 document. 3232 Non-compliance with the requirements provided in section 4.5 3233 amounts to an error, and is sufficient cause for a client to stop 3234 processing a query. 3236 7.4.2. Subordinate reference referrals 3238 Subordinate reference referrals and their schema are defined in 3239 [namedref]. Subordinate reference referrals use the 3240 SearchResultDone response with a Referral result code, which is 3241 defined and described in section 4.1.11 of RFC 2251. Subordinate 3242 reference referrals use a subset of the labeledURI syntax as 3243 defined in RFC 2079, and use the syntax definitions from RFC 2255 3244 when LDAP URLs in particular are provided, although section 4.5 of 3245 this document also defines additional restrictions on the 3246 allowable URL syntax. 3248 In the context of the LDAP-WHOIS service, subordinate reference 3249 referrals are returned when the search base specified in a search 3250 operation exists as a referral object class with the ref attribute 3251 pointing to some other entry, resulting in queries with that 3252 search base being answered with a SearchResultDone referral 3253 response. This condition means that the current search operation 3254 cannot proceed past this point, and the search MUST be restarted. 3255 This will most often occur when the inetResources entry for a DIT 3256 has been redirected to another DIT, but it can also happen after 3257 continuation reference referrals have been followed or after 3258 targeted searches have been issued, and where the queried entry 3259 exists as a referral to some other entry. 3261 The procedure for processing URLs returned in a subordinate 3262 reference referral is as follows: 3264 a. RFC 2251 allows multiple URLs to be provided, although the 3265 URLs are not provided with any "preference" or "weighting" 3266 values. If a set of URLs are provided, only one of the URLs 3267 need to be tried (implementations MAY perform additional 3268 queries in an attempt to recover from temporary failures, 3269 although this is not required). Select one of the URLs at 3270 random ("round-robin"), and continue to the next step in 3271 the process. 3273 b. Extract and discard any description text which may have 3274 been provided with the URL. 3276 c. Validate the protocol label. This specification only 3277 supports the use of LDAP and LDAPS service types. URLs with 3278 other protocol identifiers are to be treated as malformed. 3280 d. Extract the host identifier element and perform any DNS 3281 lookups which may be required. URLs without host 3282 identifiers are to be treated as malformed. 3284 e. Extract the port number provided with the URL, and set it 3285 aside for use with the subsequent connection attempt. If no 3286 port number has been provided in the URL, use the default 3287 port numbers associated with the protocol, as discovered in 3288 step 7.4.2.c. 3290 f. Extract the path element from the URL for use as the search 3291 base of the subsequent search operation. URLs without path 3292 elements are to be treated as malformed. 3294 g. Restart the current search operation, using the LDAP server 3295 from step 7.4.2.d, the port number from step 7.4.2.e, and 3296 the search base formed in step 7.4.2.f. 3298 7.4.3. Continuation reference referrals 3300 Continuation reference referrals and their schema are defined in 3301 [namedref]. Continuation reference referrals use the 3302 SearchResultReference response, which is defined and described in 3303 section 4.5.3 of RFC 2251. Continuation reference referrals use a 3304 subset of the labeledURI syntax as defined in RFC 2079, and use 3305 the syntax definitions from RFC 2255 when LDAP URLs in particular 3306 are to be provided, although section 4.5 of this document also 3307 defines additional restrictions on the allowable URL syntax. 3309 For this service, continuation reference referrals are returned 3310 when the search base specified in a search operation exists, but 3311 one or more of the answer elements exist as referral object 3312 classes, resulting in one or more SearchResultReference responses. 3313 This condition means that the current search operation has 3314 partially succeeded, but that additional searches SHOULD be 3315 started in order for all of the answer data to be retrieved (in 3316 many cases, no answer data will be provided, and in those 3317 situations, new queries will be required for any data to be 3318 retrieved). This will occur whenever the assertion value of a 3319 search has matched a resource entry which is being managed by 3320 another DIT, and can occur with any of the search operations 3321 described in this document. 3323 Multiple continuation reference referrals MAY be returned in 3324 response to a search, and each of them MUST be processed in order 3325 for all of the answer data to be retrieved. 3327 The procedure for processing the URLs returned in a continuation 3328 reference referral is as follows: 3330 a. RFC 2251 allows multiple URLs to be provided, although the 3331 URLs are not provided with any "preference" or "weighting" 3332 values. If a set of URLs are provided, only one of the URLs 3333 need to be tried (implementations MAY perform additional 3334 queries in an attempt to recover from temporary failures, 3335 although this is not required). Select one of the URLs at 3336 random ("round-robin"), and continue to the next step in 3337 the process. 3339 b. Extract and discard any description text which may have 3340 been provided with the URL. 3342 c. Validate the protocol label. This specification only 3343 supports the use of LDAP and LDAPS service types. URLs with 3344 other protocol identifiers are to be treated as malformed. 3346 d. Extract the host identifier element and perform any DNS 3347 lookups which may be required. URLs without host 3348 identifiers are to be treated as malformed. 3350 e. Extract the port number provided with the URL, and set it 3351 aside for use with the subsequent connection attempt. If no 3352 port number has been provided in the URL, use the default 3353 port numbers associated with the protocol, as discovered in 3354 step 7.4.3.c. 3356 f. Extract the path element from the URL for use as the search 3357 base of the subsequent search operation. URLs without path 3358 elements are to be treated as malformed. 3360 g. Extract the left-most RDN from the search base constructed 3361 in step 7.4.3.e, and delete the naming attribute label. The 3362 resulting string will be used as the assertion value for 3363 the subsequent search operation. For example, if the path 3364 element from a URL provided a distinguished name of 3365 "cn=example.com,cn=inetResources,dc=example,dc=com", then 3366 the "cn=example.com" RDN would be used to form an assertion 3367 value of "example.com". 3369 h. Start a new search operation, using the LDAP server from 3370 step 7.4.3.d, the port number from step 7.4.3.e, the search 3371 base formed in step 7.4.3.f, and the assertion value formed 3372 in step 7.4.3.g. 3374 7.4.4. Attribute references 3376 Attribute references are defined in this document as attributes 3377 which provide URLs as pointers to contextually related 3378 information. These are not referrals, but instead are simple URLs 3379 returned as attribute values. In particular, this document defines 3380 multiple contact-related attributes which provide these URLs. 3381 Other documents may also define attributes which reuse the URL 3382 format defined here, or may define their own URL rules, as needed. 3384 For this service, attribute reference URLs are returned when an 3385 entry has an attribute defined which uses them. Attribute 3386 references are not referrals, and do not require additional 3387 processing. Clients MAY automatically start new search operations 3388 when an attribute reference is encountered, or they MAY delay 3389 processing until a user requests the action. 3391 The procedure for processing the URLs returned in an attribute 3392 reference is as follows: 3394 a. RFC 2251 allows multiple URLs to be provided, although the 3395 URLs are not provided with any "preference" or "weighting" 3396 values. If a set of URLs are provided, only one of the URLs 3397 need to be tried (implementations MAY perform additional 3398 queries in an attempt to recover from temporary failures, 3399 although this is not required). Select one of the URLs at 3400 random ("round-robin"), and continue to the next step in 3401 the process. 3403 b. Extract and discard any description text which may have 3404 been provided with the URL. 3406 c. Validate the protocol label. This specification only 3407 supports the use of LDAP and LDAPS service types. URLs with 3408 other protocol identifiers are to be treated as malformed. 3410 d. Extract the host identifier element and perform any DNS 3411 lookups which may be required. URLs without host 3412 identifiers are to be treated as malformed. 3414 e. Extract the port number provided with the URL, and set it 3415 aside for use with the subsequent connection attempt. If no 3416 port number has been provided in the URL, use the default 3417 port numbers associated with the protocol, as discovered in 3418 step 7.4.4.c. 3420 f. Extract the path element from the URL for use as the search 3421 base of the subsequent search operation. URLs without path 3422 elements are to be treated as malformed. 3424 g. Extract the left-most RDN from the search base constructed 3425 in step 7.4.4.e, and delete the naming attribute label. The 3426 resulting string will be used as the assertion value for 3427 the subsequent search operation. For example, if the path 3428 element from a URL provided a distinguished name of 3429 "cn=example.com,cn=inetResources,dc=example,dc=com", then 3430 the "cn=example.com" RDN would be used to form an assertion 3431 value of "example.com". 3433 h. Determine the object class filter to be used with the 3434 assertion value. This will depend on the attribute which 3435 provided the attribute reference. The contact-related 3436 attributes defined in this document refer to inetOrgPerson 3437 object class entries. 3439 i. Start a new search operation, using the LDAP server from 3440 step 7.4.4.d, the port number from step 7.4.4.e, the search 3441 base formed in step 7.4.4.f, the assertion value formed in 3442 step 7.4.4.g, and the new object class filter formed in 3443 step 7.4.4.h. 3445 7.4.5. SRV processing 3447 The query models described in this document make use of DNS SRV 3448 resource records whenever a new query process is started, as a way 3449 to locate the LDAP servers associated with a DIT. 3451 The procedure for constructing this SRV lookup is as follows: 3453 a. Construct an SRV-specific label pair for the service type. 3454 For LDAP queries, this will be "_ldap._tcp", while LDAPS 3455 will use "_ldaps._tcp". 3457 b. Append the SRV label pair to the left of the input domain 3458 name. In the case of an LDAP query for "example.com", this 3459 would result in an SRV-specific domain name of 3460 "_ldap._tcp.example.com". 3462 c. Issue a DNS query for the SRV resource records associated 3463 with the domain name formed in step 7.4.5.b. 3465 Multiple SRV resource records may be returned in response to a 3466 query. Each resource record identifies a different connection 3467 target, including the domain name of a server, and a port number 3468 for that server. The port number specified in a SRV resource 3469 record MUST be used for any subsequent bind and search operations. 3471 SRV resource records provide "priority" and "weight" values which 3472 MUST be used to determine the preferred server. If a server is 3473 unavailable or unreachable, a connection attempt must be made to 3474 the next-best server in the answer set. 3476 Refer to RFC 2782 for a detailed explanation of SRV resource 3477 records and their handling. 3479 8. Internationalization and Localization 3481 The LDAP-WHOIS model uses the internationalization and 3482 localization services provided by LDAPv3. In this regard, LDAP- 3483 WHOIS clients do not need to implement any special services in 3484 order to process and display internationalized attribute data, 3485 since the attribute types already provide direct support for 3486 internationalized data. 3488 LDAP-WHOIS clients may have some localization or language-specific 3489 presentation issues with regards to attribute names, in that the 3490 names of the attributes may need to be localized for specific 3491 markets. However, these services are outside the scope of the 3492 protocol operations. Any such requirements must be dealt with 3493 according to the services available on the client platform. 3495 In the case of legacy WHOIS servers which gateway requests between 3496 TCP port 43 and the LDAP-WHOIS service, the input and output 3497 language and/or locale codes MAY be specified by server-specific 3498 options, although these mechanisms must be defined as part of the 3499 WHOIS protocol for any widespread consistency to be possible, and 3500 are therefore beyond the scope of this document. 3502 9. DIT Replication 3504 All DITs which provide data for global Internet resources SHOULD 3505 be replicated across two or more servers. Each of the 3506 authoritative LDAP servers for the managed resource MUST be 3507 specified with a unique DNS SRV resource record for the domain 3508 name associated with the top-level resource assignment space. 3510 For example, the top-level "com" delegation space SHOULD have two 3511 or more SRV resource records associated with the "_ldap._tcp.com" 3512 domain name, with each entry referring to separate LDAP servers, 3513 and with each of those servers maintaining accurate copies of the 3514 "dc=com" DIT (within reasonable timeliness). Similarly, the top- 3515 level " arpa" domain which is used by the IPv4 and IPv6 delegation 3516 trees SHOULD provide two or more SRV resource records for the 3517 "_ldap._tcp.arpa" domain name, as should the "in-addr.arpa" and 3518 "ip6.arpa" domain hierarchies. 3520 DITs which serve multiple organizations SHOULD also be replicated. 3521 For example, an ISP which provides LDAP-WHOIS services for their 3522 customers SHOULD also follow these same rules, since outages of 3523 those servers will affect multiple parties. Leaf-node DITs 3524 associated with an user-managed resource MAY be replicated, and 3525 are encouraged to do so. 3527 Similarly, any referrals which present URLs as answer data SHOULD 3528 provide multiple URLs, each of which reference different hosts on 3529 different networks. For leaf-node referrals, attribute references, 3530 and labeledURI references, this behavior MAY be relaxed, although 3531 it is still encouraged. 3533 Note that the most effective replication strategy will be for 3534 entities to replicate their DITs with the delegation parents, as 3535 this will allow queries for those resources to be processed by the 3536 parent servers (thereby eliminating the need for referral 3537 queries). In many cases, this will not be feasible (the servers 3538 for the "dc=com" DIT cannot be expected to host replicas of every 3539 subordinate DIT), but it is encouraged where practical. 3541 10. Transition Issues 3543 There are a handful of areas where the proposed service does not 3544 fully match with all of the existing WHOIS service offerings. 3545 These areas are discussed in more detail below. 3547 10.1. NIC Handles 3549 NIC handles represent a historical method of WHOIS lookups, tying 3550 unique identifiers to a specific record in a specific database. 3551 Given that the model proposed in this document uses a distributed 3552 lookup system rather than isolated databases, the NIC handle model 3553 is no longer necessary. Furthermore, given the limited global 3554 usability of NIC handles, they should be deprecated. 3556 However, NIC handles are an important part of the legacy service, 3557 and their continued usage is likely to be desired in at least some 3558 instances. There are two possible workarounds for this problem: 3560 * NIC handle output in legacy WHOIS systems SHOULD be replaced 3561 with an LDAP URL for the contact entries. This option 3562 facilitates faster coalescence around the LDAP-WHOIS system. 3564 * Referral entries MAY be defined for each existing NIC handle 3565 if the explicit NIC handle is still required for an 3566 application or usage, and queries for NIC handles MAY be 3567 processed through these referral entries. For example, the 3568 NIC handle of EH26 on Network Solutions' WHOIS server can be 3569 represented as "cn=EH26,cn=inetResources,dc=netsol,dc=com", 3570 with the inetOrgPerson and referral object classes defined, 3571 and with the ref attribute value pointing to an entry named 3572 "cn=Eric A. Hall,cn=inetResources,dc=ntrg,dc=com". 3574 Of the two mechanisms described above, the former is preferred. 3576 10.2. Change-Logs 3578 Several WHOIS services provide pseudo change-logs in their 3579 response data, listing each unique modification event which has 3580 occurred for a particular resource. For example, RIPE and some of 3581 its member ccTLDs provide WHOIS output which includes a series of 3582 "changed" fields that itemize every modification event ("updated", 3583 "added", etc.), the modifier, and the modification date, which 3584 cumulatively act as a change-log for the resource in question. 3586 While this service is useful and informative to the delegating 3587 bodies, this information is not as useful to external entities. 3588 Furthermore, the principle use of this information is for the 3589 purpose of internal audits, rather than external information. 3590 Finally, a subset of this kind of information is already provided 3591 in the *modified* operational attributes, which are always 3592 available for public review. 3594 Organizations are certainly free to maintain this information on 3595 their internal systems (and are even encouraged to do so). 3596 However, this information is not necessary for public view of the 3597 data in the LDAP-WHOIS service. Where the auditing information 3598 will be required, a format which is more suitable to legal review 3599 will be required and more appropriate. 3601 For these reasons, this service is not supported in the LDAP-WHOIS 3602 service. However, if this information is absolutely required, 3603 implementers MAY provide it as additional unstructured data via 3604 the inetGeneralComments attribute (perhaps using an 3605 "event:modifier:date" format). 3607 10.3. Open Issues 3609 The following issues require additional analysis: 3611 * inetIpv6Network entries will likely benefit from 3612 certificate-related data, although the extent and nature of 3613 this information (minimum requirements, preferred 3614 attributes, pre-existing schema, etcetera) is currently 3615 unknown by the authors. 3617 * The RIPE database v3 has several additional attributes: 3618 domain: [mandatory] [single] [primary/look-up key] 3619 descr: [mandatory] [multiple] [ ] 3620 admin-c: [mandatory] [multiple] [inverse key] 3621 tech-c: [mandatory] [multiple] [inverse key] 3622 zone-c: [mandatory] [multiple] [inverse key] 3623 nserver: [optional] [multiple] [inverse key] 3624 sub-dom: [optional] [multiple] [inverse key] 3625 dom-net: [optional] [multiple] [ ] 3626 remarks: [optional] [multiple] [ ] 3627 notify: [optional] [multiple] [inverse key] 3628 mnt-by: [optional] [multiple] [inverse key] 3629 mnt-lower: [optional] [multiple] [inverse key] 3630 refer: [optional] [single] [ ] 3631 changed: [mandatory] [multiple] [ ] 3632 source: [mandatory] [single] [ ] 3633 see http://www.ripe.net/ripe/docs/databaseref-manual.html 3635 11. Security Considerations 3637 This document describes an application of the LDAPv3 protocol, and 3638 as such it inherits the security considerations associated with 3639 LDAPv3, as described in section 7 of RFC 2251. 3641 By nature, LDAP is a read-write protocol, while the legacy WHOIS 3642 service has always been a read-only service. As such, there are 3643 significant risks associated with allowing unintended updates by 3644 unauthorized third-parties. Moreover, allowing the LDAP-WHOIS 3645 service to update the underlying delegation databases could result 3646 in network resources being stolen from their lawful operators. For 3647 example, if the LDAP front-end had update access to a domain 3648 delegation database, a malicious third-party could theoretically 3649 take ownership of that domain by exploiting an authentication 3650 weakness, thereby causing ownership of the domain to be changed to 3651 another party. For this reason, it is imperative that the LDAP- 3652 WHOIS service not be allowed to make critical modifications to 3653 delegated resources without ensuring that all possible precautions 3654 have been taken. 3656 The query processing models described in this document make use of 3657 DNS lookups in order to locate the LDAP servers associated with a 3658 particular resource. DNS is susceptible to certain attacks and 3659 forgeries which may be used to redirect clients to LDAP servers 3660 which are not authoritative for the resource in question. 3662 Some operators may choose to purposefully provide misleading or 3663 erroneous information in an effort to avoid responsibility for bad 3664 behavior. In addition, there are likely to be sporadic operator 3665 errors which will result in confusing or erroneous answers. 3667 This document provides multiple query models which will cause the 3668 same query to be answered by different servers (one would be 3669 processed by a delegation entity, while another would be processed 3670 by an operational entity). As a result, each of the servers may 3671 provide different information, depending upon the query type that 3672 was originally selected. 3674 For all of the reasons listed above, it is essential that 3675 applications and end-users not make critical decisions based on 3676 the information provided by the LDAP-WHOIS service without having 3677 reason to believe the veracity of the information. Users should 3678 limit unknown or untrusted information to routine purposes. 3680 Finally, there are physical security issues associated with any 3681 service which provides physical addressing and delivery 3682 information. Although organizations are generally encouraged to 3683 provide as much information as they feel comfortable with, no 3684 information is required. 3686 12. IANA Considerations 3688 This document defines an application of the LDAPv3 protocol rather 3689 than a new Internet application protocol. As such, there are no 3690 protocol-related IANA considerations. 3692 However, this document does define several LDAP schema elements, 3693 including object classes, attributes, syntaxes and extensibleMatch 3694 filters, and these elements should be assigned OID values from the 3695 IANA branch, rather than being assigned from a particular 3696 enterprise branch. 3698 Furthermore, this document defines delegation status codes for 3699 four of the resource types described herein, and IANA is expected 3700 to maintain the code-point mapping values associated with these 3701 attribute values. Each resource type may develop its own peculiar 3702 status codes, so each of the mapping tables will need to be 3703 maintained independently. 3705 Finally, this document also describes several instances where 3706 public DNS and LDAP servers are queried. It is expected that IANA 3707 will establish and maintain these LDAP servers (and the necessary 3708 DNS SRV domain names and resource records) required for this 3709 service to operate. This includes providing SRV resource records 3710 in the generic TLDs and the root domain, and also includes 3711 administering the referenced LDAP servers. 3713 13. Author's Addresses 3715 Eric A. Hall 3716 ehall@ehsco.com 3718 Andrew Newton 3719 anewton@research.netsol.com 3721 14. References 3723 RFC 1274 - The COSINE and Internet X.500 Schema 3725 RFC 2079 - Definition of an X.500 Attribute Type and an 3726 Object Class to Hold Uniform Resource Identifiers (URIs) 3728 RFC 2247 - Using Domains in LDAP/X.500 DNs 3730 RFC 2251 - Lightweight Directory Access Protocol (v3) 3732 RFC 2252 - Lightweight Directory Access Protocol (v3): 3733 Attribute Syntax Definitions. 3735 RFC 2253 - Lightweight Directory Access Protocol (v3): 3736 UTF-8 String Representation of DNs 3738 RFC 2254 - The String Representation of LDAP Search Filters 3740 RFC 2255 - The LDAP URL Format 3742 RFC 2256 - A Summary of the X.500(96) User Schema for use 3743 with LDAPv3 3745 RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) 3747 RFC 2782 - A DNS RR for specifying the location of services 3748 (DNS SRV) 3750 RFC 2798 - Definition of the inetOrgPerson LDAP Object 3751 Class 3752 RFC 2849 - The LDAP Data Interchange Format (LDIF) - 3753 Technical Specification 3755 [namedref] - - Named 3756 Subordinate References in LDAP Directories 3758 [ir-dir-req] - - 3759 Internet Registry Directory Requirements 3761 On a related note, VeriSign has been working on an RLDAP project 3762 [described in draft-newton-ldap-whois-00.txt (Whois Domain Data in 3763 LDAP)] that uses a query model very similar to the one described 3764 in this document, and which illustrates many of the points 3765 described in this document. The current RLDAP implementation has 3766 three client implementations, multiple distributed servers, and 3767 contains more than 32 million DNS domain entries, and 115 million 3768 resource-specific entries. In many regards, this document is an 3769 extension of RLDAP. 3771 15. Changes from Previous Versions 3773 The following changes were made to the -00 version: 3775 * The �Objectives� section has been removed. [ir-dir-req] is 3776 now being used as the guiding document for this service. 3778 * Several typographical errors have been fixed. 3780 * Some unnecessary text has been removed. 3782 * Figures changed to show complete sets of object classes, to 3783 improve inheritance visibility. 3785 * Clarified the handling of reverse-lookup domains (zones 3786 within the in-addr.arpa portion of the DNS hierarchy) in 3787 the inetDnsDomain object class reference text. 3789 * Referrals now use regular LDAP URLs (multiple responses 3790 with explicit hostnames and port numbers). Prior editions 3791 of this specification used LDAP SRV resource records for 3792 all referrals. 3794 * The delegation status codes used by the 3795 inetDnsDelegationStatus, inetIpv4DelegationStatus, 3796 inetIpv6DelegationStatus and inetAsnDelegationStatus 3797 attributes have been condensed to a more logical set. 3799 * Added an inetDnsAuthServers attribute for publishing the 3800 authoritative DNS servers associated with a domain. NOTE 3801 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 3802 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 3803 ATTRIBUTES. 3805 * Added an inetGeneralDisclaimer attribute for publishing 3806 generalized disclaimers. 3808 * Added the inetAssociatedResources auxiliary object class 3809 for defining associated resources, and moved some of the IP 3810 addressing and ASN attributes to the new object class. 3812 * Several attributes had their OIDs changed. NOTE THAT THIS 3813 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 3814 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.