idnits 2.17.1 draft-itojun-ipv6-anycast-analysis-02.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 (February 27, 2001) is 8457 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 69 looks like a reference -- Missing reference section? '1998' on line 69 looks like a reference -- Missing reference section? 'Partridge' on line 84 looks like a reference -- Missing reference section? '1993' on line 84 looks like a reference -- Missing reference section? 'Haberman' on line 220 looks like a reference -- Missing reference section? '2001' on line 220 looks like a reference -- Missing reference section? 'Crawford' on line 334 looks like a reference -- Missing reference section? '2000' on line 334 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 10 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: August 27, 2001 K. Ettikan 5 Multimedia University 6 February 27, 2001 8 An analysis of IPv6 anycast 9 draft-itojun-ipv6-anycast-analysis-02.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 August 27, 2001. 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. RFC1546 [Partridge, 1993] documents IPv4 anycast, and it 48 defines the term "anycast". 50 DRAFT Analysis of IPv6 anycast February 2001 52 Anycast can be understood best by comparing with unicast and multicast. 53 IP unicast allows a source node to transmit IP datagrams to a single 54 destination node. The destination node is identified by an unicast 55 address. IP multicast allows a source node to transmit IP datagrams to 56 a group of destination nodes. The destination nodes are identfied by a 57 multicast group, and we use a multicast address to identify the 58 multicast group. 60 IP anycast allows a source node to transmit IP datagrams to a single 61 destination node, out of a group of destination nodes. IP datagram will 62 reach the closest destination node in the set of destination nodes, 63 based on routing measure of distance. The source node does not need to 64 care about how to pick the closest destination node, as the routing 65 system will figure it out (in other words, the source node has no 66 control over the selection). The set of destionation nodes is 67 identified by an anycast address. 69 Anycast was adopted by IPv6 specification suite. RFC2373 [Hinden, 1998] 70 defines the IPv6 anycast address, and its constraints in the usage. The 71 following sections try to analyze RFC2373 rules, and understand 72 limitations with them. At the end of the draft we compile a couple of 73 suggestions to exisitng proposals, for extending the usage of the IPv6 74 anycast. 76 2. Limitations/properties in the current proposals 78 2.1. Identifying anycast destination 80 For anycast addresses, RFC2373 uses the same address format as unicast 81 addresses. Therefore, without other specific configurations, a sender 82 cannot usually identify if the node is sending a packet to anycast 83 destination, or unicast destination. This is different from 84 experimental IPv4 anycast [Partridge, 1993] , where anycast address is 85 distinguishable from unicast addresses. 87 2.2. Nondeterministic packet delivery 89 If multiple packets carry an anycast address in IPv6 destionation 90 address header, these packets may not reach the same destination node, 91 depending on stability of the routing table. The property leads to a 92 couple of interesting symptoms. 94 If we can assume that the routing table is stable enough during a 95 protocol exchange, multiple packets (with anycast address in 96 destination) will reach the same destination node just fine. However, 97 there is no guarantee. 99 If routing table is not stable enough, or you would like to take a more 100 strict approach, a client can only send one packet with anycast address 101 in the destination address field. For example, consider the following 102 packet exchange. The following exchange can lead us to failure, as we 103 DRAFT Analysis of IPv6 anycast February 2001 105 are not sure if the 1st and 2nd anycast packet have reached the same 106 destination. 108 query: client unicast (Cu) -> server anycast (Sa) 109 reply: server unicast (Su) -> client unicast (Cu) 110 query: client unicast (Cu) -> server anycast (Sa) 111 It may reach a different server! 112 reply: server unicast (Su) -> client unicast (Cu) 114 Because of the non-determinism, if we take a strict approach, we can use 115 no more than 1 packet with anycast destination address, in a set of 116 protocol exchange. If we use more than 2 packets, 1st and 2nd packet 117 may reach different server and may cause unexpected results. If the 118 protocol is completely stateless, and we can consider the first 119 roundtrip and second roundtrip separate, it is okay. For stateful 120 protocols, it is suggested to use anycast for the first packet in the 121 exchange, to discover unicast address of the (nearest) server. After we 122 have discovered the unicast address of the server, we should use the 123 server's unicast address for the protocol exchange. 125 Also because of non-determinism, if we are to assign an IPv6 anycast 126 address to servers, those servers must provide uniform services. For 127 example, if server A and server B provide different quality of service, 128 and people wants to differentiate between A and B, we cannot use single 129 IPv6 anycast address to identify both A and B. 131 Note that, the property is not a bad thing; the property lets us use 132 anycast addresses for load balancing. Also, packets will automatically 133 be delivered to the nearest node with anycast address assigned. 135 Here are situations where multiple packets with anycast destination 136 address can lead us to problems: 138 o Fragmented IPv6 packets. Fragments may reach multiple different 139 destinations, and will prevent reassembly. 141 Because the sending node cannot differentiate between anycast addresses 142 and unicast addresses, it is hard for the sending node to control the 143 use of fragmentation. 145 2.3. Anycast address assignment to hosts 147 RFC2373 suggests to assign anycast addresses to a node, only when the 148 node is a router. This is to avoid injecting host routes for anycast 149 address, into the IPv6 routing system. If no hosts have anycast address 150 on them, it is easier for us to route an IP datagram to anycast 151 destination. We just need to follow existing routing entries, and we 152 will eventually hit a router that has the anycast address. If we follow 153 RFC2373 restriction strictly, we could only place anycast addresses onto 154 routers. 156 DRAFT Analysis of IPv6 anycast February 2001 158 2.4. Anycast address in source address 160 Under RFC2373, anycast address IPv6 anycast address can not be put into 161 IPv6 source address. This is basically because an IPv6 anycast address 162 does not identify single source node. 164 2.5. IPsec 166 IPsec and IKE identify nodes by using source/destination address pairs. 167 Due to the combination of issues presented above, it is very hard to use 168 IPsec on packets with anycast address in source address, destination 169 address, or both. 171 Even with manual keying, IPsec trust model with anycast address is 172 confusing. As IPsec uses IPv6 destination address to identify which 173 IPsec key to be used, we need to use the same IPsec key for all of the 174 anycast destinations that share an anycast address. 176 Dynamic IPsec key exchange (like IKE) is almost impossible. First of 177 all, to run IKE session between two nodes, the two nodes need to be able 178 to communicate with each other. With nondeterministic packet delivery 179 provided by anycast, it is not quite easy. Even if we could circumvent 180 the issue with IKE, we have exactly the same problem as manual keying 181 case for actual communication. 183 3. Possible improvements and protocol changes 185 3.1. Assigning anycast address to hosts (non-router nodes) 187 Under RFC2373 rule, we can only assign anycast addresses to routers, not 188 to hosts. The restriction was put into the RFC because it was felt 189 insecure to permit hosts to inject host routes to anycast address. 191 If we try to ease the restriction and assign anycast addresses to IPv6 192 hosts (non-routers), we would need to inject host routes for the anycast 193 addresses, with prefix length set to /128, into the IPv6 routing system. 194 We will inject host routes from each of the nodes with anycast 195 addresses, to make packets routed to a topologically-closest node. Or, 196 we may be able to inject host routes from routers adjacent to the 197 servers (not from the servers themselvers). 199 Here are possible ways to allow anycast addresses to be assigned to 200 hosts. We would need to diagnose each of the following proposals 201 carefully, as they have different pros and cons. The most serious issue 202 would be the security issue with service blackhole attack (malicious 203 party can blackhole packets toward anycast addresses, by making false 204 advertisement). 206 o Let the host with anycast address to participate into routing 207 information exchange. The host does not need to fully participate; it 208 only needs to announce the anycast address to the routing system. To 210 DRAFT Analysis of IPv6 anycast February 2001 212 secure routing exchange, administrators need to configure secret 213 information that protects the routing exchange to the host, as well as 214 other routers. 216 o Develop a protocol for a router, to discover hosts with anycast 217 address on the same link. The router will then advertise the anycast 218 address to the routing system. This could be done by an extension to 219 IPv6 Neighbor Discovery or an extension to IPv6 Multicast Listener 220 Discovery [Haberman, 2001] . 222 The impact of host routes depends on the scope of the anycast address 223 usage. For example, if we use site-local anycast address to identify a 224 set of servers, the propagation of host route is limited inside the 225 site. If the site administration policy permits it, and the site 226 routers can handle the additional routing entries, the additional host 227 routes are okay. So, we can safely assign anycast address to non-router 228 nodes (hosts), and inject host route for the anycast address, into the 229 site IPv6 routing system. It is still questionable to inject host 230 routes into worldwide IPv6 routing system, as it has problems in terms 231 of scalability. Also, because of IPv6 route aggregation rules [Rockell, 232 2000] it is normally impossible to propagate IPv6 host routes worldwide. 234 3.2. Anycast address in destination address 236 With anycast, it is hard to identify a single node out of nodes that 237 share an anycast address. Suppose a client C would like to communicate 238 a specific server with anycast address, Si. Si shares the same anyast 239 address with other servers, S1 to Sn. It is hard for C to selectively 240 communicate with Si. 242 One possible workaround is to use IPv6 routing header. By specifying an 243 unicast address of Si as an intermediate hop, C can deliver the packet 244 to Si, not to other Sn. 246 Note that we now have lost the robustness provided by the use of anycast 247 address. If Si goes down, the communication between C and Si will be 248 lost. C cannot enjoy the failure resistance provided by redundant 249 servers, S1 to Sn. Designers should carefully diagnose if any state is 250 managed by C and/or Si, and decide if it is a good idea to use the 251 workaround presented here. 253 3.3. Anycast address in source address 255 Under RFC2373 rule, anycast address cannot be put into source address. 256 Here is a possible workaround, however, it could not win a consensus in 257 the past ipngwg meetings: 259 o When we try to use anycast address in the source address, use an (non- 260 anycast) unicast address as the IPv6 source address, and attach home 261 address option with anycast address. In ipngwg discussions, however, 262 there seem to be a consensus that the home address option should have 263 the same semantics as the source address in the IPv6 header, so we 265 DRAFT Analysis of IPv6 anycast February 2001 267 cannot put anycast address into the home address option. 269 3.4. IPsec with static key configuration 271 TBD 273 3.5. IPsec with dynamic key exchange 275 TBD 277 4. Upper layer protocol issus 279 4.1. Use of UDP with anycast 281 Many of the UDP-based protocols use source and destination address pair 282 to identify the traffic. One example would be DNS over UDP; most of the 283 DNS client implementation checks if the source address of the reply is 284 the same as the destination address of the query, in the fear of the 285 fabricated reply from bad guy. 287 query: client unicast (Cu) -> server unicast (Su*) 288 reply: server unicast (Su*) -> client unicast (Cu) 290 addresses marked with (*) must be equal. 292 If we use server's anycast address as the destination of the query, we 293 cannot meet the requirement due to RFC2373 restriction (anycast address 294 cannot be used as the source address of packets). Effectively, client 295 will consider the reply is fabricated (hijack attempt), and drops the 296 packet. 298 query: client unicast (Cu) -> server anycast (Sa) 299 reply: server unicast (Su) -> client unicast (Cu) 301 Note that, however, bad guys can still inject fabricated results to the 302 client, even if the client checks the source address of the reply. The 303 check does not improve security of the exchange at all. So, regarding 304 to this issue, we conclude as follows: 306 o To use anycast address on the UDP protocol exchange, client side 307 should not check the source address of the incoming packet. Packet 308 pairs must be identified by using UDP port numbers or upper-layer 309 protocol mechanisms (like cookies). The source address check itself 310 has no real protection. 312 o If you need to secure UDP protocol exchange, it is suggested to verify 313 the authenticity of the reply, by using upper-layer security 314 mechanisms like DNSSEC (note that we cannot use IPsec with anycast). 316 DRAFT Analysis of IPv6 anycast February 2001 318 4.2. Use of TCP with anycast 320 We cannot simply use anycast for TCP exchanges, as we identify a TCP 321 connection by using address/port pair for the source/destination node. 322 It is desired to implement some of the following, to enable the use of 323 IPv6 anycast in TCP. Note, however, security requirement is rather 324 complicated for the following protocol modifications. 326 o Define a TCP option which lets us to switch peer's address from IPv6 327 anycast address, to IPv6 unicast address. There are couple of 328 proposals in the past. 330 o Define an additional connection setup protocol that resolves IPv6 331 unicast address from IPv6 anycast address. We first resolve IPv6 332 unicast address using the new protocol, and then, make a TCP 333 connection using the IPv6 unicast address. IPv6 node information 334 query/reply [Crawford, 2000] could be used for this. 336 5. Summary 338 The draft tried to diagnose the limitation in currntly-specified IPv6 339 anycast, and explored couple of ways to extend its use. Some of the 340 proposed changes affects IPv6 anycast in general, some are useful in 341 certain use of IPv6 anycast. To take advantage of anycast addresses, 342 protocol designers would need to diagnose their requirements to anycast 343 address, and introduce some of the tricks described in the draft. 345 Use of IPsec with anycast address still needs a great amount of 346 analysis. 348 6. Security consideration 350 The document should introduce no new security issues. 352 For secure anycast operation, we may need to enable security mechanisms 353 in other protocols. For example, if we were to inject /128 routes from 354 end hosts by using a routing protocol, we may need to configure the 355 routing protocol to exchange routes securely, to prevent malicious 356 parties from injecting bogus routes. With anycast, it is very important 357 to prevent malicious parties from injecting bogus routes, as it allows 358 them to effectively suck all traffic torward anycast address. 360 References 362 Hinden, 1998. 363 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 364 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 366 DRAFT Analysis of IPv6 anycast February 2001 368 Partridge, 1993. 369 C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service" in 370 RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt. 372 Haberman, 2001. 373 B. Haberman and D. Thaler, "Host-based Anycast using MLD," internet 374 draft (February 2001). work in progress material. 376 Rockell, 2000. 377 Rob Rockell and Bob Fink, "6Bone Backbone Routing Guidelines" in RFC2772 378 (February 2000). ftp://ftp.isi.edu/in-notes/rfc2772.txt. 380 Crawford, 2000. 381 Matt Crawford, "IPv6 Node Information Queries," internet draft (August 382 2000). work in progress material. 384 Change history 386 00 -> 01 387 Improve security considerations section. Remove an invalid use of 388 home address option from UDP section. Improve wording on IPsec. 390 01 -> 02 391 Split sections for current status analysis, and future protocol 392 design suggestions. 394 Authors' address 396 Jun-ichiro itojun HAGINO 397 Research Laboratory, Internet Initiative Japan Inc. 398 Takebashi Yasuda Bldg., 399 3-13 Kanda Nishiki-cho, 400 Chiyoda-ku,Tokyo 101-0054, JAPAN 401 Tel: +81-3-5259-6350 402 Fax: +81-3-5259-6351 403 Email: itojun@iijlab.net 405 K. Ettikan 406 Faculty of Information Technology, Multimedia University (MMU) 407 Jalan Multimedia 408 63100 Cyberjaya Selangor, Malaysia 409 Tel: +60-3-8312-5403 410 Fax: +60-3-8312-5264 411 Email: ettikan@mmu.edu.my