draft-ietf-dnsop-ohta-shared-root-server-02.txt   draft-ietf-dnsop-ohta-shared-root-server-03.txt 
INTERNET DRAFT M. Ohta INTERNET DRAFT M. Ohta
draft-ietf-dnsop-ohta-shared-root-server-02.txt draft-ietf-dnsop-ohta-shared-root-server-03.txt
Tokyo Institute of Technology Tokyo Institute of Technology
November 2002 February 2004
Root Name Servers with Inter Domain Anycast Addresses Root Name Servers with Inter Domain Anycast Addresses
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 41 skipping to change at page 3, line 41
the root server's AS. Then, in a likely simple case that the root the root server's AS. Then, in a likely simple case that the root
server's AS consists of a single host, which acts as a name server server's AS consists of a single host, which acts as a name server
and a BGP router, the host should peer with adjacent AS(es) through and a BGP router, the host should peer with adjacent AS(es) through
an interface(s) address(es) of which belongs to the adjacent AS(es). an interface(s) address(es) of which belongs to the adjacent AS(es).
If the root server's AS has more complex structure, special IGP If the root server's AS has more complex structure, special IGP
arrangement of globally unique unicast address(es) is necessary in arrangement of globally unique unicast address(es) is necessary in
the AS and at the border router(s) of the adjacent AS(es). The border the AS and at the border router(s) of the adjacent AS(es). The border
router(s) must accept IGP information advertised from the root router(s) must accept IGP information advertised from the root
server's AS. server's AS.
3. Assignment 3. Redundancy Considerations
When a server with an anycast address fails but a route to it is
still available, there is no way for clients use other servers with
the same anycast address, anycast does not improve availability of
servers so much.
So, even with anycast addresses, there should be multiple root
servers.
However, as anycast solves the problem of load concentration, we
don't need so many anycast IP addresses,
We should have at least 3 and at most 7 anycast addresses for root
servers.
4. Ongoing Experiment
An experiment is ongoing with a block of IP addresses 192.83.230/24 There is widespread misunderstanding on anycast (and multicast) in,
in AS 4128 and DNS servers sharing an IP address of 192.83.230.1. including but not limited to, RFC1546 and RFC2461 that anycast (and
multicast) could have provided meaningful redundancy or fault
tolerance.
Domains served by the DNS servers are not root domain but are: real- It is true that anycast and multicast tolerate some route faults.
internet.org. and psg.com.
If one is interested in joining (or just watching) the test, send a However, a fault mode where a server process crash on an anycast
mail containing a single line of: server a route to which is still alive, can not be tolerated.
subscribe aroot Multicast, at least scalable one, is no better, because scalable
multicast needs some multicast server, such as a rendez vous point or
a core, which is the single point of failure.
to Redundancy with no single point of failure can only be provided by
using multiple anycast (or multicast) addresses served by different
anycast (or multicast) servers.
majordomo@ops.ietf.org Thus, it is meaningless that RFC1546 considers a case where there are
multiple anycast servers on a single subnet, because of redundancy.
Like unicast, it is a configuration error if there are two or more
anycast servers sharing an anycast address in a subnet, which means
that anycast works with IPv4 ARP and no special treatment of ND in
RFC2461 is necessary.
the mailing list is located at: 4. Assignment
aroot@ops.ietf.org As is discussed in the previous section, when a server with an
anycast address fails but a route to it is still available, there is
no way for clients use other servers with the same anycast address.
That is, anycast does not improve availability of servers so much.
Archive of the list is available at So, even with anycast addresses, there should be multiple root
ftp://ops.ietf.org:/pub/lists/aroot. servers.
If there is something wrong with route information from AS 4128, the However, as anycast solves the problem of load concentration, we
author of the memo or the mailing list for the test may be contacted. don't need so many anycast IP addresses,
However, for direct contact to the source of the problem, the contact We should have at least 3 and at most 7 anycast addresses for root
person of an AS next to AS 4128 in the AS path of problematic route servers.
information should be contacted.
5. Security Considerations 5. Security Considerations
This memo describes just an operational guideline with no protocol This memo describes just an operational guideline with no protocol
change. As such, the guideline does not introduce any security issues change. As such, the guideline does not introduce any security issues
of the protocol level. of the protocol level.
As the route forgery to the root servers can be implemented today As the route forgery to the root servers can be implemented today
without this memo by anyone including local intruders, the guideline without this memo by anyone including local intruders, the guideline
does not introduce any security issues of the operational level, does not introduce any security issues of the operational level,
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/