idnits 2.17.1 draft-ietf-crisp-lw-ipv6-00.txt: ** The Abstract section seems to be numbered 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2002) is 7955 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: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 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-lw-ipv6-00.txt July 2002 4 Expires: January, 2003 6 Defining and Locating IPv6 Address Blocks 7 using the Internet Resource Query Service 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 This document defines LDAP schema and searching rules for IPv6 34 addresses and address blocks, in support of the Internet Resource 35 Query Service described in [ldap-whois]. 37 2. Definitions and Terminology 39 This document unites, enhances and clarifies several pre-existing 40 technologies. Readers are expected to be familiar with the 41 following specifications: 43 RFC 2247 - Using Domains in LDAP/X.500 DNs 45 RFC 2251 - Lightweight Directory Access Protocol (v3) 47 RFC 2252 - Lightweight Directory Access Protocol (v3): 48 Attribute Syntax Definitions. 50 RFC 2254 - The String Representation of LDAP Search Filters 52 RFC 2256 - A Summary of the X.500(96) User Schema for use 53 with LDAPv3 55 RFC 2798 - Definition of the inetOrgPerson LDAP Object 56 Class 58 [namedref] - - Named 59 Subordinate References in LDAP Directories 61 [ir-dir-req] - - 62 Internet Registry Directory Requirements 64 The following abbreviations are used throughout this document: 66 DIT (Directory Information Tree) - A DIT is a contained 67 branch of the LDAP namespace, having a root of a particular 68 distinguished name. "dc=example,dc=com" is used throughout 69 this document as one DIT, with many example entries being 70 stored in this DIT. 72 DN (Distinguished Name) - A distinguished name provides a 73 unique identifier for an entry, through the use of a multi- 74 level naming syntax. Entries are named according to their 75 location relevant to the root of their containing DIT. For 76 example, "cn=inetResources,dc=example,dc=com" is a DN which 77 uniquely identifies the "inetResources" entry within the 78 "dc=example,dc=com" DIT. 80 RDN (Relative DN) - An RDN provides a locally-scoped unique 81 identifier for an entry. A complete, globally-unique DN is 82 formed by concatenating the RDNs of an entry together. For 83 example, "cn=admins,cn=inetResources,dc=example,dc=com" 84 consists of two RDNs ("cn=admins" and "cn=inetResources") 85 within the "dc=example,dc=com" DIT. RDNs are typically only 86 referenced within their local scope. 88 OID (Object Identifier) - An OID is a globally-unique, 89 concatenated set of integers which provide a kind of 90 "serial number" to attributes, object classes, syntaxes and 91 other schema elements. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 94 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 95 in this document are to be interpreted as described in RFC 2119. 97 3. The inetIpv6Network Object Class 99 The inetIpv6Network object class is a structural object class 100 which provides administrative information about a specific IPv6 101 address and an associated subnet prefix (this pairing is most 102 often used to represent the starting address of an IPv6 network, 103 but can also be used to identify a specific host). 105 3.1. Naming syntax 107 The naming syntax for IPv6 network entries MUST follow the form of 108 "cn=,cn=inetResources,". Each IPv6 109 network address which is managed as a discrete LDAP-WHOIS network 110 resource MUST have a dedicated entry in each of the DITs which 111 provide public LDAP-WHOIS data regarding that network address. 113 The inetIpv6NetworkSyntax component of an entry is subject to DN 114 rules, although the inetIpv6NetworkSyntax is also used for 115 extended search operations, and is therefore subject to specific 116 syntax rules. This syntax specifically requires the use of the 117 starting address from a range of inclusive addresses, and 118 specifically requires the use of the common IPv6 prefix 119 annotation. In this manner, it is possible to create an 120 inetIpv6Network entry for a range of addresses (by specifying the 121 starting address and the network prefix size), or a single host 122 (by specifying the host-specific address and a /128 prefix). 124 In this definition, the inetIpv6NetworkSyntax uses the 125 uncompressed, 32-nibble IPv6 addressing syntax, where the network 126 address consists of eight sub-components, with each sub-component 127 consisting of four hexadecimal values that represent one nibble, 128 with each sub-component being separated by a colon character, and 129 with the entire sequence being followed by a "/" character and a 130 three-digit decimal "prefix" value. An augmented BNF for this 131 syntax is as follows: 133 inetIpv6NetworkSyntax = vSixPart ":" vSixPart ":" vSixPart 134 ":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":" 135 vSixPart "/" vSixPrefix 137 vSixPart = 4*4nibblePart 139 nibblePart = hexadecimal digit between "0" and "F" inclusive 141 vSixPrefix = decimal value between "1" and "128" inclusive, 142 with the non-affective leading zeroes removed 144 For example, an IPv6 network with a range of addresses between 145 "3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff" 146 inclusive would have a RDN of 147 "cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". Similarly, a host 148 address of "3ffe:ffff::1:2:3:4" would have the RDN of 149 "cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128". 151 Each of the 16-bit colon-separated values MUST be written in the 152 uncompressed form. Nibbles with a value of zero MUST be 153 represented by the hexadecimal sequence of "0000". 155 Note that the use of "/" is illegal in LDAP URLs when it is 156 provided as data (in particular, URLs use this character as a part 157 delimiter). This character MUST be escaped as "%2F" when it is 158 provided as part of an inetIpv6Network entry in a ref attribute. 160 3.2. Schema Definition 162 IPv6 network entries MUST exist with the top, inetResources and 163 inetIpv6Network object classes defined. If an entry exists as a 164 referral, the entry MUST also be defined with the referral object 165 class, in addition to the above requirements. 167 The inetIpv6Network object class is a structural object class 168 which is subordinate to the inetResources object class, and which 169 MUST be treated as a container class capable of holding additional 170 subordinate entries. The inetIpv6Network object class has no 171 mandatory attributes, although it does have several optional 172 attributes. 174 The inetIpv6Network object class defines attributes which are 175 specific to IPv6 networks, such as the delegation date and the 176 status of the delegation. The inetIpv6Network object class is 177 subordinate to the inetResources object class, so it inherits 178 those attributes as well. 180 Some of the inetIpv6Network object class attributes define 181 contact-related referrals which provide LDAP URLs that refer to 182 inetOrgPerson entries, and these entries will need to be queried 183 separately if detailed information about a particular contact is 184 required. The contact attribute values follow the same rules as 185 the labeledURI attribute defined in RFC 2079, with additional 186 restrictions described in [ldap-whois]. 188 The various ModifiedBy and ModifiedDate attributes SHOULD be 189 treated as operational attributes. Their values SHOULD be filled 190 in automatically by the database management application, and 191 SHOULD NOT be returned except when explicitly requested. 193 The schema definition for the inetIpv6Network object class is as 194 follows: 196 inetIpv6Network 197 ( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetIpv6Network' DESC 'IPv6 198 network attributes.' SUP inetResources STRUCTURAL MAY ( 199 inetIpv6DelegationStatus $ inetIpv6DelegationDate $ 200 inetIpv6DelegationModifiedDate $ 201 inetIpv6DelegationModifiedBy $ inetIpv6Contacts $ 202 inetIpv6ContactsModifiedBy $ inetIpv6ContactsModifiedDate $ 203 inetIpv6RoutingContacts $ inetIpv6RoutingContactsModifiedBy 204 $ inetIpv6RoutingContactsModifiedDate ) ) 206 The attributes from the inetIpv6Network object class are described 207 below: 209 inetIpv6Contacts 210 ( 1.3.6.1.4.1.7161.1.3.2 NAME 'inetIpv6Contacts' DESC 211 'Contacts for reporting problems with this network.' 212 EQUALITY caseExactMatch SYNTAX 213 1.3.6.1.4.1.1466.115.121.1.15 ) 214 inetIpv6ContactsModifiedBy 215 ( 1.3.6.1.4.1.7161.1.3.3 NAME 'inetIpv6ContactsModifiedBy' 216 DESC 'Person who last modified the inetIpv6Contacts 217 attribute.' EQUALITY distinguishedNameMatch SYNTAX 218 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 219 distributedOperation ) 221 inetIpv6ContactsModifiedDate 222 ( 1.3.6.1.4.1.7161.1.3.4 NAME 'inetIpv6ContactsModifiedDate' 223 DESC 'Last modification date of the inetIpv6Contacts 224 attribute.' EQUALITY generalizedTimeMatch ORDERING 225 generalizedTimeOrderingMatch SYNTAX 226 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 227 distributedOperation ) 229 inetIpv6DelegationDate 230 ( 1.3.6.1.4.1.7161.1.3.5 NAME 'inetIpv6DelegationDate' DESC 231 'Date of original delegation.' EQUALITY 232 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 233 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 235 inetIpv6DelegationModifiedBy 236 ( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6DelegationModifiedBy' 237 DESC 'Person who last modified the inetIpv6DelegationStatus 238 attribute.' EQUALITY distinguishedNameMatch SYNTAX 239 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 240 distributedOperation ) 242 inetIpv6DelegationModifiedDate 243 ( 1.3.6.1.4.1.7161.1.3.7 NAME 244 'inetIpv6DelegationModifiedDate' DESC 'Last modification 245 date of the inetIpv6DelegationStatus attribute.' EQUALITY 246 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 247 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 248 distributedOperation ) 250 inetIpv6DelegationStatus 251 ( 1.3.6.1.4.1.7161.1.3.8 NAME 'inetIpv6DelegationStatus' DESC 252 'Current delegation status code for this network.' EQUALITY 253 numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} 254 SINGLE-VALUE ) 256 NOTE: In an effort to facilitate internationalization and 257 programmatic processing, the current status of a delegation 258 is identified by a 16-bit integer. The values and status 259 mapping is as follows: 261 0 Reserved delegation (permanently inactive) 262 1 Assigned and active (normal state) 263 2 Assigned but not yet active (new delegation) 264 3 Assigned but on hold (disputed) 265 4 Assignment revoked (database purge pending) 267 Additional values for the inetIpv6DelegationStatus 268 attribute are reserved for future use, and are to be 269 administered by IANA. Note that there is no status code for 270 "unassigned"; unassigned entries SHOULD NOT exist, and 271 SHOULD NOT be returned as answers. 273 inetIpv6RoutingContacts 274 ( 1.3.6.1.4.1.7161.1.3.9 NAME 'inetIpv6RoutingContacts' DESC 275 'Contacts for routing issues with this network.' EQUALITY 276 caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 278 inetIpv6RoutingContactsModifiedBy 279 ( 1.3.6.1.4.1.7161.1.3.10 NAME 280 'inetIpv6RoutingContactsModifiedBy' DESC 'Person who last 281 modified the inetIpv6RoutingContacts attribute.' EQUALITY 282 distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 283 SINGLE-VALUE USAGE distributedOperation ) 285 inetIpv6RoutingContactsModifiedDate 286 ( 1.3.6.1.4.1.7161.1.3.11 NAME 287 'inetIpv6RoutingContactsModifiedDate' DESC 'Last 288 modification date of the inetIpv6RoutingContacts 289 attribute.' EQUALITY generalizedTimeMatch ORDERING 290 generalizedTimeOrderingMatch SYNTAX 291 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 292 distributedOperation ) 294 The inetIpv6NetworkSyntax syntax is as follows: 296 inetIpv6NetworkSyntax 297 ( 1.3.6.1.4.1.7161.1.3.1 NAME 'inetIpv6NetworkSyntax' DESC 298 'An IPv6 address and prefix.' ) 300 3.3. Example 302 An example of the inetIpv6Network object class is shown in Figure 303 1 below, with attributes from the inetResources object class also 304 being used to provide administrative contacts. This data is a 305 result of a query which was sent to the LDAP servers responsible 306 for operating the ip6.arpa delegation domain. 308 cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32, 309 cn=inetResources,dc=ip6,dc=arpa 310 [top object class] 311 [inetResources object class] 312 [inetIpv6Network object class] 313 | 314 +-attribute: description 315 | value: "The example.net top-level network" 316 | 317 +-attribute: inetIpv6Contacts 318 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 319 | dc=example,dc=net" 320 | 321 +-attribute: inetGeneralContacts 322 value: "ldap://ldap.example.com/cn=admins,ou=admins, 323 dc=example,dc=net" 325 Figure 1: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32 326 inetIpv6Network delegation entry. 328 Reverse-lookup DNS domains for IPv6 address blocks are managed as 329 inetDnsDomain object class entries which are entirely different 330 network resources, and which should not be confused with the 331 inetIpv6Network object class entries. Note that due to the 128-bit 332 address size and the structuring rules defined in RFC 1886, a 333 fully-formed IPv6 reverse-lookup domain name will have 34 labels, 334 which can result in very large distinguished names. 336 4. The inetIpv6NetworkMatch Filter 338 The inetIpv6NetworkMatch filter provides an identifier and search 339 string format which collectively inform a queried server that a 340 specific IPv6 address should be searched for, and that any 341 matching inetIpv6network object class entries should be returned. 343 NOTE: IPv6 addresses are also stored in DNS for reverse- 344 lookups, and those entries are treated as inetDnsDomain 345 object class entries rather than being treated as 346 inetIpv6Network object class entries (they are treated as 347 DNS zones with their own operational administrators). As 348 such, those entries use the inetDnsDomainMatch query 349 described in [ldap-whois-dns]. 351 The inetIpv6NetworkMatch extensibleMatch filter is defined as 352 follows: 354 inetIpv6NetworkMatch 355 ( 1.3.6.1.4.1.7161.1.4.19 NAME 'inetIpv6NetworkMatch' SYNTAX 356 inetIpv6NetworkSyntax ) 358 The assertion value MUST be an IPv6 address, using the 359 inetIpv6NetworkSyntax defined in section 3. Clients MUST provide 360 assertion values in this syntax. If an input string does not match 361 this syntax, the client MAY manipulate the input string to form a 362 valid assertion value. For example, if a user provides a zero- 363 compressed IPv6 address such as 3ffe:ffff::, the client MAY 364 convert the input value to the inetIpv6NetworkSyntax form of 365 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32". 367 The server MUST compare the assertion value against the RDN of all 368 entries in the inetResources container which have an object class 369 of inetIpv6Network. Any entry for an IPv6 network resource which 370 is clearly superior to the IPv6 address provided in the input 371 string MUST be returned to the client. Entries which do not 372 encompass the queried address MUST NOT be returned. Entries which 373 do not have an object class of inetIpv6Network MUST NOT be 374 returned. 376 Using the notation format described in RFC 2254, the search filter 377 expression for the inetDnsDomainMatch query above would be written 378 as "(1.3.6.1.4.1.7161.1.4.19:= 379 3ffe:ffff:0000:0000:0000:0000:0000:0000/32)". 381 Response entries MAY be fully-developed inetIpv6Network entries, 382 or MAY be referrals generated from entries which have the 383 inetIpv6Network and referral object classes defined. Any attribute 384 values which are received MUST be displayed by the client. If a 385 subordinate reference referral is received, the client MUST 386 restart the query, using the provided data as the new search base. 387 If any continuation reference referrals are received, the client 388 SHOULD start new queries for each reference, and append the output 389 of those queries to the original query's output. 391 5. Security Considerations 392 This document describes an application of the LDAPv3 protocol, and 393 as such it inherits the security considerations associated with 394 LDAPv3, as described in section 7 of RFC 2251. 396 By nature, LDAP is a read-write protocol, while the legacy WHOIS 397 service has always been a read-only service. As such, there are 398 significant risks associated with allowing unintended updates by 399 unauthorized third-parties. Moreover, allowing the LDAP-WHOIS 400 service to update the underlying delegation databases could result 401 in network resources being stolen from their lawful operators. For 402 example, if the LDAP front-end had update access to a domain 403 delegation database, a malicious third-party could theoretically 404 take ownership of that domain by exploiting an authentication 405 weakness, thereby causing ownership of the domain to be changed to 406 another party. For this reason, it is imperative that the LDAP- 407 WHOIS service not be allowed to make critical modifications to 408 delegated resources without ensuring that all possible precautions 409 have been taken. 411 The query processing models described in this document make use of 412 DNS lookups in order to locate the LDAP servers associated with a 413 particular resource. DNS is susceptible to certain attacks and 414 forgeries which may be used to redirect clients to LDAP servers 415 which are not authoritative for the resource in question. 417 Some operators may choose to purposefully provide misleading or 418 erroneous information in an effort to avoid responsibility for bad 419 behavior. In addition, there are likely to be sporadic operator 420 errors which will result in confusing or erroneous answers. 422 This document provides multiple query models which will cause the 423 same query to be answered by different servers (one would be 424 processed by a delegation entity, while another would be processed 425 by an operational entity). As a result, each of the servers may 426 provide different information, depending upon the query type that 427 was originally selected. 429 For all of the reasons listed above, it is essential that 430 applications and end-users not make critical decisions based on 431 the information provided by the LDAP-WHOIS service without having 432 reason to believe the veracity of the information. Users should 433 limit unknown or untrusted information to routine purposes. 435 Finally, there are physical security issues associated with any 436 service which provides physical addressing and delivery 437 information. Although organizations are generally encouraged to 438 provide as much information as they feel comfortable with, no 439 information is required. 441 6. IANA Considerations 443 This document defines an application of the LDAPv3 protocol rather 444 than a new Internet application protocol. As such, there are no 445 protocol-related IANA considerations. 447 However, this document does define several LDAP schema elements, 448 including object classes, attributes, syntaxes and extensibleMatch 449 filters, and these elements should be assigned OID values from the 450 IANA branch, rather than being assigned from a particular 451 enterprise branch. 453 Finally, this document also describes several instances where 454 public DNS and LDAP servers are queried. It is expected that IANA 455 will establish and maintain these LDAP servers (and the necessary 456 DNS SRV domain names and resource records) required for this 457 service to operate. This includes providing SRV resource records 458 in the generic TLDs and the root domain, and also includes 459 administering the referenced LDAP servers. 461 7. Author's Addresses 463 Eric A. Hall 464 ehall@ehsco.com 466 8. References 468 RFC 2247 - Using Domains in LDAP/X.500 DNs 470 RFC 2251 - Lightweight Directory Access Protocol (v3) 472 RFC 2252 - Lightweight Directory Access Protocol (v3): 473 Attribute Syntax Definitions. 475 RFC 2254 - The String Representation of LDAP Search Filters 477 [ir-dir-req] - - 478 Internet Registry Directory Requirements 480 [ldap-whois] - - The 481 Internet Resource Query Service and the Internet Resource 482 Schema 484 [ldap-whois-dns] - - 485 Defining and Locating DNS Domains using the Internet 486 Resource Query Service 488 9. Acknowledgments 490 Portions of this work were funded by Network Solutions, Inc.