idnits 2.17.1 draft-ietf-crisp-firs-asn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([FIRS-CORE], [FIRS-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in ' Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (May 2003) is 7651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2798' is mentioned on line 224, but not defined == Unused Reference: 'RFC2247' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 393, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-ietf-crisp-firs-asn-00.txt May 2003 4 Expires: December, 2003 5 Category: Standards-Track 7 Defining and Locating Autonomous System Numbers 8 in the Federated Internet Registry Service 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document defines LDAP schema and searching rules for 39 autonomous system numbers, in support of the Internet Resource 40 Query Service described in [FIRS-ARCH] and [FIRS-CORE]. 42 Table of Contents 44 1. Introduction..............................................2 45 2. Prerequisites and Terminology.............................2 46 3. Naming Syntax.............................................3 47 4. Object Classes and Attributes.............................4 48 5. Query Processing Rules....................................6 49 5.1. Query Pre-Processing...................................7 50 5.2. Query Bootstrapping....................................7 51 5.3. LDAP Matching..........................................7 52 5.4. Example Query..........................................8 53 6. Security Considerations...................................9 54 7. IANA Considerations.......................................9 55 8. Author's Addresses........................................9 56 9. Normative References......................................9 57 10. Acknowledgments..........................................11 58 11. Changes from Previous Versions...........................11 59 12. Full Copyright Statement.................................11 61 1. Introduction 62 This specification defines the naming syntax, object classes, 63 attributes, matching filters, and query processing rules for 64 storing and locating Autonomous System Numbers (ASNs) in the FIRS 65 service. Refer to [FIRS-ARCH] for information on the FIRS 66 architecture and [FIRS-CORE] for the schema definitions and rules 67 which govern the FIRS service as a whole. 69 The definitions in this specification are intended to be used with 70 FIRS. Their usage outside of FIRS is not prohibited, but any such 71 usage is beyond this specification's scope of authority. 73 2. Prerequisites and Terminology 74 The complete set of specifications in the FIRS collection 75 cumulative define a structured and distributed information service 76 using LDAPv3 for the data-formatting and transport functions. This 77 specification should be read in the context of the complete set of 78 specifications, which currently include the following: 80 draft-ietf-crisp-firs-arch-00, "The Federated Internet 81 Registry Service: Architecture and Implementation" 82 [FIRS-ARCH] 83 draft-ietf-crisp-firs-core-00, "The Federated Internet 84 Registry Service: Core Elements" [FIRS-CORE] 86 draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS 87 Domains in the Federated Internet Registry Service" 88 [FIRS-DNS] 90 draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS 91 Resource Records in the Federated Internet Registry 92 Service" [FIRS-DNSRR] 94 draft-ietf-crisp-firs-contact-00, "Defining and Locating 95 Contact Persons in the Federated Internet Registry Service" 96 [FIRS-CONTCT] 98 draft-ietf-crisp-firs-asn-00, "Defining and Locating 99 Autonomous System Numbers in the Federated Internet 100 Registry Service" (this document) [FIRS-ASN] 102 draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 103 Address Blocks in the Federated Internet Registry Service" 104 [FIRS-IPV4] 106 draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 107 Address Blocks in the Federated Internet Registry Service" 108 [FIRS-IPV6] 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 111 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 112 in this document are to be interpreted as described in RFC 2119. 114 3. Naming Syntax 115 The naming syntax for ASN entries in FIRS MUST follow the form of 116 "cn=,cn=inetResources,", where 117 is the Autonomous System Number resource, and 118 where is a sequence of domainComponent relative 119 distinguished names which identifies the scope of authority for 120 the selected directory partition. 122 Entries which use the inetAsNumberSyntax rules use the decimal 123 equivalent of a 16-bit autonomous system number, with the non- 124 affective leading zeroes removed. 126 An augmented BNF for this syntax is as follows: 128 inetAsNumberSyntax = decimal value between "0" and "65535" 129 inclusive, with the non-affective leading zeroes removed 131 The schema definition for inetAsNumberSyntax is as follows: 133 inetAsNumberSyntax 134 ( 1.3.6.1.4.1.7161.1.4.1 NAME 'inetAsNumberSyntax' DESC 'An 135 autonomous system number.' ) 137 For example, an entry for ASN "1" in the "dc=arin,dc=net" 138 partition would be "cn=1,cn=inetResources,dc=arin,dc=net", while 139 an entry for AS number "65535" in the same partition would be 140 "cn=65535,cn=inetResources,dc=arin,dc=net". 142 4. Object Classes and Attributes 143 ASN-specific entries in FIRS MUST use the inetAsNumber object 144 class, in addition to the mandatory object classes defined in 145 [FIRS-CORE]. ASN entries MUST be treated as containers capable of 146 holding subordinate entries. If an entry exists as a referral 147 source, the entry MUST also be defined with the referral object 148 class, in addition to the above requirements. 150 The inetAsNumber object class is a structural object class which 151 is subordinate to the inetResources object class. The inetAsNumber 152 object class has no mandatory attributes, although it does have 153 several optional attributes. The inetAsNumber object class also 154 inherits the attributes defined in the inetResources object class, 155 including the "cn" naming attribute. 157 The schema definition for the inetAsNumber object class is as 158 follows: 160 inetAsNumber 161 ( 1.3.6.1.4.1.7161.1.4.0 NAME 'inetAsNumber' DESC 'Autonomous 162 system attributes.' SUP inetResources STRUCTURAL MAY ( 163 inetAsnDelegationStatus $ inetAsnDelegationDate $ 164 inetAsnRegistrar $ inetAsnRegistry $ inetAsnContacts $ 165 inetAsnRoutingContacts ) ) 167 The attributes from the inetAsNumber object class are described 168 below: 170 inetAsnContacts 171 ( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAsnContacts' DESC 172 'Contacts for general administrative issues concerning 173 this ASN.' EQUALITY caseIgnoreMatch SYNTAX 174 inetContactSyntax ) 176 inetAsnDelegationDate 177 ( 1.3.6.1.4.1.7161.1.4.3 NAME 'inetAsnDelegationDate' DESC 178 'Date this ASN was delegated.' EQUALITY 179 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 180 SYNTAX generalizedTime SINGLE-VALUE ) 182 inetAsnDelegationStatus 183 ( 1.3.6.1.4.1.7161.1.4.4 NAME 'inetAsnDelegationStatus' DESC 184 'Delegation status for this AS number.' EQUALITY 185 numericStringMatch SYNTAX numericString{2} SINGLE-VALUE ) 187 NOTE: In an effort to facilitate internationalization and 188 programmatic processing, the current status of a delegation 189 is identified by a 16-bit integer. The values and status 190 mapping is as follows: 192 0 Reserved delegation (permanently inactive) 193 1 Assigned and active (normal state) 194 2 Assigned but not yet active (new delegation) 195 3 Assigned but on hold (disputed) 196 4 Assignment revoked (database purge pending) 198 Additional values are reserved for future use, and are to 199 be administered by IANA. 201 Note that there is no status code for "unassigned"; 202 unassigned entries SHOULD NOT exist, and SHOULD NOT be 203 returned as answers. 205 inetAsnRegistrar 206 ( 1.3.6.1.4.1.7161.1.4.5 NAME 'inetAsnRegistrar' DESC 207 'Registrar who delegated this ASN.' EQUALITY 208 caseIgnoreMatch SYNTAX directoryString ) 210 NOTE: The inetAsnRegistrar attribute uses a URL to indicate 211 the registrar who delegated the ASN. The attribute 212 structure is identical to the labeledURI attribute, as 213 defined in [RFC2798], including the URL and textual 214 comments. The data can refer to any valid URL. 216 inetAsnRegistry 217 ( 1.3.6.1.4.1.7161.1.4.6 NAME 'inetAsnRegistry' DESC 218 'Registry where this ASN is managed.' EQUALITY 219 caseIgnoreMatch SYNTAX directoryString ) 221 NOTE: The inetAsnRegistry attribute uses a URL to indicate 222 the registry who is ultimately responsible for the ASN. The 223 attribute structure is identical to the labeledURI 224 attribute, as defined in [RFC2798], including the URL and 225 textual comments. The data can refer to any valid URL. 227 inetAsnRoutingContacts 228 ( 1.3.6.1.4.1.7161.1.4.7 NAME 'inetAsnRoutingContacts' DESC 229 'Contacts for routing-related problems with this ASN.' 230 EQUALITY caseIgnoreMatch SYNTAX inetContactSyntax ) 232 An example of an inetAsNumber entry is shown in Figure 1 below. 233 The example includes attributes from the inetAsNumber, 234 inetResources, and inetAssociatedResources object classes. 236 cn=65535,cn=inetResources,dc=arin,dc=net 237 [top object class] 238 [inetResources object class] 239 [inetAsNumber object class] 240 [inetAssociatedResources object class] 241 | 242 +-attribute: description 243 | value: "Example Hosting's autonomous system" 244 | 245 +-attribute: inetAsnContacts 246 | value: "hostmaster@example.net" 247 | 248 +-attribute: inetAssociatedIpv4Networks 249 | value: "192.0.2.0/24" 250 | 251 +-attribute: inetAsnRegistrar 252 value: "http://www.arin.net/ (ARIN)" 254 Figure 1: The entry for ASN 65535 in the dc=arin,dc=net partition. 256 5. Query Processing Rules 257 Queries for ASNs have several special requirements, as discussed 258 in the following sections. 260 Refer to [FIRS-CORE] for general information about FIRS queries. 262 5.1. Query Pre-Processing 263 Clients MUST ensure that the query input is normalized according 264 to the rules specified in section 3 before the input is used as 265 the assertion value to the resulting LDAP query. 267 There are no pre-existing mechanisms for mapping ASNs to domain 268 names. As such, there are no pre-existing mechanisms for mapping 269 ASNs to authoritative LDAP partitions. In order to facilitate 270 interoperability, FIRS queries for ASN resources MUST use 271 "dc=arpa" as the authoritative partition, and MUST use 272 "cn=inetResources,dc=arpa" for the search base. It is expected 273 that FIRS-compliant LDAP servers will be established to serve this 274 directory partition, with these servers providing entry-specific 275 referrals to registrar-specific servers. 277 5.2. Query Bootstrapping 278 FIRS clients MUST use the top-down bootstrap model by default for 279 ASN queries. 281 FIRS clients MAY use the targeted bootstrap model for queries if 282 necessary or desirable. 284 Due to the lack of any public DNS delegation mapping service, 285 there is no practical reason for FIRS clients to use the bottom-up 286 model with ASN queries. 288 5.3. LDAP Matching 289 FIRS clients MUST specify equalityMatch matching filters in LDAP 290 searches for ASN entries. 292 In order to ensure that all of the relevant entries are found 293 (including any referrals), the search filters for these resources 294 MUST specify the inetAsNumber object class and the naming element 295 of the resource as a distinguished name attribute. For example, 296 "(&(objectclass=inetAsNumber)(cn:dn:65535))" with a search base of 297 "cn=inetResources,dc=arin,dc=net" would find all of the 298 inetAsNumber object class entries with a relative distinguished 299 name of "cn=65535" in the "dc=arin,dc=net" partition. 301 The matching filters defined in this specification MUST be 302 supported by FIRS clients and servers. FIRS servers MAY support 303 additional sub-string filters, soundex filters, or any other 304 filters they wish (these may be required to support generic LDAP 305 clients), although FIRS clients MUST NOT expect any additional 306 filters to be available. 308 5.4. Example Query 309 The following example assumes that the user has specified "65535" 310 as the query value: 312 a. Normalize the input, which is "65535" in this case. 314 b. Determine the authoritative partition, which is always 315 "dc=arpa" in the case of ASNs. 317 c. Determine the search base for the query, which is always 318 "cn=inetResources,dc=arpa" in the case of ASNs. 320 d. Initiate a DNS lookup for the SRV resource records 321 associated with "_ldap._tcp.arpa." For the purpose of this 322 example, assume that this lookup succeeds, with the DNS 323 response message indicating that "firs.iana.org" is the 324 preferred LDAP server. 326 e. Submit an LDAPv3 query to the specified server, using 327 "(&(objectclass=inetAsNumber)(cn:dn:65535))" as the 328 matching filter, "cn=inetResources,dc=arpa" as the search 329 base, and the global query defaults defined in [FIRS-CORE]. 331 f. Assume that the queried server returns a continuation 332 reference referral which points to 333 "ldap:///cn=inetResources,dc=arin,dc=net". The 334 distinguished name element of 335 "cn=inetResources,dc=arin,dc=net" will be used as the new 336 search base, while "dc=arin,dc=net" will be used as the new 337 authoritative partition. 339 g. Initiate a DNS lookup for the SRV resource records 340 associated with "_ldap._tcp.arin.net." For the purpose of 341 this example, assume that this lookup succeeds, with the 342 DNS response message indicating that "firs.arin.net" is the 343 preferred LDAP server. 345 h. Submit an LDAPv3 query to the specified server, using 346 "(&(objectclass=inetAsNumber)(cn:dn:65535))" as the 347 matching filter, "cn=inetResources,dc=arin,dc=net" as the 348 search base, and the global query defaults defined in 349 [FIRS-CORE]. 351 i. Assume that no other referrals are received. Display the 352 answer data which has been received and exit the query. 354 6. Security Considerations 355 Security considerations are discussed in [FIRS-ARCH]. 357 7. IANA Considerations 358 ASNs are not currently represented in the global DNS, and there 359 are no standardized mechanisms for mapping ASNs to authoritative 360 partitions using the public DNS. This specification uses the 361 "arpa" zone for this mapping function with the expectation that 362 FIRS-capable LDAP servers will be established, and that 363 authoritative partitions will be mapped to that zone, with this 364 partition containing ASN-specific entries which will provide 365 referrals to the appropriate registrar's partitions. It is further 366 expected that IANA will oversee the creation and management of the 367 ARPA domain's LDAP SRV resource records, the "dc=arpa" LDAP 368 partition, and the necessary LDAP servers. 370 The inetAsnDelegationStatus attribute uses numeric code values. It 371 is expected that IANA will manage the assignment of these values. 373 Additional IANA considerations are discussed in [FIRS-ARCH]. 375 8. Author's Addresses 376 Eric A. Hall 377 ehall@ehsco.com 379 9. Normative References 380 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 381 and Sataluri, S. "Using Domains in LDAP/X.500 382 DNs", RFC 2247, January 1998. 384 [RFC2251] Wahl, M., Howes, T., and Kille, S. 385 "Lightweight Directory Access Protocol (v3)", 386 RFC 2251, December 1997. 388 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 389 S. "Lightweight Directory Access Protocol 390 (v3): Attribute Syntax Definitions", RFC 2252, 391 December 1997. 393 [RFC2254] Howes, T. "The String Representation of LDAP 394 Search Filters", RFC 2254, December 1997. 396 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 397 Service: Architecture and Implementation 398 Guide", draft-ietf-crisp-firs-arch-00, May 399 2003. 401 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 402 System Numbers in the Federated Internet 403 Registry Service", draft-ietf-crisp-firs-asn- 404 00, May 2003. 406 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 407 Persons in the Federated Internet Registry 408 Service", draft-ietf-crisp-firs-contact-00, 409 May 2003. 411 [FIRS-CORE] Hall, E. "The Federated Internet Registry 412 Service: Core Elements", draft-ietf-crisp- 413 firs-core-00, May 2003. 415 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 416 the Federated Internet Registry Service", 417 draft-ietf-crisp-firs-dns-00, May 2003. 419 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 420 Records in the Federated Internet Registry 421 Service", draft-ietf-crisp-firs-dnsrr-00, May 422 2003. 424 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 425 Blocks in the Federated Internet Registry 426 Service", draft-ietf-crisp-firs-ipv4-00, May 427 2003. 429 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 430 Blocks in the Federated Internet Registry 431 Service", draft-ietf-crisp-firs-ipv6-00, May 432 2003. 434 10. Acknowledgments 435 Funding for the RFC editor function is currently provided by the 436 Internet Society. 438 Portions of this document were funded by Verisign Labs. 440 The first version of this specification was co-authored by Andrew 441 Newton of Verisign Labs, and subsequent versions continue to be 442 developed with his active participation. 444 11. Changes from Previous Versions 445 draft-ietf-crisp-fir-asn-00: 447 * Restructured the document set. 449 * "Attribute references" have been eliminated from the 450 specification. All referential attributes now provide 451 actual data instead of URL pointers to data. Clients that 452 wish to retrieve these values will need to start new 453 queries using the data values instead of URLs. 455 * The attribute-specific operational attributes have been 456 eliminated as unnecessary. 458 * The inetAsnRegistrar and inetAsnRegistry attributes were 459 added. 461 * Several attributes had their OIDs changed. NOTE THAT THIS 462 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 463 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 465 * Several typographical errors have been fixed. 467 * Some unnecessary text has been removed. 469 12. Full Copyright Statement 470 Copyright (C) The Internet Society (2003). All Rights Reserved. 472 This document and translations of it may be copied and furnished 473 to others, and derivative works that comment on or otherwise 474 explain it or assist in its implementation may be prepared, 475 copied, published and distributed, in whole or in part, without 476 restriction of any kind, provided that the above copyright notice 477 and this paragraph are included on all such copies and derivative 478 works. However, this document itself may not be modified in any 479 way, such as by removing the copyright notice or references to the 480 Internet Society or other Internet organizations, except as needed 481 for the purpose of developing Internet standards in which case the 482 procedures for copyrights defined in the Internet Standards 483 process must be followed, or as required to translate it into 484 languages other than English. 486 The limited permissions granted above are perpetual and will not 487 be revoked by the Internet Society or its successors or assigns. 489 This document and the information contained herein is provided on 490 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 491 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 492 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 493 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.