idnits 2.17.1 draft-ietf-crisp-firs-ipv6-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. == There are 3 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 (May 2003) is 7651 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2798' is mentioned on line 265, but not defined == Unused Reference: 'RFC2247' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 472, 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) == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-00 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-00 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-00 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-00 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-00 == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-00 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-00 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-00 Summary: 8 errors (**), 0 flaws (~~), 15 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-00.txt May 2003 4 Expires: December, 2003 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 Internet Resource Query Service 40 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.............................5 48 5. Query Processing Rules....................................7 49 5.1. Query Pre-Processing...................................8 50 5.2. Query Bootstrapping....................................8 51 5.3. LDAP Matching..........................................9 52 5.4. Example Query.........................................10 53 6. Security Considerations..................................11 54 7. IANA Considerations......................................11 55 8. Author's Addresses.......................................11 56 9. Normative References.....................................11 57 10. Acknowledgments..........................................12 58 11. Changes from Previous Versions...........................13 59 12. Full Copyright Statement.................................13 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 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 79 The complete set of specifications in the FIRS collection 80 cumulative define a structured and distributed information service 81 using LDAPv3 for the data-formatting and transport functions. This 82 specification should be read in the context of the complete set of 83 specifications, which currently include the following: 85 draft-ietf-crisp-firs-arch-00, "The Federated Internet 86 Registry Service: Architecture and Implementation" 87 [FIRS-ARCH] 89 draft-ietf-crisp-firs-core-00, "The Federated Internet 90 Registry Service: Core Elements" [FIRS-CORE] 92 draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS 93 Domains in the Federated Internet Registry Service" 94 [FIRS-DNS] 96 draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS 97 Resource Records in the Federated Internet Registry 98 Service" [FIRS-DNSRR] 100 draft-ietf-crisp-firs-contact-00, "Defining and Locating 101 Contact Persons in the Federated Internet Registry Service" 102 [FIRS-CONTCT] 104 draft-ietf-crisp-firs-asn-00, "Defining and Locating 105 Autonomous System Numbers in the Federated Internet 106 Registry Service" (this document) [FIRS-ASN] 108 draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 109 Address Blocks in the Federated Internet Registry Service" 110 [FIRS-IPV4] 112 draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 113 Address Blocks in the Federated Internet Registry Service" 114 [FIRS-IPV6] 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 117 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 118 in this document are to be interpreted as described in RFC 2119. 120 3. Naming Syntax 121 The naming syntax for IPv4 address blocks in FIRS MUST follow the 122 form of "cn=,cn=inetResources,", 123 where is the IPv6 address block resource, 124 and where is a sequence of domainComponent relative 125 distinguished names which identifies the scope of authority for 126 the selected directory partition. 128 The inetIpv6NetworkSyntax rules use the uncompressed, 32-nibble 129 notation, terminated with a subnet "prefix". The network address 130 consists of eight sub-components, each of which are separated by a 131 colon character, and which each consist of four hexadecimal values 132 that represent one nibble. The entire sequence is followed by a 133 "/" character and a three-digit decimal "prefix" value. 135 Entries which use the inetIpv6NetworkSyntax MUST use the starting 136 address from a range of inclusive addresses, and MUST use CIDR 137 prefix notation. In this manner, it is possible to create an 138 inetIpv6Network entry for a range of addresses of any size 139 (including a single host). 141 Each of the 16-bit colon-separated values MUST be written in the 142 uncompressed form. Nibbles with a value of zero MUST be 143 represented by the hexadecimal sequence of "0000". 145 If an input string does not match this syntax, a FIRS-aware 146 application MAY attempt to manipulate the input string to form a 147 valid value. For example, if a user enters a zero-compressed IPv6 148 address such as "3ffe:ffff::", the application MAY convert the 149 input value to "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" in 150 order to form a valid inetIpv6NetworkSyntax form. 152 An augmented BNF for this syntax is as follows: 154 inetIpv6NetworkSyntax = inetIpv6Octet ":" inetIpv6Octet ":" 155 inetIpv6Octet ":" inetIpv6Octet ":" inetIpv6Octet ":" 156 inetIpv6Octet ":" inetIpv6Octet ":" inetIpv6Octet "/" 157 inetIpv6Prefix 159 inetIpv6Octet = 4*4nibblePart 161 nibblePart = hexadecimal digit between "0" and "F" inclusive 163 inetIpv6Prefix = decimal value between "1" and "128" 164 inclusive, with the non-affective leading zeroes removed 166 The inetIpv6NetworkSyntax syntax is as follows: 168 inetIpv6NetworkSyntax 169 ( 1.3.6.1.4.1.7161.1.3.1 NAME 'inetIpv6NetworkSyntax' DESC 170 'An IPv6 address and prefix.' ) 172 For example, an IPv6 network with a range of addresses between 173 "3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff" would 174 be written as "cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". 175 Similarly, a host address of "3ffe:ffff::1:2:3:4" would be written 176 as "cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128". 178 Note that the entry name of 179 "cn=0000:0000:0000:0000:0000:0000:0000:0000/0" encompasses the 180 entire IPv6 address space. 182 Note that the use of "/" is illegal as data in URLs, and MUST be 183 escaped before it is stored in a URL as data. 185 4. Object Classes and Attributes 186 IPv6 address block entries in FIRS MUST use the inetIpv6Network 187 object class, in addition to the mandatory object classes defined 188 in [FIRS-CORE]. IPv6 address block entries MUST be treated as 189 containers capable of holding subordinate entries. If an entry 190 exists as a referral source, the entry MUST also be defined with 191 the referral object class, in addition to the above requirements. 193 The inetIpv6Network object class is a structural object class 194 which is subordinate to the inetResources object class. The 195 inetIpv6Network object class has no mandatory attributes, although 196 it does have several optional attributes. The inetIpv6Network 197 object class also inherits the attributes defined in the 198 inetResources object class, including the "cn" naming attribute. 200 The schema definition for the inetIpv6Network object class is as 201 follows: 203 inetIpv6Network 204 ( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetIpv6Network' DESC 'IPv6 205 network attributes.' SUP inetResources STRUCTURAL MAY ( 206 inetIpv6DelegationStatus $ inetIpv6DelegationDate $ 207 inetIpv6Registrar $ inetIpv6Registry $ inetIpv6Contacts $ 208 inetIpv6RoutingContacts ) ) 210 The attributes from the inetIpv6Network object class are described 211 below: 213 inetIpv6Contacts 214 ( 1.3.6.1.4.1.7161.1.3.2 NAME 'inetIpv6Contacts' DESC 215 'Contacts for general administrative issues concerning this 216 IPv6 address block.' EQUALITY caseIgnoreMatch SYNTAX 217 inetContactSyntax ) 218 inetIpv6DelegationDate 219 ( 1.3.6.1.4.1.7161.1.3.3 NAME 'inetIpv6DelegationDate' DESC 220 'Date this IPv6 address block was delegated.' EQUALITY 221 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 222 SYNTAX generalizedTime SINGLE-VALUE ) 224 inetIpv6DelegationStatus 225 ( 1.3.6.1.4.1.7161.1.3.4 NAME 'inetIpv6DelegationStatus' DESC 226 'Delegation status of this IPv6 address block.' EQUALITY 227 numericStringMatch SYNTAX numericString{2} SINGLE-VALUE ) 229 NOTE: In an effort to facilitate internationalization and 230 programmatic processing, the current status of a delegation 231 is identified by a 16-bit integer. The values and status 232 mapping is as follows: 234 0 Reserved delegation (permanently inactive) 235 1 Assigned and active (normal state) 236 2 Assigned but not yet active (new delegation) 237 3 Assigned but on hold (disputed) 238 4 Assignment revoked (database purge pending) 240 Additional values are reserved for future use, and are to 241 be administered by IANA. 243 Note that there is no status code for "unassigned"; 244 unassigned entries SHOULD NOT exist, and SHOULD NOT be 245 returned as answers. 247 inetIpv6Registrar 248 ( 1.3.6.1.4.1.7161.1.3.5 NAME 'inetIpv6Registrar' DESC 249 'Registrar who delegated this IPv6 address block.' EQUALITY 250 caseIgnoreMatch SYNTAX directoryString ) 252 NOTE: The inetIpv6Registrar attribute uses a URL to 253 indicate the registrar who delegated the address block. The 254 attribute structure is identical to the labeledURI 255 attribute, as defined in [RFC2798], including the URL and 256 textual comments. The data can refer to any valid URL. 258 inetIpv6Registry 259 ( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6Registry' DESC 260 'Registry where this IPv6 address block is managed.' 261 EQUALITY caseIgnoreMatch SYNTAX directoryString ) 262 NOTE: The inetIpv6Registry attribute uses a URL to indicate 263 the registry who is ultimately responsible for the address 264 block. The attribute structure is identical to the 265 labeledURI attribute, as defined in [RFC2798], including 266 the URL and textual comments. The data can refer to any 267 valid URL. 269 inetIpv6RoutingContacts 270 ( 1.3.6.1.4.1.7161.1.3.7 NAME 'inetIpv6RoutingContacts' DESC 271 'Contacts for routing-related problems with this IPv4 272 address block.' EQUALITY caseExactMatch SYNTAX 273 inetContactSyntax ) 275 An example of the inetIpv6Network object class is shown in Figure 276 1 below. The example includes attributes from the inetIpv6Network, 277 inetResources, and inetAssociatedResources object classes. 279 cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32, 280 cn=inetResources,dc=arin,dc=net 281 [top object class] 282 [inetResources object class] 283 [inetIpv6Network object class] 284 [inetAssociatedResources object class] 285 | 286 +-attribute: description 287 | value: "The example.net top-level network" 288 | 289 +-attribute: inetIpv6Contacts 290 | value: "hostmaster@example.com" 291 | 292 +-attribute: inetAssociatedAsNumbers 293 | value: "65535" 294 | 295 +-attribute: inetIpv6Registrar 296 value: "http://www.arin.net/ (ARIN)" 298 Figure 1: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32 address 299 block in the dc=arin,dc=net directory partition. 301 5. Query Processing Rules 302 Queries for IPv6 address blocks have several special requirements, 303 as discussed in the following sections. 305 Refer to [FIRS-CORE] for general information about FIRS queries. 307 5.1. Query Pre-Processing 308 Clients MUST ensure that the query input is normalized according 309 to the rules specified in section 3 before the input is used as 310 the assertion value to the resulting LDAP query. 312 The authoritative partition for an IPv6 address block is 313 determined by mapping the normalized input to an associated 314 reverse-lookup DNS domain name (using the process as defined in 315 RFC 1886 [RFC1886], as amended by RFC 3152 [RFC3152]), and then 316 mapping the resulting DNS domain name to a sequence of 317 domainComponent labels. The subnet prefix sequence MUST be 318 stripped from the input address block as part of this mapping 319 process (note that these rules only apply to the mapping process 320 by which an authoritative partition is constructed, and does not 321 apply to the process by which the entry-specific relative 322 distinguished name is constructed). 324 Due to the 128-bit addresses and the rules defined in [RFC1886], a 325 fully-formed IPv6 reverse-lookup domain name will have 34 labels, 326 which result in very large distinguished names. 328 For example, an IPv6 address of 329 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" would be mapped to 330 the reverse-lookup DNS domain name of 331 "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. 332 ip6.arpa." which would in turn be mapped to "dc=0,dc=0,dc=0,dc=0, 333 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, 334 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, 335 dc=f,dc=3,dc=ip6,dc=arpa". 337 5.2. Query Bootstrapping 338 FIRS clients MUST use the top-down bootstrap model by default for 339 IPv6 address block queries. As such, the search base for default 340 queries would be set to "dc=arpa" rather than being set to the 341 fully-qualified distinguished name of the authoritative partition. 343 FIRS clients MAY use the targeted or bottom-up bootstrap models 344 for queries if necessary or desirable. However, it is not likely 345 that entries will be found for all IPv6 address block resources 346 using these models. As such, the top-down bootstrap model will be 347 the most useful in most cases, and MUST be used by default. 349 5.3. LDAP Matching 350 FIRS clients MUST use the inetIpv6NetworkMatch extensible matching 351 filter in LDAP searches for IPv6 address block entries. 353 The inetIpv6NetworkMatch filter provides an identifier and search 354 string format which collectively inform a queried server that a 355 specific IPv6 address should be searched for, and that any 356 matching inetIpv6network object class entries should be returned. 358 The inetIpv6NetworkMatch extensibleMatch filter is defined as 359 follows: 361 inetIpv6NetworkMatch 362 ( 1.3.6.1.4.1.7161.1.3.8 NAME 'inetIpv6NetworkMatch' SYNTAX 363 inetIpv6NetworkSyntax ) 365 The assertion value MUST be a normalized IPv6 address, using the 366 inetIpv4NetworkSyntax defined in section 3. 368 A FIRS server MUST compare the assertion value against the RDN of 369 all entries in the inetResources container of the partition 370 specified in the search base which have an object class of 371 inetIpv6Network. Any entry with an object class of inetIpv6Network 372 and with a relative distinguished name which clearly encompasses 373 the IPv6 address provided in the assertion value MUST be returned. 374 Entries which do not clearly encompass the queried address MUST 375 NOT be returned. Entries which do not have an object class of 376 inetIpv6Network MUST NOT be returned. 378 In order to ensure that all of the relevant entries are found 379 (including any referrals), the search filters for these resources 380 MUST specify the inetIpv6Network object class along with the 381 search criteria. For example, "(&(objectclass=inetIpv6Network) 382 (1.3.6.1.4.1.7161.1.3.8:= 383 3ffe:ffff:0000:0000:0000:0000:0000:0000/32))" with a search base 384 of "cn=inetResources,dc=arin,dc=net" would find all of the 385 inetIpv6Network object class entries which were superior to the 386 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" address block in the 387 "dc=arin,dc=net" partition. 389 Note that the entry name of 390 "cn=0000:0000:0000:0000:0000:0000:0000:0000/0" encompasses the 391 entire IPv6 address space. When used in conjunction with 392 referrals, this entry MAY be used to redirect all 393 inetIpv6NetworkMatch queries to another partition for subsequent 394 processing. 396 The matching filters defined in this specification MUST be 397 supported by FIRS clients and servers. FIRS servers MAY support 398 additional sub-string filters, soundex filters, or any other 399 filters they wish (these may be required to support generic LDAP 400 clients), although FIRS clients MUST NOT expect any additional 401 filters to be available. 403 5.4. Example Query 404 The following example assumes that the user has specified 405 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" as the query value: 407 a. Normalize the input, which is 408 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" in this case. 410 b. Determine the authoritative partition. 412 1. Map the input sequence to the reverse-lookup domain 413 name, which is "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 414 0.0.0.0.0.0.f.f.f.f.e.f.f.3.ip6.arpa." in this case. 416 2. Map the domain name to an authoritative partition, 417 which is "dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0, 418 dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0, 419 dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=f,dc=f,dc=f,dc=f, 420 dc=e,dc=f,dc=f,dc=3,dc=ip6,dc=arpa" in this case. By 421 default, queries for IPv6 address blocks use the top- 422 down model, meaning that the right-most relative 423 distinguished name of "dc=arpa" will be used as the 424 authoritative partition. 426 c. Determine the search base for the query, which will be 427 "cn=inetResources,dc=arpa" if the defaults are used. 429 d. Initiate a DNS lookup for the SRV resource records 430 associated with "_ldap._tcp.arpa." For the purpose of this 431 example, assume that this lookup succeeds, with the DNS 432 response message indicating that "firs.iana.org" is the 433 preferred LDAP server. 435 e. Submit an LDAPv3 query to the specified server, using 436 "(&(objectClass=inetIpv6Network)(1.3.6.1.4.1.7161.1.3.8:= 437 3ffe:ffff:0000:0000:0000:0000:0000:0000/32)" as the 438 matching filter, "cn=inetResources,dc=arpa" as the search 439 base, and the global query defaults defined in [FIRS-CORE]. 441 f. Assume that no referrals are received. Display the answer 442 data which has been received and exit the query. 444 6. Security Considerations 445 Security considerations are discussed in [FIRS-ARCH]. 447 7. IANA Considerations 448 IANA considerations are discussed in [FIRS-ARCH]. 450 8. Author's Addresses 451 Eric A. Hall 452 ehall@ehsco.com 454 9. Normative References 455 [RFC1886] Thomson, S., and Huitema, C. "DNS Extensions 456 to support IP version 6", RFC 1886, December 457 1995. 459 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 460 and Sataluri, S. "Using Domains in LDAP/X.500 461 DNs", RFC 2247, January 1998. 463 [RFC2251] Wahl, M., Howes, T., and Kille, S. 464 "Lightweight Directory Access Protocol (v3)", 465 RFC 2251, December 1997. 467 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 468 S. "Lightweight Directory Access Protocol 469 (v3): Attribute Syntax Definitions", RFC 2252, 470 December 1997. 472 [RFC2254] Howes, T. "The String Representation of LDAP 473 Search Filters", RFC 2254, December 1997. 475 [RFC3152] Bush, R. "Delegation of IP6.ARPA", RFC 3152, 476 August 2001. 478 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 479 Service: Architecture and Implementation 480 Guide", draft-ietf-crisp-firs-arch-00, May 481 2003. 483 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 484 System Numbers in the Federated Internet 485 Registry Service", draft-ietf-crisp-firs-asn- 486 00, May 2003. 488 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 489 Persons in the Federated Internet Registry 490 Service", draft-ietf-crisp-firs-contact-00, 491 May 2003. 493 [FIRS-CORE] Hall, E. "The Federated Internet Registry 494 Service: Core Elements", draft-ietf-crisp- 495 firs-core-00, May 2003. 497 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 498 the Federated Internet Registry Service", 499 draft-ietf-crisp-firs-dns-00, May 2003. 501 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 502 Records in the Federated Internet Registry 503 Service", draft-ietf-crisp-firs-dnsrr-00, May 504 2003. 506 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 507 Blocks in the Federated Internet Registry 508 Service", draft-ietf-crisp-firs-ipv4-00, May 509 2003. 511 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 512 Blocks in the Federated Internet Registry 513 Service", draft-ietf-crisp-firs-ipv6-00, May 514 2003. 516 10. Acknowledgments 517 Funding for the RFC editor function is currently provided by the 518 Internet Society. 520 Portions of this document were funded by Verisign Labs. 522 The first version of this specification was co-authored by Andrew 523 Newton of Verisign Labs, and subsequent versions continue to be 524 developed with his active participation. 526 11. Changes from Previous Versions 527 draft-ietf-crisp-fir-ipv6-00: 529 * Restructured the document set. 531 * "Attribute references" have been eliminated from the 532 specification. All referential attributes now provide 533 actual data instead of URL pointers to data. Clients that 534 wish to retrieve these values will need to start new 535 queries using the data values instead of URLs. 537 * The attribute-specific operational attributes have been 538 eliminated as unnecessary. 540 * The inetIpv6Registrar and inetIpv6Registry attributes were 541 added. 543 * Several attributes had their OIDs changed. NOTE THAT THIS 544 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 545 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 547 * Several typographical errors have been fixed. 549 * Some unnecessary text has been removed. 551 12. Full Copyright Statement 552 Copyright (C) The Internet Society (2003). All Rights Reserved. 554 This document and translations of it may be copied and furnished 555 to others, and derivative works that comment on or otherwise 556 explain it or assist in its implementation may be prepared, 557 copied, published and distributed, in whole or in part, without 558 restriction of any kind, provided that the above copyright notice 559 and this paragraph are included on all such copies and derivative 560 works. However, this document itself may not be modified in any 561 way, such as by removing the copyright notice or references to the 562 Internet Society or other Internet organizations, except as needed 563 for the purpose of developing Internet standards in which case the 564 procedures for copyrights defined in the Internet Standards 565 process must be followed, or as required to translate it into 566 languages other than English. 568 The limited permissions granted above are perpetual and will not 569 be revoked by the Internet Society or its successors or assigns. 571 This document and the information contained herein is provided on 572 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 574 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 575 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.