idnits 2.17.1 draft-ietf-crisp-firs-ipv6-01.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 270, but not defined == Unused Reference: 'RFC2247' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 486, 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-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-01 == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-01 == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-01 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-01.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 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.............................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...........................12 59 12. Full Copyright Statement.................................13 61 1. Introduction 63 This specification defines the naming syntax, object classes, 64 attributes, matching filters, and query processing rules for 65 storing and locating IPv6 address blocks in the FIRS service. 66 Refer to [FIRS-ARCH] for information on the FIRS architecture and 67 [FIRS-CORE] for the schema definitions and rules which govern the 68 FIRS service as a whole. 70 Note that reverse-lookup DNS domains for IPv6 address blocks are 71 managed as DNS domain entries in [FIRS-DNS]. These are entirely 72 different network resources, and should not be confused with IPv6 73 address block entries. 75 The definitions in this specification are intended to be used with 76 FIRS. Their usage outside of FIRS is not prohibited, but any such 77 usage is beyond this specification's scope of authority. 79 2. Prerequisites and Terminology 81 The complete set of specifications in the FIRS collection 82 cumulative define a structured and distributed information service 83 using LDAPv3 for the data-formatting and transport functions. This 84 specification should be read in the context of the complete set of 85 specifications, which currently include the following: 87 draft-ietf-crisp-firs-arch-01, "The Federated Internet 88 Registry Service: Architecture and Implementation" 89 [FIRS-ARCH] 91 draft-ietf-crisp-firs-core-01, "The Federated Internet 92 Registry Service: Core Elements" [FIRS-CORE] 94 draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS 95 Domains in the Federated Internet Registry Service" 96 [FIRS-DNS] 98 draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS 99 Resource Records in the Federated Internet Registry 100 Service" [FIRS-DNSRR] 102 draft-ietf-crisp-firs-contact-01, "Defining and Locating 103 Contact Persons in the Federated Internet Registry Service" 104 [FIRS-CONTCT] 106 draft-ietf-crisp-firs-asn-01, "Defining and Locating 107 Autonomous System Numbers in the Federated Internet 108 Registry Service" (this document) [FIRS-ASN] 110 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4 111 Address Blocks in the Federated Internet Registry Service" 112 [FIRS-IPV4] 114 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6 115 Address Blocks in the Federated Internet Registry Service" 116 [FIRS-IPV6] 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 119 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 120 in this document are to be interpreted as described in RFC 2119. 122 3. Naming Syntax 124 The naming syntax for IPv4 address blocks in FIRS MUST follow the 125 form of "cn=,cn=inetResources,", 126 where is the IPv6 address block resource, 127 and where is a sequence of domainComponent relative 128 distinguished names which identifies the scope of authority for 129 the selected directory partition. 131 The inetIpv6NetworkSyntax rules use the uncompressed, 32-nibble 132 notation, terminated with a subnet "prefix". The network address 133 consists of eight sub-components, each of which are separated by a 134 colon character, and which each consist of four hexadecimal values 135 that represent one nibble. The entire sequence is followed by a 136 "/" character and a three-digit decimal "prefix" value. 138 Entries which use the inetIpv6NetworkSyntax MUST use the starting 139 address from a range of inclusive addresses, and MUST use CIDR 140 prefix notation. In this manner, it is possible to create an 141 inetIpv6Network entry for a range of addresses of any size 142 (including a single host). 144 Each of the 16-bit colon-separated values MUST be written in the 145 uncompressed form. Nibbles with a value of zero MUST be 146 represented by the hexadecimal sequence of "0000". 148 If an input string does not match this syntax, a FIRS-aware 149 application MAY attempt to manipulate the input string to form a 150 valid value. For example, if a user enters a zero-compressed IPv6 151 address such as "3ffe:ffff::", the application MAY convert the 152 input value to "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" in 153 order to form a valid inetIpv6NetworkSyntax form. 155 An augmented BNF for this syntax is as follows: 157 inetIpv6NetworkSyntax = inetIpv6Octet ":" inetIpv6Octet ":" 158 inetIpv6Octet ":" inetIpv6Octet ":" inetIpv6Octet ":" 159 inetIpv6Octet ":" inetIpv6Octet ":" inetIpv6Octet "/" 160 inetIpv6Prefix 162 inetIpv6Octet = 4*4nibblePart 164 nibblePart = hexadecimal digit between "0" and "F" inclusive 166 inetIpv6Prefix = decimal value between "1" and "128" 167 inclusive, with the non-affective leading zeroes removed 169 The inetIpv6NetworkSyntax syntax is as follows: 171 inetIpv6NetworkSyntax 172 ( 1.3.6.1.4.1.7161.1.3.1 NAME 'inetIpv6NetworkSyntax' DESC 173 'An IPv6 address and prefix.' ) 175 For example, an IPv6 network with a range of addresses between 176 "3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff" would 177 be written as "cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". 179 Similarly, a host address of "3ffe:ffff::1:2:3:4" would be written 180 as "cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128". 182 Note that the entry name of 183 "cn=0000:0000:0000:0000:0000:0000:0000:0000/0" encompasses the 184 entire IPv6 address space. 186 Note that the use of "/" is illegal as data in URLs, and MUST be 187 escaped before it is stored in a URL as data. 189 4. Object Classes and Attributes 191 IPv6 address block entries in FIRS MUST use the inetIpv6Network 192 object class, in addition to the mandatory object classes defined 193 in [FIRS-CORE]. IPv6 address block entries MUST be treated as 194 containers capable of holding subordinate entries. If an entry 195 exists as a referral source, the entry MUST also be defined with 196 the referral object class, in addition to the above requirements. 198 The inetIpv6Network object class is a structural object class 199 which is subordinate to the inetResources object class. The 200 inetIpv6Network object class has no mandatory attributes, although 201 it does have several optional attributes. The inetIpv6Network 202 object class also inherits the attributes defined in the 203 inetResources object class, including the "cn" naming attribute. 205 The schema definition for the inetIpv6Network object class is as 206 follows: 208 inetIpv6Network 209 ( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetIpv6Network' DESC 'IPv6 210 network attributes.' SUP inetResources STRUCTURAL MAY ( 211 inetIpv6DelegationStatus $ inetIpv6DelegationDate $ 212 inetIpv6Registrar $ inetIpv6Registry $ inetIpv6Contacts $ 213 inetIpv6RoutingContacts ) ) 215 The attributes from the inetIpv6Network object class are described 216 below: 218 inetIpv6Contacts 219 ( 1.3.6.1.4.1.7161.1.3.2 NAME 'inetIpv6Contacts' DESC 220 'Contacts for general administrative issues concerning this 221 IPv6 address block.' EQUALITY caseIgnoreMatch SYNTAX 222 inetContactSyntax ) 223 inetIpv6DelegationDate 224 ( 1.3.6.1.4.1.7161.1.3.3 NAME 'inetIpv6DelegationDate' DESC 225 'Date this IPv6 address block was delegated.' EQUALITY 226 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 227 SYNTAX generalizedTime SINGLE-VALUE ) 229 inetIpv6DelegationStatus 230 ( 1.3.6.1.4.1.7161.1.3.4 NAME 'inetIpv6DelegationStatus' DESC 231 'Delegation status of this IPv6 address block.' EQUALITY 232 numericStringMatch SYNTAX numericString{2} SINGLE-VALUE ) 234 NOTE: In an effort to facilitate internationalization and 235 programmatic processing, the current status of a delegation 236 is identified by a 16-bit integer. The values and status 237 mapping is as follows: 239 0 Reserved delegation (permanently inactive) 240 1 Assigned and active (normal state) 241 2 Assigned but not yet active (new delegation) 242 3 Assigned but on hold (disputed) 243 4 Assignment revoked (database purge pending) 245 Additional values are reserved for future use, and are to 246 be administered by IANA. 248 Note that there is no status code for "unassigned"; 249 unassigned entries SHOULD NOT exist, and SHOULD NOT be 250 returned as answers. 252 inetIpv6Registrar 253 ( 1.3.6.1.4.1.7161.1.3.5 NAME 'inetIpv6Registrar' DESC 254 'Registrar who delegated this IPv6 address block.' EQUALITY 255 caseIgnoreMatch SYNTAX directoryString ) 257 NOTE: The inetIpv6Registrar attribute uses a URL to 258 indicate the registrar who delegated the address block. The 259 attribute structure is identical to the labeledURI 260 attribute, as defined in [RFC2798], including the URL and 261 textual comments. The data can refer to any valid URL. 263 inetIpv6Registry 264 ( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6Registry' DESC 265 'Registry where this IPv6 address block is managed.' 266 EQUALITY caseIgnoreMatch SYNTAX directoryString ) 267 NOTE: The inetIpv6Registry attribute uses a URL to indicate 268 the registry who is ultimately responsible for the address 269 block. The attribute structure is identical to the 270 labeledURI attribute, as defined in [RFC2798], including 271 the URL and textual comments. The data can refer to any 272 valid URL. 274 inetIpv6RoutingContacts 275 ( 1.3.6.1.4.1.7161.1.3.7 NAME 'inetIpv6RoutingContacts' DESC 276 'Contacts for routing-related problems with this IPv4 277 address block.' EQUALITY caseExactMatch SYNTAX 278 inetContactSyntax ) 280 An example of the inetIpv6Network object class is shown in Figure 281 1 below. The example includes attributes from the inetIpv6Network, 282 inetResources, and inetAssociatedResources object classes. 284 cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32, 285 cn=inetResources,dc=arin,dc=net 286 [top object class] 287 [inetResources object class] 288 [inetIpv6Network object class] 289 [inetAssociatedResources object class] 290 | 291 +-attribute: description 292 | value: "The example.net top-level network" 293 | 294 +-attribute: inetIpv6Contacts 295 | value: "hostmaster@example.com" 296 | 297 +-attribute: inetAssociatedAsNumbers 298 | value: "65535" 299 | 300 +-attribute: inetIpv6Registrar 301 value: "http://www.arin.net/ (ARIN)" 303 Figure 1: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32 address 304 block in the dc=arin,dc=net directory partition. 306 5. Query Processing Rules 308 Queries for IPv6 address blocks have several special requirements, 309 as discussed in the following sections. 311 Refer to [FIRS-CORE] for general information about FIRS queries. 313 5.1. Query Pre-Processing 315 Clients MUST ensure that the query input is normalized according 316 to the rules specified in section 3 before the input is used as 317 the assertion value to the resulting LDAP query. 319 The authoritative partition for an IPv6 address block is 320 determined by mapping the normalized input to an associated 321 reverse-lookup DNS domain name (using the process as defined in 322 RFC 1886 [RFC1886], as amended by RFC 3152 [RFC3152]), and then 323 mapping the resulting DNS domain name to a sequence of 324 domainComponent labels. The subnet prefix sequence MUST be 325 stripped from the input address block as part of this mapping 326 process (note that these rules only apply to the mapping process 327 by which an authoritative partition is constructed, and does not 328 apply to the process by which the entry-specific relative 329 distinguished name is constructed). 331 Due to the 128-bit addresses and the rules defined in [RFC1886], a 332 fully-formed IPv6 reverse-lookup domain name will have 34 labels, 333 which result in very large distinguished names. 335 For example, an IPv6 address of 336 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" would be mapped to 337 the reverse-lookup DNS domain name of 338 "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. 339 ip6.arpa." which would in turn be mapped to "dc=0,dc=0,dc=0,dc=0, 340 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, 341 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, 342 dc=f,dc=3,dc=ip6,dc=arpa". 344 5.2. Query Bootstrapping 346 FIRS clients MUST use the top-down bootstrap model by default for 347 IPv6 address block queries. As such, the search base for default 348 queries would be set to "dc=arpa" rather than being set to the 349 fully-qualified distinguished name of the authoritative partition. 351 FIRS clients MAY use the targeted or bottom-up bootstrap models 352 for queries if necessary or desirable. However, it is not likely 353 that entries will be found for all IPv6 address block resources 354 using these models. As such, the top-down bootstrap model will be 355 the most useful in most cases, and MUST be used by default. 357 5.3. LDAP Matching 359 FIRS clients MUST use the inetIpv6NetworkMatch extensible matching 360 filter in LDAP searches for IPv6 address block entries. 362 The inetIpv6NetworkMatch filter provides an identifier and search 363 string format which collectively inform a queried server that a 364 specific IPv6 address should be searched for, and that any 365 matching inetIpv6network object class entries should be returned. 367 The inetIpv6NetworkMatch extensibleMatch filter is defined as 368 follows: 370 inetIpv6NetworkMatch 371 ( 1.3.6.1.4.1.7161.1.3.8 NAME 'inetIpv6NetworkMatch' SYNTAX 372 inetIpv6NetworkSyntax ) 374 The assertion value MUST be a normalized IPv6 address, using the 375 inetIpv4NetworkSyntax defined in section 3. 377 A FIRS server MUST compare the assertion value against the RDN of 378 all entries in the inetResources container of the partition 379 specified in the search base which have an object class of 380 inetIpv6Network. Any entry with an object class of inetIpv6Network 381 and with a relative distinguished name which clearly encompasses 382 the IPv6 address provided in the assertion value MUST be returned. 383 Entries which do not clearly encompass the queried address MUST 384 NOT be returned. Entries which do not have an object class of 385 inetIpv6Network MUST NOT be returned. 387 In order to ensure that all of the relevant entries are found 388 (including any referrals), the search filters for these resources 389 MUST specify the inetIpv6Network object class along with the 390 search criteria. For example, "(&(objectclass=inetIpv6Network) 391 (1.3.6.1.4.1.7161.1.3.8:= 392 3ffe:ffff:0000:0000:0000:0000:0000:0000/32))" with a search base 393 of "cn=inetResources,dc=arin,dc=net" would find all of the 394 inetIpv6Network object class entries which were superior to the 395 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" address block in the 396 "dc=arin,dc=net" partition. 398 Note that the entry name of 399 "cn=0000:0000:0000:0000:0000:0000:0000:0000/0" encompasses the 400 entire IPv6 address space. When used in conjunction with 401 referrals, this entry MAY be used to redirect all 402 inetIpv6NetworkMatch queries to another partition for subsequent 403 processing. 405 The matching filters defined in this specification MUST be 406 supported by FIRS clients and servers. FIRS servers MAY support 407 additional sub-string filters, soundex filters, or any other 408 filters they wish (these may be required to support generic LDAP 409 clients), although FIRS clients MUST NOT expect any additional 410 filters to be available. 412 5.4. Example Query 414 The following example assumes that the user has specified 415 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" as the query value: 417 a. Normalize the input, which is 418 "3ffe:ffff:0000:0000:0000:0000:0000:0000/32" in this case. 420 b. Determine the authoritative partition. 422 1. Map the input sequence to the reverse-lookup domain 423 name, which is "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 424 0.0.0.0.0.0.f.f.f.f.e.f.f.3.ip6.arpa." in this case. 426 2. Map the domain name to an authoritative partition, 427 which is "dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0, 428 dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=0, 429 dc=0,dc=0,dc=0,dc=0,dc=0,dc=0,dc=f,dc=f,dc=f,dc=f, 430 dc=e,dc=f,dc=f,dc=3,dc=ip6,dc=arpa" in this case. By 431 default, queries for IPv6 address blocks use the top- 432 down model, meaning that the right-most relative 433 distinguished name of "dc=arpa" will be used as the 434 authoritative partition. 436 c. Determine the search base for the query, which will be 437 "cn=inetResources,dc=arpa" if the defaults are used. 439 d. Initiate a DNS lookup for the SRV resource records 440 associated with "_ldap._tcp.arpa." For the purpose of this 441 example, assume that this lookup succeeds, with the DNS 442 response message indicating that "firs.iana.org" is the 443 preferred LDAP server. 445 e. Submit an LDAPv3 query to the specified server, using 446 "(&(objectClass=inetIpv6Network)(1.3.6.1.4.1.7161.1.3.8:= 447 3ffe:ffff:0000:0000:0000:0000:0000:0000/32)" as the 448 matching filter, "cn=inetResources,dc=arpa" as the search 449 base, and the global query defaults defined in [FIRS-CORE]. 451 f. Assume that no referrals are received. Display the answer 452 data which has been received and exit the query. 454 6. Security Considerations 456 Security considerations are discussed in [FIRS-ARCH]. 458 7. IANA Considerations 460 IANA considerations are discussed in [FIRS-ARCH]. 462 8. Author's Addresses 464 Eric A. Hall 465 ehall@ehsco.com 467 9. Normative References 469 [RFC1886] Thomson, S., and Huitema, C. "DNS Extensions 470 to support IP version 6", RFC 1886, December 471 1995. 473 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 474 and Sataluri, S. "Using Domains in LDAP/X.500 475 DNs", RFC 2247, January 1998. 477 [RFC2251] Wahl, M., Howes, T., and Kille, S. 478 "Lightweight Directory Access Protocol (v3)", 479 RFC 2251, December 1997. 481 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 482 S. "Lightweight Directory Access Protocol 483 (v3): Attribute Syntax Definitions", RFC 2252, 484 December 1997. 486 [RFC2254] Howes, T. "The String Representation of LDAP 487 Search Filters", RFC 2254, December 1997. 489 [RFC3152] Bush, R. "Delegation of IP6.ARPA", RFC 3152, 490 August 2001. 492 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 493 Service: Architecture and Implementation 494 Guide", draft-ietf-crisp-firs-arch-01, May 495 2003. 497 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 498 System Numbers in the Federated Internet 499 Registry Service", draft-ietf-crisp-firs-asn- 500 01, May 2003. 502 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 503 Persons in the Federated Internet Registry 504 Service", draft-ietf-crisp-firs-contact-01, 505 May 2003. 507 [FIRS-CORE] Hall, E. "The Federated Internet Registry 508 Service: Core Elements", draft-ietf-crisp- 509 firs-core-01, May 2003. 511 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 512 the Federated Internet Registry Service", 513 draft-ietf-crisp-firs-dns-01, May 2003. 515 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 516 Records in the Federated Internet Registry 517 Service", draft-ietf-crisp-firs-dnsrr-01, May 518 2003. 520 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 521 Blocks in the Federated Internet Registry 522 Service", draft-ietf-crisp-firs-ipv4-01, May 523 2003. 525 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 526 Blocks in the Federated Internet Registry 527 Service", draft-ietf-crisp-firs-ipv6-01, May 528 2003. 530 10. Acknowledgments 532 Funding for the RFC editor function is currently provided by the 533 Internet Society. 535 Portions of this document were funded by Verisign Labs. 537 The first version of this specification was co-authored by Andrew 538 Newton of Verisign Labs, and subsequent versions continue to be 539 developed with his active participation. 541 11. Changes from Previous Versions 543 draft-ietf-crisp-firs-ipv6-01: 545 * Several clarifications and corrections have been made. 547 draft-ietf-crisp-firs-ipv6-00: 549 * Restructured the document set. 551 * "Attribute references" have been eliminated from the 552 specification. All referential attributes now provide 553 actual data instead of URL pointers to data. Clients that 554 wish to retrieve these values will need to start new 555 queries using the data values instead of URLs. 557 * The attribute-specific operational attributes have been 558 eliminated as unnecessary. 560 * The inetIpv6Registrar and inetIpv6Registry attributes were 561 added. 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 * Several typographical errors have been fixed. 569 * Some unnecessary text has been removed. 571 12. Full Copyright Statement 573 Copyright (C) The Internet Society (2003). All Rights Reserved. 575 This document and translations of it may be copied and furnished 576 to others, and derivative works that comment on or otherwise 577 explain it or assist in its implementation may be prepared, 578 copied, published and distributed, in whole or in part, without 579 restriction of any kind, provided that the above copyright notice 580 and this paragraph are included on all such copies and derivative 581 works. However, this document itself may not be modified in any 582 way, such as by removing the copyright notice or references to the 583 Internet Society or other Internet organizations, except as needed 584 for the purpose of developing Internet standards in which case the 585 procedures for copyrights defined in the Internet Standards 586 process must be followed, or as required to translate it into 587 languages other than English. 589 The limited permissions granted above are perpetual and will not 590 be revoked by the Internet Society or its successors or assigns. 592 This document and the information contained herein is provided on 593 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 594 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 595 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 596 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.