idnits 2.17.1 draft-ietf-ipngwg-ipv6-anycast-analysis-00.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Hinden,1998]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 12, 2001) is 8321 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) -- Missing reference section? 'Hinden' on line 71 looks like a reference -- Missing reference section? '1998' on line 71 looks like a reference -- Missing reference section? 'Partridge' on line 67 looks like a reference -- Missing reference section? '1993' on line 67 looks like a reference -- Missing reference section? 'Haberman' on line 255 looks like a reference -- Missing reference section? '2001' on line 255 looks like a reference -- Missing reference section? 'Elz' on line 344 looks like a reference -- Missing reference section? '1997' on line 344 looks like a reference -- Missing reference section? 'Sollins' on line 347 looks like a reference -- Missing reference section? '1992' on line 347 looks like a reference -- Missing reference section? 'Crawford' on line 382 looks like a reference -- Missing reference section? '2000' on line 382 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro itojun Hagino 3 INTERNET-DRAFT IIJ Research Laboratory 4 Expires: January 12, 2002 K. Ettikan 5 Intel ASG, Malaysia 6 July 12, 2001 8 An analysis of IPv6 anycast 9 draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ``work in progress.'' 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be January 12, 2002. 33 Abstract 35 The memo tries to identify the problems and issues in the use of IPv6 36 anycast [Hinden, 1998] defined as of today. The goals of the draft are 37 (1) to understand the currently-defined IPv6 anycast better, (2) to 38 provide guidelines for people trying to deploy anycast services, and (3) 39 to suggest updates to IPv6 anycast protocol specification. 41 The document was made possible by input from ipngwg DNS discovery design 42 team. 44 1. IPv6 anycast 46 "Anycast" is a communication model for IP, just like unicast and 47 multicast are. 49 Anycast can be understood best by comparing with unicast and multicast. 50 IP unicast allows a source node to transmit IP datagrams to a single 51 destination node. The destination node is identified by an unicast 52 address. IP multicast allows a source node to transmit IP datagrams to 53 a group of destination nodes. The destination nodes are identfied by a 54 multicast group, and we use a multicast address to identify the 55 multicast group. 57 IP anycast allows a source node to transmit IP datagrams to a single 58 destination node, out of a group of destination nodes. IP datagram will 59 reach the closest destination node in the set of destination nodes, 60 based on routing measure of distance. The source node does not need to 61 care about how to pick the closest destination node, as the routing 62 system will figure it out (in other words, the source node has no 63 control over the selection). The set of destionation nodes is 64 identified by an anycast address. 66 There are two kind of "anycast" proposed and operated for IPv4 - One is 67 RFC1546 [Partridge, 1993] anycast. Another is what we call "BGP 68 anycast" in this document; this is for replicating unicast servers by 69 BGP trick. We concentrate into the former in this document. 71 Anycast was adopted by IPv6 specification suite. RFC2373 [Hinden, 1998] 72 defines the IPv6 anycast address, and its constraints in the usage. 73 RFC2373 IPv6 anycast is very similar to RFC1546 IPv4 anycast. The 74 following sections try to analyze RFC2373 rules, and understand 75 limitations with them. At the end of the draft we compile a couple of 76 suggestions to exisitng proposals, for extending the usage of the IPv6 77 anycast. 79 1.1. BGP anycast 81 Today, there are so-called "anycast" operated mostly for critical 82 servers including DNS servers and web servers (like those for Olympic 83 games) [Hardie, 2001; Ohta, 2000] . We call the technique "BGP anycast" 84 for clarity. The BGP anycast works as follows: 86 o A provider-independent IPv4 address prefix is allocated from an RIR. 88 o The address prefix is configured at multiple distant locations on the 89 Internet. 91 o BGP routes are advertised from all of the locations. 93 o Clients will reach the nearest location based on the BGP routes. 95 BGP anycast must not be confused with the one we discuss in the document 96 (RFC2373 anycast), as the problem domain is different. 98 BGP anycast tries to replicate unicast servers in distant domains. The 99 distribution of servers is worldwide. BGP anycast is being used for 100 specific upper-layer protocols only, like DNS and HTTP. There is no 101 consideration given for the cases when a client contacts multiple 102 servers by chance (transport layer protocol will get confused), since it 103 is unlikely to see BGP route changes during the short lifetime of the 104 transport layer protocols being used. 106 RFC2373 anycast is defined in more generic manner, and does not limit 107 the routing infrastructure nor upper-layer protocol, Therefore, RFC2373 108 imposes certain limitation to the packet header contents (like IPv6 109 source address), to prevent confusions due to routing changes during the 110 lifetime of a transport-layer connection. 112 The document tries to analyze RFC2373 anycast to understand if we can 113 use it for site-scoped server replication, upper-layer protocols other 114 than DNS or HTTP, and such. Still, it is possible to apply BGP anycast 115 to IPv6. Issues with BGP anycast on IPv6 is outside of the scope of the 116 document. 118 2. Limitations/properties in the current proposals 120 2.1. Identifying anycast destination 122 For anycast addresses, RFC2373 uses the same address format as unicast 123 addresses. Therefore, without other specific configurations, a sender 124 cannot usually identify if the node is sending a packet to anycast 125 destination, or unicast destination. This is different from RFC1546 126 IPv4 anycast, where anycast address is distinguishable from unicast 127 addresses. 129 2.2. Nondeterministic packet delivery 131 If multiple packets carry an anycast address in IPv6 destionation 132 address header, these packets may not reach the same destination node, 133 depending on stability of the routing table. The property leads to a 134 couple of interesting symptoms. 136 If we can assume that the routing table is stable enough during a 137 protocol exchange, multiple packets (with anycast address in 138 destination) will reach the same destination node just fine. However, 139 there is no guarantee. 141 If routing table is not stable enough, or you would like to take a more 142 strict approach, a client can only send one packet with anycast address 143 in the destination address field. For example, consider the following 144 packet exchange. The following exchange can lead us to failure, as we 145 are not sure if the 1st and 2nd anycast packet have reached the same 146 destination. 148 query: client unicast (Cu) -> server anycast (Sa) 149 reply: server unicast (Su) -> client unicast (Cu) 150 query: client unicast (Cu) -> server anycast (Sa) 151 It may reach a different server! 152 reply: server unicast (Su) -> client unicast (Cu) 154 Because of the non-determinism, if we take a strict approach, we can use 155 no more than 1 packet with anycast destination address, in a set of 156 protocol exchange. If we use more than 2 packets, 1st and 2nd packet 157 may reach different server and may cause unexpected results. If the 158 protocol is completely stateless, and we can consider the first 159 roundtrip and second roundtrip separate, it is okay. For stateful 160 protocols, it is suggested to use anycast for the first packet in the 161 exchange, to discover unicast address of the (nearest) server. After we 162 have discovered the unicast address of the server, we should use the 163 server's unicast address for the protocol exchange. 165 Also because of non-determinism, if we are to assign an IPv6 anycast 166 address to servers, those servers must provide uniform services. For 167 example, if server A and server B provide different quality of service, 168 and people wants to differentiate between A and B, we cannot use single 169 IPv6 anycast address to identify both A and B. 171 Note that, the property is not a bad thing; the property lets us use 172 anycast addresses for load balancing. Also, packets will automatically 173 be delivered to the nearest node with anycast address assigned. 175 Here are situations where multiple packets with anycast destination 176 address can lead us to problems: 178 o Fragmented IPv6 packets. Fragments may reach multiple different 179 destinations, and will prevent reassembly. 181 Because the sending node cannot differentiate between anycast addresses 182 and unicast addresses, it is hard for the sending node to control the 183 use of fragmentation. 185 2.3. Anycast address assignment to hosts 187 RFC2373 suggests to assign anycast addresses to a node, only when the 188 node is a router. This is because there was no standard way for hosts 189 to announce their intention to accept packets toward anycast addresses. 190 If no hosts have anycast address on them, it is easier for us to route 191 an IP datagram to anycast destination. We just need to follow existing 192 routing entries, and we will eventually hit a router that has the 193 anycast address. If we follow RFC2373 restriction strictly, we could 194 only assign anycast addresses onto routers. 196 2.4. Anycast address in source address 198 Under RFC2373, IPv6 anycast address can not be put into IPv6 source 199 address. This is basically because an IPv6 anycast address does not 200 identify a single source node. 202 2.5. IPsec 204 IPsec and IKE identify nodes by using source/destination address pairs. 205 Due to the combination of issues presented above, it is very hard to use 206 IPsec on packets with anycast address in source address, destination 207 address, or both. 209 Even with manual keying, IPsec trust model with anycast address is 210 confusing. As IPsec uses IPv6 destination address to identify which 211 IPsec key to be used, we need to use the same IPsec key for all of the 212 anycast destinations that share an anycast address. 214 Dynamic IPsec key exchange (like IKE) is almost impossible. First of 215 all, to run IKE session between two nodes, the two nodes need to be able 216 to communicate with each other. With nondeterministic packet delivery 217 provided by anycast, it is not quite easy. Even if we could circumvent 218 the issue with IKE, we have exactly the same problem as manual keying 219 case for actual communication. 221 3. Possible improvements and protocol changes 223 3.1. Assigning anycast address to hosts (non-router nodes) 225 Under RFC2373 rule, we can only assign anycast addresses to routers, not 226 to hosts. The restriction was put into the RFC because it was felt 227 insecure to permit hosts to inject host routes to anycast address. 229 If we try to ease the restriction and assign anycast addresses to IPv6 230 hosts (non-routers), we would need to inject host routes for the anycast 231 addresses, with prefix length set to /128, into the IPv6 routing system. 232 We will inject host routes from each of the nodes with anycast 233 addresses, to make packets routed to a topologically-closest node. Or, 234 we may be able to inject host routes from routers adjacent to the 235 servers (not from the servers themselvers). 237 Here are possible ways to allow anycast addresses to be assigned to 238 hosts. We would need to diagnose each of the following proposals 239 carefully, as they have different pros and cons. The most serious issue 240 would be the security issue with service blackhole attack (malicious 241 party can blackhole packets toward anycast addresses, by making false 242 advertisement). 244 o Let the host with anycast address to participate into routing 245 information exchange. The host does not need to fully participate; it 246 only needs to announce the anycast address to the routing system. To 247 secure routing exchange, administrators need to configure secret 248 information that protects the routing exchange to the host, as well as 249 other routers. 251 o Develop a protocol for a router, to discover hosts with anycast 252 address on the same link. The router will then advertise the anycast 253 address to the routing system. This could be done by an extension to 254 IPv6 Neighbor Discovery or an extension to IPv6 Multicast Listener 255 Discovery [Haberman, 2001] . 257 The impact of host routes depends on the scope of the anycast address 258 usage. For example, if we use site-local anycast address to identify a 259 set of servers, the propagation of host route is limited inside the 260 site. If the site administration policy permits it, and the site 261 routers can handle the additional routing entries, the additional host 262 routes are okay. So, we can safely assign anycast address to non-router 263 nodes (hosts), and inject host route for the anycast address, into the 264 site IPv6 routing system. It is still questionable to inject host 265 routes into worldwide IPv6 routing system, as it has problems in terms 266 of scalability. Also, because of IPv6 route aggregation rules [Rockell, 267 2000] it is normally impossible to propagate IPv6 host routes worldwide. 269 3.2. Anycast address in destination address 271 By using anycast in IPv6 layer, upper-layer protocols may be able to 272 enjoy redundancy and higher availability of servers. However, for 273 stateful upper-layer protocols, a client may need to specify a single 274 node out of nodes that share an anycast address. Suppose a client C 275 would like to communicate a specific server with anycast address, Si. 276 Si shares the same anyast address with other servers, S1 to Sn. It is 277 hard for C to selectively communicate with Si. 279 One possible workaround is to use IPv6 routing header. By specifying an 280 unicast address of Si as an intermediate hop, C can deliver the packet 281 to Si, not to other Sn. 283 Note that, however, by specifying Si explicitly, C now have lost the 284 server redundancy provided by the use of anycast address in IPv6 layer. 285 If Si goes down, the communication between C and Si will be lost. C 286 cannot enjoy the failure resistance provided by redundant servers, S1 to 287 Sn. Protocol designers should carefully diagnose if any state is 288 managed by C and/or Si, and decide how the protocol should take 289 advantage of anycast addresses and their characteristics. 291 3.3. Anycast address in source address 293 Under RFC2373 rule, anycast address cannot be put into source address. 294 Here is a possible workaround, however, it could not win a consensus in 295 the past ipngwg meetings: 297 o When we try to use anycast address in the source address, use a (non- 298 anycast) unicast address as the IPv6 source address, and attach home 299 address option with anycast address. In ipngwg discussions, however, 300 there seem to be a consensus that the home address option should have 301 the same semantics as the source address in the IPv6 header, so we 302 cannot put anycast address into the home address option. 304 3.4. IPsec with static key configuration 306 TBD 308 3.5. IPsec with dynamic key exchange 310 TBD 312 4. Upper layer protocol issues 314 4.1. Use of UDP with anycast 316 Many of the UDP-based protocols use source and destination address pair 317 to identify the traffic. One example would be DNS over UDP; most of the 318 DNS client implementation checks if the source address of the reply is 319 the same as the destination address of the query, in the fear of the 320 fabricated reply from a bad guy. 322 query: client unicast (Cu) -> server unicast (Su*) 323 reply: server unicast (Su*) -> client unicast (Cu) 325 addresses marked with (*) must be equal. 327 If we use server's anycast address as the destination of the query, we 328 cannot meet the requirement due to RFC2373 restriction (anycast address 329 cannot be used as the source address of packets). Effectively, client 330 will consider the reply is fabricated (hijack attempt), and drops the 331 packet. 333 query: client unicast (Cu) -> server anycast (Sa) 334 reply: server unicast (Su) -> client unicast (Cu) 336 Note that, however, bad guys can still inject fabricated results to the 337 client, even if the client checks the source address of the reply. The 338 check does not improve security of the exchange at all. 340 If we check the existing protocol descriptions, in many cases, it is not 341 possible to perform sanity checks against IP source address for UDP 342 exchanges. Either they are not specified on the protocol documents, or 343 it is an implementation mistake to check the IP source address. For 344 example, from RFC2181 [Elz, 1997] section 4.1, we cannot check IP source 345 address matches for UDP DNS packets (client shouldn't be checking this). 346 There is no wording available on the selection of source address, in 347 TFTP protocol specification [Sollins, 1992] . 349 So, regarding to this issue, we conclude as follows: 351 o To use anycast address on the UDP protocol exchange, client side 352 should not check the source address of the incoming packet. Packet 353 pairs must be identified by using UDP port numbers or upper-layer 354 protocol mechanisms (like cookies). The source address check itself 355 has no real protection. 357 o If you need to secure UDP protocol exchange, it is suggested to verify 358 the authenticity of the reply, by using upper-layer security 359 mechanisms like DNSSEC (note that we cannot use IPsec with anycast). 361 o For many of the existing protocols, we cannot perform sanity checks 362 using IP source address address. More specifically, for UDP DNS 363 replies against queries to anycast address, it is not recommended to 364 check source address, based on RFC2181 section 4.1. TFTP 366 4.2. Use of TCP with anycast 368 We cannot simply use anycast for TCP exchanges, as we identify a TCP 369 connection by using address/port pair for the source/destination node. 370 It is desired to implement some of the following, to enable the use of 371 IPv6 anycast in TCP. Note, however, security requirement is rather 372 complicated for the following protocol modifications. 374 o Define a TCP option which lets us to switch peer's address from IPv6 375 anycast address, to IPv6 unicast address. There are couple of 376 proposals in the past. 378 o Define an additional connection setup protocol that resolves IPv6 379 unicast address from IPv6 anycast address. We first resolve IPv6 380 unicast address using the new protocol, and then, make a TCP 381 connection using the IPv6 unicast address. IPv6 node information 382 query/reply [Crawford, 2000] could be used for this. 384 5. Summary 386 The draft tried to diagnose the limitation in currntly-specified IPv6 387 anycast, and explored couple of ways to extend its use. Some of the 388 proposed changes affects IPv6 anycast in general, some are useful in 389 certain use of IPv6 anycast. To take advantage of anycast addresses, 390 protocol designers would need to diagnose their requirements to anycast 391 address, and introduce some of the tricks described in the draft. 393 Use of IPsec with anycast address still needs a great amount of 394 analysis. 396 6. Security consideration 398 The document should introduce no new security issues. 400 For secure anycast operation, we may need to enable security mechanisms 401 in other protocols. For example, if we were to inject /128 routes from 402 end hosts by using a routing protocol, we may need to configure the 403 routing protocol to exchange routes securely, to prevent malicious 404 parties from injecting bogus routes. 406 References 408 Hinden, 1998. 409 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 410 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 412 Partridge, 1993. 413 C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service" in 414 RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt. 416 Hardie, 2001. 417 T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast 418 Addresses" in draft-ietf-dnsop-hardie-shared-root-server-03.txt (January 419 2001). work in progress material. 421 Ohta, 2000. 422 Masataka Ohta, "Root Name Servers with Inter Domain Anycast Addresses" 423 in draft-ietf-dnsop-ohta-shared-root-server-00.txt (July 2000). work in 424 progress material. 426 Haberman, 2001. 427 B. Haberman and D. Thaler, "Host-based Anycast using MLD" in draft- 428 haberman-ipngwg-host-anycast-00.txt (February 2001). work in progress 429 material. 431 Rockell, 2000. 432 Rob Rockell and Bob Fink, "6Bone Backbone Routing Guidelines" in RFC2772 433 (February 2000). ftp://ftp.isi.edu/in-notes/rfc2772.txt. 435 Elz, 1997. 436 R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181 437 (July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt. 439 Sollins, 1992. 440 K. Sollins, "The TFTP Protocol (Revision 2)" in RFC1350 (July 1992). 441 ftp://ftp.isi.edu/in-notes/rfc1350.txt. 443 Crawford, 2000. 444 Matt Crawford, "IPv6 Node Information Queries" in draft-ietf-ipngwg- 445 icmp-name-lookups-07.txt (August 2000). work in progress material. 447 Change history 449 individual submission, 00 -> 01 450 Improve security considerations section. Remove an invalid use of 451 home address option from UDP section. Improve wording on IPsec. 453 individual submission, 01 -> 02 454 Split sections for current status analysis, and future protocol 455 design suggestions. 457 02 -> 00 458 Distinguish RFC2373 anycast and BGP anycast. Ettikan's new 459 address. 461 Authors' addresses 463 Jun-ichiro itojun HAGINO 464 Research Laboratory, Internet Initiative Japan Inc. 465 Takebashi Yasuda Bldg., 466 3-13 Kanda Nishiki-cho, 467 Chiyoda-ku,Tokyo 101-0054, JAPAN 468 Tel: +81-3-5259-6350 469 Fax: +81-3-5259-6351 470 Email: itojun@iijlab.net 472 Ettikan Kandasamy Karupiah 473 ASG Penang & Shannon Operations, 474 Intel Microelectronis (M) Sdn. Bhd., 475 Bayan Lepas Free Trade Zone III, 476 Penang, Malaysia. 477 Tel: +60-4-859-2591 478 Fax: +60-4-859-7899 479 Email: ettikan.kandasamy.karuppiah@intel.com