Internet Protocol version 6 (IPv6) is an Internet Layer protocol for packet-switched internetworking. IPv6 provides a 128-bit address scheme. IPv6 addresses belong to one of three categories: unicast, multicast, and anycast. Unicast is a point-to-point addressing scheme. A unicast address identifies exactly one interface. A message sent to a unicast address will generally be delivered to that interface and only that interface. A multicast address identifies a group of interfaces. A message sent to a multicast address will generally be delivered to all interfaces in the group of interfaces. An anycast address also identifies a group of interfaces. However, instead of delivering a message to all interfaces in the group as in multicast, messages sent to an anycast address are generally delivered to only one interface in the group, for example a “best” interface, where “best” may be defined or specified in any of several ways.
Anycast may also be used to refer to using routing protocols to announce a destination from multiple points on a network. A goal of anycast is to route every request to the “best” destination for that request, for the various definitions of best (closest, least loaded, etc.) Anycast is typically used to enable global configuration that operate well in different locations, as well as to provide coarse load spreading and availability.
Anycast generally works well in stateless services (e.g., Domain Name System (DNS) and Network Time Protocol (NTP)) and more generally with services (e.g. DNS and NTP) that utilize stateless protocols such as User Datagram Protocol (UDP). Stateful services, e.g. services that utilize stateful protocols such as TCP (Transmission Control Protocol) or that implement stateful state machines using stateless protocols such as UDP (User Datagram Protocol), may work well with anycast where the primary use of anycast is locality, in situations where the internal routing state is low velocity (i.e., where the routing state does not change very frequently), and where session times are limited. However, where anycast is used for other purposes such as load-balancing or in high velocity networks (i.e., networks where the routing state changes relatively frequently), and/or where sessions tend to be relatively long-lived, stateful services do not fare as well with anycast. With conventional anycast techniques, there is no guarantee that packets within a flow will all be routed to the same anycast endpoint; the network switching endpoints during a stateful session such as a TCP session breaks the stateful session.
A typical problem that such stateful services have with anycast is that a change in the routing state, using conventional anycast routing techniques, may result in messages being rerouted to a different interface. In many situations, however, it is undesirable for a stateful session between two endpoints to be rerouted to another anycast interface during the session. What happens is that the stateful service initiates a session between a sender A interface and an anycast group B using anycast and a stateful protocol such as TCP. One of the anycast group B destination endpoints is selected, and the sender A and destination endpoint in group B set up a session, e.g. using TCP. As long as the routing state remains stable, messages will generally continue to flow from the sender A to the anycast endpoint for the duration of the session. However, a change in the network routing state (e.g., the addition or deletion of a router or of an anycast interface) may result in the conventional anycast routing technique switching the anycast endpoint to a different anycast interface in group B. Thus, a different server may start receiving session packets that appear to be for an already established session that the server is not aware of. The server does not recognize the packets, sends a reset packet to the sender, and the connection drops.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.