Internet DRAFT - draft-ata-ipv6-anycast-app

draft-ata-ipv6-anycast-app





IP Version 6 Working Group                                  S. Matsunaga
Internet-Draft                                          Osaka University
Expires: August 21, 2005                                          S. Ata
                                                   Osaka City University
                                                             H. Kitamura
                                                         NEC Corporation
                                                               M. Murata
                                                        Osaka University
                                                       February 14, 2005


                    Applications of IPv6 Anycasting
                   draft-ata-ipv6-anycast-app-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on August 21, 2005.

Copyright

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the applications and characteristics of



S. Matsunaga, et al.       Expires August 2005                  [Page 1]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


   Anycast, which is network addressing and routing scheme that routes
   data through the best destination. The primary purpose of this
   document is to describe the many advantages and applications of
   Anycast and hopefully, to motivate you to consider new applications
   of Anycast.


1. Introduction

   Although [RFC2460] defines anycast, it is currently not being widely
   used. One reason is that it was only defined briefly, and the
   numerous practical applications and flexibility of the scheme have
   not yet been clearly described. Therefore, we will describe anycast
   applications and characteristics, and how they can be applied to
   enhance your current networking systems. By increasing public
   awareness about the flexibility, advantages, and potential
   applications for the scheme, the documents ivolves to popularize
   anycast and motivate people to use it to expand their current
   networking capabilities.

   One of the reasons that anycast is not widely used is that [RFC3513]
   only addressed and defined the architecture without defining the
   other specifications and terms. For clarity, we will use the term as
   defined by [ANY-TERM].


Scope of this Document

   Anycast is not only limited to network (i.e., IP) layers, but can
   also be implemented/used in other (e.g., application) layers. In this
   document, we focus on network-layer anycast, which is defined in IPv6
   specification [RFC3513].


2. Anycast Characteristics and Applications

   In this section, we will describe anycast characteristics and
   applications as they apply to [RFC3513], which describes the
   specifications of anycast addresses. First, we will describe the
   actual and potential anycast characteristics, based on these
   specifications. Then, we will describe the anycast applications that
   correspond to each anycast characteristic.

   The anycast characteristics will appear in either the IP layer,
   transport layer or application layer because IPv6 anycast is the
   technique in the IP layer. At this point, we can categorize anycast
   characteristics into three categories: the IP, the transport, and the
   application layers, in addition to ones in other layers that are not



S. Matsunaga, et al.       Expires August 2005                  [Page 2]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


   described in this draft.

   The characteristics of the IP layer are described in 2.1; the
   characteristic of the transport layer are described in 2.2; and the
   characteristics of the application layer are described in 2.3.


2.1. Characteristics of IP layer and Applications

   In this section, we will describe the anycast IP layer
   characteristics, as they relate to all anycast characteristics and
   applications that each characteristic applies to. In the IP layer,
   anycast characteristics are categorized into three types, the
   initiator, the responder, and the intermediate node views, according
   to each aspect of the node that sends, receives, and forwards the
   packets.


2.1.1. Anycast Initiator View

   In this section, we will describe the characteristics for the anycast
   initiator and anycast applications that each characteristic applies
   to.


   o  Characteristic: Source Specific Anycast
      Application   : Local Information Service

      In unicast, nodes usually communicate with the same node if the
      same unicast address is the destination. On the other hand, in
      anycast each Anycast initiator (AI) can communicate with different
      Anycast Responders (ARs) depending on the appropriateness of them,
      even if the same anycast address is the destination. Although
      various way can be considered to switch AR, the source specific
      anycast is one of those way. The source specific anycast which is
      the way that AR is selected by AI's information as same as the
      source specific multicast matches the model of anycast very well.
      Therefore, anycast communication can be used for applications that
      change the AR depending on the AI's information.

      Local information service is given to applications that make the
      best use of this characteristic. Local information services
      communicate with the appropriate server for the client as the way
      you call the telephone to the appropriate emergency facilities for
      the caller's place. The local information service in the IP layer
      are achieved by getting each AI to communicate with the
      appropriate server to the AI's location.




