Implementation and Evaluation of IPv6 Anycast

Masafumi OE <masa@fumi.org>
Suguru YAMAGUCHI <suguru@is.aist-nara.ac.jp>
Nara Institute of Science and Technology
Japan

Abstract

Internet Protocol Version 6 (IPv6) specification defines a new addressing scheme called "anycast address" that is an identifier for a set of interfaces. A packet sent to an anycast address is routed to the "nearest" interface having that address, depending on the distance of a routing path. A routing path between certain nodes may vary with changes in the network configuration. Therefore, a packet using anycast address may not be sent to the same node when any changes on the routing path occur. As a result, a point-to-point communication in which its end point is specified by an anycast address does not work well, especially with connection-oriented protocols.

For solving this issue, "Source Identification Option" was proposed in an Internet-Draft published in 1996. This is a simple mechanism to use a new IP option. This proposed mechanism could solve the issue in the IP layer; however, neither implementation nor operation has been reported.

We propose a new mechanism called "Anycast Address Mapper" which enables us to find out the corresponding unicast address from the anycast address, using Internet Control Message Protocol (ICMP). We implemented and evaluated both our "Anycast Address Mapper" and the "Source Identification Option" on FreeBSD-2.x/3.x with KAME. For our evaluation, the hypertext transfer protocol (HTTP) proxy server and the Domain Name System (DNS) server were modified to use our implementations. Through our evaluation, we confirmed that both mechanisms were working correctly.

In this paper, we discuss the address mapping issue on the use of anycast addresses and propose a new mechanism called "Anycast Address Mapper" as our solution for this issue. We show details of its implementation and evaluation with the other solution called "Source Identification Option." Finally, we confirmed that both of the solutions are working well and discuss advantages of these solutions.

Contents

Introduction

Internet Protocol Version 6 (IPv6)[1] was developed to solve the problem of address space exhaustion[2] on the Internet Protocol Version 4 (IPv4)[3]. IPv6 specification defines a new addressing scheme called "anycast address" that is an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is routed to the "nearest" interface having that address, depending on the distance of the routing path. This anycast mechanism can be used for implementation of following things:

The definition of the anycast address mechanism in RFC2373 [4] listed the following capabilities and restrictions.

Issues using anycast

A point-to-point communication in which its end point is specified by an anycast address does not work well, especially with connection-oriented protocols, because:

Even with the IPv6 architecture, there is no solution of these issues. In order to use anycast address architecture in the actual IPv6 network environment, some solutions for these issues are required.


Figure 1: Any changes on the routing path

Proposal

To give a solution for these issues, an anycast address should be used only at the beginning of communication, so that influences by any changes on the routing path can be prevented. Sending a packet with an anycast address can be considered as a way to find out the end point of the point-to-point communication. After the end point is found, then the unicast address which is assigned to the end point should be used for actual protocol processing. To provide this function, the mechanism to make a mapping from an anycast address to its corresponding unicast address is required.

In this paper, we use two proposals as a mechanism to achieve this mapping: "Source Identification Option" and "Anycast Address Mapper." We implemented these two mechanisms and confirmed their functionality.

Source Identification Option

"Source Identification Option" was proposed in an Internet-Draft published in 1996[5]. This is a simple mechanism to use a new IP option called "Source Identification Option." This option is encoded in the second Destination Options Extension Header of IP datagrams. Originally, this option was defined for inform any changes on source address to the peer. In the case of this anycast mechanism, any nodes with anycast addresses can utilize this option to notify its unicast address, which is corresponding to the anycast addresses, to the peer. However, the current transport layer protocols do not assume that the peer address has no change during the communication is existing. Therefore, a handling mechanism of "Source Identification Option" has to be integrated with both IP layer and transport layer. In the Internet-Draft, the mechanism of making a TCP 3-way-handshake[6] connection by using the "Source Identification Option" described below was proposed.

Process of TCP connection establishment

  1. A client sends a SYN packet to an anycast address M.
  2. A server with the anycast address M receives the SYN packet.
  3. Instead of using anycast address M as the destination address, the server replies to the client by sending the SYN+ACK packet with its own unicast address B as a source address and attaches "Source Identification Option" as destination option.
  4. When the client receives the SYN+ACK packet, it extracts "Source Identification Option" in the packet header and confirms if the packet is replied to the SYN packet. Then, it changes the server address from M to B.
  5. The client opens the connection by sending the ACK packet to the unicast address B.

This mechanism could solve the issue in the IP layer. However, neither the implementation nor the operation of this mechanism has been reported so far.


Figure 2: Proceeding of TCP connection establishment by "Source Identification Option"

Anycast Address Mapper

We propose a new mechanism called "Anycast Address Mapper" which enables us to find out the unicast address corresponding to the anycast address, using ICMP[7] ECHO request/reply. Before establishing a connection to a server with an anycast address, clients can find out the unicast address by using "Anycast Address Mapper." Then, the clients can use this unicast address to make a connection with the server. The process of TCP connection in this case is shown below:

Process of "Anycast Address Mapper"

  1. A Client sends the ICMP ECHO request packet to an anycast address M.
  2. A Server receives the ICMP ECHO request packet with the anycast address M.
  3. The server sends ICMP ECHO reply with its own unicast address B as a source address, back to the client.
  4. When the client receives the ICMP ECHO reply packet, it finds that unicast address B is for the anycast address M. Then, it modifies the server address from M to B.
  5. The client opens the connection to the server with unicast address B.


