diff options
Diffstat (limited to 'doc/rfc/rfc3632.txt')
| -rw-r--r-- | doc/rfc/rfc3632.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3632.txt b/doc/rfc/rfc3632.txt new file mode 100644 index 0000000..e4f146e --- /dev/null +++ b/doc/rfc/rfc3632.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Hollenbeck +Request for Comments: 3632 S. Veeramachaneni +Updates: 2832 S. Yalamanchilli +Category: Informational VeriSign, Inc. + November 2003 + + + VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document updates version 1.1.0 of the Network Solutions Inc. + (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The + changes described in this document combined with the base + specification documented in RFC 2832 specify version 2.0.0 of the + VeriSign Registry Registrar Protocol. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 2 + 2.1. Response Codes . . . . . . . . . . . . . . . . . . . . . 2 + 2.2. TRANSFER Command Update . . . . . . . . . . . . . . . . 3 + 2.3. IPv6 Name Server Addresses . . . . . . . . . . . . . . . 4 + 3. Internationalization Considerations . . . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + +Hollenbeck, et al. Informational [Page 1] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + +1. Introduction + + The Network Solutions, Inc. (NSI) Registry Registrar Protocol (RRP) + was developed by NSI in 1998 and 1999 to allow multiple registrars to + provide second level Internet domain name registration services in + the top level domains (TLDs) administered by the NSI TLD registry. + Version 1.1.0 of the NSI RRP was published as Informational RFC 2832 + [2] in May 2000. This document describes changes to RFC 2832 that + specify version 2.0.0 of the protocol. + + Conventions Used In This Document + + 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 BCP 14, RFC + 2119 [1]. + + In examples, "C:" represents lines sent by a protocol client and + "S:" represents lines returned by a protocol server. + +2. Protocol Updates + + This specification describes several modifications to RFC 2832 [2]: + two new response codes have been added, domain TRANSFER command + processing has been updated to allow a client to cancel a requested + domain transfer, and support for IPv6 name server addresses has been + added. + +2.1. Response Codes + + Section 5.1 of RFC 2832 [2] has been updated to include two + additional error response codes. + + 510 Invalid encoding + + The value of a domain name or name server entity contains invalid + ASCII compatible encoding used to represent an internationalized + domain or host name. The encoding is checked and verified in two + situations: when registering an internationalized domain name or name + server name, and when changing the name of a name server and the new + name of the server is internationalized. + + + + + + + + + + +Hollenbeck, et al. Informational [Page 2] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + + Section 5.2 of RFC 2832 [2] has been updated to include response code + 510 as a possible error value returned from the ADD command: + + Command: ADD + Success: 200, 220 + Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, + 535, 540, 541, 545, 546, 547, 549, 550, 554 + + 557 Name server locked + + An attempt has been made to modify or delete a name server that is + hosting a TLD in the root zone. Modifications to the root zone can + only be made with the approval of the U.S. Department of Commerce and + IANA, so if the registrar absolutely needs to modify or delete such a + name server, the action needs to be coordinated through the registry + operator using an out-of-band communications channel. + + Section 5.2 of RFC 2832 [2] has been updated to include response code + 557 as a possible error value returned from the DEL and MOD commands: + + Command: DEL + Success: 200, 220 + Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, + 533, 541, 544, 545, 547, 549, 551, 552, 553, 557 + + Command: MOD + Success: 200, 220 + Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, + 535, 540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553, 557 + +2.2. TRANSFER Command Update + + Section 4.3.10 of RFC 2832 [2] has been updated to include an + additional TRANSFER command processing option. + + Old text: + + Authorized User: All registrars MAY use the TRANSFER command to + request the transfer of registration service authority to the + requesting registrar. Only the current sponsoring registrar of a + domain name may explicitly approve or reject a requested transfer. + The registry MAY implicitly approve or reject requested transfers + after a fixed amount of time. + + + + + + + + +Hollenbeck, et al. Informational [Page 3] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + + New text: + + Authorized User: All registrars MAY use the TRANSFER command to + request transfer of registration service authority to the requesting + registrar. Only the current sponsoring registrar of a domain name + may explicitly approve a requested transfer. The current sponsoring + registrar MAY explicitly reject a requested transfer. The registry + MAY implicitly approve or reject requested transfers after a fixed + amount of time. The requesting registrar MAY cancel a pending + request, but the request to cancel the transfer MUST be sent before + it has been explicitly approved or rejected by the current sponsoring + registrar or it has been implicitly approved or rejected by the + registry. + + Example: + + A registrar cancels a previously requested domain transfer: + + C:transfer<crlf> + C:-Approve:No<crlf> + C:EntityName:Domain<crlf> + C:DomainName:example.com<crlf> + C:.<crlf> + S:200 Command completed successfully<crlf> + S:.<crlf> + +2.3. IPv6 Name Server Addresses + + Section 7 of RFC 2832 [2] has been updated to include support for + name servers using IPv6 addresses. IPv6 addressing architecture is + described in RFC 3513 [3]. This ABNF [4] grammar supplements the + grammar defined in RFC 2832. + + ; Lexical Tokens + + hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f + + doubleoctet = 1*4hexdigit + + docolon = doubleoctet colon + + colondo = colon doubleoctet + + ip-address = ip-address-v4 / ip-address-v6 + + ; ipv4 addresses + ip-address-v4 = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit + + + + +Hollenbeck, et al. Informational [Page 4] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + + ip-address-v6 = ip-address-v6-standard / ip-address-v6-compressed + ; Standard form of IPv6 addresses + ; 8 hexdigit strings of length 1-4 separated by colons + ; + ; Eg: 10AA:0:0:00:8:800:200C:417A + + ip-address-v6-standard = doubleoctet 7colondo + + ; Compressed form of IPv6 addresses + ; Runs of zero-value octets are represented by '::' + ; + ; Examples: + ; :: ==> 0:0:0:0:0:0:0:0 + ; + ; 1:: ==> 1:0:0:0:0:0:0:0 + ; 2:2:: ==> 2:2:0:0:0:0:0:0 + ; 7:7:7:7:7:7:7:: ==> 7:7:7:7:7:7:7:0 + ; + ; ::1 ==> 0:0:0:0:0:0:0:1 + ; ::2:2 ==> 0:0:0:0:0:0:2:2 + ; ::7:7:7:7:7:7:7 ==> 0:7:7:7:7:7:7:7 + ; + ; E::1 ==> E:0:0:0:0:0:0:1 + ; E::2:2 ==> E:0:0:0:0:0:2:2 + ; E::6:6:6:6:6:6 ==> E:0:6:6:6:6:6:6 + ; + ; E:E::1 ==> E:E:0:0:0:0:0:1 + ; E:E::2:2 ==> E:E:0:0:0:0:2:2 + ; E:E::5:5:5:5:5 ==> E:E:0:5:5:5:5:5 + ; + ; E:E:E::1 ==> E:E:E:0:0:0:0:1 + ; E:E:E::2:2 ==> E:E:E:0:0:0:2:2 + ; E:E:E::4:4:4:4 ==> E:E:E:0:4:4:4:4 + ; + ; E:E:E:E::1 ==> E:E:E:E:0:0:0:1 + ; E:E:E:E::2:2 ==> E:E:E:E:0:0:2:2 + ; E:E:E:E::3:3:3 ==> E:E:E:E:0:3:3:3 + ; + ; E:E:E:E:E::1 ==> E:E:E:E:E:0:0:1 + ; E:E:E:E:E::2:2 ==> E:E:E:E:E:0:2:2 + ; + ; E:E:E:E:E:E::1 ==> E:E:E:E:E:E:0:1 + + ip-address-v6-compressed = colon colon + ip-address-v6-compressed =/ 1*7docolon colon + ip-address-v6-compressed =/ colon 1*7colondo + ip-address-v6-compressed =/ docolon 1*6colondo + ip-address-v6-compressed =/ 2docolon 1*5colondo + + + +Hollenbeck, et al. Informational [Page 5] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + + ip-address-v6-compressed =/ 3docolon 1*4colondo + ip-address-v6-compressed =/ 4docolon 1*3colondo + ip-address-v6-compressed =/ 5docolon 1*2colondo + ip-address-v6-compressed =/ 6docolon colondo + +3. Internationalization Considerations + + This document does not introduce any internationalization + considerations that are not already documented in RFC 2832 [2]. + +4. IANA Considerations + + This document does not introduce any IANA considerations that are not + already documented in RFC 2832 [2]. + +5. Security Considerations + + This document does not introduce any security considerations that are + not already documented in RFC 2832 [2]. + +6. Acknowledgements + + The authors graciously acknowledge the contributions of John Brady, + Matt Larson, Bill Manning, Erik Nordmark, and Steve Mahlstedt. + +7. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Hollenbeck, S. and M. Srivastava, "NSI Registry Registrar + Protocol (RRP) Version 1.1.0", RFC 2832, May 2000. + + [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + + + + + + + + + + + + +Hollenbeck, et al. Informational [Page 6] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + +8. Authors' Addresses + + Scott Hollenbeck + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: shollenbeck@verisign.com + + + Srikanth Veeramachaneni + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: sveerama@verisign.com + + + Suresh Yalamanchilli + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: syalamanchilli@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck, et al. Informational [Page 7] + +RFC 3632 VeriSign RRP v2.0.0 November 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hollenbeck, et al. Informational [Page 8] + |