IETF DNSOP Working Group Y. Morishita Internet-Draft S. Sato Expires: January 19, 2006 T. Matsuura JPRS July 18, 2005 BGP Anycast Node for Authotitative Name Server Requirements draft-morishita-dnsop-anycast-node-requirements-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IP anycast [1] is a technology to share an IP address of an Internet service with multiple servers. It is now being deployed for the authoritative name servers, especially for the root servers. RFC 3258 [2] describes a set of practices to provide IP anycast technology for the authoritative name servers. And "Operation of Anycast Services" Internet-Draft [3] (hereafter, called "Abley's Morishita, et al. Expires January 19, 2006 [Page 1] Internet-Draft Anycast Node Requirements July 2005 Draft") describes a series of recommendations for distribution of services using anycast. Operators of authoritative name servers can also refer to RFC 2182 [4] and 2870 [5] for general guidances on appropriate practices for authoritative name servers. This memo describes the details of requirements and preconditions for making authoritative name servers in IP anycast technology, with the consideration of the practices in RFC 2182, 2870, 3258 and Abley's Draft. 1. Introduction By applying the IP anycast technology to DNS, name server operators can increase the number of authoritative name servers, and distribute them in topologically and geographically diverse locations, without violating the DNS protocol limitations [6] [7]. This improves the robustness against DoS attack and/or name server down. Also, this improves the DNS total response by decreasing RTT for authoritative name server, and distributes authoritative name servers' load. However, in the IP anycast system, IP address does not specify the individual end point for the Internet communications. Which means that the real communication peer can not be guaranteed by the destination IP address. Client machine can not control which anycast node to process the datagrams sent. Therefore, for example, if one of the IP anycast nodes has been corrupted, it is hard to determine from the client side that which node is the bad one. It is one of the risks for the deployment of IP anycast technology. DNS is one of an important infrastructures of the Internet, introducing IP anycasting MUST NOT decrease the total availability and reliability of DNS itself. This memo describes the details of requirements and preconditions for making authoritative name servers in IP anycast technology, which are widely distributed in topologically and geographically diverse locations. In this memo, authors focus on BGP anycast, that is, in general, it can have more widely distributed locations than IGP anycast. The basic point of view can be applied to IGP anycast, too. 2. BGP anycast and DNS service BGP anycast is a part of IP anycasting technology. It uses a shared IP address and a shared AS number for each BGP anycast nodes, and Morishita, et al. Expires January 19, 2006 [Page 2] Internet-Draft Anycast Node Requirements July 2005 their nodes are placed in the Internet. Reachability of each nodes are served by BGP routing protocol [8]. Each anycast nodes propagate the routing information of shared IP address block and AS number by BGP. Each BGP routers in the Internet choose 'nearest' node by BGP's best route selection algorithm. That is, the accesses to the shared IP address will be distributed to the each anycast nodes, depending on the clients' locations. BGP anycast can control each anycast nodes by configuring as 'local node' or 'global node' using BGP's routing framework. Concretely, using the 'no-export' BGP community [9], the 'local node' operators can limit distributing the routing information of anycast node only for the directly peering sites. Therefore, the 'local node' can localize the access to anycast node from directly peering sites. On the other hand, the 'global node' operators apply the normal BGP anycast for its node. In this memo, authors focus on 'global node' as main target, but authors believe it can be applied as 'local node' also. When one of BGP anycast node goes down, routing informations will be automatically recalculated. The datagrams to the anycast node are automatically rerouted to other anycast nodes. Thus, BGP anycast can provide redundancy for the Internet services. Current BGP anycast is hard to apply for TCP-based service, because of the instability of the dynamic routing protocol. But most of the DNS queries are based on a single UDP packet, and the BGP anycast is now being deployed on authoritative name server. As an important point, BGP anycast MUST need an exclusive IP address block which is a provider independent CIDR block and exclusive AS number for making each anycast nodes. 3. Requirements and preconditions for making BGP anycast nodes As described before, BGP anycast is one of the effective ways for making distributed authoritative name server systems. In recent authoritative name servers, especially for the large TLDs, ability to handle more data than before, more frequent data updating, and higher reliability are required. When BGP anycast technology is applied to their servers, the requirements and preconditions which described by this memo would be more important. In this section, this memo describes requirements and preconditions for making BGP anycast nodes for authoritave name servers in the following two points of view, the Internet access service, and data center. Morishita, et al. Expires January 19, 2006 [Page 3] Internet-Draft Anycast Node Requirements July 2005 3.1 Choosing the Internet access service For making BGP anycast nodes distributed in the wide area, it is important to make network environment with geographical and network topological diversity. In case of making such network environment, each anycasting nodes SHOULD have Internet connectivity from different Internet access service provider (hereafter, called ISP) for ensuring network diversity. And in case of ensuring the BGP connectivity, the owner of the authoritative name servers MUST consider the following preconditions and requirements to choose the Internet access services. 3.1.1 Reliability of the backbone network When making an important authoritative name server, for example, serving for root and/or TLD zone, high reliability for ISP's network itself is needed. For implementing this, it is desirable for ISP itself to have owned and managed its backbone network. An ISP which owns and manages the backbone network itself, has stronger responsibility for network stability than it doesn't. Then it is expectable that the stability of a network is higher. Of course, it is not absolute requirement, but it will surely be one of the important elements. 3.1.2 Connectivity of outside area In case of authoritative name service, especially root and/or TLD zone, there are many accesses from outside of its country and its local area. Thus, connectivity for them MUST be needed. In the same reason of Section 3.1.1, it is desirable that an ISP which owns and manages the outside area connectivity. 3.1.3 Peering When ensuring highly reliable Internet connectivity, it is an important element for ensuring the diversity of Internet routes including many alternative paths. Moreover, providing DNS service to many ISP networks efficiently, it is desirable for the ISP to have many BGP peers with other ISPs. 3.1.4 Connectivity for provider independent CIDR block and AS number When making BGP anycast node, a provider independent CIDR block and an AS number MUST be prepare in advance, and they MUST be used for Morishita, et al. Expires January 19, 2006 [Page 4] Internet-Draft Anycast Node Requirements July 2005 DNS service at each anycast nodes. It is also needed for making the multihomed connectivity. In this case, ISP MUST support propagating CIDR block and AS number for anycasting service to the Internet widely, and ISP MUST provide connectivity for them from the Internet. Concretely, ISP MUST provide transit service. 3.1.5 Connectivity for administration As in RFC 3258, an Internet connectivity which is different for IP anycasting MUST be needed for anycast node administration. 3.1.6 Connectivity for IPv6 There is no standard for IPv6 anycasting yet, but in near future, IP anycasting for IPv6 would be needed. RFC 3513 [10] prohibits host-based anycast in IPv6. But "IP Version 6 Addressing Architecture" Internet-Draft [11] removes this limitation and it is generally expected to obsolete 3513, it has been approved by the IESG, and is now just waiting for the RFC Editor. That is, the anycast node owner SHOULD ensure IPv6 connectivity. 3.2 Choosing the location For choosing BGP anycast node location, RFC 2182 and 2870 can be refered for useful guidance on appropriate practices for authoritative name servers. By referencing them, when choosing the location for BGP anycast node, the owner of authoritative name servers MUST consider the following preconditions and requirements. 3.2.1 Providing higher security level To realize the high defense performance to physical destruction and/or the intrusion from the outside, the location MUST provide higher security level. 3.2.2 Providing higher redundancy of electrical power supply DNS service requires high continuity and stability, the location MUST provide higher redundancy of electrical power supply and urgent power supply equipment for emergency. 3.2.3 Providing higher tolerance against disasters For the same reason of Section 3.2.2, the location MUST provide Morishita, et al. Expires January 19, 2006 [Page 5] Internet-Draft Anycast Node Requirements July 2005 higher tolerance against disasters, for example fire, earthquake and others. 3.2.4 Providing the diversity of locations For ensuring tolerance and redundancy, the diversity of locations is needed. Concretely, even if a fatal disaster occurred at one location, the continuity of DNS service MUST be ensured. 4. Cost issue In the technical point of view, BGP anycast nodes can be made in numbers of locations. But it is not realistic to prepare them more than necessity. In general, to satisfy the preconditions and requirements which is previously described, BGP anycast node needs high cost, including financial and human resources. In the current condition, this cost is mandatory for making BGP anycast node. Especially, to guarantee the quality of service, for example SLA (Service Level Agreement), needs higher cost than normal Internet connectivity. This is one of big burden for operating BGP anycast node. The authors believe that this is one of in the future issue for deploying IP anycasting. Furthermore, for administrating remote anycast nodes smoothly, many human recources are needed, including local and remote technical staffs. When making BGP anycast node, the owner of authoritative name servers MUST consider about this issue. 5. Measurement issue To verify whether the selections of the IP anycast nodes are appropriate or not, objective measurement from another network place is very important. When making BGP anycast mesh in the wide area, the measurement MUST also be carried out in the wide area. In such case, there is an effective guideline defined by ICANN, called "CNNP test" [12]. This guideline is useful for making BGP anycast node. There is typical notable project, RIPE NCC's DNSMON service [13]. The continuity is an important point for measurement. And operators SHOULD verify that the continuity of DNS service is ensured by measurement. 6. Security Considerations TBD Morishita, et al. Expires January 19, 2006 [Page 6] Internet-Draft Anycast Node Requirements July 2005 7. Acknowledgements Paul Vixie and Bill Manning reviewed a previous version of this document. Joe Abley reviewed a previous version of this document and provided detailed comments. The authors acknowledge many helpful suggestions from the members of JPRS Research and Development Department and System administration Department. This memo is included in the results of the research activities funded by National Institute of Information and Communications Technology (NICT). 8. References [1] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [2] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002. [3] Abley, J. and K. Lindqvist, "Operation of Anycast Services", draft-ietf-grow-anycast-01.txt (work in progress), July 2005. [4] Elz, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", RFC 2182, July 1997. [5] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", RFC 2870, June 2000. [6] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [7] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987. [8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [9] Chen, E. and J. Stewart, "A Framework for Inter-Domain Route Aggregation", RFC 2519, February 1999. [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [11] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipv6-addr-arch-v4-04.txt (work in Morishita, et al. Expires January 19, 2006 [Page 7] Internet-Draft Anycast Node Requirements July 2005 progress), May 2005. [12] "ICANN Unsponsored TLD Agreement: Appendix D (.info)", May 2001. [13] "RIPE-NCC/DNS Server Monitoring", . Authors' Addresses Yasuhiro Orange Morishita Research and Development Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: yasuhiro@jprs.co.jp Shinta Sato System Administration Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: shinta@jprs.co.jp Takayasu Matsuura System Administration Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: matuura@jprs.co.jp Morishita, et al. Expires January 19, 2006 [Page 8] Internet-Draft Anycast Node Requirements July 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Morishita, et al. Expires January 19, 2006 [Page 9]