Internet DRAFT - draft-ata-anycast-mip6


                                                                  S. Ata
Internet-Draft                                     Osaka City University
Expires: January 19, 2005                                   M. Hashimoto
                                                       Osaka Univerisity
                                                             H. Kitamura
                                                         NEC Corporation
                                                               M. Murata
                                                        Osaka University
                                                        January 20, 2006

                  Mobile IPv6-based Global Anycasting

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   Today, the use of anycasting is quite limited.  In this document we
   explain a new network architecture for global anycasting to solve (1)
   in practical use and able to realize with existing technology easily,
   (2) about support for stateful communications keeping a session

Ata, et al.               Expires July 19, 2006                 [Page 1]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

   information at the end nodes such as TCP. The architecture is based
   on MIPv6 because there are many similarities between MIPv6 and global

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.  Other terms
   in this document are defined in [ANYTERM]

Ata, et al.               Expires July 19, 2006                 [Page 2]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

1.  Introduction

   Today, anycast is not widely used in the IPv6 network while various
   uses are expected. There are several issues to be solved.  One of the
   main reasons is because the current form of anycast cannot establish
   the communication keeping a session. It is because the use of anycast
   address as a source address of a packet. It largely limits in
   particular a use range of anycast that anycast cannot be used for TCP
   connections.  In addition, there is no practical mechanism to realize
   global anycasting in which nodes having the same anycast address
   belong to different networks.

   In this document we explain a new network architecture for global
   anycasting to solve the above-mentioned problems.  The document
   particularly aims for following: (1) The mechanism is practical use
   and able to realize with existing technology easily, (2) The
   mechanism supports stateful communications keeping a session
   information at the end nodes such as TCP.

   As realization technique of global anycast, there are roughly two
   ways; controlling anycast packets by a router or by an end node.

   To support global anycast by a router a new anycast routing protocol
   which treats anycast packets is deployed on a router.

   This technique can realize global anycasting without any extension in
   an end node, however, realization is not easy because many of routers
   in the Internet should implement the new anycast routing protocol, to
   receive the benefit of anycasting.

   On the other hand, as for the realization by an end node, the end
   node which want to establish an anycast communication has a new
   mechanism to decide the destination of an anycast packet.  This
   technique can be realized only by a change of an end node without
   adding a revision to a router, but there is a problem that an anycast
   initiator (i.e., mostly a client) has to collect information about
   anycast receivers (i.e., servers including mirrors) beforehand, to
   decide a direction for transferring the anycast packet.

   To solve this problem, therefore, we consider the model that the
   third end node (called agent) except AIs and ARs manage all
   information about the anycast address intensively, and relay anycast
   packets between AI and ARs.

   The merit of this model is that no revision of a router is needed,
   and it is able to realize global anycast easily. In addition, as for
   the client, there is an advantage not to have to collect information
   of servers beforehand: forwarding anycast packets to agent is enough.

Ata, et al.               Expires July 19, 2006                 [Page 3]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

   As a result of having examined IPv6 existing communication models to
   be able to employ, we found that Mobile IPv6 (MIPv6), which is the
   protocol supporting mobile terminals for IPv6, is designed for the
   above model. There are many similarities between MIPv6 and global

   Therefore, in the document we show how to realize the global
   anycasting by applying MIPv6 mechanism. We first explain similalities
   and differences between MIPv6 and global anycasting. Then we describe
   the overview of a MIPv6-based global anycasting scheme. Through this
   document we refer the MIPv6-based global anycast as MGA.

Ata, et al.               Expires July 19, 2006                 [Page 4]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

2.  Similarlities and Differences between MIPv6 and Global Anycast

2.1  Addressing Issue

   In MIPv6, a mobile node (MN) has two type of addresses: HoA and CoA.
   HoA is always fixed for each MN while CoA may vary based on a place
   where the MN is belonging to. To continue the communication between
   MN and a correspondence node (CN) seamlessly, the home agent (HA)
   manages a binding cache (BC) to map HoA and CoA of MN. It is because
   the CoA of MN may change during the communication when the MN moves
   to another network.

   Global anycast has a similar characteristic. An anycast responder
   (AR) has two type of addresses: anycast address (AA) and peer unicast
   address (PUA). AA is always fixed for all ARs while PUA is different
   for each AR. Anycast packets sent from the same anycast initiator
   (AI) may be forwarded different ARs due to the network condition.  It
   means that a unicast address corresponding to anycast address varies
   with the network situation.

   Therefore, it is useful to apply the mechanism of HA (in particular
   the function managing BC) in MIPv6 to MGA architecture.

