idnits 2.17.1 draft-ietf-crisp-firs-ipv6-03.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. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2003) is 7559 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2798' is mentioned on line 262, but not defined == Unused Reference: 'RFC2247' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 515, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** 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) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 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-firs-ipv6-03.txt August 2003 4 Expires: March, 2004 5 Category: Experimental 7 Defining and Locating IPv6 Address Blocks 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 IPv6 39 address blocks, in support of the Federated Internet Registry 40 Service (FIRS) 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.....................................8 49 5.1. Query Pre-Processing....................................8 50 5.2. LDAP Matching...........................................9 51 5.3. Example Query..........................................11 52 6. Security Considerations...................................12 53 7. IANA Considerations.......................................12 54 8. Normative References......................................12 55 9. Changes from Previous Versions............................13 56 10. Author's Address..........................................14 57 11. Acknowledgments...........................................15 58 12. Full Copyright Statement..................................15 60 1. Introduction 62 This specification defines the naming syntax, object classes, 63 attributes, matching filters, and query processing rules for 64 storing and locating IPv6 address blocks in the FIRS service. 65 Refer to [FIRS-ARCH] for information on the FIRS architecture and 66 [FIRS-CORE] for the schema definitions and rules which govern the 67 FIRS service as a whole. 69 Note that reverse-lookup DNS domains for IPv6 address blocks are 70 managed as DNS domain entries in [FIRS-DNS]. These are entirely 71 different network resources, and should not be confused with IPv6 72 address block entries. 74 The definitions in this specification are intended to be used with 75 FIRS. Their usage outside of FIRS is not prohibited, but any such 76 usage is beyond this specification's scope of authority. 78 2. Prerequisites and Terminology 80 The complete set of specifications in the FIRS collection 81 cumulative define a structured and distributed information service 82 using LDAPv3 for the data-formatting and transport functions. This 83 specification should be read in the context of that set, which 84 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNS], 85 [FIRS-DNSRR], [FIRS-CONTCT], [FIRS-ASN] and [FIRS-IPV4]. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 88 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 89 in this document are to be interpreted as described in RFC 2119. 91 3. Naming Syntax 93 The naming syntax for IPv6 address blocks in FIRS MUST follow the 94 form of "cn=,cn=inetResources,", 95 where is the IPv6 address block resource, 96 and where is a sequence of domainComponent relative 97 distinguished names which identifies the scope of authority for 98 the selected directory partition. 100 The inetIpv6NetworkSyntax rules use the uncompressed, 32-nibble 101 notation, terminated with a subnet "prefix". The network address 102 consists of eight sub-components, each of which are separated by a 103 colon character, and which each consist of four hexadecimal values 104 that represent one nibble. The entire sequence is followed by a 105 "/" character and a three-digit decimal "prefix" value. 107 Entries which use the inetIpv6NetworkSyntax MUST use the starting 108 address from a range of inclusive addresses, and MUST use CIDR 109 prefix notation. In this manner, it is possible to create an 110 inetIpv6Network entry for a range of addresses of any size 111 (including a single host). 113 Each of the 16-bit colon-separated values MUST be written in the 114 uncompressed form. Nibbles with a value of zero MUST be 115 represented by the hexadecimal sequence of "0000". 117 If an input string does not match this syntax, a FIRS-aware 118 application MAY attempt to manipulate the input string to form a 119 valid value. For example, if a user enters a zero-compressed IPv6 120 address such as "3ffe:ffff::", the application MAY convert the 121 input value to "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" in 122 order to form a valid inetIpv6NetworkSyntax form. 124 An augmented BNF for this syntax is as follows: 126 inetIpv6NetworkSyntax = inetIpv6Octet ":" inetIpv6Octet ":" 127 inetIpv6Octet ":" inetIpv6Octet ":" inetIpv6Octet ":" 128 inetIpv6Octet ":" inetIpv6Octet ":" inetIpv6Octet "/" 129 inetIpv6Prefix 131 inetIpv6Octet = 4*4nibblePart 133 nibblePart = hexadecimal digit between "0" and "F" inclusive 135 inetIpv6Prefix = decimal value between "1" and "128" 136 inclusive, with the non-affective leading zeroes removed 138 The inetIpv6NetworkSyntax syntax is as follows: 140 inetIpv6NetworkSyntax 141 ( 1.3.6.1.4.1.7161.1.6.0 142 NAME 'inetIpv6NetworkSyntax' 143 DESC 'An IPv6 address and prefix.' ) 145 For example, an IPv6 network with a range of addresses between 146 "3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff" would 147 be written as "cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". 148 Similarly, a host address of "3ffe:ffff::1:2:3:4" would be written 149 as "cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128". 151 Note that the entry name of 152 "cn=0000:0000:0000:0000:0000:0000:0000:0000/0" encompasses the 153 entire IPv6 address space. 155 Note that the use of "/" is illegal as data in URLs, and MUST be 156 escaped before it is stored in a URL as data. 158 4. Object Classes and Attributes 160 IPv6 address block entries in FIRS MUST use the inetIpv6Network 161 object class, in addition to the mandatory object classes defined 162 in [FIRS-CORE]. IPv6 address block entries MUST be treated as 163 containers capable of holding subordinate entries. 165 If an entry exists as a referral source, the entry MUST be defined 166 with the referral object class, in addition to the other object 167 classes defined above. Referral sources MUST NOT contain 168 subordinate entries. Refer to section 3.5 of [FIRS-CORE] for more 169 information on referral entries in FIRS. 171 The inetIpv6Network object class is a structural object class 172 which is subordinate to the inetResources object class. The 173 inetIpv6Network object class has no mandatory attributes, although 174 it does have several optional attributes. The inetIpv6Network 175 object class also inherits the attributes defined in the 176 inetResources object class, including the "cn" naming attribute. 178 The schema definition for the inetIpv6Network object class is as 179 follows: 181 inetIpv6Network 182 ( 1.3.6.1.4.1.7161.1.6.1 183 NAME 'inetIpv6Network' 184 DESC 'IPv6 network attributes.' 185 SUP inetResources 186 STRUCTURAL 187 MAY ( inetIpv6DelegationStatus $ inetIpv6DelegationDate $ 188 inetIpv6Registrar $ inetIpv6Registry $ inetIpv6Contacts $ 189 inetIpv6RoutingContacts $ inetIpv6ParentNetwork $ 190 inetIpv6SiblingNetworks $ inetIpv6ChildNetworks ) ) 192 The attributes from the inetIpv6Network object class are described 193 below: 195 inetIpv6Contacts 196 ( 1.3.6.1.4.1.7161.1.6.2 197 NAME 'inetIpv6Contacts' 198 DESC 'Contacts for general administrative issues concerning 199 this address block.' 200 EQUALITY caseIgnoreMatch 201 SYNTAX 1.3.6.1.4.1.7161.1.4.0 ) 203 inetIpv6DelegationDate 204 ( 1.3.6.1.4.1.7161.1.6.3 205 NAME 'inetIpv6DelegationDate' 206 DESC 'Date this address block was delegated.' 207 EQUALITY generalizedTimeMatch 208 ORDERING generalizedTimeOrderingMatch 209 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 210 SINGLE-VALUE ) 211 inetIpv6DelegationStatus 212 ( 1.3.6.1.4.1.7161.1.6.4 213 NAME 'inetIpv6DelegationStatus' 214 DESC 'Delegation status of this address block.' 215 EQUALITY numericStringMatch 216 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} 217 SINGLE-VALUE ) 219 NOTE: In an effort to facilitate internationalization and 220 programmatic processing, the current status of a delegation 221 is identified by a 16-bit integer. The values and status 222 mapping is as follows: 224 0 Reserved delegation (permanently inactive) 225 1 Assigned and active (normal state) 226 2 Assigned but not yet active (new delegation) 227 3 Assigned but on hold (disputed) 228 4 Assignment revoked (database purge pending) 230 Additional values are reserved for future use, and are to 231 be administered by IANA. 233 Note that there is no status code for "unassigned"; 234 unassigned entries SHOULD NOT exist, and SHOULD NOT be 235 returned as answers. 237 inetIpv6Registrar 238 ( 1.3.6.1.4.1.7161.1.6.5 239 NAME 'inetIpv6Registrar' 240 DESC 'Registrar or sub-registry who delegated this address 241 block.' 242 EQUALITY caseExactMatch 243 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 245 NOTE: The inetIpv6Registrar attribute uses a URL to 246 indicate the registrar who delegated the address block. The 247 attribute structure is identical to the labeledURI 248 attribute, as defined in [RFC2798], including the URL and 249 textual comments. The data can refer to any valid URL. 251 inetIpv6Registry 252 ( 1.3.6.1.4.1.7161.1.6.6 253 NAME 'inetIpv6Registry' 254 DESC 'Regional registry where this address block is 255 managed.' 256 EQUALITY caseExactMatch 257 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 259 NOTE: The inetIpv6Registry attribute uses a URL to indicate 260 the registry who is ultimately responsible for the address 261 block. The attribute structure is identical to the 262 labeledURI attribute, as defined in [RFC2798], including 263 the URL and textual comments. The data can refer to any 264 valid URL. 266 inetIpv6ParentNetworks 267 ( 1.3.6.1.4.1.7161.1.6.7 268 NAME 'inetIpv6ParentNetworks' 269 DESC 'IPv6 parent networks directly associated with this 270 address block.' 271 EQUALITY caseIgnoreMatch 272 SYNTAX 1.3.6.1.4.1.7161.1.6.0 ) 274 inetIpv6SiblingNetworks 275 ( 1.3.6.1.4.1.7161.1.6.8 276 NAME 'inetIpv6SiblingNetworks' 277 DESC 'IPv6 sibling networks directly associated with this 278 address block.' 279 EQUALITY caseIgnoreMatch 280 SYNTAX 1.3.6.1.4.1.7161.1.6.0 ) 282 inetIpv6ChildNetworks 283 ( 1.3.6.1.4.1.7161.1.6.9 284 NAME 'inetIpv6ChildNetworks' 285 DESC 'IPv6 child networks directly associated with this 286 address block.' 287 EQUALITY caseIgnoreMatch 288 SYNTAX 1.3.6.1.4.1.7161.1.6.0 ) 289 inetIpv6RoutingContacts 290 ( 1.3.6.1.4.1.7161.1.6.10 291 NAME 'inetIpv6RoutingContacts' 292 DESC 'Contacts for routing-related problems with this 293 address block.' 294 EQUALITY caseIgnoreMatch 295 SYNTAX 1.3.6.1.4.1.7161.1.4.0 ) 297 An example of the inetIpv6Network object class is shown in Figure 298 1 below. The example includes attributes from the inetIpv6Network, 299 inetResources, and inetAssociatedResources object classes. 301 cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32, 302 cn=inetResources,dc=arin,dc=net 303 [top object class] 304 [inetResources object class] 305 [inetIpv6Network object class] 306 [inetAssociatedResources object class] 307 | 308 +-attribute: description 309 | value: "The example.net top-level network" 310 | 311 +-attribute: inetIpv6Contacts 312 | value: "hostmaster@example.com" 313 | 314 +-attribute: inetAssociatedAsNumbers 315 | value: "65535" 316 | 317 +-attribute: inetIpv6Registrar 318 value: "http://www.arin.net/ (ARIN)" 320 Figure 1: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32 address 321 block in the dc=arin,dc=net directory partition. 323 5. Query Processing Rules 325 Queries for IPv6 address blocks have several special requirements, 326 as discussed in the following sections. 328 Refer to [FIRS-CORE] for general information about FIRS queries. 330 5.1. Query Pre-Processing 332 FIRS clients MUST use the targeted bootstrap model by default for 333 IPv6 address block queries, using the "ip6.arpa" zone as the seed 334 domain for the initial query. 336 FIRS clients MAY use the top-down or bottom-up bootstrap models 337 for queries if necessary or desirable. However, it is not likely 338 that entries will be found for all IPv6 address block resources 339 using these models. As such, the targeted bootstrap model will be 340 the most useful in most cases, and MUST be used by default. 342 When the bottom-up bootstrap model is used, the authoritative 343 partition for an IPv6 address block is determined by mapping the 344 normalized input to an associated reverse-lookup DNS domain name 345 (using the process as defined in RFC 1886 [RFC1886], as amended by 346 RFC 3152 [RFC3152]), and then mapping the resulting DNS domain 347 name to a sequence of domainComponent labels. The subnet prefix 348 sequence MUST be stripped from the input address block as part of 349 this mapping process (note that these rules only apply to the 350 mapping process by which an authoritative partition is 351 constructed, and does not apply to the process by which the entry- 352 specific relative distinguished name is constructed). Due to the 353 128-bit addresses and the rules defined in [RFC1886], a fully- 354 formed IPv6 reverse-lookup domain name will have 34 labels, which 355 result in very large distinguished names. 357 For example, an IPv6 address of 358 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" would be mapped to 359 the reverse-lookup DNS domain name of 360 "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.f.f.e.f.f.3. 361 ip6.arpa." which would in turn be mapped to "dc=0,dc=0,dc=0,dc=0, 362 dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0, 363 dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=f,dc=f,dc=f,dc=f,dc=e,dc=f, 364 dc=f,dc=3,dc=ip6,dc=arpa", which would then be used as the 365 authoritative partition for the bottom-up bootstrap process. 367 5.2. LDAP Matching 369 If the server advertises the inetIpv6Network object class and 370 inetIpv6NetworkMatch matching filter in the inetResourcesControl 371 server control, FIRS clients MUST use the inetIpv6NetworkMatch 372 matching filter in LDAP searches for IPv6 network entries. 374 The inetIpv6NetworkMatch filter provides an identifier and search 375 string format which collectively inform a queried server that a 376 specific IPv6 address should be searched for, and that any 377 matching inetIpv6network object class entries should be returned. 379 The inetIpv6NetworkMatch matching filter is defined as follows: 381 inetIpv6NetworkMatch 382 ( 1.3.6.1.4.1.7161.1.6.0.1 383 NAME 'inetIpv6NetworkMatch' 384 SYNTAX 1.3.6.1.4.1.7161.1.6.0 ) 386 Clients MUST ensure that the query input is normalized according 387 to the rules specified in section 3 before the input is used as 388 the assertion value to the resulting LDAP query. 390 A FIRS server MUST compare the assertion value against the 391 distinguished name of all entries within and beneath the container 392 of the partition specified in the search base. Any entry in that 393 hierarchy with an object class of inetIpv4Network and a 394 distinguished name that is clearly superior to the IPv6 address 395 provided in the assertion value MUST be returned. Entries which do 396 not have an object class of inetIpv6Network MUST NOT be returned. 397 Entries which are not clearly superior to the queried address MUST 398 NOT be returned. 400 Note that "superiority" means that the address ranges specified in 401 the entry names clearly encompass the address range specified in 402 the assertion value. This can be reverse-computed by repeatedly 403 shrinking the prefix size of the address in the assertion value, 404 and using the resulting network/prefix pair as a matching value. 406 An example of this matching logic for IPv4 addresses is shown in 407 section 5.2 of [FIRS-IPV4]. 409 Note that the entry name of 410 "cn=0000:0000:0000:0000:0000:0000:0000:0000/0" encompasses the 411 entire IPv6 address space. When used in conjunction with 412 referrals, this entry MAY be used to redirect all 413 inetIpv6NetworkMatch queries to another partition for subsequent 414 processing. 416 The matching filters defined in this specification MUST be 417 supported by FIRS clients and servers. FIRS servers MAY support 418 additional matching filters, although FIRS clients MUST NOT expect 419 any additional filters to be available. 421 If the server does not advertise support for the 422 inetIpv6NetworkMatch matching filter in the inetResourcesControl 423 server control, the client MAY choose to emulate this matching 424 filter through the use of locally-constructed equalityMatch 425 filters. However, this process can result in incomplete answers in 426 some cases, so if the server advertises support for the 427 inetIpv6NetworkMatch matching filter in the inetResourcesControl 428 control, the client MUST use it. 430 5.3. Example Query 432 The following example assumes that the user has specified 433 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" as the query value: 435 a. Normalize the input, which is 436 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" in this case. 438 b. Determine the canonical authoritative partition. 440 1. Map the input sequence to the reverse-lookup domain 441 name, which is "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 442 0.0.0.0.0.0.f.f.f.f.e.f.f.3.ip6.arpa." in this case. 444 2. Determine the domain name which is appropriate for the 445 bootstrap model in use. In the default case of a 446 targeted query, use the label sequence of "ip6.arpa". 447 In the case of a bottom-up query, use the label 448 sequence determined in step 5.3.b.1. In the case of a 449 top-down query, set the domain name to "arpa". 451 3. Map the domain name to an authoritative partition, 452 which would be "dc=ip6,dc=arpa" if the default 453 bootstrap model were in use. 455 c. Determine the search base for the query, which will be 456 "cn=inetResources,dc=ip6,dc=arpa" if the defaults are used. 458 d. Initiate a DNS lookup for the SRV resource records 459 associated with "_ldap._tcp.ip6.arpa." For the purpose of 460 this example, assume that this lookup succeeds, with the 461 DNS response message indicating that "firs.iana.org" is the 462 preferred LDAP server. 464 e. Submit an LDAPv3 query to the specified server, using 465 "(1.3.6.1.4.1.7161.1.6.0.1:= 466 3ffe:ffff:0000:0000:0000:0000:0000:0000/32)" as the 467 matching filter, "cn=inetResources,dc=ip6,dc=arpa" as the 468 search base, and the global query defaults defined in 469 [FIRS-CORE]. 471 f. Assume that no referrals are received. Display the answer 472 data which has been received and exit the query. 474 6. Security Considerations 476 Security considerations are discussed in [FIRS-ARCH]. 478 7. IANA Considerations 480 This specification uses the "dc=ip6,dc=arpa" directory partition 481 by default. It is expected that authoritative LDAP partitions will 482 be mapped to that zone, and that FIRS-capable LDAP servers will be 483 established to service this partition, with this partition 484 containing IPv6-specific entries which will provide referrals to 485 the appropriate RIR partitions. It is further expected that IANA 486 will oversee the creation and management of the ip6.arpa domain's 487 LDAP SRV resource records, the "dc=ip6,dc=arpa" LDAP partition, 488 and the necessary LDAP servers. 490 The inetIpv6DelegationStatus attribute uses numeric code values. 491 It is expected that IANA will manage the assignment of these 492 values. 494 Additional IANA considerations are discussed in [FIRS-ARCH]. 496 8. Normative References 498 [RFC1886] Thomson, S., and Huitema, C. "DNS Extensions 499 to support IP version 6", RFC 1886, December 500 1995. 502 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 503 and Sataluri, S. "Using Domains in LDAP/X.500 504 DNs", RFC 2247, January 1998. 506 [RFC2251] Wahl, M., Howes, T., and Kille, S. 507 "Lightweight Directory Access Protocol (v3)", 508 RFC 2251, December 1997. 510 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 511 S. "Lightweight Directory Access Protocol 512 (v3): Attribute Syntax Definitions", RFC 2252, 513 December 1997. 515 [RFC2254] Howes, T. "The String Representation of LDAP 516 Search Filters", RFC 2254, December 1997. 518 [RFC3152] Bush, R. "Delegation of IP6.ARPA", RFC 3152, 519 August 2001. 521 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 522 Service: Architecture and Implementation 523 Guide", draft-ietf-crisp-firs-arch-03, August 524 2003. 526 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 527 System Numbers in the Federated Internet 528 Registry Service", draft-ietf-crisp-firs-asn- 529 03, August 2003. 531 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 532 Persons in the Federated Internet Registry 533 Service", draft-ietf-crisp-firs-contact-03, 534 August 2003. 536 [FIRS-CORE] Hall, E. "The Federated Internet Registry 537 Service: Core Elements", draft-ietf-crisp- 538 firs-core-03, August 2003. 540 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 541 the Federated Internet Registry Service", 542 draft-ietf-crisp-firs-dns-03, August 2003. 544 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 545 Records in the Federated Internet Registry 546 Service", draft-ietf-crisp-firs-dnsrr-02, July 547 2003. 549 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 550 Blocks in the Federated Internet Registry 551 Service", draft-ietf-crisp-firs-ipv4-03, 552 August 2003. 554 9. Changes from Previous Versions 556 draft-ietf-crisp-firs-ipv6-03: 558 * Several clarifications and corrections have been made. 560 * Added the inetIpv6ParentNetworks, inetIpv6SiblingNetworks, 561 and inetIpv6ChildNetworks attributes. 563 * Several attributes had their OIDs changed. NOTE THAT THIS 564 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 565 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 567 draft-ietf-crisp-firs-ipv6-02: 569 * Several clarifications and corrections have been made. 571 * Changed the default bootstrap model to use targeted 572 queries, with "ip6.arpa" as the default zone and 573 "dc=ip6,dc=arpa" as the default partition. 575 * Several attributes had their OIDs changed. NOTE THAT THIS 576 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 577 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 579 draft-ietf-crisp-firs-ipv6-01: 581 * Several clarifications and corrections have been made. 583 draft-ietf-crisp-firs-ipv6-00: 585 * Restructured the document set. 587 * "Attribute references" have been eliminated from the 588 specification. All referential attributes now provide 589 actual data instead of URL pointers to data. Clients that 590 wish to retrieve these values will need to start new 591 queries using the data values instead of URLs. 593 * The attribute-specific operational attributes have been 594 eliminated as unnecessary. 596 * The inetIpv6Registrar and inetIpv6Registry attributes were 597 added. 599 * Several attributes had their OIDs changed. NOTE THAT THIS 600 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 601 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 603 * Several typographical errors have been fixed. 605 * Some unnecessary text has been removed. 607 10. Author's Address 609 Eric A. Hall 610 ehall@ehsco.com 611 11. Acknowledgments 613 Funding for the RFC editor function is currently provided by the 614 Internet Society. 616 Portions of this document were funded by VeriSign Labs. 618 The first version of this specification was co-authored by Andrew 619 Newton of VeriSign Labs, and subsequent versions continue to be 620 developed with his active participation. Edward Lewis also 621 contributed significant feedback to this specification in the 622 later stages of its developments. 624 12. Full Copyright Statement 626 Copyright (C) The Internet Society (2003). All Rights Reserved. 628 This document and translations of it may be copied and furnished 629 to others, and derivative works that comment on or otherwise 630 explain it or assist in its implementation may be prepared, 631 copied, published and distributed, in whole or in part, without 632 restriction of any kind, provided that the above copyright notice 633 and this paragraph are included on all such copies and derivative 634 works. However, this document itself may not be modified in any 635 way, such as by removing the copyright notice or references to the 636 Internet Society or other Internet organizations, except as needed 637 for the purpose of developing Internet standards in which case the 638 procedures for copyrights defined in the Internet Standards 639 process must be followed, or as required to translate it into 640 languages other than English. 642 The limited permissions granted above are perpetual and will not 643 be revoked by the Internet Society or its successors or assigns. 645 This document and the information contained herein is provided on 646 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 648 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 649 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.