Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: August 27, 2001 K. Ettikan Multimedia University February 27, 2001 An analysis of IPv6 anycast draft-itojun-ipv6-anycast-analysis-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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 other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be August 27, 2001. Abstract The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. 1. IPv6 anycast "Anycast" is a communication model for IP, just like unicast and multicast are. RFC1546 [Partridge, 1993] documents IPv4 anycast, and it defines the term "anycast". HAGINO, ETTIKAN Expires: August 27, 2001 [Page 1] DRAFT Analysis of IPv6 anycast February 2001 Anycast can be understood best by comparing with unicast and multicast. IP unicast allows a source node to transmit IP datagrams to a single destination node. The destination node is identified by an unicast address. IP multicast allows a source node to transmit IP datagrams to a group of destination nodes. The destination nodes are identfied by a multicast group, and we use a multicast address to identify the multicast group. IP anycast allows a source node to transmit IP datagrams to a single destination node, out of a group of destination nodes. IP datagram will reach the closest destination node in the set of destination nodes, based on routing measure of distance. The source node does not need to care about how to pick the closest destination node, as the routing system will figure it out (in other words, the source node has no control over the selection). The set of destionation nodes is identified by an anycast address. Anycast was adopted by IPv6 specification suite. RFC2373 [Hinden, 1998] defines the IPv6 anycast address, and its constraints in the usage. The following sections try to analyze RFC2373 rules, and understand limitations with them. At the end of the draft we compile a couple of suggestions to exisitng proposals, for extending the usage of the IPv6 anycast. 2. Limitations/properties in the current proposals 2.1. Identifying anycast destination For anycast addresses, RFC2373 uses the same address format as unicast addresses. Therefore, without other specific configurations, a sender cannot usually identify if the node is sending a packet to anycast destination, or unicast destination. This is different from experimental IPv4 anycast [Partridge, 1993] , where anycast address is distinguishable from unicast addresses. 2.2. Nondeterministic packet delivery If multiple packets carry an anycast address in IPv6 destionation address header, these packets may not reach the same destination node, depending on stability of the routing table. The property leads to a couple of interesting symptoms. If we can assume that the routing table is stable enough during a protocol exchange, multiple packets (with anycast address in destination) will reach the same destination node just fine. However, there is no guarantee. If routing table is not stable enough, or you would like to take a more strict approach, a client can only send one packet with anycast address in the destination address field. For example, consider the following packet exchange. The following exchange can lead us to failure, as we HAGINO, ETTIKAN Expires: August 27, 2001 [Page 2] DRAFT Analysis of IPv6 anycast February 2001 are not sure if the 1st and 2nd anycast packet have reached the same destination. query: client unicast (Cu) -> server anycast (Sa) reply: server unicast (Su) -> client unicast (Cu) query: client unicast (Cu) -> server anycast (Sa) It may reach a different server! reply: server unicast (Su) -> client unicast (Cu) Because of the non-determinism, if we take a strict approach, we can use no more than 1 packet with anycast destination address, in a set of protocol exchange. If we use more than 2 packets, 1st and 2nd packet may reach different server and may cause unexpected results. If the protocol is completely stateless, and we can consider the first roundtrip and second roundtrip separate, it is okay. For stateful protocols, it is suggested to use anycast for the first packet in the exchange, to discover unicast address of the (nearest) server. After we have discovered the unicast address of the server, we should use the server's unicast address for the protocol exchange. Also because of non-determinism, if we are to assign an IPv6 anycast address to servers, those servers must provide uniform services. For example, if server A and server B provide different quality of service, and people wants to differentiate between A and B, we cannot use single IPv6 anycast address to identify both A and B. Note that, the property is not a bad thing; the property lets us use anycast addresses for load balancing. Also, packets will automatically be delivered to the nearest node with anycast address assigned. Here are situations where multiple packets with anycast destination address can lead us to problems: o Fragmented IPv6 packets. Fragments may reach multiple different destinations, and will prevent reassembly. Because the sending node cannot differentiate between anycast addresses and unicast addresses, it is hard for the sending node to control the use of fragmentation. 2.3. Anycast address assignment to hosts RFC2373 suggests to assign anycast addresses to a node, only when the node is a router. This is to avoid injecting host routes for anycast address, into the IPv6 routing system. If no hosts have anycast address on them, it is easier for us to route an IP datagram to anycast destination. We just need to follow existing routing entries, and we will eventually hit a router that has the anycast address. If we follow RFC2373 restriction strictly, we could only place anycast addresses onto routers. HAGINO, ETTIKAN Expires: August 27, 2001 [Page 3] DRAFT Analysis of IPv6 anycast February 2001 2.4. Anycast address in source address Under RFC2373, anycast address IPv6 anycast address can not be put into IPv6 source address. This is basically because an IPv6 anycast address does not identify single source node. 2.5. IPsec IPsec and IKE identify nodes by using source/destination address pairs. Due to the combination of issues presented above, it is very hard to use IPsec on packets with anycast address in source address, destination address, or both. Even with manual keying, IPsec trust model with anycast address is confusing. As IPsec uses IPv6 destination address to identify which IPsec key to be used, we need to use the same IPsec key for all of the anycast destinations that share an anycast address. Dynamic IPsec key exchange (like IKE) is almost impossible. First of all, to run IKE session between two nodes, the two nodes need to be able to communicate with each other. With nondeterministic packet delivery provided by anycast, it is not quite easy. Even if we could circumvent the issue with IKE, we have exactly the same problem as manual keying case for actual communication. 3. Possible improvements and protocol changes 3.1. Assigning anycast address to hosts (non-router nodes) Under RFC2373 rule, we can only assign anycast addresses to routers, not to hosts. The restriction was put into the RFC because it was felt insecure to permit hosts to inject host routes to anycast address. If we try to ease the restriction and assign anycast addresses to IPv6 hosts (non-routers), we would need to inject host routes for the anycast addresses, with prefix length set to /128, into the IPv6 routing system. We will inject host routes from each of the nodes with anycast addresses, to make packets routed to a topologically-closest node. Or, we may be able to inject host routes from routers adjacent to the servers (not from the servers themselvers). Here are possible ways to allow anycast addresses to be assigned to hosts. We would need to diagnose each of the following proposals carefully, as they have different pros and cons. The most serious issue would be the security issue with service blackhole attack (malicious party can blackhole packets toward anycast addresses, by making false advertisement). o Let the host with anycast address to participate into routing information exchange. The host does not need to fully participate; it only needs to announce the anycast address to the routing system. To HAGINO, ETTIKAN Expires: August 27, 2001 [Page 4] DRAFT Analysis of IPv6 anycast February 2001 secure routing exchange, administrators need to configure secret information that protects the routing exchange to the host, as well as other routers. o Develop a protocol for a router, to discover hosts with anycast address on the same link. The router will then advertise the anycast address to the routing system. This could be done by an extension to IPv6 Neighbor Discovery or an extension to IPv6 Multicast Listener Discovery [Haberman, 2001] . The impact of host routes depends on the scope of the anycast address usage. For example, if we use site-local anycast address to identify a set of servers, the propagation of host route is limited inside the site. If the site administration policy permits it, and the site routers can handle the additional routing entries, the additional host routes are okay. So, we can safely assign anycast address to non-router nodes (hosts), and inject host route for the anycast address, into the site IPv6 routing system. It is still questionable to inject host routes into worldwide IPv6 routing system, as it has problems in terms of scalability. Also, because of IPv6 route aggregation rules [Rockell, 2000] it is normally impossible to propagate IPv6 host routes worldwide. 3.2. Anycast address in destination address With anycast, it is hard to identify a single node out of nodes that share an anycast address. Suppose a client C would like to communicate a specific server with anycast address, Si. Si shares the same anyast address with other servers, S1 to Sn. It is hard for C to selectively communicate with Si. One possible workaround is to use IPv6 routing header. By specifying an unicast address of Si as an intermediate hop, C can deliver the packet to Si, not to other Sn. Note that we now have lost the robustness provided by the use of anycast address. If Si goes down, the communication between C and Si will be lost. C cannot enjoy the failure resistance provided by redundant servers, S1 to Sn. Designers should carefully diagnose if any state is managed by C and/or Si, and decide if it is a good idea to use the workaround presented here. 3.3. Anycast address in source address Under RFC2373 rule, anycast address cannot be put into source address. Here is a possible workaround, however, it could not win a consensus in the past ipngwg meetings: o When we try to use anycast address in the source address, use an (non- anycast) unicast address as the IPv6 source address, and attach home address option with anycast address. In ipngwg discussions, however, there seem to be a consensus that the home address option should have the same semantics as the source address in the IPv6 header, so we HAGINO, ETTIKAN Expires: August 27, 2001 [Page 5] DRAFT Analysis of IPv6 anycast February 2001 cannot put anycast address into the home address option. 3.4. IPsec with static key configuration TBD 3.5. IPsec with dynamic key exchange TBD 4. Upper layer protocol issus 4.1. Use of UDP with anycast Many of the UDP-based protocols use source and destination address pair to identify the traffic. One example would be DNS over UDP; most of the DNS client implementation checks if the source address of the reply is the same as the destination address of the query, in the fear of the fabricated reply from bad guy. query: client unicast (Cu) -> server unicast (Su*) reply: server unicast (Su*) -> client unicast (Cu) addresses marked with (*) must be equal. If we use server's anycast address as the destination of the query, we cannot meet the requirement due to RFC2373 restriction (anycast address cannot be used as the source address of packets). Effectively, client will consider the reply is fabricated (hijack attempt), and drops the packet. query: client unicast (Cu) -> server anycast (Sa) reply: server unicast (Su) -> client unicast (Cu) Note that, however, bad guys can still inject fabricated results to the client, even if the client checks the source address of the reply. The check does not improve security of the exchange at all. So, regarding to this issue, we conclude as follows: o To use anycast address on the UDP protocol exchange, client side should not check the source address of the incoming packet. Packet pairs must be identified by using UDP port numbers or upper-layer protocol mechanisms (like cookies). The source address check itself has no real protection. o If you need to secure UDP protocol exchange, it is suggested to verify the authenticity of the reply, by using upper-layer security mechanisms like DNSSEC (note that we cannot use IPsec with anycast). HAGINO, ETTIKAN Expires: August 27, 2001 [Page 6] DRAFT Analysis of IPv6 anycast February 2001 4.2. Use of TCP with anycast We cannot simply use anycast for TCP exchanges, as we identify a TCP connection by using address/port pair for the source/destination node. It is desired to implement some of the following, to enable the use of IPv6 anycast in TCP. Note, however, security requirement is rather complicated for the following protocol modifications. o Define a TCP option which lets us to switch peer's address from IPv6 anycast address, to IPv6 unicast address. There are couple of proposals in the past. o Define an additional connection setup protocol that resolves IPv6 unicast address from IPv6 anycast address. We first resolve IPv6 unicast address using the new protocol, and then, make a TCP connection using the IPv6 unicast address. IPv6 node information query/reply [Crawford, 2000] could be used for this. 5. Summary The draft tried to diagnose the limitation in currntly-specified IPv6 anycast, and explored couple of ways to extend its use. Some of the proposed changes affects IPv6 anycast in general, some are useful in certain use of IPv6 anycast. To take advantage of anycast addresses, protocol designers would need to diagnose their requirements to anycast address, and introduce some of the tricks described in the draft. Use of IPsec with anycast address still needs a great amount of analysis. 6. Security consideration The document should introduce no new security issues. For secure anycast operation, we may need to enable security mechanisms in other protocols. For example, if we were to inject /128 routes from end hosts by using a routing protocol, we may need to configure the routing protocol to exchange routes securely, to prevent malicious parties from injecting bogus routes. With anycast, it is very important to prevent malicious parties from injecting bogus routes, as it allows them to effectively suck all traffic torward anycast address. References Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. HAGINO, ETTIKAN Expires: August 27, 2001 [Page 7] DRAFT Analysis of IPv6 anycast February 2001 Partridge, 1993. C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service" in RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt. Haberman, 2001. B. Haberman and D. Thaler, "Host-based Anycast using MLD," internet draft (February 2001). work in progress material. Rockell, 2000. Rob Rockell and Bob Fink, "6Bone Backbone Routing Guidelines" in RFC2772 (February 2000). ftp://ftp.isi.edu/in-notes/rfc2772.txt. Crawford, 2000. Matt Crawford, "IPv6 Node Information Queries," internet draft (August 2000). work in progress material. Change history 00 -> 01 Improve security considerations section. Remove an invalid use of home address option from UDP section. Improve wording on IPsec. 01 -> 02 Split sections for current status analysis, and future protocol design suggestions. Authors' address Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 Email: itojun@iijlab.net K. Ettikan Faculty of Information Technology, Multimedia University (MMU) Jalan Multimedia 63100 Cyberjaya Selangor, Malaysia Tel: +60-3-8312-5403 Fax: +60-3-8312-5264 Email: ettikan@mmu.edu.my HAGINO, ETTIKAN Expires: August 27, 2001 [Page 8]