2.2  Restriction of the Use as Source Address

   In MIPv6 there is a limitation that MN cannot use its HoA for a
   source address of a packet when the MN does not exist on its own home

   It is because in a network outside the home link the HoA is not valid
   as a subnet prefix for the network. If the MN sends a packet with
   specifying the HoA as the source address, the packet may be dropped
   by the edge router of the network due to the security reason (i.e.,
   the router recognizes the packet is spoofed).

   For this problem, MIPv6 utilizes a function of message tunneling for
   the communication between the HA and both MN and CN. In the case of
   the route optimization, the MN specifies the CoA as the source
   address of the packet, and adds an home address option (one of
   destination options in IPv6) to set the HoA of MN.  The stateful
   communication that maintained a session is thus enabled.

   Global anycast has also a similar limitation. Because it is not
   guaranteed that multiple anycast packet addressed to the same anycast
   address are delivered to the same node, the use of anycast address as
   the source address of the packet is also prohibited.

Ata, et al.               Expires July 19, 2006                 [Page 5]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

   Therefore, the same approach on MIPv6 (utilizing tunneling and an
   address option) is useful for MGA.

2.3  Keeping Stateful Communication

   As shown above, we can apply the mechanism of MIPv6 for the similar
   property on global anycasting. However, there is a crucially
   different point in MIPv6 and MGA. It is the factor that the binding
   update (BU) occurs.

   In MIPv6 a binding update occurs when the MN moves to the different
   network (i.e., a timing when the CoA of MN has been changed).
   However, even if the CoA is changed the communication partner is
   always the same.

   On the other hand, in MGA, the event of binding update means that the
   appropriate anycast responder has been changed. That is, after the
   binding update an anycast packet is delivered to a different AR from
   before. This is a clear difference from MIPv6. In MGA, different PUAs
   stand for different ARs. The communication partner has been changed
   by the event of binding update.

   This difference gives a serious influence in stateful communications.
   If the binding update is happen during the communication such as TCP,
   following packets of TCP stream after the binding update are
   forwarded to the different node, the TCP connection is thus destroyed
   at this time.

   For this reason, in MGA, it is strongly required that any binding
   updates for the anycast address which is used on the stateful
   communication should be rejected.

   MIPv6 provides a route optimization as an optional function, however,
   from above reason MGA suggests the same function of a route
   optimation to be a mandatory function. Agent-relay communications
   should be used for non-stateful or one round of communication only.
   Stateful communications such as TCP must perform a route optimization
   prior to establishing the communication. The communication should be
   done with the direct connection between the AI and the selected AR
   (i.e., the node received the anycast packet forwarded by the agent).

Ata, et al.               Expires July 19, 2006                 [Page 6]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

3.  Architecture of MIPv6-based Global Anycasting

3.1  Architectural Overview

   In anycast, an anycast address assigned for a specific service may be
   given to multiple anycast receivers which provides the same service.
   An anycast initiator (a node which intends to communicate with a
   anycast receiver with an anycast address) can communicate with a
   suitable (appropriate) AR. The suitable AR may vary according to the

   In the anycast communication the anycast initiator does not specify
   the peer unicast address of the anycast receiver, but do the anycast
   address for the receivers. So it is necessary for correspondence
   between anycast address nad peer unicast address.

   Therefore MGA refers to the mechanism on MIPv6. In MGA Home Anycast
   Responder (HAR) manages Anycast Binding Cache, which is the
   correspondence information of anycast address and peer unicast

   Figure 1 shows the overview of MIPv6-based Global Anycast
   architecture. There are three types of nodes: one anycast initiator
   (AI), three anycast responders having the same anycast address AA
   (AR1, AR2, AR3), and one Home Anycast Responder. To receive the
   anycast packet addressed to AA, HAR has a unicast address AA. Peer
   unicast addresses of AR1, AR2, AR3 are PUA1, PUA2, PUA3,

   HAR has an anycast binding cache ABC. In this figure, the
   correspondence unicast address for anycast address AA is PUA2.

   First, AI sends an anycast packet by specifying the anycast address
   AA as its destination.  Since an anycast address is assigned from the
   unicast address, the anycast packet is sent to the subnet which HAR
   belongs to by the unicast routing. HAR receives the anycast packet
   and checks its anycast binding cache. In this case, the HAR found
   PUA2 is suitable for forwarding the anycast packet. Then HAR relays
   the anycast packet to AR2 by tunneling, and AR2 receives the anycast

   The communication from AR2 to AI, AR2 first encapsulates the anycast
   packet (src: AA, dst: AI), and sends to HAR by reverse tunneling
   function. HAR decapsulates it and forwards to AI.