S. Matsunaga, et al.       Expires August 2005                  [Page 3]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


      One situation where this application is very useful is when the
      mobile node uses the services. Different servers are often used by
      the mobile node after it moves from one subnet to another, even if
      it continues to use the same service. Then, if the same anycast
      address is assigned to the servers and can be used from both
      subnets, we can establish a network environment in which the
      mobile node can automatically use the most appropriate server when
      moving. This model is similar model of mobile IP which a
      corresponding node can communicate with the mobile node by using
      the same address which is called home address.


   o  Characteristic: Communication with Scope
      Application   : Service Discovery

      One or more ARs belong to an anycast group with the same anycast
      address. If each AI has a scope, AI can limit those ARs which can
      communicate with AI. The scope of multicast limits the
      communication between a node in the scope and a node outside the
      scope and a sender communicates with all nodes in the scope.But AI
      communicates with one of all ARs in the scope although the scope
      of anycast limits the communication such as multicast. In other
      words, anycast with scope is useful for applications that choose
      candidates from all ARs for each AI.

      Service discovery is given to the application that makes the best
      use of this characteristic. In this application, a packet is
      automatically forwarded to an appropriate AI server, so that AI
      only specifies the anycast address as a server address, allowing
      each AI to automatically use the service. At this time, AI
      communicates with the AR that exists in the constant range
      specified by the AI's scope.

      Further, DHCPv6 and SLP are proposed as service discovery
      techniques. However, in these techniques a client or a server must
      advertise a message that broadcasts over the subnet, and service
      discovery is provided only within the range where the message is
      advertised. On the other hand, in anycast service discovery, each
      client can specify the range of the discovery service based on its
      scope. Therefore, the client can use service discovery without
      depending on other nodes. This application is well suited to the
      IPv6 plug and play model.


2.1.2. Anycast Responder View

   In this section, we will describe the anycast characteristics of the
   anycast responder and the applications for each characteristic it



S. Matsunaga, et al.       Expires August 2005                  [Page 4]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


   applies to.


   o  Characteristic: Independent Address Assignment
                      from/based on the Unicast Address
      Application   : Plug and Play of Server

      In IPv6, one or more IP addresses can be assigned to an interface.
      However, packets are generally delivered to the subnet with the
      same prefix as the destination address of the packet. Therefore,
      if the address which doesn't have the prefix of the subnet is
      assigned to the interface, there are many troubles for the
      receiver. However, in global anycast, AR can receive packets whose
      destination does not contain a subnet prefix because anycast has
      another space from the unicast as same as the multicast has. In
      addition, AR can continue to receive packets from AI while the AR
      anycast address remains unchanged, even if the AR unicast address
      changes, as long as AI uses the service with the anycast address.
      Therefore, communications that do not depend on AR unicast
      addresses are possible using anycast, because AI uses only one
      (or, is constant numerical) anycast address, even if there is an
      increase or decrease in the number of ARs.

      Using these characteristics, plug and play of server is given as
      an application.IP address of the server commonly doesn't get
      decided until you configure the server. If the address is
      configured automatically, clients are not able to know the address
      of the server. Therefore, you need configure the fixed (unicast)
      address to the server manually when the server provides a service
      in the global network. But, in this way, the management of the
      server saves you a lot of effort for as follow reasons:

      -  the address need have the prefix of the subnet
      -  the address need be advertised to the global network
      -  the address need be changed when the server moves to
         the other subnet.

      In other words, you hope to be able to provide services by only
      auto configuration. But, in networks with global anycast, plug and
      play of server is achieved as you can decide the address for
      services by the above characteristic before you configure the
      server. In addition, if you modify the application which listens
      by an anycast address instead of "in_addr any", you can decide the
      address of the service when you make the application. As a result,
      you don't need manual assignment of the address when you configure
      the server.





