idnits 2.17.1 draft-ietf-dnsop-ohta-shared-root-server-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 61 has weird spacing: '...trators have...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7374 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Ohta 2 draft-ietf-dnsop-ohta-shared-root-server-03.txt 3 Tokyo Institute of Technology 4 February 2004 6 Root Name Servers with Inter Domain Anycast Addresses 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This memo describes an operational guideline for millions of name 32 servers to share an interdomain anycast address. 34 It enables people operate as many root name servers as they want and 35 still make them traceable. 37 1. Motivation 39 DNS root servers are the essential component of the Internet that all 40 the ISPs in the world want to run several root servers. 42 To satisfy them, we need to have thousands or millions of root 43 servers. 45 However, because of the restriction on DNS message size over UDP, the 46 number of unicast IP addresses of root servers is severely limited. 48 Thus, it is necessary to increase the number of root servers by 49 assigning an IP address to a lot of root servers. 51 Even if DNS were designed to allow a lot of root servers, it is 52 difficult for DNS clients to choose the best (with regard to 53 availability, credibility of zone content, delay, domain policy etc.) 54 root servers among so many root servers. It is not practical to ping 55 millions of servers to find which has the smallest RTT. 57 This memo proposes a mechanism of policy based selection of a root 58 server sharing an IP address (anycast IP address) with other root 59 servers and discusses operational issues related to it. 61 Because the selection is policy based, domain administrators have 62 some control over the selection of the best root server among root 63 servers sharing an IP address. 65 Note that operations similar to that described in this memo are 66 possible today locally without global coordination by any operator 67 who may be irritated by the lack of his control on (sufficiently 68 many) root servers, which may be a source of some operational 69 problems. This memo is an attempt to document the way to solve the 70 problem in a least harmful manner. 72 Similar operation described in this memo may be applicable to gTLD or 73 other global servers but it is outside the scope of this memo. 75 2. Suggested Operation 77 As is demonstrated by proliferated private use addresses, it is easy 78 to set up routers to let unicast addresses have local scopes. It is 79 also easy to let the unicast addresses have nested local scopes. The 80 important difference between the addresses for private use and root 81 servers is in their semantics that the root servers sharing an 82 address also share the globally unique semantics of the address. The 83 root servers may share a globally unique DNS host name, too. 85 A possible problem of such addresses is that the shared addresses can 86 not be used for global communication. 88 So, the root name servers with the anycast addresses must have 89 additional globally unique unicast address (or addresses), which may 90 be used for global communication such as zone transfer. 92 The other possible problem of such addresses is that the shared 93 addresses are not managed by a single entity that the mapping from 94 the shared address of a root server to some operational entity is 95 impossible. 97 However, if a router adjacent to (or near) the root server has a 98 globally unique address, it is possible to map from the global 99 address to an operational entity, which is expected to be operating 100 the root server. That is, tools like "traceroute" work to uniquely 101 identify the operational entity of the root servers sharing a anycast 102 address. 104 To be compatible with the current practice that a single address 105 belong to a single AS, each anycast address is assigned its own AS 106 number. There will be multiple ASes of the AS number containing the 107 same address ranges. 109 ASes, still, can be identified by adjacent ASes. For example, 110 network operators may choose their favorite root server based on the 111 AS numbers of the next hop ASes with, for example, AS path and BGP 112 policy. 114 It is required that operators of an AS adjacent to the root servers' 115 AS be fully responsible to the operation of the root servers. If a 116 root server's AS is adjacent to multiple ASes, operators of all the 117 ASes must be fully responsible to the operation of the root server. 118 Thus, if there is a routing problem related to a root server, 119 operators of the next hop AS(es) should be contacted. 121 To avoid complex routing tricks, globally unique unicast address(es) 122 of the root name servers must be taken from the AS(es) adjacent to 123 the root server's AS. Then, in a likely simple case that the root 124 server's AS consists of a single host, which acts as a name server 125 and a BGP router, the host should peer with adjacent AS(es) through 126 an interface(s) address(es) of which belongs to the adjacent AS(es). 127 If the root server's AS has more complex structure, special IGP 128 arrangement of globally unique unicast address(es) is necessary in 129 the AS and at the border router(s) of the adjacent AS(es). The border 130 router(s) must accept IGP information advertised from the root 131 server's AS. 133 3. Redundancy Considerations 135 There is widespread misunderstanding on anycast (and multicast) in, 136 including but not limited to, RFC1546 and RFC2461 that anycast (and 137 multicast) could have provided meaningful redundancy or fault 138 tolerance. 140 It is true that anycast and multicast tolerate some route faults. 142 However, a fault mode where a server process crash on an anycast 143 server a route to which is still alive, can not be tolerated. 145 Multicast, at least scalable one, is no better, because scalable 146 multicast needs some multicast server, such as a rendez vous point or 147 a core, which is the single point of failure. 149 Redundancy with no single point of failure can only be provided by 150 using multiple anycast (or multicast) addresses served by different 151 anycast (or multicast) servers. 153 Thus, it is meaningless that RFC1546 considers a case where there are 154 multiple anycast servers on a single subnet, because of redundancy. 155 Like unicast, it is a configuration error if there are two or more 156 anycast servers sharing an anycast address in a subnet, which means 157 that anycast works with IPv4 ARP and no special treatment of ND in 158 RFC2461 is necessary. 160 4. Assignment 162 As is discussed in the previous section, when a server with an 163 anycast address fails but a route to it is still available, there is 164 no way for clients use other servers with the same anycast address. 165 That is, anycast does not improve availability of servers so much. 167 So, even with anycast addresses, there should be multiple root 168 servers. 170 However, as anycast solves the problem of load concentration, we 171 don't need so many anycast IP addresses, 173 We should have at least 3 and at most 7 anycast addresses for root 174 servers. 176 5. Security Considerations 178 This memo describes just an operational guideline with no protocol 179 change. As such, the guideline does not introduce any security issues 180 of the protocol level. 182 As the route forgery to the root servers can be implemented today 183 without this memo by anyone including local intruders, the guideline 184 does not introduce any security issues of the operational level, 185 either. 187 A guideline to track down and verify a route or an AS path to a valid 188 or a forged root server is described in section 2. 190 Furthermore, if an ISP or a site operate its own anycast root server, 191 hosts of the ISP or the site using the root server is protected from 192 external forged route. 194 In addition, if a lot of local root servers share an anycast address, 195 it reduce the effect of distributed denial of service attack on the 196 anycast address. 198 6. Author's Address 200 Masataka Ohta 201 Graduate School of Information Science and Engineering 202 Tokyo Institute of Technology 203 2-12-1, O-okayama, Meguro-ku 204 Tokyo 152-8552, JAPAN 206 Phone: +81-3-5734-3299 207 Fax: +81-3-5734-3299 208 EMail: mohta@necom830.hpcl.titech.ac.jp