Ata, et al.               Expires July 19, 2006                 [Page 7]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

                                +-----+ Anycast Addr = AA
             Unicast      ......| AR1 | Peer Unicast Addr = PUA1
              Addres = AA :     +-----+
    +----+          +------+         +-----+ Anycast Addr = AA
    | AI |----------| HAR  |.........| AR2 | Peer Unicast Addr = PUA2
    +----+          +------+         +-----+
   Unicast    +-ABC-----+ :     +-----+ Anycast Addr = AA
   Addr = AI  | AA:PUA2 | :.....| AR3 | Peer Unicast Addr = PUA2
              +---------+       +-----+

           Fig. 1  Overview of MIPv6-based Anycast Architecture
                             (... : tunneling)

3.2  Table Fix for Stateful Communication

   As described in 2.3, above architecture works well when the
   communication is non-stateful or one round. However, if the HAR's
   anycast binding cache is updated by the anycast binding update from
   another AR during the stateful communication, further connection is
   no longer effective because the correspondence node for the anycast
   address is changed. Therefore, in MGA the same function as route
   optimization in MIPv6 is mandatory, which is called "Table Fix".

   To establish the stateful communication anycast initiator must
   perform Table Fix immediately to communicate with anycast responder
   directly prior to begin the stateful communication.

   The mechanism of table fix is almost similar to the route
   optimization in MIPv6. More specifically, when an anycast receiver
   receives an anycast packet from an anycast initiator, the receiver
   do a return routability test to the anycast initiator. After the
   test, the anycast receiver sends an anycast binding update message
   to the anycast initiator. The anycast initiator then updates its
   anycast binding cache based on the receiving anycast binding
   update. After table fix, communication is done with the peer
   unicast address of the anycast receiver. As in MIPv6, the anycast
   address is also embeded by a kind of destination option (called
   Anycast Address Option) in IPv6.

4.  Issues to be Resolved

   * Authentication mechanism to clarify anycast binding update
   * Mechanism for handling multiple Anycast Receivers simulteniously
     in HAR
   * Load distribution for HAR

5.  Security Considerations

   Because this model utilizes the similar mechanism in MIPv6, the model

Ata, et al.               Expires July 19, 2006                 [Page 8]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

   is needed to consider security issues shown in [MIPv6].

6.  References

6.1  Normative References
      [RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing
                 Architecture", RFC 2373, July 1998.

      [ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6
                 Anycast", work in progress.

      [MOBILEIP] Johnson, D., Perkins, C., and Arkko, J., "Mobility
                 Support in IPv6", work in progress.

      [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", RFC 2119, March 1997.

      [ANYTERM] Doi, S., Kahlil, I., Ata, S., Kitamura, H., Murata, M.,
                "Anycast Terminology/Functionality Definition,"
                work in progress.

Authors' Addresses

      Shingo Ata
      Osaka City University
      3-3-138, Sugimoto, Sumiyoshi-ku
      Osaka,   558-8585

      Phone: +81-6-6605-2191
      Fax:   +81-6-6690-5382

      Masakazu Hashimoto
      Osaka University
      1-5 Yamadaoka, Suita
      Suita-shi, Osaka  565-0871

      Phone: +81-6-6879-4543
      Fax:   +81-6-6879-4544

      Hiroshi Kitamura
      NEC Corporation
      (Igarashi Building 4F) 11-5, Shibaura 2-Chome
      Minato-ku, Tokyo  108-8557

Ata, et al.               Expires July 19, 2006                 [Page 9]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

      Phone: +81-3-5476-1071
      Fax:   +81-3-5476-1005

      Masayuki Murata
      Osaka University
      1-5 Yamadaoka, Suita
      Suita-shi, Osaka  565-0871

      Phone: +81-6-6879-4543
      Fax:   +81-6-6879-4544

Ata, et al.               Expires July 19, 2006                [Page 10]
Internet-Draft     Mobile IPv6-based Global Anycasting      January 2006

Intellectual Property Statement

      The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed to
      pertain to the implementation or use of the technology described in
      this document or the extent to which any license under such rights
      might or might not be available; nor does it represent that it has
      made any independent effort to identify any such rights.  Information
      on the procedures with respect to rights in RFC documents can be
      found in BCP 78 and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use of
      such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository at

      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights that may cover technology that may be
      required to implement this standard.  Please address the
      information to the IETF at

Disclaimer of Validity

      This document and the information contained herein are provided

Copyright Statement

      Copyright (C) The Internet Society (2006).  This document is
      subject to the rights, licenses and restrictions contained in
      BCP 78, and except as set forth therein, the authors retain all
      their rights.


      Funding for the RFC Editor function is currently provided by the
      Internet Society.

Ata, et al.               Expires July 19, 2006                [Page 11]