S. Matsunaga, et al.       Expires August 2005                  [Page 5]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


   o  Characteristic: Communication Zone
      Application   : Load Balancing

      One AR does not need to communicate with all the AIs when two or
      more ARs belong to a specific anycast group, and the AI of each AR
      can be allotted/allocated?. This means that each AR can limit the
      communication range by specifying a zone. This characteristic,
      allows anycast to be used even with applications that limit the
      range of the provider's service.

      The use of load balancing is an application that uses this
      characteristic. When the service range is selected by specifying a
      zone, the server only provides service to the AI that exists in
      that zone. The number of zones increases when the service provider
      increases the AR according to the service requirements/demands,
      allowing it to divide zones serviced by only one server into zones
      with two or more servers. As a result, anycast can more
      effectively balance loads because each AI can communicate with the
      corresponding AR.


   o  Characteristic: Automatic Switching to Alternate Routes
      Application   : Service Redundancy

      In unicast, there is only one receiver corresponding to each
      unicast address, so unicast routing forwards the packet to that
      receiver. The packet is unreachable and routing ends when the
      packet can no longer be forwarded, because the destination of the
      packet is uniquely selected by unicast. Therefore, to communicate
      with another node when we cannot communicate with the receiver,
      the necessity for specifying a new destination address falls upon
      the sender.

      Anycast, strives to deliver the packet to the best AR, because it
      is unacceptable to forward the packet to an AR that cannot
      receive. The same anycast address is assigned to interfaces as for
      ARs belonging to the anycast group. In this case, the packet's
      destination node can be changed into another AR because all ARs
      can receive packets with an anycast destination address. The
      packet is forwarded to AR for AI as usual. Then if the node
      detects that the packet is unable to forward it to the specified
      AR, then it tries to deliver it to another available AR. Then, if
      it is possible to switch automatically, the intermediate node and
      AI are both accepted as nodes that detect unreachable destinations
      and the packet is forwarded to another AR. This characteristic
      allows anycast to be used for applications that need to maintain a
      state in which each AI can communicate with any AR.




S. Matsunaga, et al.       Expires August 2005                  [Page 6]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


      Service redundancy is an application that uses this
      characteristic. This application maintains the state in which
      service can be used in the same address by one or more ARs and can
      improve service redundancy. Clients need to search for the address
      of another server and then restart/reestablish communication to it
      when they cannot use the communicating server. On the other hand,
      using anycast, the clients do not need to worry because anycast
      automatically establishes communication with another server using
      the same address.


2.1.3. Intermediate Node View

   In this section, we will describe the anycast characteristics for
   nodes other than AI/AR and the anycast applications that each
   characteristic applies to.


   o  Characteristic: Traffic Distribution
      Application   : Avoid DoS Attack

      Traffic can be distributed when the intermediate node (or, AI)
      retains information from multiple routes to AR in the routing
      table that can be an anycast packet or switching destination, and
      so on. Anycast can manage the band when required.

      Avoiding a DoS attacks is an application that uses this
      characteristic. Even if a DoS attack is undetectable and increases
      traffic to a a single node abnormally, we can prevent it from
      accumulating on a single route by distributing the traffic to two
      or more routes. In addition, after the DoS attack has been
      detected, we can avoid future attacks by forwarding the packet to
      a camouflage server, such as a honey pot rather than rejecting the
      packet altogether.


2.2. Characteristics in Transport Layer and Applications

   In this section, we will describe the anycast characteristics in the
   transport layer for all the applicable anycast characteristics and
   applications.


   o  Characteristic: AR Selection based Connection
      Application   : Multiple Server Access

      As described in 2, data passed from the application is divided in
      the sender's transport layer, and restored in the receiver's



