[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                           J. Bound
IPv6 Work in Progress                      Digital Equipment Corp
                                                         P. Roque
                                           Universidade de Lisboa



   IPv6 Anycasting Service: Minimum requirements for end nodes

                  <draft-bound-anycast-00.txt>



Status of this memo

   This  document  is  an  Internet-Draft.   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.''

   To learn the current  status  of  any  Internet-Draft,  please
   check  the  ``1id-abstracts.txt''  listing  contained  in  the
   Internet- Drafts Shadow Directories on ftp.is.co.za  (Africa),
   nic.nordu.net    (Europe),    munnari.oz.au   (Pacific   Rim),
   ds.internic.net (US  East  Coast),  or  ftp.isi.edu  (US  West
   Coast).

Abstract

   This document proposes a minimum set of requirements for  IPv6
   hosts  in  order to achieve communication with nodes providing
   services  through  IPv6  anycast  addresses.  We   present   a
   mechanism that aims to allow TCP and UDP communication between
   hosts where the packet exchange is initiated through the usage
   of  an anycast address, without requiring modifications to the
   general definitions of the transport protocols.


















Expires January 1997                                     [Page 1]


INTERNET-DRAFT                                          June 1996


Table of Contents:

1. Introduction.................................................3
2. Terminology and Definitions..................................3
3. Anycast address usage........................................4
4. Source Identification Option.................................5
5. Receipt of Source Identification Option......................5
6. Issues for Further Consideration.............................7
Acknowledgements................................................7
References......................................................7
Authors' Address................................................8

















































Expires January 1997                                     [Page 2]


INTERNET-DRAFT                                          June 1996


1. Introduction

   IPv6 Anycast addresses  [RFC-1883]  allow  a  datagram  to  be
   addressed  to  a  group  of  hosts  with  delivery  to one and
   preferably only one semantic. This facility  can  be  used  to
   facilitate  traffic path selection when a group identifies the
   set  of  routers  of  a  particular  traffic  provider.  Other
   possible  uses  of  anycast  addresses  are to provide a "Host
   Anycasting Service" [RFC-1546],  where  a  set  of  hosts  can
   represent   a   particular   service.   While  the  particular
   mechanisms hosts can  use  to  provide  services  via  anycast
   addresses  are  still to be defined, this document attempts to
   define  a  minimum  set  of  requirements   that   should   be
   implemented in all IPv6 hosts in order to use those services.

   The authors view a "Host Anycasting Service" as complementary,
   rather   than  orthogonal,  to  Service  Discovery  mechanisms
   [SVRLOC] since they can be used to provide lightweight service
   access  without  the  need  for  previous  configuration.  For
   instance, a well-known  site-local  address  can  be  used  to
   communicate  with  a  host  that  provides  service  discovery
   services.

   While  it  is  expected  that  the  particular  specifications
   regarding  anycast  address  usage  by application servers and
   routing are  defined  as  extensions  to  IPv6  and  companion
   protocols,  the  authors  feel that mechanisms needed in every
   host should be defined before the massive deployment  of  IPv6
   hosts.

   The problems pertaining to the usage of anycast addresses  for
   accessing application services can be clearly divided in three
   distinct components: procedures for hosts  providing  services
   via  anycast  addresses,  routing,  and  procedures  in  hosts
   accessing services via anycast. This document  focuses  solely
   on  the  later problem, as the authors consider that it can be
   solved independently of the previous two.




2. Terminology and Definitions

     IP

             Internet Protocol Version 6 (IPv6).  The terms  IPv4
             and  IPv6  are used only in contexts where necessary
             to avoid ambiguity.

     Anycast Address

             An identifier for a  set  of  interfaces  (typically
             belonging  to different nodes).  A packet sent to an
             anycast  address  is  delivered  to   one   of   the
             interfaces identified by that address (the "nearest"
             one, according to the routing protocols' measure  of
             distance).



Expires January 1997                                     [Page 3]


INTERNET-DRAFT                                          June 1996


     Communication

             Any packet exchange between nodes that requires that
             the address of each node used in the exchange remain
             the same for the duration of  the  packet  exchange.
             Examples    are    a    TCP    connection   or   UDP
             request/response.




3. Anycast address usage

   Anycast addresses are restricted to be used as the destination
   address   of  a  datagram.  This  requirement  is  imposed  by
   necessity to determine the originating node of a  datagram  in
   error   conditions.   Current  transport  protocols  [RFC-768]
   [RFC-793] rely, however, on  the  source  address  of  the  IP
   datagram to demultiplex incoming packets.

   Independently of how the network delivers datagrams  addressed
   to  an  anycast  group,  it's  usage  in  normal communication
   depends on  the  ability  of  a  host  to  accept  a  datagram
   originating  from  a  distinct unicast address as a reply to a
   packet sent to an anycast address.

   Also, as anycast addresses are  syntacticly  indistinguishable
   from  unicast  addresses, the client of a service provided via
   anycast should not  need  explicit  knowledge  of  whenever  a
   particular  address  is  unicast  or  anycast,  much  less the
   particular group membership for a particular anycast address.

   To fulfill the above stated goals,  the  authors  propose  the
   definition    of    a   Destination   Option,   named   Source
   Identification Option, to dynamically inform client hosts that
   a  particular  communication  initiated  through the use of an
   anycast address should proceed  with  the  use  of  a  unicast
   address of one of the anycast group members.

   This option requires no  processing  from  the  network  layer
   other  than  encoding  and  decoding  the respective extension
   header and MUST be passed transparently from the network layer
   to  the transport layer.  The transport layer MAY then take in
   to account this  information  when  demultiplexing  datagrams.
   Section  5  of  this  document  discusses  in  more detail the
   expected behavior of  transport  protocols  when  receiving  a
   datagram with this option.

   Although  this  document  does  not  pretend  to  specify  the
   mechanisms  to  be  used  by hosts providing a service through
   anycast addresses, we note that a reply to a datagram received
   for  an anycast address will not be correctly interpreted if a
   Source Identification Option is not present.







Expires January 1997                                     [Page 4]


INTERNET-DRAFT                                          June 1996


4. Source Identification Option

   The Source Identification Option provides  a  mechanism  hosts
   can  use  to  inform  it's  communications peers that datagram
   demultiplexing by transport protocols should be performed with
   respect to the identifier present in this option.  This option
   is encoded in the Destination Options Extension Header  of  IP
   datagrams as option type TBD.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Option Len   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Identifier                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      8-bit identifier of the type of option.   The  first  three
      bits  of  the  option are 000, indicating first that a node
      receiving the option  may  discard  the  option  and  still
      process  the rest of the packet, and second that the option
      may not be modified enroute.

   Option Length

      8-bit unsigned integer.  Length of the Option Data field of
      this option, in octets.

   Identifier

      128-bit IP  address.  The  anycast  address  known  to  the
      receiver  of  the  datagram as the destination address of a
      particular communication.




5. Receipt of Source Identification Option

   As  previously  stated  in  section  3  of  this  document,  a
   transport protocol MAY take in account the identifier received
   in a Source Identification Option  for  purposes  of  datagram
   demultiplexing.

   TCP [RFC-793] communication depends on the knowledge of  state
   information   by   communicating   peers,   initialized  on  a
   synchronization  period  referred  to  as   the   "three   way
   handshake".  In  terms of access to a service provided via the
   use of anycast address, procedures must be provided to  insure
   correct synchronization between the client and a member of the
   anycast group, and to maintain  the  same  communication  end-
   points during the duration of the connection.


Expires January 1997                                     [Page 5]


INTERNET-DRAFT                                          June 1996


   An IP node performing a TCP active open sends a segment to the
   network   addressed   to   the   destination  address  of  the
   connection. It then expects to receive  a  segment  from  this
   address  confirming  or rejecting the connection establishment
   request. When the destination address of the connection is  an
   anycast  address  this  condition  cannot  be  met  since  the
   responding host  may  not  send  datagrams  using  an  anycast
   address  as source address in datagrams. In this scenario, the
   responding node should use the Source  Identification  Option,
   with the destination address on the received syn segment as an
   identifier, in order to inform the node performing the  active
   open that the segment is related to this communication.

   A TCP performing an active open MAY then use  the  IP  address
   present on the Source Identification Option to demultiplex the
   incoming segment. If the segment  causes  TCP  to  proceed  to
   SYN-RECEIVED  or  ESTABLISHED  it  MUST then consider that the
   destination address of the connection is  the  source  address
   present on the received segment.

   Note that for TCP, the  receipt  of  a  Source  Identification
   Option  is  meaningful  only  when  the  segment  refers  to a
   connection on  the  SYN-SENT  state.  Otherwise,  this  option
   should be ignored by TCP. This will cause the received segment
   to be interpreted as a segment to a connection in  the  CLOSED
   state,  assuming that no communication is taking place between
   the same address/port pairs.

   Datagram exchanges  using  UDP  [RFC-768]  constitute  a  more
   problematic  case.  While  UDP  is itself connectionless, many
   applications using this transport protocol require state to be
   maintained.  This  implies that while some applications desire
   to communicate with any of the members of the  anycast  group,
   others  can  only  tolerate  anycast  initiated  communication
   requiring subsequent packets to be delivered to the same host.

   Since the appropriate semantics of anycast  address  usage  on
   UDP   communication   are   application   dependent,   a   UDP
   implementation should only  take  in  to  account  the  Source
   Identification  Option  when this behavior has been explicitly
   requested by the application. When such option is selected  by
   the   application   incoming  datagrams  containing  a  Source
   Identification Option shall be demultiplexed and delivered  to
   the  application  using the identifier contained in the option
   as the source address of the datagram. Otherwise,  the  Source
   Identification   Option   should   be   ignored   by   a   UDP
   implementation.

   As UDP already provides  a  means  for  determination  of  the
   originating  node  of  a received datagram by applications, no
   further modifications are required to allow the  use  of  this
   service with the desired semantics.








Expires January 1997                                     [Page 6]


INTERNET-DRAFT                                          June 1996


6. Issues for Further Consideration

   Security considerations.

   Receipt of a RST segment carried in a  datagram  containing  a
   Source Identification Option.

      According  to  [RFC-793],  a  segment  containing  a  valid
      acknowledgement  value  and  the  RST  bit  on  for  a  TCP
      connection in SYN-SENT state, will cause the connection  to
      enter  the  CLOSED state. In the specific case of an active
      open to an anycast address, this abortive termination could
      be  caused  by a failure from one of the group members. The
      appropriate action to take in this case  is  an  issue  for
      further study.




Acknowledgements

We would like to thank Dan Harrington and  Mike  Shand  who  have
provided comments and review of an earlier version of this work.




References

[RFC-768]
    J. Postel, "User Datagram Protocol", STD-6, August 1980.

[RFC-793]
    J. Postel, "Transmission Control Protocol", STD-7,  September
    1981.

[RFC-1546]
    C.  Partridge,  T.  Mendez,  W.  Milliken,  "Host  Anycasting
    Service", Informational Request for Comments, November 1993.

[RFC-1883]
    S. Deering and  R.  Hinden,  "Internet  Protocol  Version  6,
    (IPv6) Specification" Proposed Standard, December 1995.

[SVRLOC]
    J. Veizades, E. Guttman, C. Perkins and S.  Kaplan,  "Service
    Location  Protocol", Internet Draft, March 1996, <draft-ietf-
    svrloc-protocol-12.txt>












Expires January 1997                                     [Page 7]


INTERNET-DRAFT                                          June 1996


Authors' Address

    Jim Bound
    Digital Equipment Corporation
    110 Spitbrook Road, ZKO3-3/U14
    Nashua, NH 03062
    Phone: (603) 881-0400
    Email: bound@zk3.dec.com

    Pedro Roque
    Departamento de Inform'atica
    Faculdade de Ciencias da Universidade de Lisboa
    Campo Grande - Bloco C5
    1700 Lisboa, Portugal
    Email: roque@di.fc.ul.pt













































Expires January 1997                                     [Page 8]