From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4698.txt | 2691 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2691 insertions(+) create mode 100644 doc/rfc/rfc4698.txt (limited to 'doc/rfc/rfc4698.txt') diff --git a/doc/rfc/rfc4698.txt b/doc/rfc/rfc4698.txt new file mode 100644 index 0000000..78579d7 --- /dev/null +++ b/doc/rfc/rfc4698.txt @@ -0,0 +1,2691 @@ + + + + + + +Network Working Group E. Gunduz +Request for Comments: 4698 RIPE NCC +Category: Standards Track A. Newton + VeriSign, Inc. + S. Kerr + RIPE NCC + October 2006 + + + IRIS: An Address Registry (areg) Type + for the Internet Registry Information Service + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes an IRIS registry schema for IP address and + Autonomous System Number information. The schema extends the + necessary query and result operations of IRIS to provide the + functional information service needs for syntaxes and results used by + Internet Protocol address registries. + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 1] + +RFC 4698 IRIS Address Registry Type October 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Document Terminology ............................................3 + 3. Schema Description ..............................................3 + 3.1. Query Derivatives ..........................................4 + 3.1.1. Query ................................4 + 3.1.2. .................................4 + 3.1.3. and + ................................5 + 3.1.4. .............................5 + 3.1.5. ..............................6 + 3.1.6. ....................................6 + 3.1.7. .....................................7 + 3.1.8. ..........................7 + 3.1.9. Contact Search Group ................................8 + 3.1.10. Common Search Group ................................8 + 3.1.11. Match Parameters ...................................8 + 3.2. Result Derivatives .........................................9 + 3.2.1. and Results .............9 + 3.2.2. Result ..........................10 + 3.2.3. Result ...................................11 + 3.2.4. Result ..............................12 + 3.2.5. Contact References .................................12 + 3.2.6. Common Result Child Elements .......................13 + 3.3. Support for ...........................13 + 4. Terminology for Nesting of Networks ............................14 + 5. Formal XML Syntax ..............................................18 + 6. BEEP Transport Compliance ......................................31 + 6.1. Message Pattern ...........................................31 + 6.2. Server Authentication .....................................31 + 7. URI Resolution .................................................31 + 7.1. Application Service Label .................................31 + 7.2. Operational Considerations ................................31 + 7.3. Top-Down Resolution .......................................31 + 8. Internationalization Considerations ............................32 + 9. IANA Considerations ............................................32 + 10. Security Considerations .......................................32 + 11. References ....................................................33 + 11.1. Normative References .....................................33 + 11.2. Informative References ...................................33 + Appendix A. Privacy Considerations ................................34 + Appendix B. Example Requests and Responses ........................34 + B.1. Example 1 .................................................34 + B.2. Example 2 .................................................36 + Appendix C. Specificity Examples ..................................39 + Appendix D. Contributors ..........................................46 + Appendix E. Acknowledgements ......................................46 + + + +Gunduz, et al. Standards Track [Page 2] + +RFC 4698 IRIS Address Registry Type October 2006 + + +1. Introduction + + An Internet address registry stores information about: + + o address ranges + + o autonomous system number ranges + + o associated contacts and organizations + + o name servers + + This information is interrelated, and Internet address registries + store this information and the information's interrelationships in a + manner befitting the needs of each Internet address registry and its + constituents. This document specifies a method for accessing and + retrieving this information in a common XML format. + + This document describes an IRIS namespace for Internet address + registries using an XML Schema [8] derived from and using the IRIS + [2] schema. This schema and registry type are provided to + demonstrate the extensibility of the IRIS framework beyond the use of + domains, a criteria defined in CRISP [4]. + + The schema given is this document is specified using the Extensible + Markup Language (XML) 1.0 as described in XML [5], XML Schema + notation as described in XML_SD [7] and XML_SS [8], and XML + Namespaces as described in XML_NS [6]. + + Examples of client/server XML exchanges with this registry type are + available in Appendix B. + +2. Document Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +3. Schema Description + + IRIS requires the derivation of both query and result elements by a + registry schema. Descriptions for these follow. + + The descriptions contained within this section refer to XML elements + and attributes and their relation to the exchange of data within the + protocol. These descriptions also contain specifications outside the + scope of the formal XML syntax. Therefore, this section will use + terms defined by RFC 2119 [1] to describe the specification outside + + + +Gunduz, et al. Standards Track [Page 3] + +RFC 4698 IRIS Address Registry Type October 2006 + + + the scope of the formal XML syntax. While reading this section, + please reference Section 5 for needed details on the formal XML + syntax. + +3.1. Query Derivatives + +3.1.1. Query + + searches for contacts given search constraints. + + The allowable search fields are handled by one of the elements in the + "contactSearchGroup" (see Section 3.1.9) or the element + . The element constrains the query + based on the organization ID (handle) associated with contacts. This + element is an "exactMatchParameter" (see Section 3.1.11). + + This query also provides optional elements containing + language tags. Clients MAY use these elements to give a hint about + the natural language(s) of the affected element. Servers MAY use + this information in processing the query, such as tailoring + normalization routines to aid in more effective searches. + + The client SHOULD pass the names unchanged to the server, and the + implementation of the server decides if the search is case sensitive + or not. + +3.1.2. + + searches for organizations given search + constraints. + + The allowable search fields are handled by one of the elements in the + "commonSearchGroup" (see Section 3.1.10) or the element + . This element is an + "exactOrPartialMatchParameter" (see Section 3.1.11). + + This query also provides optional elements containing + language tags. Clients MAY use these elements to give a hint about + the natural language(s) of the affected element. Servers MAY use + this information in processing the query, such as tailoring + normalization routines to aid in more effective searches. + + The client SHOULD pass the names unchanged to the server, and the + implementation of the server decides if the search is case sensitive + or not. + + + + + + +Gunduz, et al. Standards Track [Page 4] + +RFC 4698 IRIS Address Registry Type October 2006 + + +3.1.3. and + + The and elements + allow searches by name of autonomous systems and networks, + respectively. Both have the same format. + + The child element is an "exactOrPartialMatchParameter" (see + Section 3.1.11). + + This query also provides optional elements containing + language tags. Clients MAY use these elements to give a hint about + the natural language(s) of the affected element. Servers MAY use + this information in processing the query, such as tailoring + normalization routines to aid in more effective searches. + + The client SHOULD pass the names unchanged to the server, and the + implementation of the server decides if the search is case sensitive + or not. + +3.1.4. + + The element is a query for a network given a + related IP address or IP address range. It has the following child + elements: + + o - has a child element containing the + starting IPv4 address of the network and an optional child of + containing the ending IPv4 address of the network. Clients + MUST convert any short-form notation to the fully-qualified + notation. + + o - same as , but the child addresses + contain IPv6 addresses. Clients MUST convert any short-form + notation to the fully-qualified notation. + + o - determines the network specificity for the search + (see Section 4). Valid values are "exact-match", "all-less- + specific", "one-level-less-specific", "all-more-specific", and + "one-level-more-specific". This element may have the optional + attribute 'allowEquivalences'. When it is set to "true", the + result set should include networks with equivalent starting and + ending addresses. The default value for 'allowEquivalences' is + "false". + + The results from this query MUST be either or + results. More than one network result MAY be returned. + + + + + +Gunduz, et al. Standards Track [Page 5] + +RFC 4698 IRIS Address Registry Type October 2006 + + +3.1.5. + + The element is a query for a network given a + the handle of a related network. It has the following child + elements: + + o - specifies the network handle. + + o - determines the network specificity for the search + (see Section 4). Valid values are "all-less-specifics", "one- + level-less-specifics", "all-more-specifics", and "one-level-more- + specifics". + + The results from this query MUST be either or + results. More than one network result MAY be returned. + + This query could be used to discover the parentage relationships + between networks that have the same starting and ending addresses. + + The client SHOULD pass handles unchanged to the server, and the + implementation of the server decides if the search is case sensitive + or not. + +3.1.6. + + The element allows a search for autonomous systems + given an autonomous system number (ASN) range. It has the following + child elements: + + o - specifies the start of the ASN range. + + o - specifies the end of the ASN range. + + o - determines the range specificity for the search + (see Section 4). Valid values are "exact-match", "all-less- + specific", "one-level-less-specific", "all-more-specific", and + "one-level-more-specific". This element may have the optional + attribute 'allowEquivalences'. When it is set to "true", the + result set should include ranges with equivalent starting and + ending numbers. The default value for 'allowEquivalences' is + "false". + + The results from this query MUST be results. More + than one result MAY be returned. + + + + + + + +Gunduz, et al. Standards Track [Page 6] + +RFC 4698 IRIS Address Registry Type October 2006 + + +3.1.7. + + The element allows a search for autonomous systems, + IP networks, and organizations on fields associated with that + entity's contact. The optional search element + MUST restrict the results to autonomous systems, IPv4 networks, IPv6 + networks, or organizations using the values 'returnASs', + 'returnIPv4Networks', 'returnIPv6Networks', and + 'returnOrganizations', respectively. + + The allowable search fields are handled with either the + element or one of the elements in the + "contactSearchGroup" (see Section 3.1.9). The + element allows for the entities to be selected based on the contact + having the specified contact handle, and it is an + "exactMatchParameter" type (see Section 3.1.11). The client SHOULD + pass these search fields unchanged to the server, and the + implementation of the server decides if the search is case sensitive + or not. + + The query MAY also be constrained further using the optional + element. The contents of this element signify the role the contact + has with the entity. The allowable values for this element are + "adminContact", "nocContact", "techContact", "abuseContact", and + "otherContact". + + This query also provides optional elements containing + language tags. Clients MAY use these elements to give a hint about + the natural language(s) of the affected element. Servers MAY use + this information in processing the query, such as tailoring + normalization routines to aid in more effective searches. + + The results from this query MUST be results, + results, results, or + results. More than one result MAY be returned, and the results MAY + be of mixed types. + +3.1.8. + + The element allows a search for IP + networks based on their associated name servers. The + element contains the fully qualified domain name of the name server. + The optional search element MUST restrict the + results to IPv4 networks or IPv6 networks using the values + 'returnIPv4Networks' and 'returnIPv6Networks', respectively. + + + + + + +Gunduz, et al. Standards Track [Page 7] + +RFC 4698 IRIS Address Registry Type October 2006 + + + The results from this query MUST be or + results. More than one result MAY be returned, and the results MAY + be of mixed types. + +3.1.9. Contact Search Group + + Some of the queries above have similar query constraints for + searching on contacts. This section describes those common + parameters. + + allows the query to be constrained based on the common + name of the contact. This constraint is an + "exactOrPartialMatchParameter" (see Section 3.1.11). + + This group also contains all the members of the "commonSearchGroup" + (see Section 3.1.10). + +3.1.10. Common Search Group + + Some of the queries above have similar query constraints for + searching on contacts. This section describes those common + parameters. + + constrains the query based on the e-mail address of the + contact. This constraint is a "domainResource" type (see + Section 3.1.11). + + The , , , and elements restrict + the scope of the query based on the city, region, country, or postal + code of the contact, respectively. These constraints are all + "exactMatchParameter" types (see Section 3.1.11). The contents of + MUST be compliant with ISO 3166 [9] two-character country + codes. + +3.1.11. Match Parameters + + Some of the queries above have constraints that match strings using + matching parameters. This section describes those matching + parameters. + + Elements of type "exactMatchParameter" will have one child element of + . The contents of this child element are to match + exactly in the use of the constraint. + + Elements of type "partialMatchParameter" will have either a + child element with an optional child element + or an child element. The content of the + + + + +Gunduz, et al. Standards Track [Page 8] + +RFC 4698 IRIS Address Registry Type October 2006 + + + element specifies the beginning character sequence for the + constraint. The content of the element specifies the + ending character sequence for the constraint. + + Elements of type "exactOrPartialMatchParameter" can have either the + child element allowed with the "exactMatchParameter" type or the + child elements allowed with the "partialMatchParameter" type. + + Elements of type "domainResource" can have either the child element + allowed with the "exactMatchParameter" type or a child element of + . This parameter type is meant to match email, SIP, + Extensible Messaging and Presence Protocol (XMPP), and other types of + "user@domain" addresses. When this parameter is specified with the + child element, the constraint is based on the whole + email address. When this parameter is specified with the + child element, the constraint is based on any email address within + the domain given. The MUST only contain a valid domain + name (i.e., no '@' symbol), and the matching SHOULD take place only + on the domain given (i.e., no partial matches with respect to + substrings or parent domains). + +3.2. Result Derivatives + +3.2.1. and Results + + The and share a common definition of + 'ipNetworkType'. It has the following child elements: + + o contains the registry-unique assigned handle for + this network. + + o contains a human-friendly name for the network. + + o contains the first IP address of the network. + + o contains the last IP address of the network. + + o contains a string denoting the type of network. + + o is an entity reference to a definition of the + values explained in a plain natural language. The referent MUST + be a as defined by [2]. + + o contains the domain name of a nameserver responsible + for reverse-DNS mapping for this network. + + + + + + +Gunduz, et al. Standards Track [Page 9] + +RFC 4698 IRIS Address Registry Type October 2006 + + + o contains an entity reference to the organization + assigned this network. The referent MUST be an + (Section 3.2.4) result. + + o One of the following: + + * contains an entity reference to the parent network of + this network. The referent MUST be an + (Section 3.2.1) result if this reference is a child of + . The referent MUST be an + (Section 3.2.1) result if this reference is a child of + . + + * signifies that this network has no parent network. + + o Contact references (see Section 3.2.5). + + o Common child elements (see Section 3.2.6). + +3.2.2. Result + + The element represents an assigned or allocated + autonomous system number range. It has the following children: + + o contains a registry-unique assigned handle for this + autonomous system number range. + + o contains an integer indicating the starting number + for the autonomous system number range. + + o contains an integer indicating the ending number for + the autonomous system number range. + + o contains a human-readable name for this autonomous system. + + o contains an entity reference to the organization + assigned or allocated this autonomous system number range. The + referent MUST be an (Section 3.2.4) result. + + o One of the following: + + * contains an entity reference to the parent autonomous + system of this autonomous system. The referent MUST be an + (Section 3.2.2) result. + + * signifies that this autonomous system has no parent + autonomous system. + + + + +Gunduz, et al. Standards Track [Page 10] + +RFC 4698 IRIS Address Registry Type October 2006 + + + o Contact references (see Section 3.2.5). + + o Common child elements (see Section 3.2.6). + +3.2.3. Result + + The element represents the registration of a point of + contact. It has the following child elements: + + o contains the registry-unique assigned handle for + this contact. + + o specifies the name of the contact. + + o contains the email address for this contact. + + o contains the sip address for this contact. + + o contains an entity reference to the organization + associated with this contact. The referent MUST be an + (Section 3.2.4) result. + + o contains information for reaching the contact via + postal mail. It is composed of the following child elements: + + *
contains the address for this contact. + + * contains the city where this contact is located. + + * contains the national region where this contact is + located. + + * contains the postal code where this contact is + located. + + * contains the country code where this contact is + located. This MUST be compliant with ISO 3166 [9] + two-character country codes. + + o contains child elements describing the phone number of the + contact. The child elements are , , and + . + + o Common child elements (see Section 3.2.6). + + + + + + + +Gunduz, et al. Standards Track [Page 11] + +RFC 4698 IRIS Address Registry Type October 2006 + + +3.2.4. Result + + The element represents an organization. It has the + following child elements: + + o contains the name of the organization. + + o contains a registry-unique identifier for this organization. + + o contains the email address for this organization. + + o contains a information for reaching the + organization via postal mail. It is composed of the following + child elements: + + *
contains the address for this organization. + + * contains the city where this organization is located. + + * contains the national region where this organization + is located. + + * contains the postal code where this organization + is located. + + * contains the country code where this organization is + located. This MUST be compliant with ISO 3166 [9] + two-character country codes. + + o contains child elements describing the phone number of the + contact. The child elements are , , and + . + + o Contact references (see Section 3.2.5). + + o Common child elements (see Section 3.2.6). + +3.2.5. Contact References + + The registry schema defined in Section 5 normalizes out a group of + elements used to reference contacts. This group is used by many of + the result types for this registry. The group has the following + elements, each of which may appear as many times as needed. The + referent of each MUST be (Section 3.2.3) results. + + o + + o + + + +Gunduz, et al. Standards Track [Page 12] + +RFC 4698 IRIS Address Registry Type October 2006 + + + o + + o + + o + +3.2.6. Common Result Child Elements + + The registry schema defined in Section 5 normalizes out a group of + common elements that are used most among the result types. The group + has the following elements: + + o contains an entity reference to the + number resource registry of record. The referent MUST be an + (Section 3.2.4) result. + + o contains the date of first registration. + + o contains the date when the registration was last + updated. + + o The element contains an entity reference specifying + an entity that is indirectly associated with this result object. + This element can be used for comments and remarks. + +3.3. Support for + + The following types of entity classes are recognized by the + query of IRIS for this registry: + + o ipv4-handle - a registry-unique identifier specifying an IPv4 + network. Queries with these names will yield a + result. + + o ipv6-handle - a registry-unique identifier specifying an IPv6 + network. Queries with these names will yield a + result. + + o as-handle - a registry-unique identifier specifying an autonomous + system. It yields a result of . + + o contact-handle - a registry-unique identifier of a contact. + Yields a result of . + + o organization-id - a registry-unique identifier of an organization. + Yields a result of . + + o The entity names of these entity classes are case insensitive. + + + +Gunduz, et al. Standards Track [Page 13] + +RFC 4698 IRIS Address Registry Type October 2006 + + +4. Terminology for Nesting of Networks + + The following terms are defined for describing the nesting of IP + networks. + + o More specific: Given two networks, A and B, A is more specific + than B if network B includes all space of network A, and if + network B is larger than network A. + + o Less specific: Opposite of more specific. The network B is less + specific than network A if network A's space is completely + included in network B and if network A is smaller than network B. + + o Most specific: Given a set of networks, the network or networks + that are more specific than zero or more specific of the other + networks in the set, and that are not less specific of any of the + networks in the set. + + o Least specific: Given a set of networks, the network or networks + that are not more specific to any of the other networks in the + set. + + Examples: + + +-------------------------------------------------------+ + | | + | Given the networks A, B, C, and D as follows: | + | | + | A |---------------------------------| | + | B |-----------------| | + | C |---------| | + | D |-------| | + | | + | | + | Network A is less specific than B, C, and D. | + | Network B is more specific than A. | + | Among these four networks, A is the least specific, | + | and C and D are the most specific. | + | | + +-------------------------------------------------------+ + + Figure 1: Nesting Example 1 + + + + + + + + + +Gunduz, et al. Standards Track [Page 14] + +RFC 4698 IRIS Address Registry Type October 2006 + + + +-------------------------------------------------------+ + | | + | Given networks E, F, and G: | + | | + | E |----------| | + | F |--------------| | + | G |---| | + | | + | Networks E and F are least specific networks. | + | Networks F and G are most specific networks. | + | | + +-------------------------------------------------------+ + + Figure 2: Nesting Example 2 + + The following definitions assume that there are no overlapping + networks in the database. A network overlaps with another one when + they encompass each other's space partially. Examples: + + A |---------------------| + B |----------------------------| + + Figure 3: Nesting Example 3 + + Here, networks A and B are overlapping networks because network A + encompasses network B's space partially, and network B encompasses + network A's space partially. + + C |------------------| + D |---------| + + Figure 4: Nesting Example 4 + + Here, networks C and D are NOT overlapping networks because even if + network D encompasses a part of network C's space, network C does not + encompass network D's space partially (it encompasses network D + completely). + + The address directory can contain more than one network with the same + range. They are said to be exact match networks. + + The parent/child relationship in the internet address directory is + unidirectional. That is, there might also be parent/child + relationship with exact match networks, but a network cannot be a + parent and a child of its exact match network at the same time. + + + + + + +Gunduz, et al. Standards Track [Page 15] + +RFC 4698 IRIS Address Registry Type October 2006 + + + The following are nested matching searches: + + (1) all less specifics search: Given a range, find all the networks + that contain that range (i.e., all less specifics and exact + matches). These networks are the networks that fulfill the + following condition: + + (start(network) <= start(search)) AND (end(network) >= end(search)) + + (2) one-level less specifics search: Given a range, find only the + most specific network that contains that range (could be multiple + networks, but usually single). This is the set of networks from + (1), with the provision that no network in the return set is + contained by any other network in the set. If there are exact + match networks in the set from (1), they both must appear in the + result set. The result set may contain a network that is exact + match to the query range, if the search allows exact matches. + + A |-------------------------------| + B |---------------------------| + C |-------| + Query |- - - - - - - - - -| + + Figure 5: Nesting Example 5 + + In the above case, the query must return B. + + A |-------------------------------| + B |---------------------------| + C |---------------------------| + D |-------| + Query |- - - - - - - - - -| + + Figure 6: Nesting Example 6 + + Here, the query must return B and C (they are exact matches of + each other). + + A |-------------------------------| + B |---------------------------| + C |---------------------------| + D |-------| + Query |- - - -| + + Figure 7: Nesting Example 7 + + + + + + +Gunduz, et al. Standards Track [Page 16] + +RFC 4698 IRIS Address Registry Type October 2006 + + + Here, the query must return B and C (they are exact matches of + each other). D must not be in the result set, as it is exact + match to the query if the search specifies that exact matches of + query range should not appear in the result set. + + In Figure 7, if the search specifies that exact matches to the + query range are allowed in the result set, then only D must be + returned. + + (3) all more specifics search: Given a range, find all the networks + that are fully within that range. The search contains a flag + that specifies if an exact match to the query range should appear + in the result set or not. Thus, the result set may or may not + contain the exact match to the query range, as instructed by the + search. + + (start(network) >= start(search)) AND (end(network) <= end(search)) + + (4) one-level more specifics search: Given a range, find only the + least specific networks that are fully within that range. This + is the set of networks from (3), with the provision that no + network in the return set contains any other network in the + return set. + + Query |- - - - - - - - - - - - - - - - - - - - - - -| + + A |------------------| + B |-------------------------| + C |--------| + D |---------| + + Figure 8: Nesting Example 8 + + (5) exact match search: Given a range, find the networks that begin + and end on the same IP addresses as the range. That is, the + networks that fulfill the following condition: + + (start(network) = start(search)) AND (end(network) = end(search)) + + (6) Given a range, find the exact match network if it exists, and if + it does not, perform the (2) search. + + The following are parent-child relationship searches: + + (7) Given a network handle, find the network that is the direct (one + level up) parent of the network with the given handle. + + + + + +Gunduz, et al. Standards Track [Page 17] + +RFC 4698 IRIS Address Registry Type October 2006 + + + (8) Given a network handle, find the network or networks that are + direct (one level down) children of the network with the handle + given. + +5. Formal XML Syntax + + This IP address registry is specified in the XML Schema notation. + The formal syntax presented here is a complete schema representation + suitable for automated validation of an XML instance when combined + with the formal schema syntax of IRIS. + + + + + + + + + IP address registry schema derived from IRIS + schema + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 18] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 19] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 20] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 21] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 22] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 23] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 24] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 25] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 26] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 27] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 28] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 29] + +RFC 4698 IRIS Address Registry Type October 2006 + + + + + + + + + + + + + + + + + + + + + Figure 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 30] + +RFC 4698 IRIS Address Registry Type October 2006 + + +6. BEEP Transport Compliance + + IRIS allows several extensions of the core capabilities. This + section outlines those extensions allowable by IRIS-BEEP [3]. + +6.1. Message Pattern + + This registry type uses the default message pattern as described in + IRIS-BEEP [3]. + +6.2. Server Authentication + + This registry type uses the default server authentication method as + described in IRIS-BEEP [3]. + +7. URI Resolution + +7.1. Application Service Label + + See Section 9 for the application service label registration. + +7.2. Operational Considerations + + Address registries do not have natural links to DNS. Using reverse + DNS tree presents problems for IP address delegation (for example, + delegations do not fall into byte boundaries, unlike reverse DNS), + and DNS does not currently contain any information regarding + autonomous system delegation. + + Therefore, in order for the top-down resolution to operate properly, + it is requested that the IAB instruct IANA to insert and maintain a + NAPTR DNS resource record for areg.iris.arpa, as described in + Section 9. + +7.3. Top-Down Resolution + + The top-down alternative resolution method MUST be identified as + 'top' in IRIS URIs. + + The process for this condition is as follows: + + 1. The IRIS [2] direct-resolution process is tried against + areg.iris.arpa. + + 2. If the direct-resolution process yields no server for which a + connection can be made, then a negative response is returned, and + no further action is taken. + + + + +Gunduz, et al. Standards Track [Page 31] + +RFC 4698 IRIS Address Registry Type October 2006 + + + It is RECOMMENDED that IRIS clients issuing AREG1 requests use the + 'top' resolution method when no resolution method has been explicitly + given by a user. IRIS servers accepting AREG1 requests that seek + information for which they are not authoritative SHOULD refer clients + using the 'top' resolution method. + +8. Internationalization Considerations + + This document lays out no new considerations for internationalization + beyond those specified in IRIS [2]. + +9. IANA Considerations + + The following URN has been registered with IANA according to the IANA + considerations defined in IRIS [2]: + + urn:ietf:params:xml:ns:areg1 + + The following S-NAPTR application service label has been registered + with IANA according to the IANA considerations defined in IRIS [2]: + + AREG1 + + Under instructions from the IAB, the IANA will create a new second + level domain under .arpa called iris (i.e., iris.arpa.). The + contents of this new domain are to be under the control of the IAB. + Under instructions from the IAB, the IANA will insert and maintain a + NAPTR DNS resource record in the iris.arpa. domain for the name + areg.iris.arpa. The initial contents for that record is: + + areg.iris.arpa. + ;; order pref flags service re replacement + IN NAPTR 100 10 "" "AREG1:iris.xpc:iris.lwz" "" areg.nro.net + +10. Security Considerations + + This document lays out no new considerations for security precautions + beyond those specified in IRIS [2]. + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 32] + +RFC 4698 IRIS Address Registry Type October 2006 + + +11. References + +11.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information + Service (IRIS) Core Protocol", RFC 3981, January 2005. + + [3] Newton, A. and M. Sanz, "Using the Internet Registry Information + Service (IRIS) over the Blocks Extensible Exchange Protocol + (BEEP)", RFC 3983, January 2005. + + [4] Newton, A., "Cross Registry Internet Service Protocol (CRISP) + Requirements", RFC 3707, February 2004. + +11.2. Informative References + + [5] World Wide Web Consortium, "Extensible Markup Language (XML) + 1.0", W3C XML, February 1998, + . + + [6] World Wide Web Consortium, "Namespaces in XML", W3C XML + Namespaces, January 1999, + . + + [7] World Wide Web Consortium, "XML Schema Part 2: Datatypes", + W3C XML Schema, October 2000, + . + + [8] World Wide Web Consortium, "XML Schema Part 1: Structures", + W3C XML Schema, October 2000, + . + + [9] International Organization for Standardization, "Codes for the + representation of names of countries, 3rd edition", ISO Standard + 3166, August 1988. + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 33] + +RFC 4698 IRIS Address Registry Type October 2006 + + +Appendix A. Privacy Considerations + + Internet address registries store contact details and other + information that may be abused. The XML Schema defined in this + document purposefully makes the inclusion of any data in a response + an option that is dependent on the needs and policies of the Internet + address registry serving the data. + + Combined with the authentication mechanisms of an IRIS transfer + protocol, Internet address registries may derive authorization + policies to meet their needs without compromising general privacy + policies. As an example, the constituents of an Internet address + registry may create a policy whereby NOC contact email addresses are + only to be available to members of the Internet address registry. To + institute this policy, the XML elements for NOC contacts will never + appear in a response to a user that has not been authenticated to be + a member of the Internet address registry. + +Appendix B. Example Requests and Responses + + The examples in this section use the string "C:" to denote data sent + by a client to a server and the string "S:" to denote data sent by a + server to a client. + +B.1. Example 1 + + The following is an example of entity lookup for the contact-handle + of 'JN560-RIR1'. + + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: + + S: + S: + S: + S: + S: + S: + S: + S: + S: JN560-RIR1 + S: + S: Bob Smurd + S: + S: + S: + S: Organization X, Inc. + S: + S: + S: + S: + S: +1-703-555-5555 + S: office + S: + S: + S: + S: + S: + S: + S: + S: + + Figure 11: Example 1 + + + + + + + + + + +Gunduz, et al. Standards Track [Page 35] + +RFC 4698 IRIS Address Registry Type October 2006 + + +B.2. Example 2 + + The following example shows a query to find the IP networks + containing a given address. + + C: + C: + C: + C: + C: + C: + C: + C: 192.0.2.134 + C: + C: + C: one-level-less-specific + C: + C: + C: + C: + C: + + S: + S: + S: + S: + S: + S: + S: + S: NET-192-0-2-128-1 + S: + S: + S: UU-192-0-2-D6 + S: + S: + S: 192.0.2.128 + S: + S: + + + +Gunduz, et al. Standards Track [Page 36] + +RFC 4698 IRIS Address Registry Type October 2006 + + + S: 192.0.2.255 + S: + S: reassigned + S: + S: + S: Organization X, Inc. + S: + S: + S: + S: + S: + S: Smurd, Bob + S: + S: + S: + S: 2002-11-18T00:00:00-00:00 + S: + S: + S: 2002-11-18T00:00:00-00:00 + S: + S: + S: + S: + S: + S: NET-192-0-2-0-2 + S: + S: + S: UU-192-0-2-0-D5 + S: + S: + S: 192.0.2.0 + + + +Gunduz, et al. Standards Track [Page 37] + +RFC 4698 IRIS Address Registry Type October 2006 + + + S: + S: + S: 192.0.2.255 + S: + S: direct allocation + S: auth03.ns.example.org + S: auth00.ns.example.org + S: + S: + S: Organization Y, Inc. + S: + S: + S: + S: + S: + S: 2000-10-27T00:00:00-00:00 + S: + S: + S: 2002-02-13T00:00:00-00:00 + S: + S: + S: + S: + S: + S: + S: + S: Addresses within this block are non-portable. + S: + + + + + + + + + +Gunduz, et al. Standards Track [Page 38] + +RFC 4698 IRIS Address Registry Type October 2006 + + + S: + S: + S: + S: + S: + + Figure 12: Example 2 + +Appendix C. Specificity Examples + + This section includes examples to clarify specificity options for + network and ASN searches. + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + + Contents of the DB + + Figure 13: Specificity Example 1 + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 39] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - - | 192.0.2.0 - 192.0.2.9 + + + Exact match (1) + + Result: C + + Figure 14: Specificity Example 2 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - - - | 192.0.2.0 - 192.0.2.12 + + + Exact match (2) + + Result: None + + Figure 15: Specificity Example 3 + + + + + +Gunduz, et al. Standards Track [Page 40] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 + + + All more specifics, allowEquivalences = false + + Result: C, F, & G (A is not included; exact match) + + Figure 16: Specificity Example 4 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 + + + All more specifics, allowEquivalences = true + + Result: A, C, F, & G (A is included; exact match) + + Figure 17: Specificity Example 5 + + + + + +Gunduz, et al. Standards Track [Page 41] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 + + + One level more specifics, allowEquivalences = false + + Result: C + + Figure 18: Specificity Example 6 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 + + + One level more specifics, allowEquivalences = true + + Result: A + + Figure 19: Specificity Example 7 + + + + + +Gunduz, et al. Standards Track [Page 42] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query |- - | 192.0.2.6 - 192.0.2.9 + + + All less specifics, allowEquivalences = true + + Result: A, C, & G (G is included; exact match) + + Figure 20: Specificity Example 8 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query |- - | 192.0.2.6 - 192.0.2.9 + + + All less specifics, allowEquivalences = false + + Result: A & C (G is not included; exact match) + + Figure 21: Specificity Example 9 + + + + + +Gunduz, et al. Standards Track [Page 43] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query |- - | 192.0.2.6 - 192.0.2.9 + + + One level less specifics, allowEquivalences = true + + Result: G (the exact match) + + Figure 22: Specificity Example 10 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query |- - | 192.0.2.6 - 192.0.2.9 + + + One level less specifics, allowEquivalences = false + + Result: C + + Figure 23: Specificity Example 11 + + + + + +Gunduz, et al. Standards Track [Page 44] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query|- - - - - - | 192.0.2.0 - 192.0.2.8 + + + One level less specifics, allowEquivalences = false or true + + Result: C + + Figure 24: Specificity Example 12 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query = E + + + Find parent (Query argument is a handle) + + Result: D + + Figure 25: Specificity Example 13 + + + + + +Gunduz, et al. Standards Track [Page 45] + +RFC 4698 IRIS Address Registry Type October 2006 + + + A |------------------| 192.0.2.0 - 192.0.2.15 + + B |------------------| 192.0.2.16 - 192.0.2.31 + + C |--------------| 192.0.2.0 - 192.0.2.9 + + D |---------------| 192.0.2.16 - 192.0.2.30 + + E |---------------| 192.0.2.16 - 192.0.2.30 + + F |--------| 192.0.2.0 - 192.0.2.5 + + G |----| 192.0.2.6 - 192.0.2.9 + + Query = D + + + Find child (Query argument is a handle) + + Result: E + + Figure 26: Specificity Example 14 + +Appendix D. Contributors + + David Blacka and Tim Christensen made substantial contributions to + this document. + +Appendix E. Acknowledgements + + Eric Hall, William Leibzon, April Marine, George Michaelson, Tim + Christensen Cathy Murphy, Andrei Robachevsky, Marcos Sanz, Frederico + Neves, Ted Hardie, and many others contributed constructively in the + mailing list discussions and IETF Meeting sessions. + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 46] + +RFC 4698 IRIS Address Registry Type October 2006 + + +Authors' Addresses + + Engin Gunduz + RIPE NCC + Singel 258 + Amsterdam 1016AB + The Netherlands + + Phone: +31 20 535 4444 + EMail: e.gunduz@computer.org + + + Andrew L. Newton + VeriSign, Inc. + 21345 Ridgetop Circle + Sterling, VA 20166 + USA + + Phone: +1 703 948 3382 + EMail: andy@hxr.us + + + Shane W. Kerr + RIPE NCC + Singel 258 + Amsterdam 1016AB + The Netherlands + + Phone: +31 20 535 4444 + EMail: shane@time-travellers.org + + + + + + + + + + + + + + + + + + + + + +Gunduz, et al. Standards Track [Page 47] + +RFC 4698 IRIS Address Registry Type October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Gunduz, et al. Standards Track [Page 48] + -- cgit v1.2.3