--- 1/draft-ietf-dnsop-ohta-shared-root-server-02.txt	2006-02-04 23:14:11.000000000 +0100
+++ 2/draft-ietf-dnsop-ohta-shared-root-server-03.txt	2006-02-04 23:14:11.000000000 +0100
@@ -1,15 +1,15 @@
 
 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
-                                                           November 2002
+                                                           February 2004
 
          Root Name Servers with Inter Domain Anycast Addresses
 
 Status of this Memo
 
    This document is an Internet-Draft and is subject to all provisions
    of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
@@ -124,65 +124,62 @@
    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
    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).
    If the root server's AS has more complex structure, special IGP
    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
    router(s) must accept IGP information advertised from the root
    server's AS.
 
-3. Assignment
-
-   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
+3. Redundancy Considerations
 
-   An experiment is ongoing with a block of IP addresses 192.83.230/24
-   in AS 4128 and DNS servers sharing an IP address of 192.83.230.1.
+   There is widespread misunderstanding on anycast (and multicast) in,
+   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-
-   internet.org. and psg.com.
+   It is true that anycast and multicast tolerate some route faults.
 
-   If one is interested in joining (or just watching) the test, send a
-   mail containing a single line of:
+   However, a fault mode where a server process crash on an anycast
+   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
-   ftp://ops.ietf.org:/pub/lists/aroot.
+   So, even with anycast addresses, there should be multiple root
+   servers.
 
-   If there is something wrong with route information from AS 4128, the
-   author of the memo or the mailing list for the test may be contacted.
+   However, as anycast solves the problem of load concentration, we
+   don't need so many anycast IP addresses,
 
-   However, for direct contact to the source of the problem, the contact
-   person of an AS next to AS 4128 in the AS path of problematic route
-   information should be contacted.
+   We should have at least 3 and at most 7 anycast addresses for root
+   servers.
 
 5. Security Considerations
 
    This memo describes just an operational guideline with no protocol
    change. As such, the guideline does not introduce any security issues
    of the protocol level.
 
    As the route forgery to the root servers can be implemented today
    without this memo by anyone including local intruders, the guideline
    does not introduce any security issues of the operational level,