Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: April 30, 2001 K. Ettikan Multimedia University October 30, 2000 An analysis of IPv6 anycast draft-itojun-ipv6-anycast-analysis-01.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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at 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 April 30, 2001. Abstract The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] . The goals of the draft are (1) to understand 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: April 30, 2001 [Page 1] DRAFT Analysis of IPv6 anycast October 2000 Anycast can be understood best by comparing with unicast and multicast. IP unicast allows a source device to transmit IP datagrams to a single destination device. The destination device is identified by an unicast address. IP multicast allows a source device to transmit IP datagrams to a group of destination devices. The destination devices are identfied by a multicast group, and we use a multicast address to identify the multicast group. IP anycast allows a source device to transmit IP datagrams to a single destination device, out of a group of destination devices. IP datagram will reach the topologically-closest destination device in the set of destination devices. The source device does not need to care about how to pick the closest destination device, as the routing system will figure it out (in other words, the source device has no control over the selection). The set of destionation devices 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. To give an outline, RFC2373 defines IPv6 anycast like below: o IPv6 anycast address is carved out of IPv6 unicast address space. IPv6 anycast address is basically not distinguishable from IPv6 unicast addresses. This is different from experimental IPv4 anycast [Partridge, 1993] , where anycast address is distinguishable from unicast addresses. o IPv6 anycast address can be assigned to IPv6 routers only. This is to avoid injecting host routes for IPv6 anycast destination, into IPv6 cloud. Another reason is that we need a secure routing information exchange, if we are to inject host routes into the routing system. o 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. The following sections try to follow RFC2373 restrictions. 2. Terminology Throughout the document, we will use the following terminology: Anycast server A server which is assigned an anycast address (or addresses). A service is provided by a set of IPv6 TCP/UDP servers, where the server's address is identified by using a single anycast address. There can be multiple anycast servers, with the same anycast address. Clients will reach one of the servers based on IPv6 anycast routing. HAGINO, ETTIKAN Expires: April 30, 2001 [Page 2] DRAFT Analysis of IPv6 anycast October 2000 3. IP layer constraints We should not fragment packets, if the packet has anycast address in the IPv6 destination address field. This is because the fragments may reach multiple different destinations. In general, we cannot use IPsec with packets with anycast address. Dynamic IPsec key exchange (like IKE) is almost impossible. 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. 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 anycast server and may cause unexpected results. For example, consider the following packet exchange. The following exchange can easily lead us to failure, as we are not sure if the 1st and 2nd anycast packet have reached the same server. If the protocol is completely stateless, and we can consider the first roundtrip and second roundtrip separate, it is okay. 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) 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. As IPv6 anycast addresses are not distinguishable from IPv6 unicast addresses, in general, it is not easy for a sender to determine if the destination address is anycast address or not. We may need to have an explicit configuration to help the determination. 4. UDP constraints 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 HAGINO, ETTIKAN Expires: April 30, 2001 [Page 3] DRAFT Analysis of IPv6 anycast October 2000 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). 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). NOTE: One may think that we can circumvent this issue by using home address option on the reply, with server anycast address in it. However, as the home address option should have the same semantics as the source address in the IPv6 header, the workaround is discouraged. 5. TCP constraints 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. 6. Service content restrictions 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 HAGINO, ETTIKAN Expires: April 30, 2001 [Page 4] DRAFT Analysis of IPv6 anycast October 2000 provides 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. 7. Routing constraints 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 servers onto routers. 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 anycast servers, to make packets routed to a topologically-closest anycast server. Or, we may be able to inject host routes from routers adjacent to the servers (not from the servers themselvers). 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. 8. Summary To deploy anycast servers, the following items should be satisfied: o For an anycast address, anycast servers must provide the identical service. o If we are to deploy worldwide uniform services, we should use well- known scoped (site-local or link-local) anycast address. o If we are to use TCP or UDP, interaction of anycast with TCP and UDP must carefully diagnosed. HAGINO, ETTIKAN Expires: April 30, 2001 [Page 5] DRAFT Analysis of IPv6 anycast October 2000 9. 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. Partridge, 1993. C. Partridge, T. Mendez, and W. Milliken, ""Host Anycasting Service"" in RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt. Crawford, 2000. Matt Crawford, ""IPv6 Node Information Queries"," internet draft (August 2000). 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. Change history 00 -> 01 Improve security considerations section. Remove an invalid use of home address option from UDP section. Improve wording on IPsec. Authors' address HAGINO, ETTIKAN Expires: April 30, 2001 [Page 6] DRAFT Analysis of IPv6 anycast October 2000 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: April 30, 2001 [Page 7]