One document matched: draft-morishita-dnsop-anycast-node-requirements-02.txt
Differences from draft-morishita-dnsop-anycast-node-requirements-01.txt
IETF DNSOP Working Group Y. Morishita
Internet-Draft S. Sato
Expires: July 23, 2006 T. Matsuura
JPRS
January 19, 2006
BGP Anycast Node for Authotitative Name Server Requirements
draft-morishita-dnsop-anycast-node-requirements-02.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 July 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 July 23, 2006 [Page 1]
Internet-Draft Anycast Node Requirements January 2006
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
Morishita, et al. Expires July 23, 2006 [Page 2]
Internet-Draft Anycast Node Requirements January 2006
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
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
Morishita, et al. Expires July 23, 2006 [Page 3]
Internet-Draft Anycast Node Requirements January 2006
for making BGP anycast nodes for authoritave name servers in the
following two points of view, the Internet access service, and data
center.
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.
Morishita, et al. Expires July 23, 2006 [Page 4]
Internet-Draft Anycast Node Requirements January 2006
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
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.
Morishita, et al. Expires July 23, 2006 [Page 5]
Internet-Draft Anycast Node Requirements January 2006
3.2.3. Providing higher tolerance against disasters
For the same reason of Section 3.2.2, the location MUST provide
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
Morishita, et al. Expires July 23, 2006 [Page 6]
Internet-Draft Anycast Node Requirements January 2006
measurement.
6. Security Considerations
TBD
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-02.txt (work in progress),
October 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.
Morishita, et al. Expires July 23, 2006 [Page 7]
Internet-Draft Anycast Node Requirements January 2006
[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
progress), May 2005.
[12] "ICANN Unsponsored TLD Agreement: Appendix D (.info)",
May 2001.
[13] "RIPE-NCC/DNS Server Monitoring", <http://dnsmon.ripe.net/>.
Morishita, et al. Expires July 23, 2006 [Page 8]
Internet-Draft Anycast Node Requirements January 2006
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 July 23, 2006 [Page 9]
Internet-Draft Anycast Node Requirements January 2006
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morishita, et al. Expires July 23, 2006 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 22:24:18 |