Figure 3: Proceeding of TCP connection establishment by "Anycast Address Mapper"

Implementation

We implemented and evaluated both our "Anycast Address Mapper" and the "Source Identification Option" on FreeBSD-2.2.8/3.x with KAME[8].

The implementation of "Source Identification Option"

Figure 4 depicts the implementation model of "Source Identification Option."

This mechanism requires modifications only in the IP layer and the transport layers; therefore, any applications can use the anycast address mechanism without any modification to themselves.


Figure 4: The implementation model of "Source Identification Option (SIO)"

Implementation of "Anycast Address Mapper"

Figure 5 shows the implementation model of "Anycast Address Mapper." "Anycast Address Mapper" determines the unicast address by using ICMP ECHO request/reply and maintains the mapping of anycast and unicast address. The "Anycast Address Mapper" is implemented as a daemon in the user memory space.

While transport and IP layers are not changed, we have to modify the application in order to use "Anycast Address Mapper."


Figure 5: The implementation model of "Anycast Address Mapper"

Evaluation

In order to evaluate our system, we used (1) "Source Identification Option" and "Anycast Address Mapper" to operate the HTTP proxy service and (2) "Anycast Address Mapper" to operate the DNS service. HTTP and DNS client applications were modified in the case of using "Anycast Address Mapper." The network topology in our experiments is shown in Figure 6. In this topology, we installed two servers with anycast address M and used RIPng[9] as routing protocol. The distance of a routing path is listed in Table 1.

Table 1: Hop counts from Hx to Ax

Client Node Hop counts to A1 Hop counts to A2
H1 3* 4
H2 1* 5
H3 5 1*


Figure 6: Network map for the experimentation.

Experiment 1: HTTP proxy service

For each "Source Identification Option" and "Anycast Address Mapper," we used the tcpdump to record the process of TCP connection establishment between H1 and A(see Figure 6), and checked if each client communicated with the nearest server. As the result, we have verified that all of the clients were able to communicate with the nearest servers in both cases.

Figure 7 is a part of tcpdump outputs in case of "Source Identification Option." The first line shows the packet from H1 arrived at A1, which was the nearest server. The second line shows that the anycast address M was changed by "Source Identification Option." And the third line shows that the connection between H1 and A1 has been established.


Figure 7: Tcpdump output of HTTP proxy using "Source Identification Option"

Also, Figure 8 shows the result of tcpdump in case of "Anycast Address Mapper." The first and the second lines show ICMP echo reply and request used in finding the unicast address corresponding to the anycast address. The rest of lines show TCP-3way handshake process using the unicast address and the connection establishment.

Therefore, we can confirm that these mechanisms are working correctly.


Figure 8: Tcpdump output of HTTP proxy using "Anycast Address Mapper"

Experiment 2: DNS service

We used "Anycast Address Mapper" to find the corresponding unicast address from the anycast address, then used this unicast address in querying and answering the DNS server. Figure 9 shows the results of the tcpdump process of DNS query and answer between client and anycast server.


Figure 9: Tcpdump output of DNS query and answer using "Anycast Address Mapper"

From this experiment, it is clear that we can use the DNS anycast address for making a connection to the nearest anycast server.

Through our experiments, we confirmed that both mechanisms were working correctly. "Source Identification Option" obviously requires modifying the IPv6 stack, while "Anycast Address Mapper" can be implemented without any modifications to the stack. Therefore, "Anycast Address Mapper" has more advantages than "Source Identification Option" for actual network operations. "Source Identification Option," on the other hand, can be considered a smart mechanism when it is combined with the TCP or other transport layer protocols, because the mechanism does not require any applications to be modified to use anycast addresses. In the developing period of IPv6, we recommend using "Anycast Address Mapper" as the anycast address resolving mechanism because the implementation cost of "Anycast Address Mapper" is much lower than "Source Identification Option." After this developing period, we recommend using "Source Identification Option" because it needs fewer transactions.

Conclusion and future work

In this paper, we have discussed the address mapping issue on the use of anycast addresses and have proposed a new mechanism called "Anycast Address Mapper" as our solution for this issue. We showed details of its implementation and evaluation with the other solution called "Source Identification Option." Finally, we have confirmed that both of the solutions are working and have discussed advantages of these solutions. However, we recognized that there are many issues for further consideration, including:

Acknowledgments

We would like to thank the members of the WIDE IPv6 working group, for their valuable comments. Also, we thank the KAME projects for providing a free IPv6 and IPsec stack for BSD variants to the world.

References

  1. S. Deering and R. Hinden, "Internet Protocol Version 6," RFC 2460, December 1998.
  2. G. Huston, "Observations on the Management of the Internet Address Space," RFC 1774, December 1994.
  3. J. Postel, "Internet Protocol," RFC 791, September 1981.
  4. R. Hinden and S. Deering, "Internet Protocol Version 6(IPv6) Addressing Architecture," RFC 2373, July 1998.
  5. J. Bound and P. Roque, "IPv6 Anycasting Service: Minimum requirements for end nodes," draft-bound-anycast-00.txt( EXPIRED ), August 1996.
  6. J. Postel, "Transmission Control Protocol," RFC 793, September 1981.
  7. A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)," RFC 2463, December 1998.
  8. KAME Project, provide a free IPv6 and IPsec (for both IPv4 and IPv6) stack for BSD variants, http://www.kame.net
  9. G. Malkin and R. Minnear, "RIPng for IPv6," RFC 2080, January 1997.