S. Matsunaga, et al.       Expires August 2005                  [Page 7]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


      transport layer. To properly transmit the divided data to the same
      node, a connection is established between both nodes in the
      transport layer. At this time, AI can use AR according to each
      connection by sending a packet to the anycast address that
      establishes a connection. Therefore, using this characteristic, we
      can achieve applications that communicate with different ARs
      according to the connection.

      Multiple server access is an application that uses this
      characteristic. When anycast is used with an application that
      establishes multiple connections to the same unicast address, each
      connection is automatically established with different servers
      that specify the same anycast address. As a concrete illustration,
      when a client browses a web page, they download the html file and
      each picture file from separate mirror servers. As a result, the
      client can use the entire bandwidth, and can download the whole
      web page more quickly than with unicast.


2.3. Characteristics in Application Layer and Applications

      In this section, we will describe the anycast characteristics in
      the application layers for all applicable anycast characteristics
      and applications.


   o  Characteristic: Cross-Platform API with Unicast
      Application   : Easy Installation of Anycast

      Because IPv6 anycast is performed in the IP layer, the application
      layer can communicate with anycast characteristics only when using
      an anycast address instead of a unicast address. The difference
      between anycast and unicast in the application layer is whether
      the destination of the communication is an anycast or a unicast
      address. However, because both addresses have the same format,
      there is no difference in the applications can use these addresses
      with same API to communicate between a single sender and single
      receiver. This means anycast characteristics can be added to the
      existing services being provided by unicast without changing the
      application operation in the application layer.

      Anycast's easy installation feature is an application that uses
      this characteristic. Anycast characteristics can be added to
      services without changing the protocol and operations for the
      various services provided in the application layer. When high
      reliability service is provided for special distribution devices,
      we need to enable the devices and servers to work together.
      However, anycast applications are added to services only if the



S. Matsunaga, et al.       Expires August 2005                  [Page 8]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


      servers use an anycast address to receive packets, while
      performing same operations as the unicast address. Therefore, we
      can complete anycast installation simply by assigning an anycast
      address to the interface of each server. Then, the various
      functions described in this draft can be added to the
      applications.


3. Security Considerations

   This draft does not include any security issues of anycast.  Other
   security descriptions about anycast are shown in [ANALYSIS].







































S. Matsunaga, et al.       Expires August 2005                  [Page 9]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


4. References

   [RFC2460]  S. Deering and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification," RFC 2460, December 1998.

   [RFC3513]  R. Hinden, and S. Deering, "IP Version 6 Addressing
              Architecture," RFC3513, April 2003.

   [ANY-TERM] Hashimoto, M., Ata, S., Kitamura, H., Murata, M., "IPv6
              Anycast Terminology Definition,"
              <draft-doi-ipv6-anycast-func-term-03.txt>,
              February 2005 "work in progress."

   [ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6
              Anycast,"
              <draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt>,
              June 2003 "work in progress."


































S. Matsunaga, et al.       Expires August 2005                 [Page 10]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


Authors' Addresses


   Satoshi Matsunaga
   Osaka University
   1-5, Yamadaoka, Suita
   Osaka,  565-0871,
   Japan

   Phone: +81-6-6850-6863
   FAX:   +81-6-6850-6868
   EMail: s-matung@ist.osaka-u.ac.jp


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

   Phone: +81-6-6605-2191
   Fax:   +81-6-6690-5382
   EMail: ata@info.eng.osaka-cu.ac.jp


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

   Phone: +81-3-5476-1071
   Fax:   +81-3-5476-1005
   EMail: kitamura@da.jp.nec.com


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

   Phone: +81-6-6879-4543
   Fax:   +81-6-6879-4544
   EMail: murata@ist.osaka-u.ac.jp






S. Matsunaga, et al.       Expires August 2005                 [Page 11]

INTERNET-DRAFT       Applications of IPv6 Anycasting            February


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
   http://www.ietf.org/ipr.

   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 ietf-
   ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




S. Matsunaga, et al.       Expires August 2005                 [Page 12]