idnits 2.17.1 draft-ietf-weirds-bootstrap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 173: '...stries. Clients SHOULD not fetch ever...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: This method relies on the fact that RDAP clients are fetching the IANA XML registries. Clients SHOULD not fetch every time the XML files. -- The document date (February 13, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-weirds-json-response-06 == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-10 == Outdated reference: A later version (-15) exists of draft-ietf-weirds-using-http-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Standards Track February 13, 2014 5 Expires: August 17, 2014 7 Finding the Authoritative Registration Data (RDAP) Service 8 draft-ietf-weirds-bootstrap-01.txt 10 Abstract 12 This document specifies a method to find which Registration Data 13 Access Protocol (RDAP) server is authoritative to answer queries for 14 a requested scope, such as domain names, IP addresses or Autonomous 15 System numbers, using data available in IANA registries. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 17, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Domain Name RDAP Registry . . . . . . . . . . . . . . . . . . 2 53 3. Internet Numbers RDAP Registries . . . . . . . . . . . . . . 3 54 3.1. IPv4 Address Space RDAP Registry . . . . . . . . . . . . 3 55 3.2. IPv6 Address Space RDAP Registry . . . . . . . . . . . . 3 56 3.3. Autonomous Systems RDAP Registry . . . . . . . . . . . . 3 57 4. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 4 59 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 60 7. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 11. Non-Normative References . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Querying and retrieving registration data from registries are defined 70 in the Registration Data Access Protocol(RDAP)[I-D.ietf-weirds-rdap-q 71 uery][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. 72 These documents do not specify where to send the queries. This 73 document specifies a method to find which server is authoritative to 74 answer queries for the requested scope. 76 The proposed mechanism is based on that allocation data for domain 77 names and IP addresses are maintained by IANA, are publicly available 78 and are in a structured format. The mechanism assumes some data 79 structure within these registries and request IANA to modify or 80 create these registries for the specific purpose of RDAP use. An 81 RDAP client fetches the registries, extract the data and then do a 82 match with the query data to find the authoritative registration data 83 server and appropriate query base URL. 85 2. Domain Name RDAP Registry 87 The domain names authoritative registration data service is found by 88 doing the longest match of the target domain name with the values of 89 the Domain column in the IANA Domain Name RDAP registry as defined in 90 section Section 9. This is a string search of the longest match 91 starting from the end of the target name and the end of each value in 92 the Domain column. The value of the "RDAP URL" column is the base 93 RDAP url as described in [I-D.ietf-weirds-rdap-query]. 95 For example, a RDAP query for example.com matches the .com entry in 96 the Domain column of the registry. The RDAP server URL for this 97 address is located in the corresponding "RDAP URL" column for that 98 entry, which could be http://rdap.example.org/rdap. Therefore the 99 query URL would be: http://rdap.example.org/rdap/domain/example.com. 100 This example is not normative. 102 3. Internet Numbers RDAP Registries 104 3.1. IPv4 Address Space RDAP Registry 106 The IPv4 address space authoritative registration data service is 107 found by doing a longest match of the target address with the values 108 of the Prefix column in the IANA IPv4 address space RDAP registry as 109 defined in section Section 9. The longest match is done the same way 110 as for routing: the addresses are converted in binary form and then 111 the binary strings are compared. The value of the "RDAP URL" column 112 is the base RDAP url as described in [I-D.ietf-weirds-rdap-query]. 114 For example, a query for "192.0.2.0/24" matches the "192/8" entry in 115 the Prefix column of the registry. The RDAP server URL for this 116 address is located in the corresponding "RDAP URL" column for that 117 entry, which could be http://rdap.example.org/rdap. Therefore the 118 query URL would be: http://rdap.example.org/rdap/ip/192.0.2.0/24. 119 This example is not normative. 121 3.2. IPv6 Address Space RDAP Registry 123 The IPv6 address space authoritative registration data service is 124 found by doing a longest match of the target address with the values 125 of the Prefix column in the IANA IPv6 address space RDAP registry as 126 defined in section Section 9. The longest match is done the same way 127 as for routing: the addresses are converted in binary form and then 128 the binary strings are compared. The value of the "RDAP URL" column 129 is the base RDAP url as described in [I-D.ietf-weirds-rdap-query]. 131 For example, a query for "2001:db8::/32" matches the "2001/16" entry 132 in the Prefix column of the registry. The RDAP server URL for this 133 address is located in the corresponding "RDAP URL" column for that 134 entry, which could be http://rdap.example.org/rdap. Therefore the 135 query URL would be: http://rdap.example.org/rdap/ip/2001:db8::/32. 136 This example is not normative. 138 3.3. Autonomous Systems RDAP Registry 140 The Autonomous Systems (AS) authoritative registration data service 141 is found by identifying the range in which the target Autonomous 142 System is, with the values of the Number column in the IANA 143 Autonomous Systems (AS) Numbers RDAP registry as defined in section 144 Section 9. The value of the "RDAP URL" column is the base RDAP url 145 as described in [I-D.ietf-weirds-rdap-query]. 147 For example, a query for AS 65411 matches the "64512-65534" entry in 148 the Number column of the registry. The RDAP server URL for this 149 address is located in the corresponding "RDAP URL" column for that 150 entry, which could be http://rdap.example.org/rdap. Therefore the 151 query URL would be: http://rdap.example.org/rdap/autnum/65411. This 152 example is not normative. 154 4. Entity 156 Since there is no global namespace for entities, this document does 157 not describe how to find the authoritative RDAP server for entities. 158 It is possible however that, if the entity identifier was received 159 from a previous query, the same RDAP server could be queried for that 160 entity or the entity identifier itself is a fully referenced URL that 161 can be queried. 163 5. Non-existent Entries or RDAP URL Values 165 The registries may not contain the requested value or the RDAP URL 166 value may be empty. In these cases, there is no known RDAP server 167 for that requested value and the client should provide an appropriate 168 error message to the user. 170 6. Deployment Considerations 172 This method relies on the fact that RDAP clients are fetching the 173 IANA XML registries. Clients SHOULD not fetch every time the XML 174 files. 176 If the query data does not match any entry in the already fetched 177 registry in the client, then the client may implement various 178 methods, such as the following: 180 o The client first queries the DNS to see if the respective entry 181 has been recently delegated or if it is a mistyped information by 182 the user. The DNS query could be to fetch the NS records for a 183 domain TLD. If the DNS answer is negative, then there is no need 184 to fetch the new version of the XML registry. However, if the DNS 185 answer is positive, this means that the currently cached XML 186 registry is no more current. The client should fetch the 187 registry, parse and then do the normal matching as specified 188 above. 190 o If the client knows the existence of a RDAP aggregator or 191 redirector and trust that service, then it could send the query to 192 the redirector, which would redirect the client if it knows the 193 authoritative server that client has not found. 195 o Clients can also rely on HTTP headers to verify if the registry 196 has changed since last time it was fetched, without the need to 197 fetch the whole registry. 199 IANA should make sure that the service of those registries is able to 200 cope with a larger demand and should take appropriate measures such 201 as caching and load balancing. 203 This specification makes no assumption on how the authorities of 204 registration data may work together on sharing their information for 205 a common service. 207 7. Limitations 209 This method does not provide a direct way to find authoritative RDAP 210 servers: 212 o for entities 214 o for queries using search patterns that do not contain a 215 terminating string that matches some entries in the registries 217 8. Security Considerations 219 By providing a bootstrap method to find RDAP servers, this document 220 helps making sure that the end-users will get the RDAP data from 221 authoritative source, instead of from rogue sources. The method 222 itself has the same security properties as the RDAP protocols 223 themselves. The transport used to access the registries could be 224 secured by TLS if IANA supports it. 226 9. IANA Considerations 228 IANA is requested to do the following: 230 o Create a new registry for IPv4 address space with the following 231 columns: the first column is the entries taken from the current 232 "IPv4 Address Space" registry[ipv4reg] and and the second column 233 is the RDAP server URL. The same registrants for these entries 234 are entitled to provide the RDAP URL value for their respective 235 space, using the same communication channels already established 236 between the registrants and IANA. 238 o Create a new registry for IPv6 address space with the following 239 columns: the first column is the entries taken from the current 240 IPv6 Address Space registries [ipv6regparent][ipv6reg] and the 241 second column is the RDAP server URL. The same registrants for 242 these entries are entitled to provide the RDAP URL value for their 243 respective space, using the same communication channels already 244 established between the registrants and IANA. 246 o Create a new registry for Autonomous System Number space with the 247 following columns: the first column is the entries taken from the 248 current "Autonomous System Number Space" registry[asreg] and the 249 second column is the RDAP server URL. The same registrants for 250 these entries are entitled to provide the RDAP URL value for their 251 respective space, using the same communication channels already 252 established between the registrants and IANA. 254 o Create a new registry of domain names, essentially TLDs, with the 255 following columns: Domain and RDAP URL. The content should be 256 initially populated by an extract of the Root zone 257 database[domainreg]. The same registrants for these entries are 258 entitled to provide the RDAP URL value for their respective space, 259 using the same communication channels already established between 260 the registrants and IANA. 262 o A change happening in any of the source registries should trigger 263 a change in the corresponding new registry. For example, a new 264 IPv6 address block appearing in the source IPv6 address space 265 registry should trigger the same new entry in the corresponding 266 RDAP registry. 268 o IANA shall update its procedures to include the provisioning of 269 these values. 271 o It is envisioned that the entries of each of these registries are 272 synched from the source assignment registries. There shall be no 273 additional records. If there is a need for additional records, 274 then the policy for updating the registry is Standards Track RFC. 276 10. Acknowledgements 278 The weirds working group had multiple discussions on this topic, 279 including a session during IETF 84. The idea of using IANA 280 registries was discovered by the editor during discussions with his 281 colleagues as well as by a comment from Andy Newton. All the people 282 involved in these discussions are herein acknowledged. Linlin Zhou, 283 Jean-Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott 284 Hollenbeck, Arturo Servin, Andy Newton have provided input and 285 suggestions to this document. 287 11. Non-Normative References 289 [I-D.ietf-weirds-json-response] 290 Newton, A. and S. Hollenbeck, "JSON Responses for the 291 Registration Data Access Protocol (RDAP)", draft-ietf- 292 weirds-json-response-06 (work in progress), October 2013. 294 [I-D.ietf-weirds-rdap-query] 295 Newton, A. and S. Hollenbeck, "Registration Data Access 296 Protocol Query Format", draft-ietf-weirds-rdap-query-10 297 (work in progress), February 2014. 299 [I-D.ietf-weirds-using-http] 300 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 301 Registration Data Access Protocol (RDAP)", draft-ietf- 302 weirds-using-http-08 (work in progress), February 2014. 304 [asreg] Internet Assigned Numbers Authority(IANA), , "Autonomous 305 System (AS) Numbers", . 308 [domainreg] 309 Internet Assigned Numbers Authority(IANA), , "Root Zone 310 Database", . 312 [ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address 313 Space", . 316 [ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global 317 Unicast Address Assignments", . 321 [ipv6regparent] 322 Internet Assigned Numbers Authority(IANA), , "Internet 323 Protocol Version 6 Address Space", . 326 Author's Address 327 Marc Blanchet 328 Viagenie 329 246 Aberdeen 330 Quebec, QC G1R 2E1 331 Canada 333 Email: Marc.Blanchet@viagenie.ca 334 URI: http://www.viagenie.ca